Live data from Hacker News

Revisiting How We Put Together Linux Systems (2014)

0pointer.net

11–20 of 56 posts

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

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

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.

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

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

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

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?

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

#16

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.

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

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

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

#18

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

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

#19

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

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

#20

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.

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.
Post reply on HN