Revisiting How We Put Together Linux Systems (2014)(0pointer.net) |
Revisiting How We Put Together Linux Systems (2014)(0pointer.net) |
I'm not sure if there's any substantial progress update yet. Last I heard, they're still waiting for kdbus to be merged, after which they'll need to finish up the GNOME sandboxing features, and only then will they truly start.
Given that kdbus is receiving some shaky reception, it might prove to be a while.
The weird thing to me is why Nix was never brought up. Not only that, but Lennart was actively avoiding the question when he submitted this to his G+ feed.
Ignoring history usually leads to reinventing things in a bad way. Nix for example, has put a lot of effort into getting all these things right. Why not having at least a look into it to see if we can borrow many of their ideas?
That's the same thing they did when systemd was first released. Everyone complained it's not too wise to have a huge process running as PID 1, yet they never even considered these criticisms.
While systemd brings some valuable things to the table, I wonder if they price to pay is too much. We seem to be destroying all elegant Unix core concepts and creating a messy architecture of tightly coupled components.
Gobo and Nix (Guix is something of a reimplementation of Nix) get around the whole "dependency hell" that Poettering's container fetish is supposed to solve without requiring the use of container, cgroups, or any of the other "sexy" that systemd uses (though i have come to understand that Nix has adopted systemd).
Heck, Gobo is basically driven by shell scripts. And its boot system is the sysv's init binary combined with homegrown scripts (it may be likened to BSD init).
About UNIX concepts, they're hidden temporarily because systemd, IMHO, is surfing a deep wave of change in the way OSes are understood. It's very declarative, open to instrumentation (virtualization). Turning the machine into an object. In a few years ideas will have settled and maybe tiny unix-like core components will emerge.
It seems to go a bit beyond just treating each package as its own fiefdom but all the way to doing it with separate OSes, but it's the same basic idea: cooperation is impossible, every package for itself.
It's essentially how Apple's app bundles work too: everything has to package all of its dependencies. This seems to use btrfs instead of dmg.
On GNU/Linux, where you work by assembling white-box components, it's not so straightforward. That said, there have been similar attempts: Autopackage, Klik, 0install, Slax packages... none have received widespread adoption. Seems like no one actually cares until you force the ecosystem into it.
On Gobolinux each version of a program or lib is given its own versioned subdir in /Programs, but that's as far as it goes.
What Poettering is pushing is for full containerization, where each "app" has its own tailored environment.
Sandboxed Apps https://wiki.gnome.org/Projects/SandboxedApps from Alex Larsson.
The code is hosted at https://github.com/alexlarsson/xdg-app .
The first xdg-app release https://blogs.gnome.org/alexl/2015/03/31/official-gnome-sdk-... has some more details and summary, and links to the proof of concept builds.
He talks about a state explosion of packages and libraries, but in practice, I don't see that it matters.
Yes, there is technically a state explosion, so you can't test every possible combination of packages. But you don't need to because they don't interfere with one another much in practice.
I won't pronounce that as universally true (I suspect some people would strongly disagree), but that's been my experience.
no more shared anything, other than the kernel.
Can this 'cabal' (what an ominous term) do better? Hard to say.
Self-referential humour about cabals dates to 1983, thanks to the Backbone Cabal (cf. "There Is No Cabal").
Can we please stop with the posts in every thread being pedants about article age without any useful comment of their own. It's been getting noticably worse into the last few months.
Fuck this. I'm moving to BSD.
Conservatism can be a feature, not a bug.
As for negativity and lack of optimism, well, I would be very disappointed if sunshine, rainbows, and unicorns became the standard of commentary here.
I doubt Red Hat (which has to actually sell it's OS and still flogs a load of Red Hat 6) will carry on pushing it if it really turns out to be a turd. (Yes I know where the main author works).
Containers are also part of Nix (which unlike Guix uses systemd). AFAIK, in Nix these are used for booting up an isolated environment (e.g. if you're running some binary which you perhaps would like to isolate).
But they are two different things: nix package manager -> managing dependencies, containers -> managing isolation.
By performing both at once, I feel systemd is not only breaking the Unix ethos (do one thing, and do it well); but it may eventually also creep into the package manager arena. Eventually, most userland will belong to systemd.
Heck, i think with some clever symlinking you could in theory dump a rpm into its own (optionally versioned) subdir and still have it working in the grand scheme of things.
The biggest stumbling block for current package management is that of versioned libs. Usually they work around this by putting different package names on different major lib versions.
ps: Debian is working on something similar to that https://wiki.debian.org/ReproducibleBuilds.
One can really wonder what is going on when Gentoo opts for picking up maintainership while Debian, that has previously forked Firefox over trademark issues, does not (and Poettering etc are leaving snide remarks aimed at the Gentoo people for this "defiance").
One thing to keep in mind is the gorilla behind the curtains, Red Hat. Key devs of systemd etc are on their payroll...
The bulk of the blame, though, lies with Poettering and friends. Without rehashing every "systemd is terrible" argument out there (and there are many, and I find them as tiresome as you do to review here), the fact remains that political wheeling and dealing is the reason that the project has taken as much root as it has, and that the sheer smugness in the face of reasonable critiques is irksome.
Poettering is part of the group that is "Hey, Linux can be on the desktop too!". History hasn't borne this out, nor likely will it. They'd be welcome to experiment elsewhere, but for them it is anathema that the ecosystem as a whole not follow in their footsteps--and that kinda makes sense, honestly, because for their plan to work they have to kill off all of the features that conflict with their vision of the desktop. Unfortunately, those features are what are kinda important to us folks writing server and infrastructure systems.
It's never going to get fixed, and so we must go beyond the rim.
Independently though, if it's so bad and do obvious that it's bad, why is every major distro picking it up? Is RedHat leaning on Arch behind the scenes?