This is a response to Alexander’s post “Rethinking the Linux distibution“.
Well, Alexander is trying to solve a problem, or to be exact, some problems. I think he should focus on each problem separately.
I imagine a system where the OS is a well defined set of non-optional core libraries, services and apps. The OS is shipped as a read-only image that gets loopback mounted at / during early boot. So, not only does everyone have the same files, they are using (and testing) *exactly* the same bits. We can do semi-regular updates by replacing the image (keeping the old one for easy rollback), and we can do security hot-fixes by bind-mounting over individual files.
This approach is problematic. What would happen if the user need a 3rd party driver that we can’t ship due to licensing issues? You can’t deny that there are all kinds of hardware that we can’t support right now, certain broadcom wireless chips for example.
The core OS is separated into two distinct parts. Lets call it the platform and the desktop. The platform is a small set of highly ABI stable and reliable core packages. It would have things like libc, coreutils, libz, libX11, libGL, dbus, libpng, Gtk+, Qt, and bash. Enough unix to run typical scripts and some core libraries that are supportable and that lots of apps need.
The desktop part is a runtime that lets you work with the computer. It has the services needed to be able to start and log into a desktop UI, including things like login manager, window manager, desktop shell, and the core desktop utilities. By necessity there will some libraries needed in the desktop that are not in the platform, these are considered internal details and we don’t ship with header files for them or support third party binaries using them.
Another case you should consider, gstreamer plugins. Right now, we can’t play mp3 files or MPEG4 files out of the box, due to patent issues. Right now, users can install gstreamer plugins for those formats via a 3rd party repository. But with your solution, it is not possible. Not without rebuilding the core OS read only disk image, which is not a task for the average user that just want his mp3s to play.
All applications are shipped as bundles, single files that contain everything (libraries, files, tools, etc) the application depends on. Except they can (optionally) depend on things from the OS platform. Bundles are self-contained, so they don’t interact with other bundles that are installed. This means that if a bundle works once it will always keep working, as long as the platform is ABI stable as guaranteed. Running new apps is as easy as downloading and clicking a file. Installing them is as easy as dropping them in a known directory.
Well, it seems that you want to replace package management with bundles. Bundles are a good solution to allow 3rd party (proprietary, mostly) to ship Linux application easily. But this is not a good solution for FOSS applications.
You say that bundles are self contained. So what happens to, say OpenShot, that calls blender to create animated titles? It would need to ship the entire blender in it’s bundle. That doesn’t sound like a good idea. And there are more examples for Linux applications that interacts with each other.
Also, downloading applications from the web? Really? Well, that’s just a bad idea. What the bundle solution really need is, live side by side with package management, and an Application Store/Market/Center (whatever you want to call it) that will allow you to download and install bundles and packages easily, from the same place. There would still be an option to download bundles from the web, but the primary way for getting applications would be the “store”, in which all bundles will be verified, and there will be an infrastructure to donate for FOSS applications or pay for commercial ones easily. Such store should be shared between all distributions that’ll support bundles. Users won’t see any difference between packaged applications and bundled applications, except from a small line saying “source: $APP_DEVELOPERS (bundle)” or “source: $APP_DEVELOPERS (packaged by $DISTRO)”.
Anyway, the first step in this direction should be designing and developing a GNOME application installer (PackageKit UI) and having application information metadata in fedora.
Bundles are a great idea, actually, to solve the problem of 3rd party software developers (mostly proprietary) saying “I won’t develop for Linux because packaging for each distro is too much work”. But having a read only file system, and killing existing package management is just not the right solution. Making bundles the only way to install software destroys all advantages of a package management system.
I assume (mainly because I saw some gnome designers oppose to package management) that this is going to be the way you install software in GNOME OS. Am I right? Well, I hope at least you’ll develop it as a freedesktop spec and not only in GNOME.
You summed up my thoughts precisely. It’s puzzling because one of the key advantages of Fedora/Ubunbtu over Mac/Windows *are* the app repositories. ‘Bundles’ seem like a step back in almost every way except for proprietary vendors.
Some comments:
Just because / is a readonly image doesn’t mean that you can’t install things without modifying that image. For instance, one obvious solution (there are many) to make this possible is to have /usr/local point to something that is not readonly. Of course, anything you put in there does negatively effect the whole “run systems as similar as possible to other users”, so use of such should be minimized.
I don’t see why OpenShot would have to include blender to be able to run it. It can just look for it being installed and exectute it, just as a packaged OpenShot would. Of course, it can’t guarantee that the blender bundle is installed, but I don’t think an OpenShot package would add such a dependency anyway, its more something that is put in the docs.
As for downloading from the web. Its just one possible distribution channel, and the distribution channel is quite orthogonal to the implementation. Its easy to imagine a centralized app store with a nice UI, automatic updates, signed bundles, etc, based on something like glick2.
But at the end of the day, there are lots of applications that depend on others. Perhaps a better example is ImageMagick. Calibre ebook reader uses ImageMagick (I think) to generate covers and the like dynamically if needed. Say there are three other applications that use ImageMagick (doesn’t take up much imagination to think of some), do you then install one ImageMagick bundle and let them share, or does each get an ImageMagick shipped with each bundle?
No solution is perfect, but most distributions are stable enough where you won’t get packages clobbering each other in typical use cases, and distributions that aren’t that stable are well known to be not stable as a selling point of the distro.
Like the author says, a bundle is convenient if you explicitly want to ship everything in one chunk (which I have done before), but wanting every non-system critical application to do so is a bit extreme.
Has anything like this ever happened to Fedora? http://www.osnews.com/comments/25441 i.e it shipped something and had to erase it because licensing changed?
I’m not aware of packages that were removed from Fedora due to licensing changes (licensing changes are rather rare in clean FOSS software), but even if it’ll ever happen, we will never remove it from user’s machines automatically (there is no clean way of doing this, and it’s just wrong. if a package is removed from Fedora’s repositories, users should have the freedom to chose whether they will un-install it from their machine or not).