Resetting My Running

2017 was admittedly not a good year for running. Mumbai is a great city, but I couldn’t find the time or the space to get my running in the rhythm it used…

2017 was admittedly not a good year for running. Mumbai is a great city, but I couldn’t find the time or the space to get my running in the rhythm it used to be in the previous season. I loved the long runs in Mumbai. It was amazing to run on Marine drive or to run with the Mumbai Road Runners. But the daily easy runs never happened and I fell off the wagon. This year, the first book I finished reading is Daniels’ Running Formula. If you’re starting out running or somewhere in the mid-level where you feel stuck, I fully recommend you read this book. It’s oriented towards fast runners as well as beginners. It gives you a great amount of foundational knowledge of running and workouts. For instance, it explains what the different kinds of workouts do and how they help you become a better runner. This means you know exactly why you’re doing a specific speed workout.

I’m resetting my running training from this month. I’ve gained weight almost to the exact point when I first finished the C25K plan. Instead of restarting C25K, I’m starting with Jack Daniels’ White Plan. It’s meant for people who’re absolute beginners. I’ve checked my VDOT and I’m starting with a VDOT of 25.6.My goal this year is to build this up. I’m going to be running ADHM, but I plan on racing very little otherwise. I’ll be doing 10Ks if I’m racing. I plan to work through a few of the beginner plans to build up my mileage and VDOT. This year, I’m focusing my running on actually being fitter and less to do with running running races or pace. I want to build a habit of waking up every day with a run.

The White Plan has me running easy for the most part with walking breaks in between at a pace that’s getting more and more comfortable as I keep repeating the workout. This year, I have a modest goal, set a habit of running every week 🙂

Building Gluster with Address Sanitizer

We occasionally find leaks in Gluster via bugs filed by users and customers. We definitely have benefits from checking for memory leaks and address…

We occasionally find leaks in Gluster via bugs filed by users and customers. We definitely have benefits from checking for memory leaks and address corruption ourselves. The usual way has been to run it under valgrind. With ASAN, the difference is we can compile the binary with ASAN and then anyone can run their tests on top of this binary and it should crash in case it comes across a memory leak or memory corruption. We’ve fixed at least one bug with the traceback from ASAN.

Here’s how you run Gluster under ASAN.

./autogen.sh ./configure --enable-gnfs --enable-debug --silent make install CFLAGS="-g -O0 -fsanitize-recover=address -fsanitize=address" -j 4 

You need to make sure you have libasan installed or else this might error out. Once this is done, compile and install like you would normally. Now run tests and see how it works. There are problems with this approach though. If there’s a leak in cli, it’s going to complain about it all the time. The noise doesn’t imply that fixing that is important. The Gluster CLI is going away soon. Additionally, the CLI isn’t a long running daemon. It’s started, does it’s job, and dies immediately.

The tricky part though is catches memory you’ve forgotten to free. It does not catch memory that you’ve allocated unnecessarily. In the near future, I want to create downloadable RPMs which you can download and run tests against.

The configuration I’ve setup lets you continue to run the program after the first memory corruption by setting the environment variable ASAN_OPTIONS=halt_on_error=0. If you find an existing leak you are not interested in fixing, you can suppress it. More information on the wiki page

2017 Year in Review

Another year has flown away and we’ve moved cities again. I don’t think Delhi has ever felt as much at home as it does right now. I somehow missed living in Delhi quite a lot. It has a lot of problems, but it still remains my favorite…

Another year has flown away and we’ve moved cities again. I don’t think Delhi has ever felt as much at home as it does right now. I somehow missed living in Delhi quite a lot. It has a lot of problems, but it still remains my favorite city.

Studies: This year, I’m going to aim to finish my BSc coursework. I really really want to finish the coursework by Dec 2018. This is going to take priority over everything else. I’ll be doing less racing and less traveling this year.

Accounting: Last year, I paid for YNAB and that’s been the best decision ever. I’ve managed to set apart more money for real expenses and save more money. It’s worth every penny I paid for the software.

Speaking: I spoke at even more conferences this year. Looking back I spoke at 4 conferences this year. I’m unhappy with all but one. I’m traveling less this year, so I’ll be aiming for writing talks for local events.

Learn C and Javascript: I’m better at C than I used to be. I can now debug some simpler pieces of code. I haven’t yet written anything that I expect to be in production. I’m contemplating playing with GTK to produce something for fun. I’m needing JS less these days. Golang and Groovy look like things I’ll use on a more regular basis.

Cutting Down Servers: I’m down to killing my oldest two servers. They both run Ubuntu 12.04 so it’s about time I changed them. They run a few apps in production, so it’s going to take me some time to get there. This time I’ve got a migration plan like I would for a work server migration 🙂

Writing: I’ve been trying to write 750 words for the last year on and off. If I miss out a day, then I tend to lapse into laziness and not continue for the rest of the month. This month, I finally finished an entire month. I wrote 750 words every day in December, totaling to 23,684 words this month. It’s helped me rant about frustrating topics and write a few blog posts in advance. I often use my daily writing as a rough drafts for future blog posts.

Reading: I wanted to read more books this year, but that hasn’t happened, because I keep looking at it as a big goal. This year, I learned to look at it as reading about 20 to 30 pages every day. That means I finish at least one book every 2 weeks.

Fitness: This year has been pretty bad for my running. I’m currently at my worst fitness levels since I started running. It’s going to be a slow and painful few months of training. I’ve discovered the joys of afternoon runs for winter months. I work from home, it makes sense to run in the afternoon. Most public parks are closed at that time, so I’m stuck running inside the gated area where we live.

I got my cycle serviced the other day. It now runs pretty smoothly and I’ve been riding a bit. I want to be riding about 100 km to 200 km a month. It’s a trivial amount of distance for most people. But for me, that means taking a weekend out to do long rides and a few mid-week rides too. I plan to cross train along with running.

I want to get fit enough for hiking and go on at least one hike this year. I want to do one hike that’s a few hours long and then a longer few-days worth hike. Those both should give me more kickstart into getting into a better shape.

I’m using my shopping instinct to control my habits. I’m only going to get a new shoe for long-distance running if I hit 500 km on my regular ones by 1st May 2018. I’ll give it a margin of error of about 10 km. That’s actually not a big goal. I need to be consistent at my training. I’m only going to buy any sort of cycling equipment if I manage to cycle 500 km in 2018. I’m not going to buy new books until I finish the short list I’ve made for the next year. I can read any of them in any order though. As soon as that’s done, the flood gates are open for new books.

Getting Better

Across Nov, Dec, and Jan, I spent a significant amount of time in a hospital for a family emergency. I was working, but I was also reading while waiting…

Last year, across Nov-Jan, I spent a significant amount of time in a hospital for a family emergency. I was working, but I was also reading while waiting around. One of the books I read during this time was “Better” by Atul Gwande. The book talks about certain aspects about improvement that I’ve also read in Swtich.

An empty hospital floor

The chapter titled “The Bell Curve” is one my favorite chapters. Dr. Gwande talks about cystic fibrosis treatments across the US. This is how he described the doctor at the top treatment center:

He believed that excellence came from seeing, on a daily basis, the difference between being 99.5{13371f13f0bf161e7595c2ac5df92e005bed3de1d132ef646d0a44f3a1a9ee62} successful and being 99.95{13371f13f0bf161e7595c2ac5df92e005bed3de1d132ef646d0a44f3a1a9ee62} successful.

It looks like they’re almost the same but over the course of a month, it adds up. Over the course of a year, it adds up even more.

A line from the conclusion of that chapter:

Even doctors with great knowledge and technical skill can have mediocre results; more nebulous factors like aggressiveness and diligence and ingenuity can matter enormously.

As a sysadmin and software engineer, my success does not depend on my skills alone. I work in a team. I can only be successful if I communicate effectively and work with the team. On that note, I’d also recommend the post “What we can learn from the Mayo Clinic” from The Farnam Street blog.

Image credit: Naoki Takano hospital (license)

Static Analysis for Gluster

Static analysis programs are quite useful, but also prone to false positives. It’s really hard to…

Static analysis programs are quite useful, but also prone to false positives. It’s really hard to keep track of static analysis failures on a fairly large project. We’ve looked at several approaches in the past. The one that we used to do was to publish a report every day which people could look at if they wished. This guaranteed that nobody looked at it. Despite knowing where to look for it, even I barely looked at it.

The second approach was to run them twice, before your patch is merged and after your patch is merged in. If the count goes up with your patch, the test fails. This has a problem that it doesn’t account for false positives. An argument could be made that you could go fix another static analysis failure in your patch. But that means your patch now does two things, which isn’t fun for when you want to do a backport, for instance. Or even for history purposes. That’s landing two unrelated changes in one patch.

The approach that we’ve now gone with is to have them run on a nightly basis with Jenkins. Deepshika did almost all the work for this and wrote about it on her blog. It has more details on the actual implementation. This puts all the results in one place for everyone to take a look at. Jenkins also gives us a visual view of what changed over the course of time, which wasn’t as easy in the past.

She’s working on further improving the visual look by uniting all the jobs that are tied to static analysis. That way, we’ll have a nightly pipeline run for each branch that will put all the tests we care about for a particular branch in one place.