Live data from Hacker News

Revisiting How We Put Together Linux Systems (2014)

0pointer.net

41–50 of 56 posts

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

#41

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.

I'm seriously considering to move to Guix, which is essentially the Linux distro Nix reimplemented in Scheme, minus systemd.

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

#42
post #21

Earlier quoted context omitted.

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.

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.

I'm not a huge fan of the distros either, because they should've been on guard for this (having seen the nonsense of, say, PulseAudio).

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.

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

#43
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…

I assume they didn't mention nix for the simple reason that RedHat and Debian and other distros aren't going to give up their own packaging setup. So the only way forward is to work with what you have.

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

#44
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…

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

you forgot that they are stuck dealing with the systems already in place. Do you expect Redhat and Debian to give up rpms and debs?

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

#45
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…

I assume they didn't mention nix for the simple reason that RedHat and Debian and other distros aren't going to give up their own packaging setup. So the only way forward is to work with what you have.

Err, what the blog entry describes is just as disruptive to the deb/rpm setup as what nix is doing.

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.

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

#46

Earlier quoted context omitted.

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

you forgot that they are stuck dealing with the systems already in place. Do you expect Redhat and Debian to give up rpms and debs?

And they just as much has to do that to adopt the PoetteringOS as they have going Nix.

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

#47
post #7

Isn't this a lot like Gobolinux again? 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.

Gobolinux (and NixOS) don't go as far as what is suggested here.

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.

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

#48

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.

Likely they see themselves as having done so, as they pretty as the run of the place over at Fedora...

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

#49

Earlier quoted context omitted.

you forgot that they are stuck dealing with the systems already in place. Do you expect Redhat and Debian to give up rpms and debs?

And they just as much has to do that to adopt the PoetteringOS as they have going Nix.

your usage of PoetteringOS outs you as a troll.. this discussion is over.

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

#50

Earlier quoted context omitted.

I assume they didn't mention nix for the simple reason that RedHat and Debian and other distros aren't going to give up their own packaging setup. So the only way forward is to work with what you have.

Err, what the blog entry describes is just as disruptive to the deb/rpm setup as what nix is doing. 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 na…

i was pretty happy with the way gentoo had slotted installs. It's a big help, but it's still just a bandaid.
Post reply on HN