Introduction
Have you ever launched a simple program on your machine, say, the Windows file Explorer, and were surprised as to why it took several seconds to launch, even though your hardware is pretty decent ?
Or maybe you came across posts saying how opening and closing the start menu repeatedly on Windows 11 makes your CPU usage spike to 60% ? Also why is the search feature so slow ?
As far as you can remember, that wasn’t the case in previous versions… 
Has my computer gotten worse ?
How is that even possible ? Is a file explorer some kind of arcane software that can only be ran by the latest hardware ?
Or maybe, as time went by, weird features got added - without much of your consent - and loading all of them at once significantly slows down launch time.
As for that start menu issue, let’s look at it a bit closer and see how this complex piece of sof-.. Oh.. this is a React Native application… My OS' widget that is on screen at all time is a React Native application… That explains the CPU usage and the poor performance.
All this confusion boils down to a single statement: Modern day applications are full of bloat
As Niklaus Wirth, father of the Pascal language, stated: software is slowing faster than hardware is accelerating, negating every benefit gained from having better hardware.
But this is not the end; there exists an irreducible group of programmers who aim to bring back the glorious days of 8KB text editors, when less than 1GB of RAM usage was the norm, and when computers lasted for decades.
This article will try to shed some light on this community, and maybe convince the reader to take some inspiration from their practices.
Disclaimer
To fully appreciate this article, you might need to understand some things:
- What a Window Manager is
- Basic Linux concepts, such as daemons, init systems, etc.
Suckless, what is that ?
Suckless.org is a community of programmers focused on developing Free and Open Source Software that follow the suckless philosophy.
The suckless project was founded by Anselm Garbe in 2006, it started from a window manager called “Window Manager Improved”; which later got replaced by the Dynamic Window Manager, which is very well known today and is a staple of suckless software; and from there the suckless community grew in numbers.
The suckless philosophy
The suckless philosophy was created to counteract the rise of software that don’t focus on usability and simplicity, but rather on eye candy and unnecessary features; in a more vulgar way, software that sucks.
You might be wondering: “Why is that bad ? More features seems like a good
thing.” 
To this I reply: the more complex a code base is, the bigger your
program is, and the more error prone it is.
As its name suggests, the suckless project aims to follow the opposite of
software that suck, by focusing on minimalism, usability, and code efficiency,
in speed and size; in other words, to follow the KISS (Keep It Simple and
Short) principle: do one thing
and do it right. 
In the community, software that follow this philosophy is
known as “software that rock”.
But there are complex problems that require complex solutions, how does
suckless deal with that while following the KISS principle ? 
Divide big problems into smaller problems, instead of providing a huge
monolithic program that deals with everything (looking at you, systemd),
delegate the work to smaller, specialized programs, making it more modular, and
by extension, kept simple and short.
Examples of things that suck
As stated many times, a lot of software actually suck, here are some of them
SystemD
The famous init system systemd took the Linux ecosystem by storm when it first came out as a replacement for init: it was fast, stable, and worked out of the box (still does to this day).
A short reminder of what init systems are supposed to do: It is the first process started at boot of the OS, and it is tasked with starting other daemons at boot, for example, your network manager; as such, all daemons are direct or indirect childrens of your init system.
So, why does systemd suck ? 
This “init system” tries to do everything in your system: init, boot,
networking, user switching, mounting, and so on.
This not only makes a huge binary for the task at hand, it also exposes a greater security risk: as lines of code multiply, so do oversights and programming mistakes, most people don’t care about saving five kilo bytes on their binary, but a lot do want to know what their computer is doing, with systemd, it’s practically impossible to know everything that’s being done.
Moreover, because systemd is the most used by default in most popular Linux distributions, a lot of programmers decided to rely purely on its existence, making it a hard dependency of many projects. This makes it problematic for people wanting to use alternative init systems or simply problematic from a design point of view, no project should depend on an init system of anything.
In short, systemd strayed from being a simple init system; it is now a whole ecosystem/suite of tools, but for those who want only the init part of it, they’re out of luck, as it became a big, monolithic and complex software; and those who seek alternatives need to find workarounds or patch projects.
There are many other problems with systemd out of the scope of this article, such as terrible project management, etc..
Web Apps
Ever heard of electron ? This sweet little piece of software enables web pages to run on your desktop, outside of your regular web browsers like firefox, chrome, and whatnot. Isn’t that great ?
Well.. Yes, but there’s a catch; this is one of the most resource hungry
framework that exists. 
The web uses two main components: HTML and Javascript;
that means you need to have NodeJS runtime, and an HTML renderer a.k.a web
browser: Chromium ! 
So what happens is that Electron packages a version of said web browser as part
of your build and runs your web application inside ! 
This results in a huge binary (a simple hello world app is around 50MB in size)
AND a huge runtime cost in RAM (depends on the web app, but for reference,
Discord uses around 1GB on my setup).
There are other frameworks out there like CEF (spotify uses it, for example) but it is more or less the same verdict.
Examples of software that rock
These are the software that are implemented with the suckless philosophy in mind and that I find interesting.
Programs
This category ranges from window managers to web browsers to command line utilities.
- DWM: Dynamic Window Manager, the original suckless software
and the one that started it all !  Configuration is written directly into the
source code, making it blazingly fast. 
 Very minimalist at its core, need a feature ? Just code it ! (or take someone’s code, with credit)
- dmenu: A menu to launch programs with
- sxhkd: The Simple X HotKey Daemon, a personal favorite of mine that I used to daily drive. Maybe you guessed from its name, the only goal of sxhkd is to handle hotkeys, very simple.
- bspwm: Another Window Manager and personal favorite. This one rocks in particular because it only manages windows, you need external programs to manage the simplest things like keybinds, which makes it very lightweight !
- foot: Maybe one of the smallest terminal emulators out there: only 600KB ! 
 Unfortunately not configured in header files, it is not the most suckless, but it is the best Wayland option out there for minimalists.
- mpd: Who needs bloated GUIs when you could simply listen to your music from a daemon ! Choose whatever front end you need (or none), the choice is yours my friend.
- feh: Probably the most widespread suckless program, it displays images and can set wallpapers, voilà.
Libraries
Utilities used for writing software that sucks less
- musl: an implementation of the standard C library that
attempts to be as small as possible. 
 Still very young (released in 2011) and has a long way to go, is slower in most cases; but it is way smaller and has more robust security than the regular glibC.
- Nuklear: a cross platform graphical user interface toolkit written in pure C, doesn’t have any dependencies, draws windows and grabs input, that’s it; it also has bindings for many languages, so no excuses !
That’s all good, but why is it so niche ?
The main reason, as cited by suckless.org themselves: “Our project focuses on
advanced and experienced computer users.” 
Their goal is not to appeal to a broad audience at all, they want to provide
software for those who can handle it. Software such as these are made mostly
for power users and those who want to configure every nook and cranny of their
system.
Another, very unfortunate reason, the community: elitist by design and NOT novice friendly, you better know everything about C (the one that rocks) or you will get ghosted…
Last but not least, programs like these require a good amount of configuring until you get a setup you’re comfortable with and is ready for work or whatever a user might be doing, most people want their desktop to “just work”.
A real life example on a slow machine
Talking is fine, but it is better if you can put proof on top of it, so here comes the interesting part.
I have with me a Unowhy Y13G002S4EI, generously provided by the state during my high school days.
It came with Windows 10 Education pre-installed, which was frankly unusable due to the storage actually being around 50GB, and not 64GB due to reserved partitions, and windows taking up 25GB. Adding to this, opening a web browser, or even the file explorer, could take up to tens of seconds.
It was evident that while being good computers for a minimal workload, they were not sized for Windows 10, yet it came shipped with it by default.
As soon as I graduated high school, we were given authorization to tinker with it, so I instantly installed a simple Ubuntu on it, and it became much better; but I am not satiated.
How far can we go so we get the most minimalist, grahical system ready for daily use, and how different would it be from a more “normal” system ?
The following tests will be held on the exact same machine, starting from scratch.
Getting set up
Regular setup
For this one, we will use the latest Ubuntu long term support release as of now, Ubuntu 24.04.2 LTS.
The setup is quite simple, on another machine, download the ISO image, use
disk destroyer dd to flash a 8GB usb drive: # dd bs=4M if=/path/to/ubuntu.iso of=/dev/sda conv=fdatasync status=progress. 
Then plug it your machine and boot on it, open the installer and press next
several times, remember, we want the most default Ubuntu possible for testing
purposes (except for the disk setup, here we erase disk).
Go grab tea, learn to play an instrument or maybe draw a picture, because this is going to take a lot of time.
Once we’re done, let’s start measuring, but first, we need to boot; a minute or so later, we are ready to go !
Right off the bat, we can notice that the desktop lags a bit, the cursor jumps
around and keystrokes take a while to register.. 
Part of it can be explained by what is installed by default: the GNOME desktop;
it is not known to be lightweight on low end systems.
Let’s check the resource usage using btop: on idle the CPU clocks at 800MHz,
and sometimes doubles only to come back down a second after, it has a stable
usage between 2 and 4%, with 1.5% being the terminal, not bad (for the desktop)
! 
As for RAM usage, out of the 4GB that are available to us, we only get
1.5GiB free, again, that’s with no programs running except for gnome-terminal
and btop, huh, that doesn’t leave much room…  Last but not least, the OS and
its default applications take 12GiB out of the 55GiB available, a big step up
from Windows 10 Education and its 20GiB !
Now, let’s try launching some applications, starting with Firefox, the default
installed browser. 
It takes around 4 seconds to launch, much quicker than Windows. 
But that’s where things go south: right after launching firefox, we lose 1GiB of
free memory, leaving us with only 500MiB ! 
Launching a website like Youtube makes the CPU spike to 40% and now we only have
300MiB of free RAM.
So, we can conclude that, very much like Windows, installing such a bloated distribution is not ideal for multitasking, as the system becomes very loaded once you start a single instance of firefox, let alone doing something else like compiling a project at the same time…
The suckless setup
Now to the interesting part, let’s build a full suckless setup:
- Void Linux: A independant Linux distribution written from scratch, focuses on stability, and most importantly, it uses runit instead of systemd; it also supports the musl implementation. Minimal at it’s core, we will boot into a TTY and build from there.
- Wayland, or Xorg ? Both of these suck, so let’s go with Wayland, which sucks a bit less.
- DWL: DWM, but for Wayland
- wmenu: dmenu, but for Wayland
- Foot terminal is a perfect pick for wayland
- Vim as a text editor
- Firefox as a browser (yes, this is NOT suckless)
Installing Void
To install, we shall go to the Void Linux website and
download the Base -> Live Image [musl] ISO, then go through the same procedure
as with the Ubuntu ISO, use dd, plug the USB drive into the test subject, and
boot on the USB drive.
Now this installation is quite different from Ubuntu’s, we boot into a spooky
TTY, which looks like a big terminal with no desktop. 
But once we login, a terminal user interface installer is made available to us,
phew ! 
Here we need to select more detailled options like which network interface to
use, the mirror used for downloading packages, the bootloader to use, and
describing the mount points. 
Very intimidating for inexperienced users, so you might want to download a
premade image if you’re not really comfortable with installing Linux. 
Once everything is configured, just press install, and reboot once it is done
(way faster this time).
Setting up the environment and packages
For DWL, we need to compile the project, as it goes with suckless programs, just
go on their homepage and follow the instructions.  Change up some options in
config.h, use sudo make install, aaaaaaaaaaaaaand we’re good to go !
For the installation of all the other packages, one needs to use xbps, Void’s
package manager.  After installing DWL, wmenu, Foot, Vim and Firefox, let’s run
the same tests as we did last time.
A brief performance overview
First thing to note is that the system booted in 10 seconds past GRUB, this is literally 6 times faster than on Ubuntu, this is mostly explained by the difference in init systems; while Ubuntu uses systemd, void uses the much faster runit.
Right away we can feel that the desktop is way more responsive. Partly due to the fact that the computer has nothing better to do than give us its whole attention, no pesky background service to take up precious memory !
Let’s open up the foot terminal and check with btop what our resource usage
looks like. 
On the CPU side, we get a stable 2-3% usage (mostly the terminal), clocking at
around 800MHz, so almost no difference there. 
However, on the memory side is where it gets interesting; while idle, only
450MiB of RAM is used ! 
That leaves us with 3.2GiB of free memory to use elsewhere. 
On the disks side, the whole installation takes about 7GiB out of the 55GiB
available, how small.
Let’s run firefox and check what happens now: 
As expected, firefox is the most resource hungry, taking almost 1GiB by itself;
however, with us saving so much RAM by installing a suckless setup, we still
have a whopping 2.5GiB of RAM, plenty to engage in multitasking.
Much better, THIS is what should have been installed from the start, right ?
Comparing results
Now, let’s start things off by stating the obvious: The second setup is WAY lighter than the first; all the eye candy was traded off for performance and battery life, at the cost of ease of use and accessibility.
But let’s look at some numbers:
- From Ubuntu to Void, the CPU usage and clock stayed mostly the same, but the
former did experience usage % spikes, explained by the background services
waking up and going back to sleep right after. 
 We can thus conclude that it’s marginally easier on the CPU to go suckless.
- The memory usage however was like night and day: 
 Ubuntu used up 2.5GiB of memory while doing nothing, whereas Void only used 400MiB: that’s an 84% decrease in memory usage.
 We used the same browser for testing, so the memory usage difference was marginal, but lower for void: GNOME uses window decorations and handles that might use up more memory.
- As for the disk usage, we went from 12GiB with the default setup to 7GiB with a customized one, that’s a marginal 5GiB decrease (still 10% of total storage on this particular machine).
Ok, great, we can definitely conclude that using suckless software is way better for the computer, but that is not really the most important to me and to everyone else, really.
But is it really usable ?
Yes it is. 
It sure does require a lot more experience: no fancy app installer,
no desktop for you to click around, you actually need to learn keyboard
shortcuts, and learn a tiny bit of C and Shell.
And that’s the keyword here: you need to learn; once you do, the suckless world truly becomes yours, and anything becomes possible. You want it ? You create it.
But if you want something that works out of the box, that does not require any configuration whatsoever at the cost of performance, there is surely an option that will fit you.
Conclusion
Whew !
We explored the world of suckless, what it meant, some examples of it in the
real world, and most importantly, that it could turn a machine that’s reluctant
to work on slightly too demanding setups such as Windows, Ubuntu, and many other
OSes out there… 
However, we proved that it is not the end of its life, as we could - with a bit
of work - create a setup that’s worth being called usable !
Now, the suckless philosophy and the attached project are needed, we need people that create the lightest programs that can run anywhere, for machines like mine that cannot run anything else.
Is it for everyone ? Absolutely not, you need to spend a lot of time on your configuration, and with today’s hardware, the improvements will be marginal; but if you do need every KiB of RAM for your workflow, then suckless might be what you’re looking for.
For the developers reading this article, I hope it made you rethink how to approach software creation, because it is truly wonderful the amount of work these machines can achieve, so let’s not waste it with highly inefficient and unnecessary features.
Before leaving, I will add that there are obviously other options that are not
full-suckless or full-bloated, and it is interesting to look at alternatives,
their advantages and disadvantages. 
Some of these options include window managers: Hyprland, i3 or xmonad are
awesome programs; one could also take a peek at other desktop software such as
Rofi, Wezterm, or quickshell…
There are many more projects that I couldn’t cover in this article, and I highly encourage you to take a look for yourself to get an idea of what options are available.
Thank you for reading, and stay suckless.
Links
- The suckless project: https://suckless.org
- An interview with the creator: https://twit.tv/shows/floss-weekly/episodes/355?autostart=false
- Void Linux website: https://voidlinux.org