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?
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:
http://www.pcbsd.org/en/package-management/