
Revisiting How We Put Together Linux Systems (2014) - ward
http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html
======
vezzy-fnord
I'm the one who originally submitted this on 9/1/14, FWIW.

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.

~~~
nextos
It's indeed extremely odd they never say a word about Nix, Guix or even Gobo
Linux.

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.

~~~
digi_owl
Because they don't use the sexy tech de jour, containers.

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

~~~
nextos
Yes, very good explanation.

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.

~~~
digi_owl
Well this is Poettering. Who pretty much advocates to take the book on
Unix&Linux programming and toss the parts about Unix.

------
jordigh
Isn't this a lot like Gobolinux again?

[http://www.gobolinux.org/](http://www.gobolinux.org/)

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.

~~~
vezzy-fnord
App bundles work for Apple because they have perfect control over the API/ABI
stability and what consists of the base system, and then the user
applications.

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.

~~~
wmf
Maybe assembling components is the problem. Why should we expect a good OS to
emerge out of components that are independently developed with no coherent
vision?

~~~
digi_owl
Civilization has done just that, unless one subscribe to the Illuminati
theory...

------
Spidler
For those that wish to see what came from this, we have:

Sandboxed Apps
[https://wiki.gnome.org/Projects/SandboxedApps](https://wiki.gnome.org/Projects/SandboxedApps)
from Alex Larsson.

The code is hosted at [https://github.com/alexlarsson/xdg-
app](https://github.com/alexlarsson/xdg-app) .

The first xdg-app release [https://blogs.gnome.org/alexl/2015/03/31/official-
gnome-sdk-...](https://blogs.gnome.org/alexl/2015/03/31/official-gnome-sdk-
runtime-builds-are-out/) has some more details and summary, and links to the
proof of concept builds.

------
louwrentius
It reads to me that a problem is being solved that I don't have. For one
thing, I only care about Linux on the server, not on the desktop.

~~~
javert
Funny because I only care about Linux on the desktop and I don't have this
problem, either.

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.

~~~
thrownaway122
If you only need versions in your distro's repos then this is usually fine -
although often the more obscure stuff is broken in e.g. Ubuntu repos. If you
want a newer version? Things break fast.

------
falcolas
Is btrfs really the right choice for this? Even their own faq lists it as
still being experimental, and if this becomes as ubiquitous as systemd (which
is likely if it's bundled with systemd) we'll really want a stable and
performant file system.

~~~
detaro
Btrfs is by now used as a default file system in some distros. As far as I
understand, only some features are still considered experimental.

~~~
mdekkers
Yeah, CoreOS used to have btrfs as default, and changed away due to many
issues: [http://www.phoronix.com/scan.php?page=news_item&px=CoreOS-
Bt...](http://www.phoronix.com/scan.php?page=news_item&px=CoreOS-Btrfs-To-
EXT4-OverlayFS)

------
AdrianRossouw
I kinda think that docker changes how a lot of this stuff is put together.

no more shared anything, other than the kernel.

~~~
falcolas
The shared nothing of docker comes at a cost, though. And the solution for
those performance costs is to undo the isolation.

Can this 'cabal' (what an ominous term) do better? Hard to say.

~~~
jacques_chester
> _(what an ominous term)_

Self-referential humour about cabals dates to 1983, thanks to the Backbone
Cabal (cf. "There Is No Cabal").

------
0x006A
That's a post from September 1st 2014. Any particular reason to (re)post this
today?

~~~
angersock
Because some of us may not have seen it yet?

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.

~~~
Redoubts
I'd rather not see these kind of posts stop. Frequently, there's a good reason
to post an older article on a particular day, and calling it out helps bring
out the new modern context. Otherwise, reminding readers that a submission
happened in a different environment from today is worth while on its own.

~~~
angersock
Then the author should leave a comment explaining the significance of the
day...otherwise, these posts tend to just clutter things up.

~~~
Redoubts
Or HN could just have comment folding baked in. There's more than one way to
solve this problem :^)

------
angersock
Can somebody just open up a fork of Linux for Poetering et al to fuck around
in so they don't feel the political necessity to screw around with the
infrastructure we all depend on?

Fuck this. I'm moving to BSD.

 _Conservatism can be a feature, not a bug._

~~~
falcolas
I want to put you down for negativity, for a lack of optimism, but damn it, I
agree. It bothers me that come 2016 I will have no option but to move to a
systemd based distro if we want to remain on a supported Linux version. Change
is not always good.

~~~
angersock
If it were optional, sure, but it's being rammed down everyone's throats via
the popular distros. And unfortunately, I kind of frown on going the whole
"Well, just roll your own Linux without the parts you don't like".

As for negativity and lack of optimism, well, I would be very disappointed if
sunshine, rainbows, and unicorns became the standard of commentary here.

~~~
wmf
So your problem is really with the distros, not with Poettering et al. But as
the old saying goes, if you think all the distros are assholes, maybe the
problem isn't with the distros.

~~~
digi_owl
The problem is that key components are being "depreciated" by the Poettering
crew for no better reason than "code elegance". Thus distros either have to
take over maintainership a ever growing codebase, or accept the Poettering
code wholesale.

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

~~~
Redoubts
> key components are being "depreciated"

Only the greater community can do that, and it wouldn't be happening unless
the alternative was solving real problems.

