by flykespice on 2/21/25, 6:27 PM with 235 comments
by saidinesh5 on 2/21/25, 9:15 PM
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.
by lugu on 2/21/25, 8:44 PM
by unclad5968 on 2/21/25, 9:58 PM
> 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.
by sitkack on 2/21/25, 8:25 PM
by tomtomtom777 on 2/21/25, 11:25 PM
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?
by imiric on 2/21/25, 9:07 PM
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]
by alkonaut on 2/22/25, 1:34 PM
That’s… certainly a low bar for not sucking
by clintonc on 2/21/25, 8:46 PM
> 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.
by swfsql on 2/21/25, 9:37 PM
by LAC-Tech on 2/22/25, 11:12 AM
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.
by xmichael909 on 2/21/25, 8:43 PM
by nicebyte on 2/21/25, 9:04 PM
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-...
by znpy on 2/21/25, 9:19 PM
by jauntywundrkind on 2/21/25, 8:26 PM
by sylware on 2/22/25, 2:08 AM