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.