So the proposal is another layer of indirection, à la namespaces, à la where-have-I-seen-this-before.
I'd appreciate it if they'd stop thinking that what they're doing is for the benefit of everyone instead of in their particular interests.
I wish someone, anyone, would officially pull udev out of systemd for the sake of all Linuces.
But in reality, I'm betting on hypervisor-based micro OSes as they way to go. We don't need another "app" format, like what Docker/libcontainer and this proposal are gravitating toward. We already have one, it's called HTML5/REST/HTTPS. Get that in your skulls people! A tar-ball is an app that serves the directory tree, okay. A POST virtualizes this, like a copy-on-write fork(). Now you have to determine how you virtualize on sessions/user logins/etc. There is nothing in this decade that needs to be done any other way!
> So the proposal is another layer of indirection, à la namespaces, à la where-have-I-seen-this-before.
Every year or two another group of people gets it into their heads that there is "something wrong" with the way distributions do things, and they have "the answer". (Often the answer involves a lot of new names for things.) These groups always make a lot of noise, launch a bunch of new projects to reinvent a lot of wheels "the right way", and draw a bunch of media attention.
All of the users who like this sort of thing immediately desert the previous group and leap to this new one. Last year's group somehow manages to become even louder as their userbase dwindles.
Meanwhile, the established distros dig into what this latest group is doing, and finally manage to cut away enough of the rhetoric to identify what real advantages it has. This usually boils down to a couple of features buried behind several gigabytes of blogs, mailing lists, wikis, and enthusiastic-but-content-free rants. The established distros usually say "yeah, that could be handy" and implement these new features, without rewriting the world.
Sound familiar?
This one looks like some folks decided docker wasn't complicated enough and renaming everything would let them make a new thing. If you look through their summary proposal, it's a list of things which you can already do, albeit without there being any single distro you can install today which has all of them working out of the box (largely because cryptographic verification and docker are still works-in-progress - they'll get there).
That's normally harmless... But this time it's systemd developers doing the dance, and they have enough leverage to take several distros hostage into their new ways.
Or maybe that sort of thing is what is necessary to make somebody replace systemd for once.
> Every year or two another group of people gets it into their heads that there is "something wrong" with the way distributions do things, and they have "the answer".
Even Nix package manager, which I think is doing something usefully different?
Having just spent too much time trying to compile PHP 5.5, 5.4 and 5.3 + extensions on the same Ubuntu 14.04 box and failing due to small-but-incompatible underlying library changes (especially FreeType) I'd really appreciate it if established distros learned from their model.
But in reality, I'm betting on hypervisor-based micro OSes as they way to go. We don't need another "app" format, like what Docker/libcontainer and this proposal are gravitating toward.
That approach works well for web apps, but not for desktop applications, of which there are (luckily) still thousands.
I agree that this seems over-engineered and a move to tie everything in the systemd ecosystem.
Frankly, I don't see why an approach like OS X's application bundles would not work. Sure, since libraries are generally less ABI stable, you'd end up packaging more libraries in the bundle, but disk space is cheap. Slap on some MAC and you'll also have sandboxing.
PC-BSD's PBI seems to go more in the right direction:
The problem with "application bundles" is that a lot of libraries are involved in interactions between programs. Can libgnome from 3.10 interact with libgnome from 3.12? What happens when you try? How about when you've got 20+ applications each using a different version? I'm not sure anybody really knows the answer to these questions, because we normally go to great lengths to avoid finding out.
OSX "solves" this problem by not having it: all the major libraries are supplied by Apple and are part of the system, not part of the bundle. So in practical terms, OSX does it the same way as the linux distros: on the vendor's timetable, and upstream authors have to follow along.
You can bundle things like zlib, which have a very well-defined API and never really change... but then you have a horrible mess when there is a security flaw in zlib and you need to update every application installed everywhere. But stable libraries like zlib are exactly the sort of thing that regular shared libraries work great for, and it's the fast-moving unstable APIs like libgnome that cause all the grief.
No, it doesn't require systemd, and that's the annoying bit.
I now want to take the opportunity to explain a bit where we want to take this with systemd in the longer run
The systemd cabal (Kay Sievers, Harald Hoyer, Daniel Mack, Tom Gundersen, David Herrmann, and yours truly)
recently met in Berlin about all these things, and tried to come up with a scheme that is somewhat simple,
but tries to solve the issues generically, for all use-cases, as part of the systemd project
If this doesn't require systemd, why should it be part of the systemd project?
I wish someone, anyone, would officially pull udev out of systemd for the sake of all Linuces.
Already happened a while ago, much to the collective and highly amusing derision of many pro-Freedesktop developers: http://www.gentoo.org/proj/en/eudev/
I'm curious how they'll handle the libudev migration from netlink to kdbus, though.
For simpler systems, there's also mdev from busybox and toybox (no 3d engine included). It's usually enough for headless servers or vm's and fits in neatly with making these "micro OSes" even more lightweight.
> But in reality, I'm betting on hypervisor-based micro OSes as they way to go. We don't need another "app" format, like what Docker/libcontainer and this proposal are gravitating toward. We already have one, it's called HTML5/REST/HTTPS. Get that in your skulls people! A tar-ball is an app that serves the directory tree, okay. A POST virtualizes this, like a copy-on-write fork(). Now you have to determine how you virtualize on sessions/user logins/etc. There is nothing in this decade that needs to be done any other way!
What you're describing sounds interesting. Is there a way I can read about what you said in more detail? I mean the following:
- HTML5/REST/HTTPS can be thought of an app container format?
- tarball is an app that serves the directory tree.
- POST virtualizes it like a copy-on-write fork()
I'm trying to connect it to what I've been thinking: that Javascript is permeating everything, and is like the assembly language of the future, cz everything would be done inside the browser, the OS would only be there to provide hardware (based on the Gary Bernhardt's talk: https://youtu.be/tMEH9OMYmsQ).
I'd appreciate it if they'd stop thinking that what they're doing is for the benefit of everyone instead of in their particular interests.
I wish someone, anyone, would officially pull udev out of systemd for the sake of all Linuces.
But in reality, I'm betting on hypervisor-based micro OSes as they way to go. We don't need another "app" format, like what Docker/libcontainer and this proposal are gravitating toward. We already have one, it's called HTML5/REST/HTTPS. Get that in your skulls people! A tar-ball is an app that serves the directory tree, okay. A POST virtualizes this, like a copy-on-write fork(). Now you have to determine how you virtualize on sessions/user logins/etc. There is nothing in this decade that needs to be done any other way!