Hell Oh Entropy!

Life, Code and everything in between

About Me

This used to be a conventional resume but given that LinkedIn has pretty much all the information one would need (and because I’ve realized that HR doesn’t visit websites) this page is now a story. It is a long boring and somewhat personal story of my life at work, life in the FOSS world and life in general, so you’ve been warned; there’s nothing of importance here that you would miss out on. It is for myself to remind me how far I’ve come when I feel like I’ve achieved nothing in life, and maybe for clueless younglings driven by the idea of average people getting lucky and landing unbelievable opportunities.

I am Siddhesh Poyarekar, a Free and Open Source systems software hacker. I have been an active contributor to the GNU toolchain and have a keen interest in low level programming. I have been working on software since 2004, beginning with internships and then full time jobs at a couple of popular outsourcing companies in India (also known as outsourced sweatshops, job stealers, etc. depending on who you ask) for the initial years of my career, mainly because they are the most lucrative jobs in India. I am not and never was ‘passionate’ about software or technology; it is perhaps my curious nature, OCD of not giving up on problems and in fact a bit of a fetish for seemingly unsolvable problems that seem to keep me going. And of course, the money. Software jobs pay ridiculously more than anything else in the country and luckily for me, software feeds my OCD just fine.

I do however care deeply about software freedom and in general, knowledge freedom; whether I am passionate about it or not I am yet to find out, even after working on Free Software for over a decade.

Beginnings in FOSS

My introduction to CS was accidental; I had a deep love for physics and mechanics and that’s what I wanted to do all my life. I failed to qualify for IIT (twice) and went into a year long depression (because hey, there’s no life beyond IIT right?), landing into a BSc CS course that I didn’t quite choose for myself. In the final year of that course a certain quasibaba was our professor for the Linux course paper and the just graduated FOSS militant introduced us to the course with Revolution OS. I was hooked. I pooled in money with a dozen friends (most of us were piss poor) to buy a set of Debian woody CDs and thus started my journey of inflicting pain upon myself through rebuilding kernels, reading manuals and staying up nights. I still wasn’t doing anything worthwhile, this phase only ensured that Linux was my default OS and also that of my family.

In 2006 I got my first full time job (I did an MCA after my BSc CS, which was only important because I met my wife Nisha there. That’s it. It was a waste of three years otherwise) and after a pretty intense training session in Coimbatore that I did very well in, I had expected to land in an onsite project to earn lots of money (did I mention that I was in it for the money?) but that was not to be. To make things worse, the project I was assigned to was run like a fiefdom and I had a hard time toeing the line all the time, which meant that I was not enjoying the one thing I thought I was meant to do back then, earn money. And then came ayttm.

Ayttm: A case study in dead projects giving life to careers

This was not the first time I had encountered Philip Tellis. He had come to my college many years ago for a LUG meet and talked about CVS. I had absolutely no clue what he talked about and had dozed off during his session. However when he sent an email to the ILUG-BOM list with a request for volunteers, that became my escape out of my misery. That was not the first time I had heard of ayttm either. I had tried the ayttm instant messenger a year ago to replace Gaim and that thing had crashed on me. I dutifully filed a bug report on sourceforge but when Philip asked me for a stack trace, I abandoned it because I did not know what a stack trace was. Yes, I was a CS graduate who had not heard of stack traces.

I spent the next couple of years pouring all of my free time (and sleep!) into ayttm for some completely unknown reason. I had barely any users (barring the Puppy Linux users) and there was obviously no compensation either, just blind hacking. I learned how to really program in C, makefiles, reverse engineering protocol packets, socket programming, chat protocols and a number of other things by just blindly hacking away at ayttm for some years. Maybe one solace was that it was an escape from an otherwise complete absence of a life, given that I’m not much of a socializer and Nisha and I had jobs in different cities and we could meet only every other week. So I guess ayttm made sure I didn’t go completely crazy…

While ayttm did not compensate me financially, it was responsible for the next big thing that happened to me; I got hired by Red Hat.

Coloured Head Gear

It was not a position among the many FOSS heroes in Red Hat that get talked about and worshipped in the popular FOSS community. It was technical support. I was one of many picking up support tickets coming over email and solving people’s issues while making sure that they don’t get too pissed off at us, something people found easier to do when they saw an Indian name on the ticket. I had to move to a different city for a pay raise that did not compensate for my living rent, and nope, it was not the city that Nisha lived in. So there was more time to hack on FOSS. And being in Red Hat, there’s a lot more time to hack on FOSS because you’re living and breathing FOSS every waking working hour. I could not let this opportunity pass.

I worked on tickets night and day, on tickets that were not even supposed to be in my area of speciality, all because I knew how to read code and more importantly, because I taught myself how to read core dumps, sometimes without debug information. I was part of 6 different speciality groups at the end of the first couple of years and when it was time to be promoted to L3 engineering (aka SEG or support engineering group), I was wanted in 4 of those groups. It felt great to be wanted, to be accepted as one of their own despite being in a completely different geography. Oh yeah, I should mention that having SEG in India was not the norm, I was one of the earlier few to make that transition, surely among the first five.

While I was all over the place debugging problems and writing fixes for RHEL and Fedora in different specialities, one theme was recurring: I loved digging deep into systems. This could have gone the security way because I was doing quite a bit of reverse engineering of binaries and building weird network packets to reproduce issues but my distaste of the security community in India (Ankit Fadia ftw!) meant that I did not really think of it too seriously and instead went the way of toolchains. And as luck would intervene again, it was around the time that the glibc project was going through a turbulent time with Ulrich Drepper leaving the community. The Red Hat fort was being held firmly by Jeff Law while they looked for someone to fill an empty position of a glibc engineer. I was helping out a bit on the internal Red Hat trees and all the while struggling to get my first patch accepted into glibc upstream but I did not for a second think that I could fit into a developer role. However on Nisha’s insistence I dropped a sheepish email to Jeff on the lines of “Surely you don’t think I fit this position, do you?”.

And he replied! Not only did he reply, he said that I should absolutely apply and that he would have interviews conducted, etc. It went through like a breeze and when I was offered the job, there was no question in my mind what I would do. I was finally part of the fabled Red Hat engineering team. THE toolchain team! OK not quite sure if I belonged but hey, I was there!

Dream Team

On pretty much the same month that I joined the toolchain team, another gentleman joined the glibc team in Red Hat, his name is left as an (extremely easy!) exercise to the reader if they have managed to reach this far in this text! Him and I became the glibc team and it was the best work partnership I had (or still have had, as on the day I wrote this) in my career. The larger toolchain team wasn’t any less amazing. It had legendary names that gave no clue of their legendariness when you spoke to them. Every engineer humble, helpful and approachable. It’s the kind of team that everyone dreams of but few get to work with. This was the team I grew in as a glibc developer to a maintainer. This growth came alongside the growth of the glibc community (did I mention before that I’ve been very lucky?) and despite being a prolific committer, I wasn’t too sure of my capabilities, mainly because I never really learned CS the right way, something one misses when working on something as core as compilers. I had an intuitive understanding of a lot of things through experimentation but not much by way of formal theory. I had to step out of what was becoming a comfort zone and get deeper into computer architecture and the Linaro opportunity came in at exactly the right time. Yes, I’m insanely lucky.

Going Green

If Red Hat was where I got a strong footing as a FOSS developer and maintainer, Linaro was where finally felt the part. Being a much smaller company than Red Hat, I felt much more part of the organisation than being part of an Indian offshoot; whatever one did, being part of any company’s India organisation was immediately met with ‘meh, outsourced’. I was literally the first person in India to move from the tech support organisation in into the RHEL engineering organisation, so the presence of a RHEL/upstream engineer in India was not a common occurrence until Gluster was acquired. I had to step out of the ‘outsourced’ shadow even if it did not technically apply and Linaro was that opportunity.

I finally felt part of a global community, felt equipped to discuss with and sometimes even disagree with developers around the world as an equal and not as an unsure offshore engineer trained to follow whatever their western counterparts told them. I learned new things every day (working in tiny companies is amazing!), technically as well as a leader of a team of toolchain hackers. I remained involved in glibc and also expanded my experience into many different projects as I helped management with project proposals and sometimes in the process, even fixed bugs in those projects. A sequence of events even led me to fork and maintain moonjit for a while, but I eventually gave it up. I ended my involvement with Linaro with perhaps the most bleeding edge project I had worked on, i.e. the Arm Morello board. I wrote the GNU assembler and linker implementation for this new experimental architecture and in the process, learned a ton about security and what it entails in the hardware, OS, runtime and compiler contexts.

Returning Home

Small companies are amazing for the amount of exposure one gets but they come with their own challenges. One such challenge I faced was in 2019 when I was going through a slightly rough time, looking for a project to work on. The timing of it all was superb as I happened to talk to friends at Red Hat at that precise moment. One thing led to another and we were talking about how I could return to Red Hat. Through all those discussions I did not give too much thought to exactly what I was working on because my main interest was going back to the team I loved and admired so much. I absolutely loved Linaro (I still do) but I was missing a sense of purpose. I was also finding it difficult to drive myself; being locked up at home through the pandemic had probably gotten to me.

All this contributed to me returning to Red Hat. I only really started reading about my responsibilities once I had joined. That’s when I realized that I’ll be looking at toolchain security, an area that I had recently gained interest in thanks to Morello. The fast pace and collaborative environment in Red Hat was just what I needed to get my sense of purpose back. This was different from my last stint at Red Hat though - I was now one of the senior folks and was supposed to help chart the direction of technology to improve the state of distribution and software security through improvements in the toolchain. This is where I am today, working with friends on projects that I feel strongly about and convinced that I’m helping change the world, one bounds check at a time.

Ways to get in touch

LinkedIn is where I am more official because those that write paychecks still expect that and like I said before, I came here for the money ;)