Live data from Hacker News

Revisiting How We Put Together Linux Systems (2014)

0pointer.net

31–40 of 56 posts

Re: Revisiting How We Put Together Linux Systems (2014)

#31
post #21

Earlier quoted context omitted.

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.

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 Poet…

Embrace, extend, extinguish.

Re: Revisiting How We Put Together Linux Systems (2014)

#32

Earlier quoted context omitted.

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.

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.

I you find a place where comments are generally positive, then you've found a place where people avoid challenges rather than face them.

Re: Revisiting How We Put Together Linux Systems (2014)

#33
post #17

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 u…

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 ha…

Ignoring Nix is a blatant sign of failure. systemd could learn a thing or two, or even a few dozen things from the language design itself.

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.

Re: Revisiting How We Put Together Linux Systems (2014)

#34
post #17

Earlier quoted context omitted.

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 ha…

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 script…

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.

Re: Revisiting How We Put Together Linux Systems (2014)

#35
post #34

Earlier quoted context omitted.

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 script…

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 t…

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

Re: Revisiting How We Put Together Linux Systems (2014)

#36

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 u…

NIH isn't limited to the commercial world. There's a problem to be solved, and inventing a solution is much better for one's career than pointing out an existing solution.

Re: Revisiting How We Put Together Linux Systems (2014)

#37

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.

Why update if you want to keep linux as it is? I am sure there are a few LTS distros around that will stay systemd free for the next few years.

Re: Revisiting How We Put Together Linux Systems (2014)

#38

I kinda think that docker changes how a lot of this stuff is put together. no more shared anything, other than the kernel.

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.

> (what an ominous term)

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

Re: Revisiting How We Put Together Linux Systems (2014)

#39

Earlier quoted context omitted.

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.

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.

I know very little about systemd, but it sounds like it solves some issues. The only concrete thing I've seen is starting up services, which has traditionally been idiotic on Linux distros, needing silly boilerplate scripts copied all over. Even Windows does this better in a way.

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?

Re: Revisiting How We Put Together Linux Systems (2014)

#40

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.

This would only require read-only support from Btrfs. Which is stable.
Post reply on HN