É tempo! Independência ou Morte! Estamos separados de Portugal!

Rant in the woods

On 2020 I've been watching lots of Luke Smith's videos, among other Linux-related youtubers. Luke's known to be a controversial figure, and he often wanders off the regular bash-and-vim routine to talk about something else, like this one, where talks about independence and life choices. As in, how he feels life gets better when, on a decision-by-decision basis, we strive for more independence. He proceeds to dab on big-city dwellers for having their lives constrained during this pandemic crisis, as opposed to his country life.

It's not hard to see how this relates to a more strict free-software tooling: it takes a little work and patience, yes, but hard works pays off, and what you install and configure is really your own. Your extensible text editor, your window manager, your operating system. You're not constrained by whatever Microsoft or Apple give you, and that feeling of freedom makes it difficult to ever consider going back, no matter what shiny software they may have to offer.

That video ended up having an effect on me and made me rethink some choices when writing software. No worries, I won't try to sell anyone Emacs or XMonad here, as I feel workflows are pretty much personal and rightfully private. I would prefer to share an interesting point of view I've learnt along this expedition through the GNU/Linux cultural jungle so far, which may be refreshing to you as it was to me.

The Suckless philosophy

Suckless is the name given to this sort of organization/movement/site that houses a some free software projects, such as the dwm tiling window manager, the st terminal and the dmenu application launcher. For those who have never heard of these, they are very popular with whoever wants a minimal desktop setup in Linux, as all of these are designed to do a lot with very little, and be as flexible as possible so you can tweak their behaviour at will. There's a catch, though, which makes the whole enterprise so controversial: to configure these, you will need to edit the C source code yourself and recompile.

It's not so big of a deal as it seems. Most minimal software in the Linux world is configured either via a config file, which may be YAML-y, shell scripts, maybe even a source file in a determined programming language that must interact with the software API (like it is with XMonad - its config file is written in Haskell). Suckless software just takes a step further, and provides the user with a config header file to play around. From the dwm page:

dwm is customized through editing its source code, which makes it extremely fast and secure - it does not process any input data which isn't known at compile time, except window titles and status text read from the root window's name. You don't have to learn Lua/sh/ruby or some weird configuration file format (like X resource files), beside C, to customize it for your needs: you only have to learn C (at least in order to edit the header file).

One of the advantages of this stategy is the patching system: in order to add features to your dwm build, for instance, that you would like to have, the community offers a wide variety of patches to apply in its source code. It may seem like an extra step, but it's all about not having the features you don't want, and avoiding have too much bloat holding you back.

Here's a word you kind of don't hear too much in the web developer scene in general (at least in the environment I'm used to), but that you get in touch with a lot when messing around with this sort of software: bloat. Software bloat often means either that a software takes too much memory and CPU usage for the tasks it's supposed to do, or it suffers from feature-creep, adding often useless or unwanted functionality. It might mean, perhaps, that a software demands too many dependencies. It may be a very subjective notion, as some may regard some functionality as vital whereas others would be very well without it. Either way, it has been a trend for a while (as commented in a lot of interesting talks - I often recall the beginning of this one from Jonathan Blow) that a lot of software developers don't give performance too much thought, and there are significantly obvious examples of software that demands more and more hardware nowadays.

Avoiding software bloat is in the core of the suckless philosophy.

Designing simple and elegant software is far more difficult than letting ad-hoc or over-ambitious features obscure the code over time. However one has to pay this price to achieve reliability and maintainability. Furthermore, minimalism results in reasonable and attainable goals. We strive to maintain minimalism and clarity to drive development to completion.

As much as you might not agree with everything they have to say, it's undeniable the suckless folks are onto something. I would recommend everyone to read their manifest, and perhaps to play a bit with dmenu. It's a dynamic menu for X, mostly used as an application launcher, but with endless applications. Here you can find a video by Luke Smith showing a little of the potential involving dmenu's and st's minimalism: he shows how it pays off not to have a terminal with build-in emojis (like kitty), but using instead a dmenu script to fetch it from somewhere else in the system. Using that dmenu script, the solution is not only more lightweight, but portable as well: whether in the browser, or in another application, he can use the script to use the same functionality.

Minimalist software: a journey towards independence

There are lots of ways we can relate minimalist software with software that promotes independence. For instance, minimalist software demands less from your server's and your client's hardware. Not only that shows respect for your user's time and your server expenses, but it also allows for more to be done with the same amount of resources. By avoiding feature creep, and striving for generic usage - such as the dmenu case I mentioned above - you allow software to be used in composition, instead of reworking the same features over and over again. By restricting the amount of dependencies, you avoid a lot of hassle when maintaining it later (specially on volatile ecossystems - I am looking at you, Javascript), and keep the overall result more lightweight.

The same also applies to the programming languages we use: how much abstraction do you really need, and what part of it ends up getting in your way? What kinds of programming languages may enable you to write more minimalist software? Some may say the abstractions will actually make you more independent from hardware, and the whole point of platforms such as the JVM are to free you from the machine you're running on; but can you really call it independence when you don't directly control the hardware you're running on? Maybe stripping away these conveniences will allow me and you, as software developers, to better comprehend and make use of the metal beneath us.

The minimalist software movement in general offers a lot to talk about and lots of interesting ideas to apply on a daily basis. Each of the topics I mentioned is probably worthy of an article in its own. I hope I am able at least to increase awareness of this topic and enable some healthy discussion. As far as the journey goes, I am pretty much at a starting line: I've always worked with very high-level languages such as Java, Javascript and Clojure, so I'm having a wild ride learning Rust, where I hope I can try to put some of these ideas to the test.

Update: August/21

While I don't entirely dismiss these ideas, I also don't subscribe too much to the line of thought presented here anymore. I've already (temporarily) given up on Rust, and my adventures with Haskell have shown me other possibilities regarding software abstraction. If you're interested in what kind place these other kinds of abstraction might lead, I highly recommend this Gabriella Gonzalez' article.

Update: January/22

Well, I kind of still stick to these ideas, actually. Having to use Mac at work makes me value more and more that kind of bare-bones minimalism from the Linux environment.

I'm starting to sound like the worse is better guy.