back
25 comments
Ah, the suckless philosophy - making everything as terse, austere and featureless as possible in the name of 'simplicity'. It's a wonder so few people want to adopt it.

To get a further glimpse into that philosophy check this out: http://harmful.cat-v.org/software/ and recoil in horror as literally everything you've ever used (and sometimes even liked) is deemed harmful. There also used to be some more ahem 'controversial' content which I assume was removed to get with the current times.

It is an interesting exercise in minimalism and understanding as many parts of the system as possible, but I wouldn't know why you'd want that too be your daily driver and I can think better alternatives from people who don't name their machines after nazi bunkers and liberally use alt-right dogwhistles. Linux from scratch or Alpine for instance.
what I never understood about the philosophy is their definition of simplicity. For example all their terminal software and so on basically requires configuration in C and every time you change one thing you have to recompile it, and everything is one big mush of code. And when you want to patch something you have to apply diffs in the right order and pray. That's not simple, that's spaghetti code.

Modularity and proper configs produce more lines of code, but it's actually simpler in human terms.

There is no suckless "philosophy". The official page explaining it makes a few solid points about simplicity vs. complexity [0] but for the most part its just thinly-veiled programmer rage and elitism. This is reinforced by the community's purity tests which include enforcing arbitrary limits on the lines of code in a given project (about as dumb and wrong as dogmatically asserting that more lines of code in a commit is better - complexity is about abstraction). That's not even getting into the racial purity tests [1].

Aside from that, suckless software just sucks. Software is more than just source code; it's the user experience, it's the community, it's what comes out of that software. The Blender source code certainly wouldn't fulfill the suckless vision (in sofar as one even exists) and yet it's infinitely more important and useful than any piece of suckless software. Showing off your minimalist desktop on /r/unixporn or /g/ is fun and all but eventually you're going to want to do real work with your computer and realize how much time you've wasted recompiling C code to make basic configuration changes.

[0] http://suckless.org/philosophy/

[1] https://twitter.com/kuschku/status/1156488420413362177

Simplicity of implementation vs simplicity of use (as well as simplicity for a beginner vs simplicity for an advanced user). A suckless tool (lets say st) is a simpler implementation. Easier to port, less likely to have bugs, less likely to have security issues, etc. Features are added under patches, as it's easier to add a feature then take one out.

If it helps think of it as how much of programming is dedicated to reducing complexity, breaking things down, abstracting to core components, etc.

I do use a lot of suckless utilities but from personally experience running Alpine as a daily driver for ~3 months I can't in good conscience recommend a MUSL distribution, despite the fact that in my opinion Alpine does everything else right.

If it actually is common to customize with patches as GP suggests then it seems like you're MORE likely to run into security issues.
Hmm, why would that be? The patches are all vetted by the suckless people, but there might be something I'm not thinking of.
I was thinking of the possibility of bad interactions between multiple patches. But maybe in practice that's not actually a problem. It was just what came to mind when I read that bit.
I looked at that list, expecting to recoil in horror as you said and... it's pretty much okay?
"stali is a static linux distribution based on the original pre-2010 plans of the suckless.org project, however since 2018 it became independent from suckless.org and is maintained by Anselm solely."
Should have just ran with it and called in StaLin.
Except that name is taken -- by a Scheme compiler: https://engineering.purdue.edu/~qobi/software/
We all know: Stalin brutally optimizes. Iirc it is still one of the faster scheme compilers. Sure, Chez will probably run more stable, but I for numeric code or when the full program optimization can work it's magic in ways that other scheme compilers can't it produces faster code than all other compilers.

Last time i checked it was the most capable at optimizing type inference in the presence of mutation. Where most other schemes just did boxing, Stalin produced nice and fast code.

Actually, it used to be called just that.
Are the resource overheads of a dynamically linked system really that important in 2020, considering that Linux has always been famous for being able to run on low spec hardware?

Musl has its problems too. I've stopped using alpine as a docker base image to avoid having to sink time into fixing occasionally compatibility issues (pip, Java)

Dynamic linking overhead was not that significant in the late 1980s on 25MHz 68030 and 68040 systems. Only in an overwhelmingly large system will that fraction of a fraction of a percent matter significantly.
>Are the resource overheads of a dynamically linked system really that important in 2020

Sure, just think about google and how much a overhead of 0.01% costs every Day.

Is this stable to use as a daily driver?
From the link:

> Note that stali in its current form is totally experimental. Use at your own risk.

So I’d say probably not yet.

I recommend against running any musl distros as daily drivers, despite what else they may have going for them at this point.

Source: ran Alpine as a daily driver for 3 months

Love the modern approach to the project and breaking legacy technologies and the use of statically linked binaries, but the name is... err...

I can see why a letter is missing, even when it specific to linux. So removing the 'n' is, well saving you from a puzzling name revolt.

linux + static = Stalinux?

I'm sure you know there's something wrong here.

> but the name is... err...

Nothing is wrong with the name and you are free to fork it and name it Hitle if you want.

edit: s/ I'm sure it would be a big hit /s it should be Hitli then

HitLE, where obviously LE stands for Little Endian
tl;dr: shared libraries considered harmful