6 ms·

Stali is a static Linux distribution

56 points by kristianpaul 6y ago

kristianpaul 6y ago
"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."
rvz 6y ago
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.
- type0 6y ago
  > 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
  - denysvitali 6y ago
    HitLE, where obviously LE stands for Little Endian
5986043handy 6y ago
Is this stable to use as a daily driver?
- addicted 6y ago
  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.
- inamiyar 6y ago
  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
sacomo 6y ago
Should have just ran with it and called in StaLin.
- bitwize 6y ago
  Except that name is taken -- by a Scheme compiler: https://engineering.purdue.edu/~qobi/software/ https://engineering.purdue.edu/~qobi/software/
  - bjoli 6y ago
    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.
- slrz 6y ago
  Actually, it used to be called just that.
raffraffraff 6y ago
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)
- nix23 6y ago
  >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.
- eschaton 6y ago
  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.
throwaway33339 6y ago
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/ 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.
- Barrin92 6y ago
  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.
  - inamiyar 6y ago
    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.
    - ziml77 6y ago
      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.
lionkor 6y ago
tl;dr: shared libraries considered harmful
lproven 6y ago
There are other such things: • http://morpheus.2f30.org http://morpheus.2f30.org Perhaps, arguably: • https://k1ss.org https://k1ss.org There were more: • http://web.archive.org/web/20141218065305/http://starchlinux.org/ http://web.archive.org/web/20141218065305/http://starchlinux... • http://web.archive.org/web/20150212085658/http://bifrost.slu.se/ http://web.archive.org/web/20150212085658/http://bifrost.slu...

56 points by kristianpaul 6y ago

"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."

rvz 6y ago

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.

type0 6y ago
> 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
- denysvitali 6y ago
  HitLE, where obviously LE stands for Little Endian

5986043handy 6y ago

Is this stable to use as a daily driver?

addicted 6y ago
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.
inamiyar 6y ago
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

sacomo 6y ago

Should have just ran with it and called in StaLin.

bitwize 6y ago
Except that name is taken -- by a Scheme compiler: https://engineering.purdue.edu/~qobi/software/ https://engineering.purdue.edu/~qobi/software/
- bjoli 6y ago
  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.
slrz 6y ago
Actually, it used to be called just that.

raffraffraff 6y ago

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)

nix23 6y ago
>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.
eschaton 6y ago
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.

throwaway33339 6y ago

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/ 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.

Barrin92 6y ago
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.
- inamiyar 6y ago
  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.
  - ziml77 6y ago
    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.

lionkor 6y ago

tl;dr: shared libraries considered harmful

lproven 6y ago

There are other such things: • http://morpheus.2f30.org http://morpheus.2f30.org Perhaps, arguably: • https://k1ss.org https://k1ss.org There were more: • http://web.archive.org/web/20141218065305/http://starchlinux.org/ http://web.archive.org/web/20141218065305/http://starchlinux... • http://web.archive.org/web/20150212085658/http://bifrost.slu.se/ http://web.archive.org/web/20150212085658/http://bifrost.slu...