Why stal/IX. Part 2
Prereq: Part 1
Many times I promised to write about why I created my own Linux distribution and why it is designed this way.
Part two: Why this way and not another
Directory structure
Here everything is pretty simple. I don’t understand how one can create a new distribution based on LSB/FHS nowadays.
This is some kind of creepy legacy that has remained since the beginning of Unix, with a bunch of poorly solvable problems (DLL hell, atomic updates (ostree is a hack, don’t argue otherwise)).
The FS should be a content addressable storage, similar to Git/Nix/Guix.
This provides us with almost free benefits, just to name a few:
- Multi-versioning.
- Fast rollbacks and updates.
- Atomic updates (switching the entire configuration — switching 1 symlink).
- Free caching of build artifacts in the package system.
- Non-root/user package management. This is a direct consequence of content addressable storage.
Functional configuration management
This refers to the fact that the contents of etc/ are actually determined by a set of realm settings and a description of the package base.
You can’t manually edit etc/, it is generated by realm preparation scripts and is read-only.
I won’t write much here, those who know will understand, and I won’t be able to explain it in two sentences anyway.
Static linking
A good text with a summary of why the main criticisms of static linking cannot withstand serious scrutiny — https://gavinhoward.com/2021/10/static-linking-considered-harmful-considered-harmful/.
Some arguments from Linus — https://lore.kernel.org/lkml/CAHk-=whs8QZf3YnifdLv57+FhBi5_WeNTG1B-suOES=RcUSmQg@mail.gmail.com/.
My arguments for static linking:
- The tooling for static linking is still better because it’s as simple as ABC.
- According to forums, Linux has an eternal problem with dynamically loaded plugins — something may not be found at runtime, and because of this, nothing works. If it’s linked statically, then the declared functionality will be available.
- The resulting binaries are faster despite some duplication of object code.
- The file system is cleaner, there is no unnecessary garbage, and I can tell what each file does. In Nix/Guix, for example, there can be dozens of versions of the same library, it’s ungrepable noodles.
- As a consequence, it is aesthetically easier to have different versions of the same library because they do not hurt the eyes.
- Personal factor. For the last 15 years, I have been promoting static linking at Yandex and have generally succeeded in doing so. I have the ambition to show the world that based on this model, it is possible to create a full-fledged, non-toy distribution.
Healthy minimalism
I want to be able to oversee the entire system. No code bloat, no systemd, no PipeWire(?), etc.
Overall, no vendor lock on RedHat/IBM software.
The Red Hats really want to lock the Linux ecosystem onto themselves. Onto systemd, onto GStreamer as a part of PipeWire, etc.
I don’t see anything good in this, and all this software hinders the ability to understand how the system works.
I’ll just briefly note here that I don’t mind if someone makes a variant stal/IX on top of systemd, I’m not getting in the way of that, and I’m even willing to help.
Take a look at this folder, even my runit scripts are not part of the main package so that you can have systemd/s6/etc units in parallel.
