http://divajutta.com/doctormo/ubunchu/c.html
here you go ;) (well, not really a translation of what OP linked but the first chapters of the manga in…lots of different languages)
As much as I dislike snaps…it’s not true that everything snaps do can also be done with flatpaks. snaps can be used for system updates (system libs, kernel, drivers…)…something flatpaks can’t do (and are not meant to do). (Sorry, best link I can find in a short search…but it doesn’t get in very many details :()
As gentoo user I can’t argue with that… ;)
But I think there are reasons why someone would want to build suckless tools manually…namely that their configuration is mostly done in the source-code (Damn, it’s so hard to not write anything too opinionated about suckless but I really try my best). But even then I agree with your other post that it’s far better to use the distro facilities for building the the distro source packages just with your own patches applied.
Lets set aside my personal belief that suckless is a satire that too many people started to take seriously…
Always using the latest git version as done in the article doesn’t strike me as the most sane thing to do if you “just” want to use the software especially as suckless offers version tarballs.
But suggesting sudo make clean install to build is really not okay…(and also not how the suckless tools I checked suggest it). You cloned (or better extracted the tarballs) as user…there is not a single reason to build the software as root. If you have to install then do it in two steps, build as user and only “make install” as root.
I guess a mixture of POSIX compatibility, backward compatibility and non-interactive shell use-cases.
Being somewhat POSIX compatible offers a way to write scripts that work on many systems independent of the actual shell implementation (bash, dash, zsh…). But this means major overhauls of the shell “language” are out of question…
Backward compatibility gets important for things that ignored the first point and used features only available in bash. Given that bash is the default for 30 years for linux now there are probably plenty of examples.
And while bash is not the smallest shell it is also not the largest one…and rather configurable at compile-time when it comes to supported features. This makes it a viable option as “shell-script” interpreter for systems that hardly have any interactive shell usage. It’s not a completely bare-bone shell so you get a bit of “comfort” for scripts but you can remove unnecessary things like interactive command line editing with lib readline…I can imagine some embedded systems find uses for such a shell.
And it’s not that there aren’t alternatives…Microsoft’s Powershell is probably the most successful one “recently”. But changing all existing “workflows” from a text-based one to an object based one is not a trivial task…and in addition you run in new problems with any new shell design (For example I really dislike the overly verbose interactive useage of powershell but that’s rather subjective)
I settled with German because finding English took way longer than I care to admit ;)