First and foremost, this is not an article designed to convince you to use Linux. Frankly, I don’t think it’s entirely beneficial to try and convince you of that much. Rather, I want to take a look at the things that make Linux and other Open Source or otherwise “niche”¹ operating systems appealing to myself and folks with similar sensibilities. I have been using Linux for well over a decade at this point. Earlier posts on this blog reveal as much, and I’ve seen the landscape of desktop AND server linux change in the time I’ve been involved significantly. Regardless of the changes seen over time, however, some key facets have remained true – but we’ll get to that.

First, some background. The first computer I remember using was an old Apple laptop, I think a PowerBook Duo or 165, though I can’t really remember and at this point it has certainly been e-cycled. It was my dad’s in college and had sat unused in the closet space for decades. At some point I had dug it out and begun aimlessly clicking away at the icons on-screen. Not much really emerged from this, aside from a moderate appreciation for trackball mice, but it serves as a starting point. Some time later, my dad showed me emacs. At the time, pre-wikipedia mind you, I assumed it was named that because it was a thing all mac computers had. I didn’t use emacs for file editing or anything like that, but I did spend plenty of time playing tetris within emacs. This again isn’t particularly impactful on its own, but it did get me comfortable with the navigation methods older software like emacs used. Not long after this point, I began to poke around on the command line to play with the “say” command that was present on MacOS at the time (it might still be, I haven’t checked), and over time wound up writing some very basic bash scripts, with the help of a pocket guide I’d pilfered from the bookshelf in my dad’s office. Little by little I became more and more acquainted with the command line and some basic POSIX-y concepts. At some point, I asked my dad for a video game – probably Halo if I had to guess, considering gaming on Mac at the time was pretty limited – but was instead given a book on Ruby² and told to “make one myself”. This resulted in a few text adventure type games and some basic hangman and tic-tac-toe type programs, but before long I was pirating flash³ to be able to make games with graphical elements. After quickly learning that I do not have much in the way of capacity for visual design, I shelved those aspirations and for most of the rest of middle and high school, programming in general.

Fighting for Control

At some point around middle school, my parents saved up enough to get me a Macbook for christmas. It was one of those glossy-white ones that would accrue a much less appealing brownish-grey tarnish by nature of, y’know, being a thing fingers need to touch. My parents set up the basic apple parental controls on it and gave it to me to be on my merry way. But, although I wasn’t writing much code at the time, I was certainly still a power user of sorts and more than that, someone who spent a lot of time on the computer. So, the parental time limits set up simply would not do. At first, I would do a little social engineering, albeit at the time I didn’t know that term, to gain access to the parental account with elevated privileges (and without time limits). However, this was not a perfect solution since any time the computer would be without interaction for too long, or would restart, that access was lost. Something else was needed to gain full control. Enter: the recovery “disk”. See, a computer’s security is really only as good as your knowledge of its access points. Previous versions of MacOS had required a physical recovery disk to be inserted in the case that system repair needed to be performed. However, as the CD was becoming increasingly less relevant and storage space more available, newer versions of MacOS set up a partition on disk that held the recovery image instead. In case of emergency, an administrator would simply need to boot the machine into single-user mode and mount that partition in order to run whatever recovery tools were needed. Ideally, this would be paired with a firmware password lock on an adminstered machine such that, the non-admin user could not boot into recovery or single-user modes without a password⁴. My parents did not know or did not think to set this password, because once I had discovered the information, that computer was mine. I mounted the recovery parition, escalated my user permissions, and from that point on my parents just about stopped trying to set parental controls on my computers.

This, perhaps, was the first time I really internalized the value of having direct, system-level control over a computer. The ability to boot into a limited but functional single-user context and fix things on the machine was not something I would have encountered had I not been trying to circumvent parental controls⁵, I’m not sure I would have had that intrinsic link formed in my head between system interfaces and making the computer do what I wanted. It might be overly poetic to say that it was the spark that made me who I am and turned me into some huge Linux nerd, but it definitely stuck in my head. As I got into High School and then College, I became more and more opninionated on how my computer should be. At some point, I installed Linux Mint onto the iMac I had been using, which at that point had started to show its age a bit. It brought the machine back to life. With it brought a newfound interest in the tools I now had at my disposal.

In that era of my life, I was particularly into anime, and on more tha one occasion ran into issues with subtitles not being able to render properly, or causing artifacts on-screen, or else mucking things up in some odd way. I was dual-booting Windows 7 and Linux, and on the Windows side of things would regularly encounter issues with VLC and MPCHC(+cccp), that would cause a file to just refuse to play properly. However, out of curiosity one day I opened the terminal, cd’d into the directory that had one of the offending video files, and just tried to play it with mpv. To my surprise and delight – it just worked. No configuration, no community codec packs, nothing. Just mpv foo.mkv and hey presto, a heaping helping of anime schlock. Likewise, for a number of random regular tasks, I began to find that the navigation from menu to submenu to submenu of submenu to dialog box pattern so common on windows and to an extent MacOS began to irk me. On Linux, many of these things could be accomplished with a single, simple command. I did not understand why these things needed to be overcomplicated.

The Concept of Complexity is… Complex

Talking about complexity in computer systems is a weird thing. There are various places where complexity can appear, and often when complexity is reduced in one area it is increased in another. Abstraction to user interface, for instance, can obfuscate or complicate access to those functions. Likewise, having a “simple” command-line tool to perform an action can complicate access to that action for those who do not interact with the command line. There is a real value to reducing complexity in either of these vectors. It is not necessarily an implicit truth that working towards visual simplicity hampers functional simplicity and vice versa, but it often seems to work out that way in my experience. Why is that, though?

For my money, I think a large component of the complexity User Interfaces can bring about when command line interactions are more “simple” (don’t worry, I’ll get to the concept of smiplicity too) has to do with how we categorize the various tasks those command line tools must do. It is easy, for me, to remember that cp will copy a file from one place to another. All I need to do is type cp myfile some/path/myfile and I’ve copied a file. However, if we were to implement this in a graphical interface, say, a file browser, you need to handle a lot more considerations.

• What file is being referred to? (selection state of a file or directory)
• What kind of operation is this? (a file copy operation might be, rightfully, categorized under a ‘file > copy’ submenu)
• Where does this file need to go? (now we must open a new file browser to allow the user to naviagate to the path they wish to copy the file to)
• What kind of file is this? (some files may not be copied, say, virtual files. Additionally, directories can’t just be copied on their own, they need to be recursively copied)

These are things which complicate the otherwise ‘simple’ task of taking a file, reading its content, and outputting that content to another place⁶. That all represents a kind of complexity that emerges from needing to both translate user expectations (for instance, a user in a file browser isn’t going to expect some additional “copy recursively” option) to function calls, as well as presenting those actions in a way that is generally accepted as being “idiomatic”. A “copy” option being under, for instance, “help”, would make little sense to an end-user. Interactional complexity is incredibly difficult as a concept and there is a reason I mostly write system code. I am bad at it.

On another side of things, there’s informational complexity. The amount of information required to understand and interact with a system can be quite high, and in many cases, the “command line” way of doing things at the very least feels like a high degree of informational complexity. Rather than simply knowing that file operations will be under the “file” menu, a user must know the specific commands required to make that operation happen, or resort to searching the internet for an answer – assuming their search query is precise enough to actually return a useful result. These two paradigms are not necessarily at odds, mind you. In actual fact, there are countless programs extant today which are essentially just user interfaces on top of those same command line tools. Personally, I encourage this paradigm – providing both simple command-line tools and user interfaces to them is an admirable exercise⁷.

All that context-setting exists for me to say: I find Linux to be simple.

Simplicity is Subjective, I Guess?

As I’ve discussed, complexity is not exactly straightforward, and what any individual user finds complicated, and conversely what they find simple, is largely up to their particular sensibilities. So what exactly do I mean by saying that Linux is simple? We are after all talking about an operating system whose mainstream conception is “It’s the one where you need to open a command line to do anything”. Whether this is true or not⁸, I personally don’t see that as a bad thing. I like the command line. I am one of those sickos who absolutely love a good command line utility or program. Emphasis on good. The way my brain works, and the way I operate on a day-to-day basis, having a suite of specific tools to do specific tasks exactly fits my needs. Unix philosophy all the way, baby. Let me just use 12 different programs with pipes to shuffle data between them, hell yeah. But I’m going on a bit of a tangent here, so let me indulge myself for a moment to bring things back on track.

I do not find menus to be a particularly “simple” experience. I need to click into one menu, then another, then another, just to reach the thing I want to do. I know what I want to do, why can’t I just tell the computer to do it? The obfuscation of the commands underpinning the action I want to do at times actively confuses me. Call it a skill issue if you want, but I actively find myself confused by plenty of menu systems⁹. My desire, when I use my computer, is to turn it on, log in, and do the thing I want to do. I don’t want to spend a bunch of time managing trying to just get to the thing I want to do. I turn on my laptop, log into my user, and hit mod+enter to launch a terminal window in i3. If I want a program like Firefox to open, I hit mod+d and type “firefox”, and then it just opens. There is no extraneous navigation necessary. While this is not explicitly unique to Linux, in the modern computing world it seems to be increasingly rare.

My most recent work laptop was a Windows machine. It had been roughly a decade since I used windows to any real extent, and my past memory of it was not exactly favorable, but contained significantly less advertising than it does now. I am absolutely the kind of bitch who brings up the Halloween Memos at a party, so I will stop myself from going on a full on diatribe in this article, but suffice it to say that the modern Windows experience is anything but simple.

MacOS is… better, but still falls short. Aside from a general lack of ability to truly dig into the system and make it my own¹⁰, the proliferation of “helper” tools and utilities has bogged down the experience significantly since I was a regular Mac user. Moreover, while many of the command line tools I use on a daily basis do exist on MacOS, they are often significantly older ports, or have major usage differences from their Linux or BSD counterparts. What often frustrates me when using MacOS is less the architecture than the fact that it’s close to being what I want, without actually being what I want.

A Conclusion? I Think?

Ultimately, I think you should use whatever operating system works best for you – let people like things, right? If Windows works for you, that’s great. I personally find the experiences on other operating systems deeply frustrating, but I also understand that my opinion has no bearing on anyone else. What I do think, however, is that we need to see more open, non-commercial¹¹ operating systems. Failing that, we need operating systems that respect their users. Increasingly, the operating system experience is filled with advertisement, data collection, invasive AI and “helper” utilities, and aggressive attempts to get you to use such-and-such software you never asked for. I despise this paradigm. Users deserve better from their systems. They deserve not to be treated like they are. Computing does not need to be needlessly complex. I’ll save the rest of the rant for a different post.