A Window Manager That Refuses to Coddle You
I installed dwm three years ago because I was tired of watching a desktop environment eat 600 megabytes of RAM before I even opened a browser. I stayed because it does exactly one thing and does it without asking for permission. dwm is a dynamic tiling window manager for X11, written in C by the suckless crowd, and it has roughly two thousand lines of source code spread across a handful of files. That is not a typo. The entire window manager you boot into lives in less space than a modern CSS framework. At its core, dwm tiles your windows automatically. When you launch an application, it claims a portion of your screen and rearranges everything else to accommodate it. There is no taskbar by default, no system tray, no settings menu. Everything is driven through keyboard shortcuts hardcoded into the binary. You configure it by opening config.h, changing a few lines, and running make. That recompilation step is the single biggest reason people either fall in love with dwm or walk away from it on day one. I had a specific problem last November that taught me more about how this thing actually works than any documentation ever did. I was compiling a custom build with the fakefullscreen patch because some applications like to hijack window manager hints and refuse to behave in a tiling environment. The compile failed with a linker error that made zero sense at first glance. After about twenty minutes of grep work, I realized the issue: I had enabled fakefullscreen but not enabled the corresponding Xinerama or single-monitor awareness in the patch config. The fix was editing config.mk and adding the right flag before rebuilding. This happens all the time. Every patch you layer on dwm changes the dependency graph, and the error messages will not walk you through it. You will read source code until the problem becomes obvious.
The default layout behavior is where most beginners trip up. dwm uses a master-stack model by default. One window sits in the master area on the left, and the rest stack in a slave column on the right. You can resize the master area with Mod+Shift+comma and Mod+Shift+period. If you have four applications open and they all look cramped, it is usually because you are not using the resize command correctly or you are fighting against an application that ignores size hints. Some Java apps and Electron apps report fixed dimensions that dwm respects reluctantly, which makes them appear as tiny boxes inside a large tile. The workaround is typically Mod+Shift+Return to float the window, then manually resize it, or patch dwm with sizehints so it ignores broken clients altogether. Another counter-intuitive thing about dwm that nobody warns you about: the kill shortcut does not always kill what you expect. Mod+Shift+C closes the focused window, but if you are running a process that does not handle the WM_DELETE_WINDOW protocol properly, the window will close while the process keeps running in the background. I lost an entire SSH session once because I hit that shortcut and the tmux pane appeared to die but the underlying process survived with no visible terminal attached. I found it three hours later using ps aux and had to carefully clean it up. This is not a dwm bug, it is just how X11 works when programs ignore clean shutdown signals. The hotkey scheme uses Mod as the super key by default. Mod+Shift+Return opens a terminal, Mod+Shift+Q kills a window, Mod+j and Mod+k cycle focus between tiles, Mod+h and Mod+l adjust the master area, and Mod+Shift+space toggles a floating window. There are only so many combinations available, so people tend to develop muscle memory within the first week. I would recommend spending two full days doing absolutely nothing but using the keyboard before touching the mouse. The moment you reach for the mouse, you are fighting the design.
Performance is the part that actually justifies the friction. dwm typically idles at around twelve megabytes of RAM. Window switching is instantaneous because there is no compositor doing fancy animations or rendering effects. On older hardware, especially machines with Intel integrated graphics from before 2015, dwm feels noticeably snappier than i3, sway, or any Wayland compositor because it is talking directly to the X server with almost zero middleware between them. If you are running a development workflow with ten terminals, a browser, and a IDE open, the difference in system responsiveness is measurable. The real downside is that dwm assumes you are willing to be uncomfortable. There is no graphical settings dialog, no app menu, and no support for features that the suckless philosophy considers unnecessary bloat. Monitors with different resolutions work but require patching. Bluetooth integration does not exist. Network management is not handled by dwm and you are expected to use something external like networkmanager or a shell script. If you need a desktop environment to manage those things for you, dwm will not. You use it alongside something like dwmblocks or dzen2 for status information, but those are separate projects with their own maintenance cycles. Another limitation worth stating plainly: the suckless development model means patches are applied manually and there is no package management for the patches themselves. When you update dwm from upstream, every patch you applied will need to be reapplied by hand, and some of them may conflict with the new version. I lost an afternoon once because a status bar patch broke silently after an update. The fix involved reading the diff between versions and adjusting the patch to match the new structure. This is normal for this kind of project. If you are not comfortable reading C code and using git, you will struggle more than you should.
Get the Full Details
To get started, you need an X11 setup already running. Clone the source from git.suckless.org/dwm, read config.h carefully, set your favorite terminal emulator path, adjust the colors, add any patches you want by copying the .diff files into the source directory, run make clean all, and install with sudo make install. Then add dwm to your display manager or start it manually from ~/.xinitrc. The whole process takes about ten minutes on a fresh system if nothing breaks. If you hit a compilation error, the output will tell you roughly where to look, but it will not tell you what to change. That part requires reading. I have used dwm as my primary window manager for most of the last three years. It is the kind of tool that stops being interesting after the novelty wears off and just works until something forces you to pay attention to it. That is usually a good sign.
