"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."
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.
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.
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.
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.
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.
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.
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.
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.
27 comments
[ 6.0 ms ] story [ 72.1 ms ] threadI 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.
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
> Note that stali in its current form is totally experimental. Use at your own risk.
So I’d say probably not yet.
Source: ran Alpine as a daily driver for 3 months
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.
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)
Sure, just think about google and how much a overhead of 0.01% costs every Day.
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.
Modularity and proper configs produce more lines of code, but it's actually simpler in human terms.
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.
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
• http://morpheus.2f30.org
Perhaps, arguably:
• https://k1ss.org
There were more:
• http://web.archive.org/web/20141218065305/http://starchlinux...
• http://web.archive.org/web/20150212085658/http://bifrost.slu...