6 ms·

> 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 t

> 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.

woodruffw 5y ago
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.
- badsectoracula 5y ago
  > 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?
  - woodruffw 5y ago
    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.
fouric 5y ago
> 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.
sascha_sl 5y ago
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.
foxfluff 5y ago
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.
kjeetgill 5y ago
> 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
- CyberRabbi 5y ago
  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.
  - hiptobecubic 5y ago
    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.
akkartik 5y ago
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 https://github.com/akkartik/teliva#readme
2c2c2c 5y ago
there's something especially annoying about building the worst performing terminal (https://danluu.com/term-latency/ https://danluu.com/term-latency/) while having 5% of features and proclaiming everyone else's software sucks
- csande17 5y ago
  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.

woodruffw 5y ago

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.

badsectoracula 5y ago
> 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?
- woodruffw 5y ago
  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.

fouric 5y ago

> 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.

sascha_sl 5y ago

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.

foxfluff 5y ago

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.

kjeetgill 5y ago

> 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

CyberRabbi 5y ago
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.
- hiptobecubic 5y ago
  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.

akkartik 5y ago

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 https://github.com/akkartik/teliva#readme

2c2c2c 5y ago

there's something especially annoying about building the worst performing terminal (https://danluu.com/term-latency/ https://danluu.com/term-latency/) while having 5% of features and proclaiming everyone else's software sucks

csande17 5y ago
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.