Turning suckless into suckmore

Published on 2020-03-23. Modified on 2020-03-25.

The suckless philosophy is all about keeping things simple, minimal and usable, but some people seem to have misunderstood it completely.

The suckless philosophy is all about keeping things simple, minimal and usable, and as it is stated on the project website:

Ingenious ideas are simple. Ingenious software is simple. Simplicity is the heart of the Unix philosophy. The more code lines you have removed, the more progress you have made. As the number of lines of code in your software shrinks, the more skilled you have become and the less your software sucks.

At the heart of the suckless project lies the Worse is better philosophy and the Unix philosophy. In order to understand why those philosophies make software better we have to understand the following:

• Quality does not necessarily increase with functionality and there is a point where less functionality ("worse") is preferable.
• With complexity comes errors, slowness and security problems.
• If we make each program do one thing well we can combine multiple programs to do multiple things well and efficiently.

And all that is fine and well, but why is it then that a lot of people who pride themselves on YouTube and elsewhere about using suckless applications and following the Unix philosophy seem to patch the bejeebers out of suckless applications?

Looking at the project website for the st terminal emulator there is listed 38 different patches that have been submitted where a majority of those are adding or changing functionality. The dwm tiling window manager has a stunning 141 patches also with a majority adding either functionality or changing the fundamental way the window manager works. And when you look around on GitHub, GitLab and elsewhere, where people share their dotfiles and stuff, you'll notice that a lot of people are franticly combining a lot of these patches to the different suckless programs.

In order to apply multiple patches you actually have to apply most of the patches manually, except for the first one you use. As soon as you change a single line in the source code, which you do when you apply the first patch, all the other patches becomes useless. The way most people deal with that is that they apply the rest of the patches by manually editing the source code, copying and pasting and deleting where needed.

Besides from the fact that this takes up quite a lot of time if you apply many patches, you now also have the problem that you have to keep in sync with upstream development. If a new version of the software you want is released, you have to wait until someone makes new patches (in case you cannot do it yourself), then you have to do it all over again.

Another problem arise when people take these philosophies to the extreme because there is also such a thing as too simple. This happens when the software you're using simply cannot do even the basic things you need without having to combine ten different programs. One of the things you'll start to notice is that you begin spending more time getting these programs to work well together than you do on the actual problem these programs are supposed to solve.

You're doing something wrong when you:

• Have to run and maintain a gazillion pathetically slow shell scripts to compensate for the lack of basic functionality.
• Have to keep hacking away on multiple configuration files in order to avoid common pitfalls and problems between the programs you use.
• Notice that you spend more time on your scripts and dotfiles than you do on actually getting work done.

If you find yourself in this situation you should know that you have just turned simplicity into complexity.

What some people misunderstand is that one of the major reasons behind the Unix philosophy is not to keep programs simple for simplicity's sake, on the contrary, it's all about people. It's about avoiding the headaches that follow complexity of both, wasted time that could have been spent doing much more useful stuff, and avoiding the stress that results from having to maintain the complexity.

The terminal emulator st doesn't have scrolling capabilities because normally that's not what the terminal is about. Instead you're supposed to run the st terminal emulator in a terminal multiplexer. A terminal multiplexer is a wrapper that allows multiple text programs to run at the same time, and provides features that allow the user to use the programs within a single interface productively.

This is the Unix way. You combine st with a terminal multiplexer like tmux or GNU Screen and achieve an amazingly productivity on the command line. Why then would you want to patch st with capabilities that doesn't belong in a terminal emulator?

However, while a terminal multiplexer is especially useful for running remote sessions, what if you're only working locally and don't need any of the capabilities that a multiplexer provides? Isn't adding the multiplexer the same as adding complexity? Well, yes, because you're now running multiple programs capable of achieving some of the same results, at least somewhat. But this is exactly the point of this article, you wouldn't care about such minuscule details unless you have taken the philosophy to the extreme.

Whether you apply a single patch to the st terminal emulator in order to be able to efficiently scroll your terminal output, or you run the terminal in a multiplexer, or you use something like xterm that already does all that very well, doesn't really matter, what matters is that you spend more time on the important stuff and not on patching, configuring, re-patching, re-configuring, several times a week in a frantic attempt to turn st into something that it was never designed to be.

If you're doing all of these things you would most likely be much better of using something like the Xfce4 Terminal, the GNOME Terminal or Konsole from KDE because all of these terminal emulators are packed with all the bells and whistles you could ever need and you will hardly notice the extra second it takes for one of them to launch.

So you have just migrated away from something like the i3 tiling window manager because you think it's too bloated, and you have shunned the heavier terminal emulators like Xfce4 Terminal and even xterm. Instead you feel amazed at the simplicity of suckless and you're now running the dwm tiling window manager instead, with a ton of patches and scripts added because of course dwm is useless without transparency, gaps and a glowing status bar with the latest weather report, a volume indicator, and all the other bloatware you left behind in GNOME or KDE. And you run the st terminal emulator, again with a ton of patches and scripts added because the terminal emulator needs to look like the GNOME Terminal and behave like Vim. And in order to glue all the different parts together with all the other terminal and window based application you're running you have to maintain a huge repository of dotfiles and scripts that need to be automatically updated using cron because of all the daily tinkering you're doing.

I congratulate you on your amazing achievement of turning suckless into suckmore! :)