Lennart Poettering Talks Up His New Linux Vision That Involves Btrfs

[Isedonde]

Unless I got Lennart wrong, Qt 4 / 5 etc. "runtimes" can be installed at the same time. Not by installing into different file system locations, but simply by only ever "mounting" one of the runtimes at any given time in one filesystem namespace. Since the concept involves filesystem namespaces, there's no conflict: When you start a Qt4 app, the Qt4 runtime is mounted to /usr/lib/qt (or whatever) in the app's very own filesystem. When you start a Qt5 app afterwards, there's a completely new (initially empty) filesystem, and Qt5 is mounted to /usr/lib/qt (and also your /home/foo is mounted, and the base /usr system, and the root filesystem, etc). Unless Qt4/5 prefer to install into directories called qt4 and qt5, but that is not required if no single app uses both of them.


I completely agree with curaga's post. On top of these points, I wonder how security / grave functionality bug fixes in runtimes would be handled. Say, $MIGHTY_RUNTIME_VENDOR (let's call that vendor gnome foundation) discovers that there's a critical bug in the libgio library that is part of GNOME_RUNTIME_3_12, and it might erase your home directory. So the gnome foundation releases GNOME_RUNTIME_3_12_1 or something like that. Now all the apps still use the old libgio from 3_12?

Or maybe this is one point that wasn't very clear to me (or I just wasn't reading careful enough), can there be updates to existing runtimes that do NOT require app runtime depency bumps? For example, the bug is in libgio from "GNOME_RUNTIME_3_12, version 3.12.0" and then gnome publishes "GNOME_RUNTIME_3_12, version 3.12.1" and all the apps pick up the change automatically? I guess that's possible. Of course, the "major version" / "name" of a runtime must be increased when the ABI of at least one of the contained libraries changed.

Also, I can't imagine major distros saying "Oh fine, we'll stop maintaining any package that is not required to boot the system, since those will be supplied from a 3rd party through a runtime. We will just provide systemd in a basic /usr system to boot the system, and we will make sure /etc/issue contains our distro name, since that is the only thing specific to our distro now!". Clearly, there will be UBUNTU_GNOME_RUNTIME, FEDORA_GNOME_RUNTIME, SUSE_GNOME_RUNTIME, DEBIAN_GNOME_RUNTIME. And of course the vanilla GNOME_RUNTIME. I guess there will be no ARCH_GNOME_RUNTIME though? Basically, any distro that likes to add their own patches to libraries will create their own runtimes, containing different library versions/APIs/ABIs, and then we're back to "oh noes I must build 50 different versions of my app for every existing runtime on the planet".

[gilboa]

They install to different locations in the file system where there is no chance of interference, like how one can have both gtk2 and gtk3 libraries in the same system (or qt3 and qt4).
Your point?

Had you bother to read my comment in full, you'd understand the implication of no system wide package management.
- No centralized secure means to install software.
- No centralized updates management, leaving the system littered with multiple unmanaged software and libraries. In Linux, if a vulnerability is fixed, it is fixed system wide (as opposed to fixing a single copy of one application).
- No centralized secure means to uninstall software. A failure in a 3'rd party software uninstaller can leave the system littered with orphan libraries, files - let alone trashed registry.

Per the two examples you gave:
- Anyone that ever did serious development work on Windows knows, that when dealing with weird crashes you should start searching the %PATH% and registry for duplicate MSVCRT* and friends. dbghelp.dll is the worst offender of them all.
- At least in Fedora, qt3, qt4 and qt5 are co-installed (all supported; all receiving security fixes).

[JX8p]

And what happens with the BSDs, that does not have btrfs?

FreeBSD and NetBSD have ZFS, upon which btrfs was modeled, and therefore have all these features (snapshots, deduplication, Copy-on-Write, send/recv) that would be needed, making implementation simple enough. DragonflyBSD's HAMMER is also similarly capable. Bitrig and OpenBSD would be left in a lurch until they develop their own way of doing this, or perhaps imported HAMMER.


With regards to Poettering's idea. It isn't so bad in ways - it's been done (in some ways) before with PBIs and the GOBO-Linux structure. It'll be interesting to see how it progresses.

[Ardje]

Why doesn't Lennart just build his own distro? It's quite a serious question and would resolve a lot of the bad blood around his work being not-so-warmly-received by users of current distros.

I think that is exactly what he is saying.
Distro's have been trying to solve a number of issues. In the dominant package managers all installed files are registered in the package managers.
(There is deb and all it's derivatives up to opkg, and there is rpm).
All these files follow guidelines and standards.
So what he actually is saying is that distro's should come together and use a common standard, but trying to explain it by using btrfs as an example. Oh wait, there is a standard: it's called the FHS. The FHS has some troubles coping with multi-arch setups. Let's concentrate on that.
Even for developers there is something called pkg-config ...
Now we have just one thing we need to have: a standard API/procedure to incorporate non-distro software (.tar distributions) so it can be incorporated into the package management database.
Another handy item would be to be able to mount squashfs filesystems as an overlay fs...
But we should not revert to technical solutions that are only viable for systems with more than 2GB RAM and that have daily backups when the first thing to do is to have consensus.
I love to use btrfs especially if it is stable and raid5 or 6 is working too. It can take a lot of pain away by assuring correct data. But I do not see it as a solution of a problem that has more to do with upstream not wanting to talk with downstream and downstreams not wanting to talk to eachother or conform to the FHS.

[Awesomeness]

And what happens with the BSDs, that does not have btrfs?

They can either implement the APIs on top of OpenZFS or STFU.

[Isedonde]

And what happens with the BSDs, that does not have btrfs?

Also, I think Lennart describes only a new way to package software. Sure, it's not the traditional way of packaging things and it offers quite a lot of new things, but in the end, it's just a means to get software onto your system including any dependencies. Gnome, LibreOffice, etc. will still be available in source code form if this plan works out.

So for BSDs, nothing will change. They grab the source, they add it to their base system or ports, and then they're done (unless the software depends on systemd stuff that BSDs don't provide). It's just for (some of the) Linux distros that will no longer create RPMs/debs/? and send those to their users, they will create runtimes and app bundles (maybe based on RPMs/debs/? internally) instead and send those to their users.


Third-Party software providers (games, closed source software, etc) may or may not adopt the new packaging system to provide their software as an "app bundle" instead of a deb/RPM/tarball specific to one distro. Instead that app bundle would depend on one runtime that may or may not be shared (or sharing a common ABI at least) between various distros. Of course, BSDs then can't use that software as-is. But AFAIK right now BSDs already can't use software that was packaged for Linux only where no source code is available. (I think I read about some compat layer that allows this, but surely that compat layer could also read the app bundle, BTRFS is open source after all, and extract the executable file from there to execute it. It's more complicated, but not impossible AFAICT.)

[Thaodan]

As the aproach is very difficult, wouldn't it be easyer to unfiy path and file names across distros? And maybe the package names?
This solution doesn't seem to be very KISS.

[johnc]

Lennart mentioned taking care of users as a motivation here but other than specific types like engineers or developers, I don't think it's really that helpful.

His example of installing Fedora, Mandriva, and Arch on the same box... I could see some people who would want that, but grandma user won't be one of them.

To me it seems to add a lot of needless complication. I couldn't imagine trying to keep track of all of that myself. And I don't want to have ten versions of Firefox installed (again, unless I'm doing development).

But the most important take-away from the post is all the way at the top where he mentions that this vision is part of where he sees systemd going in the longer run. I'm curious to see what systemd will look like in 2020.

[blackout23]

[...] wouldn't it be easyer to unfiy path and file names across distros? And maybe the package names?

I think we would see peace in the middle east first. Also this wouldn't change the fundamental problem, that you can't ship something on Linux and be sure that it will work everywhere the same way it did on your development system. There are still 10^100 different package combinations across distros.

And I don't want to have ten versions of Firefox installed (again, unless I'm doing development).

Who says that you'd have to have multiple versions installed?

[johnc]

Who says that you'd have to have multiple versions installed?

It's not that I'd have to, it's that it's something that wouldn't interest me.