A lot of people when they move into linux will learn of the magic of tiling window managers.

Generally, they are curious, and some find it as a waste of time, others die by it. And people will even wonder why in the hell someone would take the time to configure one of these things.

However, I’m not here to debate whether or not it’s a waste of time, or if it’s worth it. I’m here to help out people who have heard of dwm and want to try it out. Whether you’ve heard it from a friend, a youtuber, a random, or whomever, people at first find dwm as a scary thing that’s IMPOSSIBLE to configure.

But fret not! For your neighborhood suckless shill is here to help!

Prerequisites

Before you start going ham on the configuring/ricing, this isn’t your average joe i3, Hyprland, or whatever. You’ve probably heard that dwm is a “compile from source” configuration, and this just means that every change you’re going to make has to be compiled all over again.

“Woah, woah, woah!” you might be saying. “Compile? Like C code? H4x0r like stuff?”

Yep, that’s the ticket! But don’t let it scare you off. It’s simpler than it sounds. Think of it like baking a cake. You have a recipe (config.h), you mix your ingredients (the source code and your changes), and then you bake it (make). Each time you want a different flavor (a new feature or keybinding), you tweak the recipe and bake it again. You will need to kill dwm and re-run it again since the binary that runs is loaded in memory, it doesn’t change in real time.

A common misconception is an over exaggeration on how tedious the reconfiguration is. Whilst it can be a bit annoying, especially in the beginning when you are getting it tailored towards your preferences, it’s definitely overblown. See, once you have a working system, there isn’t a need to keep on configuring onwards, a necessary process I would say.

So, what do you actually need?

A C Compiler:

Most likely, you’ll want gcc. It’s the most common C compiler everyone gets.

If you’re on a Debian-based system (like Mint), you can usually get this and other essential tools by installing build-essential.

    $ sudo apt install build-essential 

For Arch users (for the “I use Arch btw” furries):

    $ sudo pacman -S base-devel

And for Fedora folks:

    $ sudo dnf groupinstall "Development Tools" "Development Libraries"

Make:

This is a build automation tool that will, well, “make” dwm for you. It usually comes with the build-essential or base-devel packages.

LibX11 development files:

DWM interacts with the X Window System, so you’ll need the development headers for it. Often called something like libx11-dev or libX11-devel.

Debian:

    $ sudo apt install libx11-dev libxft-dev libxinerama-dev

Arch:

    $ sudo pacman -S libx11 libxft libxinerama

Fedora:

    $ sudo dnf install libX11-devel libXft-devel libXinerama-devel

(Note: libxft-dev is for font rendering and libxinerama-dev is handy for multi-monitor setups, which you’ll probably want later on!)

Got all that? Sweet!

Getting the Goods (The Source Code!)

Alright, let’s grab the dwm source code. The suckless crew hosts their code on their own git server. However I recommend personally to get their official tarball releases (this links to the latest of the time of writing this: 6.5) their page.

1. Save the source code to where you want to keep it. A common spot is something like 
    ~/.config/ or ~/.local/suckless/, just anywhere to hide it out of sight.

2. Unextract it

3. Open your terminal & navigate to that directory (using cd and stuff)

Take a peek. You’ll see a bunch of .c files, a Makefile, and the golden goose: config.def.h.

The Infamous config.h

This is where the magic happens, folks. config.def.h is the default configuration. You’re not supposed to edit this directly. Instead, you copy it to config.h: bash $ cp config.def.h config.h Now, config.h is your personal configuration file. Open it up with your favorite text editor. You’ll see C arrays defining your keys, your tags, your fonts, your colors. It might look a bit intimidating at first, but it’s surprisingly straightforward.

For now, don’t change anything. Let’s just get it built!

The First Bake: Compiling DWM

Still in your dwm directory? Good. Time to compile! This is the part that sounds scary but is usually super simple thanks to the Makefile.

To compile and install it system-wide:

    $ sudo make clean install

Or, if you prefer not to install it system-wide immediately yet (which is a good idea for testing):

    $ make

If all your prerequisites were met, this should complete without errors. You’ll now have a dwm executable file in the directory (and runnable in your terminal if you ran the system wide installation)!

To run dwm, you’ll typically need to configure your .xinitrc file to launch it. For example, you could add this line to your ~/.xinitrc:

    exec dwm

For the people who run a Display Manager which is more likely (i.e gdm, sddm, lightdm, etc.). You’ll need to create a .desktop file. This file basically has the information and stuff for the thing to see and run it. You’ll need to create one in the /usr/share/xsessions/. And here’s an example dwm.desktop for reference:

/usr/share/xsessions/dwm.desktop:

[Desktop Entry]
Encoding=UTF-8
Name=dwm
Comment=Dynamic window manager
Exec=dwm
Icon=dwm
Type=XSession

The default keybinding for the Terminal is Alt+Shift+Return. Any other keybindings can be found in config.h, it shouldn’t be hard to understand the giant struct declaration. Comments left by the suckless team are your friends! Read them!

Uh Oh, It’s Plain! Time for Patches!

“Okay,” you say, “this is cool and all, but it’s a bit… barebones. My buddy’s dwm has gaps, a cool status bar, and fancy tag names!”

Aha! You’ve stumbled upon the next layer of the suckless philosophy: patching.

Instead of bloating the core dwm code with every feature under the sun, the suckless community maintains a collection of patches. These are .diff files that you apply to your source code to add specific functionalities.

    Want gaps between windows? There's a patch for that.
    Want clickable status bar elements? Patch!
    Want windows to swallow terminals? Patch!
    Want your bar at the bottom? You guessed it, patch!

This is where the “do it yourself” ethos really shines. You pick and choose exactly what you want. However it might be daunting for some people. And unfortunately, many patches don’t really like to work together. If you want a nice dwm patching experience, I would use this one, he’s the same creator as st-flexipatch and other “flexipatch” series. Basically, all you do is edit the patches.h file and you can basically get all the patches you want without too much hassle.

For those who are the tinkers, continue on…

How to Patch (The Basics)

First of all, you’ll need to download the patch utility if you don’t have it. You can probably guess what it’ll be called when you install it using a package manager. Once you’ve done that here are the general steps:

1. Find a Patch: Head over to the dwm patches page. Find a patch you like. Let’s say you want the autostart patch, which allows you to run commands automatically when dwm starts (I highly reccomend this especially if you’re running from a display manager!).

2. Download the Patch: Download the .diff file for the patch. Save it somewhere, perhaps in a patches subdirectory within your dwm source folder.

3. Apply the Patch: In your dwm source directory, use the patch command: bash patch -Np1 -i patchfile.diff

4. Resolve Conflicts (If Any): Sometimes, patches might conflict, especially if they modify the same lines of code or if you’re applying a patch meant for an older version of dwm. This will result in .rej (rejected) files. You’ll need to manually edit the source files to resolve these conflicts, looking at the .rej files to see what couldn’t be applied. This is the trickiest part, but it gets easier with practice. Start with simple, popular patches.

5. Recompile: After applying a patch (and resolving any conflicts), you need to recompile! bash $ sudo make clean install

And that’s the patching dance! It can be a bit fiddly, especially when patches conflict, but it gives you incredible control over your window manager. Also, a quick note! Some patches might change the config.def.h, add these new changes to your config.h since they are default configs for the new patches.

Next Steps & The Suckless Mentality

From here, the world is your oyster:

• Explore config.h: Seriously, dive in. Change your mod key (Alt is default, many prefer the Super/Windows key, just change the MODKEY definition from Mod1Mask to Mod4Mask). Change your fonts, colors, and tag names. Recompile after every change.
• Browse More Patches: Get those gaps (vanitygaps), add a systray, try different layouts (fibonacci, centeredmaster).
• Status Bar: Dwm’s status bar is typically populated by setting the root window’s name. You’ll often use a separate shell script or program (like slstatus or a custom script) that periodically updates this. The autostart patch is great for launching such scripts. You can also decide to change out the bar to something like polybar or something.
• Embrace Simplicity: The core idea of suckless is to keep things simple and understandable. If a patch seems overly complex or breaks things too often, maybe it’s not for you. The beauty is in building your ideal, minimal environment.

Don’t be afraid to break things! If you mess up your config.h or a patch goes horribly wrong, you can always run a patch -R -i file.patch. And for the config.h, the config.def.h will always be there as the default to save you.

It’s a journey, not a race. You’ll learn a bit about C, a bit about how window managers work, and a lot about what you really want from your desktop.

So go forth, compile, patch, and make dwm your own! It’s less about having a flashy setup (though you can certainly make it look nice) and more about having a tool that’s perfectly tailored to you. Less is indeed more, especially when you’re the one deciding what that “less” consists of.

Happy Hacking!

– cowmonk

MacOS…

The very name whispers promises of seamless integration and… well, mostly just working.

Already, there’s a sense of profound relief when you think about starting with a sleek, aluminium unibody and not having to build everything from the ground up. And it only gets better – one quick look, and you learn of the magical process of the App Store, where dependencies are someone else’s elegantly hidden problem. Not only is installing effortless, but updating? It just happens, often while you sleep, like benevolent digital elves maintaining your walled garden. Looking at this, people will naturally wonder, “why didn’t you switch sooner?”.

I am, perhaps surprisingly, still the same person who championed LFS, but I now use a MacBook for school, development, and other fun things with newfound ease. What I say doesn’t mean I’m telling you how you should use your computer, but an insight into why I personally now crave this… simplicity. If you are intrigued by this radical shift, and if you want to try macOS; I implore you to experience the polished cage, but be aware of the sheer lack of hardship you’ll face because, I do want to preface that macOS is no weekend project in reverse; it’s an instant gratification machine, and your patience–or desire to tinker–will be rendered utterly obsolete.

Embracing Pre-Packaged Perfection

There is a common misconception that macOS is restrictive and locks you down; however, that can only be far from the truth, the real freedom is the liberation from choice. The difficulty isn’t high either: the Human Interface Guidelines can be easily ignored as a user, and the process is relatively simple to understand: you click things. Most people can just drag & drop, just like most of troubleshooting involves turning it off and on again anyways. However, there is a level of difficulty in the tedious task of resisting the urge to look under the hood. But that also isn’t fully true in itself either, as you can install tools like Homebrew to automate most installations of things Apple didn’t deem worthy. Obviously, you could use Windows and also install WSL on top of that, but the ability to have one blessed way of doing things, dictated by Cupertino, without the need to distro-hop, and without the need to worry about isolating package managers because it’s all handled with magical fairy dust… it’s intoxicating.

And that is where we go into one of my favorite aspects of macOS: the ability to accept everything built with Apple’s tools and environment that they want: You are blissfully bound to their curated environment. That probably means everything to the majority of users, and the fact that you are bound to it is very… relaxing; what it means is the ability to be consistent–similar to how LFS is defined by its lack of definition, macOS is defined by its polished, unwavering look and feel–macOS is defined precisely by what it comes with.

But of course, another thing people say is that macOS is just polished BSD with vendor lock-in. This is not entirely true, macOS is a “lifestyle”, a fancy way of saying that although it is much less customizable than even Ubuntu, it is still an “experience” at the end of the day. There are tools and aesthetics forced upon you, such as Finder, the Dock, etc. that make it give you the “Apple experience”. A real user experience means starting from UNBOXING (no source tarballs or whatever) and accepting the tools they give you, which is what you do on macOS anyways. But then does it mean that you can’t enjoy the simplicity macOS already gives you? Of course not!

But what I mean is that the lack of customizability and control that you have over your macOS system is unlike any other OS I have ever used. There’s something satisfying that comes from not understanding how applications are packaged or how system integration really works on a lower level. There is maximum abstraction, and you get to take in the raw “Consumer Experience”. There is a sense of relief from avoiding these types of challenges as well, so that’s another bonus too.

Challenges of Effortlessness

Of course, the ease of macOS can only be true if you follow the Apple way word for word and don’t try to shake things up a bit. Everything I said about macOS’s simplicity before is still true. But the real hell comes from the lack of need for documentation; while the Apple Support pages are comprehensive for common issues, doing anything slightly non-standard often requires accepting it’s impossible or finding obscure forum threads. Whilst this is the norm for niche problems, at least with the rise of AI: finding answers to macOS internals seems less important than asking how to sync your iCloud photos. Unfortunately for me, doing crazy things like trying to replace launchd with systemd is apparently not in any training data or reality I wish to inhabit anymore. Resulting in just… not doing it. And trust me, I’ve done all sorts of web searches, but to no avail. Why fight it?

A common truth that I want to address here is concerning the stability of macOS. And unlike Arch that’ll break if you look at it funny, or LFS that you break by looking at it funny, macOS is surprisingly stable and nothing usually ever breaks in ways you can fix yourself, only very rarely in ways that require a Genius Bar visit. And it has to do with the fact that it’s not very common for most macOS users to update core components themselves, and most macOS users follow the stable releases pushed by Apple that are known to just work (mostly). At least from my experience, a macOS system has never broken in a way that required recompiling the kernel, but there are update issues if you try and hold back: Apple’s own damn way. Other than those outliers, it’s similar to why appliances are stable in that you rarely ever tinker; and when you update, it usually should work out fine since you usually only update the whole OS monolith, like for example accepting the latest point release rather than worrying about glibc very often.

Challenges to using a macOS system are always… first-world problems. They always happen due to Apple’s nature of changing things too much between versions, but at least for me: the lack of challenge is always worth it. It makes using my computer less exciting, and the results of doing something that everyone does makes me feel… normal. Every time my computer boots instantly, it’s a testament to pre-optimization and continuous integration from a massive corporation, and somewhat of a surprise given how complex it must be under the hood (not that I care anymore).

Final Thoughts (Seriously?)

I have done my best to compile some of my favorite aspects of macOS into a coherent blog post, but in reality it’s a complicated… well, actually, it’s pretty simple. I really think macOS is about embracing abstraction layers and discovering the beauty of a polished surface hiding complex design. Before I tried macOS seriously, I never really understood how simple using a computer could be, how modern tools really made our ideas of computing so effortless and we don’t really appreciate the work that goes into hiding the complexity; especially for me, as someone who built an OS from scratch, it’s really thanks to Apple that I have a clear path… to getting actual work done without compiling GCC for 8 hours.

For all to have made it to the end of this blog post, I want to thank you personally for taking an interest into my shocking change of heart. I want to apologize if this caused any LFS purists heart palpitations. I also want to thank… uh… Tim Cook? I guess? For this amazing ecosystem.

But that’s all from me! Happy clicking, and may your system updates be error-free!

Linux From Scratch…

The very name tells you everything that you need to know.

Already, there is a sense of dread when you think about starting with a bare-metal system and building everything from the ground up. And it doesn’t get any better, one quick look, and you learn of the monstrous process of manually installing and resolving your own dependencies. Not only is installing is difficult, but updating it too. Looking at this, people will naturally wonder, “why would you even try using LFS?”.

I am not the average computer user, but I do still use an LFS system for school and other fun things no problem. What I say doesn’t mean that I’m telling you how you should use your computer, but an insight of why I personally enjoy it. If you are interested in what I talk about, and if you want to try LFS; I implore you to try it out or explore it, but be aware of the hardships you’ll face because, I do want to preface that LFS is no weekend project, unless it’s not your first rodeo and you’re following by the books, it’s a marathon, and your patience–or coffee supply–will be tested.

Building Things from Scratch

There is a common misconception that LFS is really difficult to maintain, and even sometimes I see people say practically impossible; however that can only be far from the truth, and the difficulty of it isn’t that high as well: the handbook can be easily skimmed and the process is relatively simple to understand. Most people can just copy & paste, just like most of troubleshooting in Arch anyways. However, there is a level of difficulty in the tedious task of installing packages without a package manager. But that also isn’t fully true in itself either, as you can install a package manager like nix (in my opinion, flatpak done right) to automate most installations. Obviously, you could use normal distros and also install nix on top of that, but the ability have multiple options like pacman, apt, zypper, xbps, etc. are all available on LFS, without the need to distro-hop, and without the need to isolate the package manager in its own prefix since it’s really not a good idea to not isolate it.

And that is where we go into one of my favorite aspects of LFS: the ability to build everything with your own tools and environment that you want: You are not bound to any environment. That probably means nothing to the majority of users, but the fact that you are not bound to anything is very liberating; what it means is the ability to be fluid–similar to how Arch Linux is not defined to what it looks like, while Ubuntu is generally thought of with their own Gnome spin–LFS is not defined on what it can even come with.

But of course, another thing people say is that Gentoo is just LFS with tools on top. This is not entirely true, Gentoo is a “meta-distro”, a fancy way of saying that although it is much more customizable than Arch, it is still a “distro” at the end of the day. There are tools that are forced upon you, such as portage, udev, etc. that make it give you the “gentoo experience”. A real LFS with tools would be starting from SCRATCH (no stage3s or whatever) and adding the tools you want yourself, which is what you do on LFS anyways. But then does it mean that you can’t enjoy the customizability Gentoo already gives you? Of course not!

But what I mean is that the customizability and control that you have over your LFS system is unlike any other distro I have ever used. There’s something satisfying that comes from understanding how all packages are compiled and how USE flags on Gentoo really works on a lower level. There is much less abstraction, and you get to take in the raw “Linux experience”. There is a sense of accomplishment from doing these types of challenges as well, so that’s another bonus too.

Challenges

Of course, the ease of LFS can only be true if you follow the handbook word by word and not shake things up a bit. Everything I said about LFS’ difficulty before is still true. But the real hell comes from lack of documentation; while the handbook is comprehensive, doing anything not in the handbook often require digging through forum threads and/or mailing lists. Whilst this is the norm for most programmers, at least with the rise of AI: finding answers to those programming questions are much easier and generally accurate. Unfortunately for me, doing crazy things like a pure clang toolchain on LFS is apparently not in any training data of any popular LLMs I’ve tried, resulting in just trial and error. And trust me, I’ve done all sorts of prompt engineering, but to no avail.

A common misconception that I want to address here is concerning the stability of LFS. And unlike Arch that’ll break if you breath on it the wrong way, LFS is surprisingly stable and nothing usually ever breaks, only very rarely. And it has to do with the fact that it’s not very common for most LFS users to update their packages and most LFS users following stable releases of the handbook that are known to work. At least from my experience, a LFS system has never broke on me but there are compilation issues if you try and do what I do: my own damn way. Other than those outliers, it’s similar to why debian is stable in that you rarely ever update; and when you do, it usually should work out fine since you usually only update one minor component of the system, like for example firefox rather than core components like glibc very often.

Challenges to using a LFS system are always annoying, they always happen due to my nature of tinkering too much, but at least for me: the challenge is always worth it. It makes using my computer more exciting, and the results of doing something that no one really does makes me feel great. Every time my computer boots, it’s a testament to perseverance and continuous learning, and somewhat of a surprise to the stability of a LFS system.

Final Thoughts

I have done my best to compile some of my favorite aspects of LFS into a coherent blog post, but in reality it’s a complicated love-hate relationship. I really think LFS is about breaking abstraction layers and discovering the beauty of simplicity beneath complex design. Before I have tried LFS, I never really understood how complex Linux was, how modern tools really made our ideas of distros so convoluted and we don’t really appreciate the effort and work that really goes into it; especially for me, as the founder of LearnixOS, it’s really thanks to LFS that I have a clear path and a vision to create an independent distro.

For all to have made it to the end of this blog post, I want to thank you personally for taking an interest into what I have to say. I want to apologize for the wait, I’ve been pretty caught up with school, and hopefully I can try to make these come out faster. I also want to thank Patrick from the LearnixTV server for this amazing idea, I hope I answered the question to a satisfactory amount.

But that’s all from me! Happy building, and may your compilations be error-free!

– cowmonk

It was a simple suggestion from someone on the LearnixTV server when I completed one of the hardest challenges of my linux journey, achieving 30mib idle with dwm running on a modern 64 bit system: “why don’t you make a blog post about this?”, or something along those lines. It really stuck with me, and it was further strengthened by kirwano’s blogs and TronNerd’s blogs; reading them gave me a lot of inspiration in what I could write about and get down into. The idea of writing and documenting what I did and writing guides for other enthusiasts like myself intrigued me. But when I do write, hopefully I won’t bore anyone with what I have to say and people can gain insight from these blogs.

More about me

For the unaware, I am known as cowmonk, a crazy linux lunatic if the intro didn’t tell you otherwise. My first daily driver was arch, being the only reason for using it (being a life long windows user back then) was for a challenge. Hence, it was a no-brainer for me to move to gentoo as I naturally sought more ways to inconvenience myself whilst using my computer. My time on gentoo was simply put: “a tinker’s dream”, I gradually became a huge suckless shill and loved the minimalist approach. This brought me down a massive rabbit hole and I began to aim for the most bloatless system, with the least possible amount of ram used. And so, began the long journey to 30mib and “debloating” my system. It was then however, after acheiving such a massive goal, I realized that there was truly nothing left for me to do, and finally my switch to LFS as my final distro and daily driver.

During this time of my linux journey, I also somehow became the founder of LearnixOS, which started out as a joke. In fact, the distro was supposed to be a spin off of Linux Mint, and just be another Hannah Montana joke distro. It went through many ideas and iterations of what it could be. How I would love to continue on about the history of LearnixOS, but that’ll be for a future blog post. Long story short, LearnixOS is now LFS based, and as of writing there are already multiple people working on it and its own custom package manager.

Plans

I plan to continue these blogs as frequent as possible, a partial reason being to help me get better at writing in english. If your cup of tea is to listen to a nerd do nerdy things, I hope that by the end of every blog post from me you are able to replicate my actions or learn something. There might be a few rants/papers coming up, but also on the process on some insane projects I did in the past; There are also plans for guides, such as tips and tricks for custom kernels if anyone is interested in that. These plans aren’t fully set in stone and it would be interesting to dive into other things, such as updates on LearnixOS or anything of the like.

Contact

If you want to contact me, my public contact exists on discord primarily: cowmonk (duh)

I don’t really use anything else, unless I really want to doxx myself.