Suckless.org: software that sucks less
> Do not use for loop initial declarations
> Variadic macros are acceptable, but remember
Maybe my brain is too smooth, but I don't understand how for(int i = 0...) is too clever but variadic macros are not. That makes no sense to me.
It's been around ten years that my desktop barely changed except a few pixels thanks to dwm and dmenu. I am a bit exaggerating but I love the stability that minimalism brings. If only they could make a pdf viewer...
> surf is a simple web browser based on WebKit2/GTK+. It is able to display websites and follow links.
That’s… certainly a low bar for not sucking
One can embrace minimalism without all of this https://news.ycombinator.com/item?id=25751853
Suckless has a beautiful coding philosophy and I wish all software was written with this in mind, but surely a window manager and X-menu aren't really the best showcases? These aren't the types of programs where complexity is the biggest enemy.
I'm not claiming I could write these tools as simple as these, but surely the importance of these paradigms arise when actual complicated software is needed?
The drama around this community is silly. I use these tools because I absolutely love their philosophy on software, and software alone. I couldn't care less what the authors personal beliefs and political leanings are, or who they offended on IRC or social media.
I recently spent a few hours evaluating different terminals. I went back to urxvt, tried Alacritty again, gave Ghostty a try, and spent quite some time configuring Kitty. After all this I found that they all suck in different ways. Most annoying of all is that I can't do anything about it. I'm not going to spend days of my life digging into their source code to make the changes I want, nor spend time pestering the maintainers to make the changes for me.
So I ended back at my st fork I've been using for years, which sucks... less. :) It consists of... 4,765 SLOC, of which I only understand a few hundred, but that's enough for my needs. I haven't touched the code in nearly 5 years, and the binary is that old too. I hope it compiles today, but I'm not too worried if it doesn't. This program has been stable and bug-free AFAICT for that long. I can't say that about any other program I use on a daily basis. Hhmm I suppose the GNU coreutils can be included there as well. But they also share a similar Unixy philosophy.
So, is this philosophy perfect? Far from it. But it certainly comes closer than any other approach at building reliable software. I've found that keeping complexity at bay is the most difficult, yet most crucial thing.[1]
From the page about dwm:
> 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.
...sucks less than what? :) Simple is good, but simpler does not necessarily mean better.
I think I miss a suckless but async and for everything (lots and lots of apps). To the point where each of those different apps are single thread, and in such a way that they collaboratively all share the same single thread. So I'm looking for a single app that has many library-apps inside of it, all brutalistic, async and single thread.
I like that these guys are here. I definitely appreciate what they're doing.
But I think I like software that sucks a little bit. BSPWM with its config as shell commands to the bspc daemon is about right; re-compiling C code is a bit much.
Yah, I don't know, DWM looks like it kinda sucks imho...
I wonder how they are doing in the era of X11 leaving its spot to Wayland.
Software that has an attitude & advertises based off of it.
yeah no. I've mainlined dwm + dmenu all the way back in 200x, I've written tons of makefiles and have the scars to prove it.
These days I'm off of this minimalism crap. it looks good on paper, but never survives collision with reality [1] (funny that this post is on hn front-page today as well!).
[1] http://johnsalvatier.org/blog/2017/reality-has-a-surprising-...
dwm and st, everyday.
The biggest impact suckless had on me was via. Their Stali Linux FAQ: https://sta.li/faq/ .
They've built an entirely statically linked user space for Linux . Until then i never questioned the default Linux "shared libraries for everything" approach and assumed that was the best way to deliver software.
Every little cli tool i wrote at work - i used to create distro packages for them or a tarball with a shell script that set LD_LIBRARY_PATH to find the correct version of the xml libraries etc i used.
It didn't have to be this way. Dealing with distro versioning headaches or the finnicky custom packaging of the libraries into that tar ball just to let the users run by 150 kb binary.
Since then I've mostly used static linking where i can. AppImages otherwise. I'm not developing core distro libraries. I'm just developing a tiny "app" my users need to use. I'm glad with newer languages like Go etc... static linking is the default.
Don't get me wrong. Dynamic linking definitely has it's place. But by default our software deployment doesn't need to be this complicated.