Jon Atkinson

Distrohopping, and some thoughts on minimalism

I’ve been going through a long period of re-evaluating my computing choices; probably for a year or more now. I feel that I’ve gone deep down the rabbit-hole, and I’ve learned a lot. This article presents some notes on the experience and some more fundamental thoughts about computing.

First, some history. I’m a long-time Linux user. I was lucky enough to grow up immersed in web 1.0, and I spent my teenage years freely associating with the online geek communities of the late 90’s are early 2000’s. This was a wonderful formative experience for me, and I was exposed to the Linux scene of the time; RedHat pre-Fedora, SuSE, Slackware, and the online communities like Slashdot and Kuro5hin.

At some point, I learned enough about configuring systems and compiling software that I ran a Linux-From-Scratch machine on my desktop (Pentium II, 200mHz, 32Mb RAM) for a year or so. I never really learned C, but I understood enough about how the kernel interacted with libraries and applications. At the time Linux was a small enough system to understand.

When I left school, my time became slightly more valuable, so computing on a system like LFS, with it’s very high maintainance costs, wasn’t viable any more. At the time I landed on Debian, which I ran for a few years, and then Ubuntu. This was a very exciting period in the Linux timeline, but also where my understanding of the software which is running on my computers because slightly more abstract. When using LFS, I understood each process in the list; I’d probably compiled the software by hand! As Linux evolved into a genuine desktop experience, it because harder to understand the system as deeply as I once had. In the dash to emulate and surpass the Windows desktop experience, there was an explosion in techniques and systems, led by GNOME, FreeDesktop, Xamarin and suchlike.

Without the time to dedicate to deep exploration, elements of the systems which I ran became black boxes. When dealing with complexity, it’s natural to seek abstractions, and at the time, exploring the real details became overwhelming. I understood well how to operate these systems; I remained confident in my ability to configure and manage systems, but I was generally interacting with systems using their exposed surfaces; init scripts, a package manager, then latterly configuration management tools.

To be clear, I don’t resent this additional complexity. I understand that it’s a natural evolution, and as Linux reached maturity and wide commercial acceptance, the knowledge which I did have served me very well. My teenage years were not wasted.

Then, early in my career, with one of my early paycheques in-hand, I bought one of the early PPC Powerbooks. This was right at the inflection point where OSX took off. It gained popularity rapidly, among people who I respected. It was so common to hear people exclaim the virtues of Apple: the polished desktop OS with tight hardware integration which still had all that UNIX underneath. I remember seeing ‘real hackers’ (the paunchy, bearded types who built the early internet, wrote HOWTOs, and understood Usenet) carrying Powerbooks. Does anyone remember the “Real UNIX” Apple adverts?

I realise looking back this was probably investment bias and I only saw the Apple users I wanted to see, but it really felt like an important sea-change. A few years later all the hackers at a given conference would have Apple hardware, something which continues today.

Embracing OSX, even with it’s UNIX underpinnings, led to further distance to the inner workings of the software I used. Not only was the system foreign to me, it encouraged applications to hide their inner workings. This led to a wonderful desktop experience, one which helped me be very productive, but over time my connection with the underlying operating system and hardware atrophied.

As my career began to develop led to demands for efficiency, and I was managing more and more systems. This need for efficiency meant that it was more effective to interact with these systems in an abstract manner; package management via a tool like Puppet/Ansible/Chef. When configuration and service management are lines in a DSL, you don’t really need to understand what is happening under the hood.

This leads to an interesting aside: I had no opinion whatsoever on systemd. This is a testament to the really great engineering work done by Debian; throughout a period of significant change in the Linux underpinnings, the manner in which I interacted with systems didn’t change at all. I could still (to this day) login to a system and issue /etc/init.d/service action. It was more likely that I would change a line in my Ansible scripts, but in the event I did SSH into a server, the old interfaces maintained their predictable behavior. As some sections of the Linux community heated to the point of bitter conflict, nothing changed for me. It was a strange situation.