dwm.suckless.org
dwm
https://dwm.suckless.org
97 comments
I use both i3 (actually Sway) and MacOS on a daily basis and they both support this feature. I agree I could not live without it.
I have never used dwm seriously, but as far as I can tell the main feature it offers over i3 is tagging. I don't really understand how this meaningfully changes the day to day workflow, and I'd love to hear what you consider to be the advantages.
I have never used dwm seriously, but as far as I can tell the main feature it offers over i3 is tagging. I don't really understand how this meaningfully changes the day to day workflow, and I'd love to hear what you consider to be the advantages.
No, the biggest feature of DWM is dynamic window tiling (pretty sure DWM stands for Dynamic Window Manager). Sway/i3 can be made to kinda dynamically tile with scripts, but it's much less consistent, less powerful, and hardly works. They are manual tilers and they don't try to be dynamic tilers.
Personally I prefer being able to quickly toggle a dynamic window layout based on my current workflow, and switch back to manual tiling when I specifically need to manually tile.
Currently I use Sway too as it's the most mature tiling compositor on Wayland, but once River WM[0], also based on wlroots, matures more I think I will likely make the switch because I often miss dynamic tiling.
[0] https://github.com/riverwm/river
On a side note, I hate how window moving works in Sway/i3. I can hardly ever get windows to move to where I want them to go with keyboard. As a result, I have a bind that enters a 'move' mode that takes the current selected window and moves it to a window that I can select. That, or I just use the mouse to drag the window, which is kinda annoying considering this is a keeb focussed environment.
Personally I prefer being able to quickly toggle a dynamic window layout based on my current workflow, and switch back to manual tiling when I specifically need to manually tile.
Currently I use Sway too as it's the most mature tiling compositor on Wayland, but once River WM[0], also based on wlroots, matures more I think I will likely make the switch because I often miss dynamic tiling.
[0] https://github.com/riverwm/river
On a side note, I hate how window moving works in Sway/i3. I can hardly ever get windows to move to where I want them to go with keyboard. As a result, I have a bind that enters a 'move' mode that takes the current selected window and moves it to a window that I can select. That, or I just use the mouse to drag the window, which is kinda annoying considering this is a keeb focussed environment.
fwiw; for i3/sway I use this autotiling script: https://github.com/nwg-piotr/autotiling
Yea, I've used that before but just switching between vertical and horizontal tiling doesn't get you anywhere close to dynamic tiling and on demand layouts.
> I have never used dwm seriously, but as far as I can tell the main feature it offers over i3 is tagging.
What are you specifically referring to when you say "tagging"?
What are you specifically referring to when you say "tagging"?
I think it was explained to me as the ability to tag certain windows with short descriptors and then assign tags or groups of tags to different displays/layouts/panes. The main reason I haven't tried it because I had already switched to Sway and gotten rid of Xorg entirely.
I think the great part is being able to assign multiple tags to a window so it appears under multiple workspaces (same toolbelt as a sticky tag, which can co-exist), and being able to assign multiple tags to a workspace ("Chat" and "Music"). The ability to toggle your music windows in and out of existence, independently of other contexts, feels more like having every window on a hotkey than switching to another entire workspace or using sticky. It abstracts your contexts out from your workspaces and allows you to preform manipulations across those sets. I don't think dwm would let you show the difference (https://en.m.wikipedia.org/wiki/Difference_set) between two tags without a patch (because why?), but if you wanted to you could.
> It's not uncommon with tiling WMs that have good multi-monitor support, but you really can't find it in traditional WMs
That's because this feature is not a Freedesktop standard. The X11 root window have a property _NET_NUMBER_OF_DESKTOPS and a few more[0] to help implement this behavior.
Most tiling WMs choose to ignore this standard in favor of this great feature. But the WMs of Gnome, Xfce, KDE, etc... will probably never implement it just in case some apps don't support it (like some games that needs to be floating windows in tiling WMs).
That's because this feature is not a Freedesktop standard. The X11 root window have a property _NET_NUMBER_OF_DESKTOPS and a few more[0] to help implement this behavior.
Most tiling WMs choose to ignore this standard in favor of this great feature. But the WMs of Gnome, Xfce, KDE, etc... will probably never implement it just in case some apps don't support it (like some games that needs to be floating windows in tiling WMs).
[0] - https://specifications.freedesktop.org/wm-spec/1.3/ar01s03.htmlFreedesktop isn't specifying standards, it just puts out some specs to help interoperability where that is desired but not all specs are expected to be followed and really anyone can propose new specs. It is even in their site:
https://www.freedesktop.org/wiki/Specifications/
> freedesktop.org produces specifications for interoperability, but we are not an official standards body. There is no requirement for projects to implement all of these specifications, nor certification.
Freedesktop doesn't have any sort of authority, while it does provide some useful specs (e.g. the .desktop files are in general useful), not everything they do is like that.
The reason that this isn't found in floating WMs is simply that the developers of those WMs didn't found it useful to implement it, not because of Freedesktop (which BTW could update EWMH to include such a thing, it isn't like it has to be written in stone).
https://www.freedesktop.org/wiki/Specifications/
> freedesktop.org produces specifications for interoperability, but we are not an official standards body. There is no requirement for projects to implement all of these specifications, nor certification.
Freedesktop doesn't have any sort of authority, while it does provide some useful specs (e.g. the .desktop files are in general useful), not everything they do is like that.
The reason that this isn't found in floating WMs is simply that the developers of those WMs didn't found it useful to implement it, not because of Freedesktop (which BTW could update EWMH to include such a thing, it isn't like it has to be written in stone).
This is something I have come to realize I unconsciously have gotten very dependent on - MacOS let's you swap virtual desktops for the monitor you are currently focused on without swapping any of the others. I never realized how intuitive this is until switching back to my XFCE linux installation and getting very frustrated with virtual desktops entirely. I might have to give dwm a try again on my linux machine if it supports this.
Yes! Before I went all-in on desktop Linux, I was a Mac user, and MacOS definitely got virtual desktops exactly right in this regard.
They definitely did not.
OS X has the same issue as a lot of other VMs. You can not simply have a single pool of workspaces and chose to view any N of them, where N is the number of monitors that you have. In OS X you can have workspaces on your left monitor, and workspaces on your right monitor, but you can't easily share the workspaces between the monitors without re-arranging them.
The only WM I have used that gets virtual desktops right for multi monitors is xmonad. Maybe dwm can work the same way, not sure.
In xmonad you can have 10 workspaces and 2 monitors, and pull up any workspace on any monitor. You can have hotkeys to cycle workspaces on either monitor independently and a key to swap the two monitors.
OS X has the same issue as a lot of other VMs. You can not simply have a single pool of workspaces and chose to view any N of them, where N is the number of monitors that you have. In OS X you can have workspaces on your left monitor, and workspaces on your right monitor, but you can't easily share the workspaces between the monitors without re-arranging them.
The only WM I have used that gets virtual desktops right for multi monitors is xmonad. Maybe dwm can work the same way, not sure.
In xmonad you can have 10 workspaces and 2 monitors, and pull up any workspace on any monitor. You can have hotkeys to cycle workspaces on either monitor independently and a key to swap the two monitors.
You can drag a workspace from one monitor to another in native Mac OS. With yabai you can hotkey it to send to a different one.
Not the same at all, really.
My first real job back in 2013 gave all of the devs macbooks to work on. I never used it specifically because osx couldn't do this.
Even now, they still don't get it right and treat each monitor as its own set of desktops.
Even now, they still don't get it right and treat each monitor as its own set of desktops.
Go into System Preferences, Mission Control, and uncheck “Displays have separate spaces”.
Oh if they fixed it that's great! I've got no reason to use it now, but maybe if I had another job like that one it would have been less frustrating.
FWIW: Not trolling, but I believe they added this setting in 2013 with Mavericks.
Now, if macOS could get auto-tiling options like Linux has...
Now, if macOS could get auto-tiling options like Linux has...
Rectangle ?
https://rectangleapp.com/
> I can keep a set of windows on my right monitor, and flip between virtual desktops on my center monitor without the right monitor changing at all.
If you decide that you want to see two workspaces from your center monitor, can you easily pull up one of them on the right monitor? The only thing I've ever used that lets you do this is xmonad (described in another comment below).
If you decide that you want to see two workspaces from your center monitor, can you easily pull up one of them on the right monitor? The only thing I've ever used that lets you do this is xmonad (described in another comment below).
Yup. There's a spot in the default config file to specify a key binding to move the whole virtual desktop to another window.
What’s a pager in the context of a window manager? I’m aware of CLI pagers like less but I’ve never heard the term used with WMs.
It's the little desktop "preview boxes," I guess you'd call them, that you can click on to switch between virtual desktops. Usually running in the taskbar in most desktop environments.
> In contrast to ion, larswm, and wmii [...] dwm has no Lua integration, no 9P support, no shell-based configuration, no remote control, and comes without any additional tools, such as for printing the selection or warping the mouse
Holy cow, some of these features seem really useful. I should look at some of those other window managers!
> customized through editing its source code
Yikes, this is a very bad idea. This kind of customization is very hard to split off from the tool, share, version-control, and verify. Customization in a full, general-purpose imperative programming language is also a bad idea. Either make the tool a platform (Emacs) or use a declarative configuration language.
> Because dwm is customized through editing its source code, it's pointless to make binary packages of it. This keeps its userbase small and elitist.
Suckless tools are developed for the needs (and the benefit) of their own developers, and nobody else. Remember that.
Holy cow, some of these features seem really useful. I should look at some of those other window managers!
> customized through editing its source code
Yikes, this is a very bad idea. This kind of customization is very hard to split off from the tool, share, version-control, and verify. Customization in a full, general-purpose imperative programming language is also a bad idea. Either make the tool a platform (Emacs) or use a declarative configuration language.
> Because dwm is customized through editing its source code, it's pointless to make binary packages of it. This keeps its userbase small and elitist.
Suckless tools are developed for the needs (and the benefit) of their own developers, and nobody else. Remember that.
>> Because dwm is customized through editing its source code
> Suckless tools are developed for the needs (and the benefit) of their own developers, and nobody else. Remember that.
Just to flip this on it's head a bit (because different perspectives are more illuminating than crude dichotomies).
One of the underlying principles they use to justify not supporting external configuration, is minimal code. The absence of configs are one of many sacrifices they make for their ~1000 line limit. So on the face of it, it seems elitist, but on the other hand this principle makes the code significantly more accessible... one group (non programmers) have been more excluded; another group (programmers of almost all stripes) have had the barrier to entry significantly lowered due to this principle, not only to configure it, but to very feasibly change any aspect of it as they see fit.
> Suckless tools are developed for the needs (and the benefit) of their own developers, and nobody else. Remember that.
Just to flip this on it's head a bit (because different perspectives are more illuminating than crude dichotomies).
One of the underlying principles they use to justify not supporting external configuration, is minimal code. The absence of configs are one of many sacrifices they make for their ~1000 line limit. So on the face of it, it seems elitist, but on the other hand this principle makes the code significantly more accessible... one group (non programmers) have been more excluded; another group (programmers of almost all stripes) have had the barrier to entry significantly lowered due to this principle, not only to configure it, but to very feasibly change any aspect of it as they see fit.
strong disagree because an artificial codebase size limit doesn't make the codebase more accessible, it makes it worse.
Well designed code isn't primarily short, it's readable, modular, extensible and so on. This isn't the case for dwm. Simplest example, to enable extensions in the form of patches you basically have to apply diffs and because everything is just one giant pile of code even applying two entirely unrelated features can break depending on the order of the patch application.
This isn't elitist in the sense of applying best programming standards, it's elitist in the sense of "if you want to join the club you get hazed first"
Well designed code isn't primarily short, it's readable, modular, extensible and so on. This isn't the case for dwm. Simplest example, to enable extensions in the form of patches you basically have to apply diffs and because everything is just one giant pile of code even applying two entirely unrelated features can break depending on the order of the patch application.
This isn't elitist in the sense of applying best programming standards, it's elitist in the sense of "if you want to join the club you get hazed first"
If you know C, the fact that dwm's code is only ~2000 lines long makes it far more accessible than any other window manager. You can fairly easily read the source code in an afternoon and fit the whole thing in your head, then make whatever changes you want. (I've done it! For what it's worth, the code is pretty well-factored and easy to understand.) You don't have to worry about how any of your changes interact with some complicated configuration system, scripting language binding, or IPC protocol.
If you don't know C, you benefit from your window manager offering things like scripting language bindings. The overall system becomes more complex and harder to debug, but it's easier to do simple things like change the color scheme.
So when dwm says they're "elitist", they mean that they haven't tried to make their window manager cater to people who don't know C. Luckily, there are a lot of other window managers out there that are better suited to those people.
If you don't know C, you benefit from your window manager offering things like scripting language bindings. The overall system becomes more complex and harder to debug, but it's easier to do simple things like change the color scheme.
So when dwm says they're "elitist", they mean that they haven't tried to make their window manager cater to people who don't know C. Luckily, there are a lot of other window managers out there that are better suited to those people.
Can reading a configuration value from a file (something that can be abstracted away in a fairly simple single function) really make code so much more complicated than hard coding that configuration value in code?
You can probably make a small function to do it, but then it might take more than you imagine to do it robustly... then there are 1000 other "small" features like this, if you accept them all you wouldn't have a small code base any-more. They are just pretty brutal about what is and what isn't worth a line of code.
> Suckless tools are developed for the needs (and the benefit) of their own developers, and nobody else. Remember that.
This a key point. I personally would rather work in Lua than C; the Suckless developers feel the opposite way. This is fine, except when the Suckless developers imply that people who make different technical decisions are inferior or ignorant.
This a key point. I personally would rather work in Lua than C; the Suckless developers feel the opposite way. This is fine, except when the Suckless developers imply that people who make different technical decisions are inferior or ignorant.
It's suckless. Once you know them and their goals none of this is surprising.
I'm not even sure what they actually use computers for at all, it always seems like lightweight enthusiasts actually do less with tech than average people, if you don't count random tinkering and stuff they do at work.
Their goals are just... very different from most.
I'm not even sure what they actually use computers for at all, it always seems like lightweight enthusiasts actually do less with tech than average people, if you don't count random tinkering and stuff they do at work.
Their goals are just... very different from most.
>Suckless tools are developed for the needs (and the benefit) of their own developers, and nobody else. Remember that.
Another way of putting it is: if you can use it, you become a suckless developer :)
Another way of putting it is: if you can use it, you become a suckless developer :)
Another way of putting that is "you are required to become a developer in order to use the tool." Great for developer community, but not great for the average user (or even the above-average user - say, 98th percentile) who wants to use computers for the purpose for which they were intended (and are amazing at) - labor-saving devices.
Heck, even as a developer, I would always rather use a tool that doesn't require me to learn the internals in order for me to use it at a basic level of proficiency. Wouldn't you? (probably not in your specific case - I'm addressing the median HN user) Isn't that the point of abstraction and API boundaries?
If your goal is to make software that artificially requires others to invest a lot of needless time and effort in order to use it, or if you like creating beautiful pieces of code-art then suckless is for you.
If your goal is to build software that saves other humans time and effort, the suckless philosophy is absolutely the opposite thing of what you want[1].
[1] https://news.ycombinator.com/item?id=29941395
Heck, even as a developer, I would always rather use a tool that doesn't require me to learn the internals in order for me to use it at a basic level of proficiency. Wouldn't you? (probably not in your specific case - I'm addressing the median HN user) Isn't that the point of abstraction and API boundaries?
If your goal is to make software that artificially requires others to invest a lot of needless time and effort in order to use it, or if you like creating beautiful pieces of code-art then suckless is for you.
If your goal is to build software that saves other humans time and effort, the suckless philosophy is absolutely the opposite thing of what you want[1].
[1] https://news.ycombinator.com/item?id=29941395
>I would always rather use a tool that doesn't require me to learn the internals in order for me to use it at a basic level of proficiency. Wouldn't you?
In general, I agree, but there is a lot to be said for stripping the cruft out of systems that should be simple. Window management is not complicated - the fact that dwm is functional by default at <2k lines of C is evidence of this.
>If your goal is to make software that artificially requires others to invest a lot of needless time and effort in order to use it...
It is not made artificially difficult. It is just not made artificially easy either. The codebase is organized in a way that optimizes reading it and understanding its function. If you have done anything in C before, you will be up and making small modifications within 10-20 minutes.
Despite the tongue-in-cheek celebration of "elitism," people are more than happy to take a look at your code and tell you what you are doing wrong, and getting my dwm desktop to where I want it took about an afternoon, which is not something I can say of i3, GNOME, KDE, etc.
All of that said, the whole point is that it's not for everyone. If you don't like it, don't use it!
In general, I agree, but there is a lot to be said for stripping the cruft out of systems that should be simple. Window management is not complicated - the fact that dwm is functional by default at <2k lines of C is evidence of this.
>If your goal is to make software that artificially requires others to invest a lot of needless time and effort in order to use it...
It is not made artificially difficult. It is just not made artificially easy either. The codebase is organized in a way that optimizes reading it and understanding its function. If you have done anything in C before, you will be up and making small modifications within 10-20 minutes.
Despite the tongue-in-cheek celebration of "elitism," people are more than happy to take a look at your code and tell you what you are doing wrong, and getting my dwm desktop to where I want it took about an afternoon, which is not something I can say of i3, GNOME, KDE, etc.
All of that said, the whole point is that it's not for everyone. If you don't like it, don't use it!
[deleted]
>Suckless tools are developed for the needs (and the benefit) of their own developers, and nobody else. Remember that.
You say that as if it's some kind of terrible problem? seems fine to me.
If you don't like it, I guess it's not for you
You say that as if it's some kind of terrible problem? seems fine to me.
If you don't like it, I guess it's not for you
I have nevertheless been a happy user of the binary openbsd package for more than 10 years.
[deleted]
The zen of dwm is endlessly browsing this list of patches and eventually adding so many that any new patches cause merge errors that take a long time to untangle: https://dwm.suckless.org/patches/
Reminds me of early 00s phpBB MODs (which they allcapped to avoid confusion with moderators). It ended up this horrific syntax (http://web.archive.org/web/20041010114405/http://www.phpbb.c... ) that functioned as both a bbcode forum post for manual instructions that didn't look too out of place for people to manually apply but also parseable for auto installers like easy mod.
Then it turned into this XML file format in 3.0, which was similar in spirit but a more regular language made it less easy to screw up. XSL was used to make the "go edit it yourself" instructions version: http://web.archive.org/web/20160310004103/https://www.phpbb....
It looks like they've finally ported to a real plugin system (https://www.phpbb.com/extensions/), but I had my fill of extend by patching in those days.
Then it turned into this XML file format in 3.0, which was similar in spirit but a more regular language made it less easy to screw up. XSL was used to make the "go edit it yourself" instructions version: http://web.archive.org/web/20160310004103/https://www.phpbb....
It looks like they've finally ported to a real plugin system (https://www.phpbb.com/extensions/), but I had my fill of extend by patching in those days.
Isn't that what https://github.com/bakkeby/dwm-flexipatch is made for?
eh, perhaps, but I'd never use it. I used dwm because I loved staring at that code and modifying it to my needs, and all those preprocessor directives are frankly horrifying. I'm sure this would have been much more practical, but I stopped using dwm in the name of practicality anyways.
that would make for a fun gentoo ebuild
I cycled through dwm at one point. The thing that killed me was that on my nvidia machine, for some reason it would flash when I changed desktops, like the draw order was wrong. i3 is the only tiling window manager that didn't, I think because it uses xcb instead of xlib.
I love the magical bullshit in the description. Each line contains some face palm.
> dwm doesn't distinguish between layers: there is no floating or tiled layer. Whether or not the clients of currently selected tag(s) are in tiled layout, you can rearrange them on the fly. Popup and fixed-size windows are always floating, however.
Ok so it does have floating then?
> Because dwm is customized through editing its source code, it's pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions. There are some distributions that provide binary packages though.
Ok so you can package then....?
> dwm is only a single binary, and its source code is intended to never exceed 2000 SLOC.
Strange flex but ok.
> dwm has no Lua integration, no 9P support, no shell-based configuration, no remote control, and comes without any additional tools, such as for printing the selection or warping the mouse.
It uses x, x warps the mouse.
> 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.
ok so there is input that could hacked (not saying there IS, but if you process strings or floats from the user those can contain unexpected values).
All that said, suckless tools are nice, just think the mindset is hilarious.
I love the magical bullshit in the description. Each line contains some face palm.
> dwm doesn't distinguish between layers: there is no floating or tiled layer. Whether or not the clients of currently selected tag(s) are in tiled layout, you can rearrange them on the fly. Popup and fixed-size windows are always floating, however.
Ok so it does have floating then?
> Because dwm is customized through editing its source code, it's pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions. There are some distributions that provide binary packages though.
Ok so you can package then....?
> dwm is only a single binary, and its source code is intended to never exceed 2000 SLOC.
Strange flex but ok.
> dwm has no Lua integration, no 9P support, no shell-based configuration, no remote control, and comes without any additional tools, such as for printing the selection or warping the mouse.
It uses x, x warps the mouse.
> 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.
ok so there is input that could hacked (not saying there IS, but if you process strings or floats from the user those can contain unexpected values).
All that said, suckless tools are nice, just think the mindset is hilarious.
To package it would defeat the point.
The point is that the software that you're using to manage your computer is simple enough that you can read all of it and understand it -- not that you have to, but you could.
The official method for "extensions" to DWM is in the form of Git patches (https://dwm.suckless.org/patches/). You apply the patch and re-compile. If you had dwm through your package manager, you wouldn't be able to apply any patches, because you would just have the binary.
>Ok so it does have floating then?
What's meant by the quoted text is that you can cycle through all windows on your current workspace, including the floating ones, using only your keyboard. Yes, it does have floating.
edit: I should also say, the real power move for me is that I can just fork the dwm git repo on github, and have my exact desktop configuration available to me 24/7 from anywhere, and I can deploy it on a potato.
The point is that the software that you're using to manage your computer is simple enough that you can read all of it and understand it -- not that you have to, but you could.
The official method for "extensions" to DWM is in the form of Git patches (https://dwm.suckless.org/patches/). You apply the patch and re-compile. If you had dwm through your package manager, you wouldn't be able to apply any patches, because you would just have the binary.
>Ok so it does have floating then?
What's meant by the quoted text is that you can cycle through all windows on your current workspace, including the floating ones, using only your keyboard. Yes, it does have floating.
edit: I should also say, the real power move for me is that I can just fork the dwm git repo on github, and have my exact desktop configuration available to me 24/7 from anywhere, and I can deploy it on a potato.
> Because dwm is customized through editing its source code, it's pointless to make binary packages of it. This keeps its userbase small and elitist.
This is the zen of suckless. Unlike other projects that desperately reach for users anywhere they can get them and then suffer the resulting bloat, suckless knows exactly who they are building for.
It’s a tough thing to swallow but embracing the opposite of the suckless zen is probably a large part of why modern software is so bad. The more we try to pretend it should be possible for all people to program or use computers in general, the worse software becomes.
This is the zen of suckless. Unlike other projects that desperately reach for users anywhere they can get them and then suffer the resulting bloat, suckless knows exactly who they are building for.
It’s a tough thing to swallow but embracing the opposite of the suckless zen is probably a large part of why modern software is so bad. The more we try to pretend it should be possible for all people to program or use computers in general, the worse software becomes.
There's a middle ground though.
I think most people would consider OpenBSD for instance to be "small." It comes packed full of tools, many of which you might never use. Many things come with "user friendly" config formats. I don't think anyone in their right mind would call it bloated (as far as reasonably modern unixalikes are concerned), but it's also far from being so minimalistic as to require you to configure things at source level.
And in OpenBSD, you find this window manager called cwm. It's not exactly comparable; hardcore dwm users would no doubt be very disappointed with it. However, I use both WMs and both suck & are good in their own ways. cwm has a config format and you don't need a compiler and the entire toolchain to be able to configure it. On the other hand, you don't have all the useful patches people have made for dwm over the years. cwm is small, and not bloated.
I think most people would consider OpenBSD for instance to be "small." It comes packed full of tools, many of which you might never use. Many things come with "user friendly" config formats. I don't think anyone in their right mind would call it bloated (as far as reasonably modern unixalikes are concerned), but it's also far from being so minimalistic as to require you to configure things at source level.
And in OpenBSD, you find this window manager called cwm. It's not exactly comparable; hardcore dwm users would no doubt be very disappointed with it. However, I use both WMs and both suck & are good in their own ways. cwm has a config format and you don't need a compiler and the entire toolchain to be able to configure it. On the other hand, you don't have all the useful patches people have made for dwm over the years. cwm is small, and not bloated.
Elitist (and not elite) is correct: my experience as an observer in the *nix "ricing" community is that there's a weak negative correlation between obsessive suckless tool use and programming competency. "Fetishistic" users are over-represented in suckless's userbase.
Source: dmenu user.
Source: dmenu user.
> there's a weak negative correlation between obsessive suckless tool use and programming competency
So basically what you're trying to say is that the people who use suckless tools are incompetent programmers?
So basically what you're trying to say is that the people who use suckless tools are incompetent programmers?
I wouldn't go as far as to say that categorically, since I know a lot of very competent programmers who use individual suckless tools. But it's been my observation that a lot of "hyper-minimal"/"code as configuration" ricer-types tend to both use suckless tools and not be great programmers.
> The more we try to pretend it should be possible for all people to program or use computers in general, the worse software becomes.
I was 100% with you until that last sentence. For me, it's just an important reminder that software isn't just a commercial endeavor, or just a job, but can be artistry, hobby, and tool. And that each of those are vibrant enough to support and serve their own overlapping communities.
I definitely miss the heart and aesthetics of software some days, so I get the cynism!
Signed - dmenu fan
I was 100% with you until that last sentence. For me, it's just an important reminder that software isn't just a commercial endeavor, or just a job, but can be artistry, hobby, and tool. And that each of those are vibrant enough to support and serve their own overlapping communities.
I definitely miss the heart and aesthetics of software some days, so I get the cynism!
Signed - dmenu fan
Well my point is that we pretend programming can be easy by allowing people to program in JavaScript, for example. Sure this has resulted in a boon of apps but the downside is that the average quality of these apps is pretty low in terms of performance-oriented usability and probably in terms of bugs as well.
I sometimes use retro computers and marvel at how well the software for those machines runs. The only difference i can guess is that the average developer ability was higher.
I sometimes use retro computers and marvel at how well the software for those machines runs. The only difference i can guess is that the average developer ability was higher.
I think this way over-romanticizes what that era actually produced and ignores the huge breakthroughs since then. So many things would not exist if participation was limited only to the kind of people that were writing software in the 80s and 90s. Many of the landmark brands of today were not thought up or written by such people.
Also, I strongly feel like old software "runs better" because neither the OS nor the software itself practically did anything. The security model was "be a good citizen." Graphics programming meant writing to a big buffer and then copying it to the screen. Oh your native language isn't representable in ASCII? It reads right-to-left? You are colorblind and need to apply a color transform to the display? Too bad. Those things aren't "clean and simple" code and the team of 30-something 1337 guys that wrote wasn't imagining you when deciding how the program would work.
Also it's not like these programs aren't still available. Did you write this comment using lynx? Do you do your finances with "gnome spreadsheet?" Do you listen to music with WinAmp 2.0? Do you moan in frustration every time you find a long, informative Wikipedia article, undoubtedly written by someone who doesn't understand cache lines, or even CSS? I don't even though I used to (well not the last one). I've moved on to objectively better things.
We're way, way better off with lower barriers and increased participation because it's additive. Despite electron being a thing or Visual Studio ushering in an era of "GUI builder + simple callback" apps, suckless still exists.
Also, I strongly feel like old software "runs better" because neither the OS nor the software itself practically did anything. The security model was "be a good citizen." Graphics programming meant writing to a big buffer and then copying it to the screen. Oh your native language isn't representable in ASCII? It reads right-to-left? You are colorblind and need to apply a color transform to the display? Too bad. Those things aren't "clean and simple" code and the team of 30-something 1337 guys that wrote wasn't imagining you when deciding how the program would work.
Also it's not like these programs aren't still available. Did you write this comment using lynx? Do you do your finances with "gnome spreadsheet?" Do you listen to music with WinAmp 2.0? Do you moan in frustration every time you find a long, informative Wikipedia article, undoubtedly written by someone who doesn't understand cache lines, or even CSS? I don't even though I used to (well not the last one). I've moved on to objectively better things.
We're way, way better off with lower barriers and increased participation because it's additive. Despite electron being a thing or Visual Studio ushering in an era of "GUI builder + simple callback" apps, suckless still exists.
Arguably, lowering the barrier to adoption has caused entrepreneurs who might not have otherwise cared about "that software thing" to find every possible nook and cranny to put in increasingly hostile monetization schemes to applications that wouldn't have had them otherwise. It's gotten to the point that people have figured out how to make others pay for JPEGs. That might just be a thing to laugh off if the same breed of technology didn't have the potential to saturate the Earth's entire energy capacity.
In terms of the greater concept of technology adoption, mandated facial recognition and apps for accessing crucial government/financial services only started making sense once smartphones had become useful enough to the average person from being an objectively better way of consuming information, such that nearly everyone decided to purchase and use one. That was because so many engineers and other people had eyes on the technology given its objective utility, and they all contributed to its uprising.
Despite this, I highly doubt that the elitist technological separation that suckless proposes would ever come to pass in the real world. We're simply too smart to not find better ways of manipulating burnt sand on our own, whether or not they exist to serve some powerful entity's ulterior motive.
In terms of the greater concept of technology adoption, mandated facial recognition and apps for accessing crucial government/financial services only started making sense once smartphones had become useful enough to the average person from being an objectively better way of consuming information, such that nearly everyone decided to purchase and use one. That was because so many engineers and other people had eyes on the technology given its objective utility, and they all contributed to its uprising.
Despite this, I highly doubt that the elitist technological separation that suckless proposes would ever come to pass in the real world. We're simply too smart to not find better ways of manipulating burnt sand on our own, whether or not they exist to serve some powerful entity's ulterior motive.
> Those things aren't "clean and simple" code and the team of 30-something 1337 guys that wrote wasn't imagining you when deciding how the program would work.
If those 1337 guys were tasked with writing software to accommodate those use cases, I’m certain it would be better than software today that accommodates those use cases
> Also it's not like these programs aren't still available. Did you write this comment using lynx? Do you do your finances with "gnome spreadsheet?" Do you listen to music with WinAmp 2.0?
I was referring to 80s software, not 90s software. In terms of architecture, 90s software is closer to the software of today than the software of the 80s.
If those 1337 guys were tasked with writing software to accommodate those use cases, I’m certain it would be better than software today that accommodates those use cases
> Also it's not like these programs aren't still available. Did you write this comment using lynx? Do you do your finances with "gnome spreadsheet?" Do you listen to music with WinAmp 2.0?
I was referring to 80s software, not 90s software. In terms of architecture, 90s software is closer to the software of today than the software of the 80s.
But they weren't directed to accommodate those use cases, even though those people existed.
there's something especially annoying about building the worst performing terminal (https://danluu.com/term-latency/) while having 5% of features and proclaiming everyone else's software sucks
That particular benchmark is running st on macOS using Apple's XQuartz emulation layer. That's naturally a lot slower than running st on the operating system it was written for (see the "linux-st" line on the chart). And if I'm reading the table in that post correctly, st still used one-tenth the memory of any other terminal tested.
But yes, if you use macOS, st is probably not the terminal for you.
But yes, if you use macOS, st is probably not the terminal for you.
userbases ideally drive investment into software too
the scope of suckless software will always be rather limited. one of the reasons their distro failed. but judging by how their elitism is not just tongue in cheek, most of them likely run LFS anyway. they seem like the kind of people that look at gentoo and decide that's not enough micromanagement for them.
the scope of suckless software will always be rather limited. one of the reasons their distro failed. but judging by how their elitism is not just tongue in cheek, most of them likely run LFS anyway. they seem like the kind of people that look at gentoo and decide that's not enough micromanagement for them.
There are options between those opposites, though. Here's my preferred point[1] in the space of possibilities:
It's impossible for all people to effectively use software over the long term without learning about its internals. Software can help people learn about its internals.
[1] https://github.com/akkartik/teliva#readme
It's impossible for all people to effectively use software over the long term without learning about its internals. Software can help people learn about its internals.
[1] https://github.com/akkartik/teliva#readme
> embracing the opposite of the suckless zen is probably a large part of why modern software is so bad
Yes, so don't embrace the opposite of suckless - shoot for a nice middle-ground.
The suckless philosophy is antithetical to the purpose of computers, which is as time-saving, labor-saving, collaborative automation devices. Here's what I wrote on Lobsters:
---------------------------------
Unfortunately, the suckless philosophy leads to software that doesn’t do what software is meant to do - alleviate human work by making the machine do it instead. The suckless philosophy of “simplicity” translates to “simplistic software that doesn’t do what you would need it to do, so either you waste time re-implementing features that other people have already written (or would have written), or you do the task by hand instead”.
If, when required to choose exactly one of “change the software to reduce user effort” and “make the code prettier”, you consistently choose the latter, you’re probably not a software engineer - you’re an artist, making beautiful code art, for viewing purposes only. You definitely aren’t writing programs for other people to use, whether you think you are or not.
This philosophy (and the results) are why I switched away from dmenu to rofi - because rofi provided effort-saving features that were valuable to me out-of-the-box, while dmenu did not. (I used dmenu for probably a year - but it only took me a few minutes with rofi to realize its value and switch) rofi is more valuable as a tool, as a effort-saving device, than dmenu is, or ever will be.
In other words - the suckless philosophy, when followed, actively makes computers less useful as tools (because, among other things, computers are communication and collaboration devices, and the suckless philosophy excludes large collaborative projects that meet the needs of many users). This is fine if your purpose is to make art, or to only fulfill your own needs - just make sure that you clearly state to other potential users that your software is not meant for them to make use of.
Also note that the most-used (and useful) tools follow exactly the opposite of the suckless philosophy - Firefox, Chromium, Windows, Libreoffice, Emacs, VSCode, Syncthing, qmk, fish, gcc, llvm, rustc/cargo, Blender, Krita, GIMP, Audacity, OBS, VLC, KiCad, JetBrains stuff, and more - not just the ones that are easy to use, but also ones that are hard to use (Emacs, VSCode, Audacity, Blender, JetBrains) but meet everyone’s needs, and are extensible by themselves (as opposed to requiring integration with other simple CLI programs).
There’s a reason for this - these programs are more useful to more people than anything suckless-like (or built using the Unix philosophy, which shares many of the same weaknesses). So, if you’re writing software exclusively for yourself, suckless is great - but if you’re writing software for other people (either as an open-source project, or as a commercial tool), it sucks.
To top it off, people writing open-source software using the suckless philosophy aren’t contributing to non-suckless projects that are useful to other people - so the rest of the open-source community loses out, too.
Yes, so don't embrace the opposite of suckless - shoot for a nice middle-ground.
The suckless philosophy is antithetical to the purpose of computers, which is as time-saving, labor-saving, collaborative automation devices. Here's what I wrote on Lobsters:
---------------------------------
Unfortunately, the suckless philosophy leads to software that doesn’t do what software is meant to do - alleviate human work by making the machine do it instead. The suckless philosophy of “simplicity” translates to “simplistic software that doesn’t do what you would need it to do, so either you waste time re-implementing features that other people have already written (or would have written), or you do the task by hand instead”.
If, when required to choose exactly one of “change the software to reduce user effort” and “make the code prettier”, you consistently choose the latter, you’re probably not a software engineer - you’re an artist, making beautiful code art, for viewing purposes only. You definitely aren’t writing programs for other people to use, whether you think you are or not.
This philosophy (and the results) are why I switched away from dmenu to rofi - because rofi provided effort-saving features that were valuable to me out-of-the-box, while dmenu did not. (I used dmenu for probably a year - but it only took me a few minutes with rofi to realize its value and switch) rofi is more valuable as a tool, as a effort-saving device, than dmenu is, or ever will be.
In other words - the suckless philosophy, when followed, actively makes computers less useful as tools (because, among other things, computers are communication and collaboration devices, and the suckless philosophy excludes large collaborative projects that meet the needs of many users). This is fine if your purpose is to make art, or to only fulfill your own needs - just make sure that you clearly state to other potential users that your software is not meant for them to make use of.
Also note that the most-used (and useful) tools follow exactly the opposite of the suckless philosophy - Firefox, Chromium, Windows, Libreoffice, Emacs, VSCode, Syncthing, qmk, fish, gcc, llvm, rustc/cargo, Blender, Krita, GIMP, Audacity, OBS, VLC, KiCad, JetBrains stuff, and more - not just the ones that are easy to use, but also ones that are hard to use (Emacs, VSCode, Audacity, Blender, JetBrains) but meet everyone’s needs, and are extensible by themselves (as opposed to requiring integration with other simple CLI programs).
There’s a reason for this - these programs are more useful to more people than anything suckless-like (or built using the Unix philosophy, which shares many of the same weaknesses). So, if you’re writing software exclusively for yourself, suckless is great - but if you’re writing software for other people (either as an open-source project, or as a commercial tool), it sucks.
To top it off, people writing open-source software using the suckless philosophy aren’t contributing to non-suckless projects that are useful to other people - so the rest of the open-source community loses out, too.
I've been using dwm for years. Oddly enough, I almost always keep it in monocle mode (one window at a time that takes up the entire screen). I rarely find myself wanting to look at two or more windows at once. More often, tmux seems the more appropriate place to split windows. Monocle mode also seems to help me stay focused.
Of course, when I do really need multiple windows, tiling mode is an Alt-t away.
I enjoy using a simple program to meet my simple needs.
Of course, when I do really need multiple windows, tiling mode is an Alt-t away.
I enjoy using a simple program to meet my simple needs.
Before you even ask: yes, there's a port for Wayland: https://github.com/djpohly/dwl
The feature everyone overlooks in this window manager is that it presents windows according to the set of selected tags, and tags can be added or removed from windows on the fly (this is the 'd' in 'dwm'). Aside from its predecessor wmii, I have not been able to find another window manager with this functionality, and I really miss it on my Wayland systems. Once you're accustomed to dynamic tagging it's difficult to return to the restrictive 'workspace/desktop' paradigm.
According to this[0] comment there is a wayland equivalent called dwl[1]? Have not tried it myself - latest commit 3 months ago
[0] https://news.ycombinator.com/item?id=29940855 [1] https://github.com/djpohly/dwl
[0] https://news.ycombinator.com/item?id=29940855 [1] https://github.com/djpohly/dwl
Dwm has inspired many users to exercise freedom 1 with own modifications (patches), forks and rewrites in other languages: for instance Xmonad, awesome, and even a Microsoft Windows port. And adaptions for emacs, too. Of course. Hell, even for vim! :o
It "inspired" them because dwm is functionally incomplete and requires a complete redesign. Something like xmonad also does the "my wm is actually library and I wrote the wm with it" approach, but is designed in a way to support code reuse and sharing. It's infinitely better, imo.
I am an avid user of dmenu, it is absolutely fantastic, there's nothing as easy as pressing a key (or two) and then typing what I'm trying to launch, with autocompletion as well. I know a lot of DEs are incorporating a launch box in the menu directly, and I like the double utility but usually these menus are just too busy. A simple menu like the good ol gnome 2 days with a text box would be perfect, but alas this does not really exist, its either all or nothing.
DWM though, having to compile it every time you want to change the configuration is too much.
DWM though, having to compile it every time you want to change the configuration is too much.
I tried DWM, and I think it's pretty cool. But extending the functionality through C, and the limited set of patches, kind of bothered me. I wanted to essentially DIY my own window manager, but with a language that's a bit quicker to write, and less a burden to think about.
For this, I highly recommend AwesomeWM. Been my daily driver for half a year now. I absolutely love it. It's scripted with Lua, so it's still snappy, while being easy to extend. The only downside is the *meh* documentation, but it's still usable.
For this, I highly recommend AwesomeWM. Been my daily driver for half a year now. I absolutely love it. It's scripted with Lua, so it's still snappy, while being easy to extend. The only downside is the *meh* documentation, but it's still usable.
AwesomeWM has been my daily driver for 6 years now. was using i3 for a few years before that. Awesome definitely hits the sweet spot for me.
Kind of like ratpoison with a mouse? [0]
[0] https://www.nongnu.org/ratpoison/
[0] https://www.nongnu.org/ratpoison/
Please check out DWM flexipatch for a painless way to try out patches and get your setup right!
You can turn patches on and off at will, without having to mess with diffs. Once you get it right you can finalize your config with a separate script. It is like magic. There are also flexipatch repos for st and dmenu
https://github.com/bakkeby/dwm-flexipatch
You can turn patches on and off at will, without having to mess with diffs. Once you get it right you can finalize your config with a separate script. It is like magic. There are also flexipatch repos for st and dmenu
https://github.com/bakkeby/dwm-flexipatch
Check also Awesome WM, which is a successor of dwm configurable/scriptable with lua.
dwm requires you to configure your environment in C, and recompile the project.
>> 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).
From a usability perspective, that's pretty awful.
Stick with i3 for a happier time.
>> 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).
From a usability perspective, that's pretty awful.
Stick with i3 for a happier time.
Just in case you thought about using Suckless/dwm:
They’re doing literal torch hikes through southern Germany at their conferences, fighting online against "cultural marxism", and their mail server has the hostname "Wolfsschanze" (see: https://twitter.com/pid_eins/status/1113738766471057408)
Source: https://twitter.com/kuschku/status/1156488420413362177
They’re doing literal torch hikes through southern Germany at their conferences, fighting online against "cultural marxism", and their mail server has the hostname "Wolfsschanze" (see: https://twitter.com/pid_eins/status/1113738766471057408)
Source: https://twitter.com/kuschku/status/1156488420413362177
From linked page:
"This keeps its userbase small and elitist. No novices asking stupid questions."
From Wikipedia's definition of Eugenics:
"Eugenics is a set of beliefs and practices that aim to improve the genetic quality of a human population, historically by excluding people and groups judged to be inferior or promoting those judged to be superior."
"This keeps its userbase small and elitist. No novices asking stupid questions."
From Wikipedia's definition of Eugenics:
"Eugenics is a set of beliefs and practices that aim to improve the genetic quality of a human population, historically by excluding people and groups judged to be inferior or promoting those judged to be superior."
Filtering out the inexperienced has nothing at all to do with genetics.
The mindset behind that attitude, however, is pretty much the same.
And what would that be?
Disrespect for people perceived as inferior because of limited knowledge in one field. Those elitists totally ignore that the newbie asking stupid questions about a Linux app could be the heart surgeon who one day saves their mommy's life.
what a stupid misunderstanding and interpolation of it! Very few software is so accessible than suckless to anyone who wishes to use and fully understand it. Reading a source of 2000 lines is a comprehensible size indeed and there's no barrier. Quite the contrary: helpful manpages, web-browsable file trees and comments in the sources, mailinglist archives, tons of reviews in blogs and youtube, irc.
It's interesting to see where support for certain ideologies intersect. Suckless philosophy seems to be rooted in a disgust for "complex, error-prone and slow software", and they seem to have conservative tendencies towards new software tools/practices. Applying those ideas to multiculturalism could land you pretty near Nazism.
What's interesting is I was actually drawn to suckless several years ago, and used dwm for a while. At the time, my work had me maintaining a disturbingly bug-ridden codebase, and it gave me a visceral disgust for bad code. Suckless was really compelling. They seemed to hate all the things I hated, and promised a solution.
Eventually I changed jobs, grew out of it, and found more interesting solutions. Oh well, at least it wasn't a bout of National Socialism.
What's interesting is I was actually drawn to suckless several years ago, and used dwm for a while. At the time, my work had me maintaining a disturbingly bug-ridden codebase, and it gave me a visceral disgust for bad code. Suckless was really compelling. They seemed to hate all the things I hated, and promised a solution.
Eventually I changed jobs, grew out of it, and found more interesting solutions. Oh well, at least it wasn't a bout of National Socialism.
what else to expect from a "KDE developer. Qt/QML and full stack developer. Work at Nextcloud. Opinion are my own."
Don't forget the time they waded into the Debian mailing list to argue "maybe Hitler wasn't actually bad"
https://web.archive.org/web/20190404153507/https://lists.dyn...
https://web.archive.org/web/20190404153507/https://lists.dyn...
I am not involved in suckless, but who is this "they" you are talking about? This is one individual whose only connection to suckless appears to have been starting 2 threads about surf in 2017?
https://lists.suckless.org/dev/author.html
ctrl f "enrico"
https://lists.suckless.org/dev/author.html
ctrl f "enrico"
I read the whole post and might have missed the part you are referencing here- can you provide a direct quote?
And don't forget to check for recurring libel motives: systemd proponents, KDE-developers or lbgt extraverts like the "lady" with the torch light story. You can tell which way the wind is blowing.
> lbgt extraverts like the "lady" with the torch light story.
Is there a joke I'm missing or why are you using quotes there?
Is there a joke I'm missing or why are you using quotes there?
just use bspwm!
dwm is not my daily driver, but it’s incredibly easy to be productive with the default config – it’s my go-to on my distro of choice (Fedora) on machines that aren’t both mine and intended for long-term use.
bspwm is somewhat more painful to install and configure in my experience (though also great once it’s set up), and afaik it does not have an easy config for the right-side window stack that is a key selling point of dwm to me.
bspwm is somewhat more painful to install and configure in my experience (though also great once it’s set up), and afaik it does not have an easy config for the right-side window stack that is a key selling point of dwm to me.
I would say you use DWM for the suckless philosophy of it at this point, but it is historically important as one of the major early tiling window managers during this current wave that starting around the late naugties. deserves some recognition. It a bit later that bspwm was written, and now it has gained some traction in the "ricing" community. DWM was sort of a default choice for the minimal tiling WM. However, it wasn't for me, I used Subtle for its features and than XMonad for the Haskell experience.
Now I've actually settled into enjoying EXWM the most, feels very natural to have everything to at least appear to be inside emacs. My point is that there is no right tiling window manager.
Now I've actually settled into enjoying EXWM the most, feels very natural to have everything to at least appear to be inside emacs. My point is that there is no right tiling window manager.
Came here to say this. Bspwm is like Emacs - it's the basis to make your own window manager however you want it!
I think I'll forever be on bspwm <3
I think I'll forever be on bspwm <3
Definitely, I use bspwm for my work computer and its great.
For me, the killer feature (aside from tiling vs overlapping) is that on my three monitors, I can switch virtual desktops independently on each monitor. After being able to do this, I don't understand why every window manager doesn't offer this. It's not uncommon with tiling WMs that have good multi-monitor support, but you really can't find it in traditional WMs. There's an unmaintained patch of openbox--openbox-multihead--that added the feature, and there's an "experimental" hybrid window manager written in Go (by the same author of the openbox patch), but no mainstream window managers appear to have the feature. Apparently it goes against a requirement/assumption in the EWMH spec and breaks existing pagers. But that's okay, because I don't use a pager.
Anyway, it really is critical to how I work now. I can keep a set of windows on my right monitor, and flip between virtual desktops on my center monitor without the right monitor changing at all. (And no, using the "sticky" feature of other WMs doesn't work for me because sometimes I do want to flip to a different virtual desktop on the right monitor and have that set of windows for whatever context I'm switching to). Along the same lines, the pertag patch is part of making dwm the perfect windows manager for me.
(If you're interested in the particular set of patches I use and my config, I maintain it at https://github.com/racingmars/dwm)