Goals and Design
Maui is a GNU/Linux-based operating system focused on desktop experience and ease of use with a look to the future.
We want to offer a lightweight and modular desktop environment with a user interface tailored for the device (desktop, tablet and even phone) on which it runs.
We also want:
- Safe, atomic and fast upgrades
- To maintain API/ABI compatibility between point releases
- Develop a platform rather than a set of packages
Packages have a central role in most general-purpose GNU/Linux systems but for our goals, packages lead to fundamental architectural conflicts.
Distributions are usually fine and have a lot of applications already packaged but they are not as reliable as you would like. I'm sure that most users have experienced breakage during package updates or some applications stopped working. Sometimes updates don't get enough tests, sometimes upstream libraries changed their API/ABI messing with your applications but there are deeper issues involved here.
Applications and libraries gets installed into a single large system where every package interacts with each other in unpredictable ways.
The most delicate packages are the ones that provide an API that is shared among different applications and desktop environments: libraries and DBus services. A library update might be required by an application but it might also affect other applications as well and even preventing them from running.
Each user has a different set of packages installed and their unpredictable interaction can cause problems. Building packages have been improved over the years. It's common for packagers to build in a clean chroot that only has a minimal system plus a development toolchain, this helps finding the right dependencies but won't solve the problems outlined above because even if you build a package with the right dependencies, its installation changes the system at runtime and this can give different results due to a different package set, installation order and maybe even hardware.
Safe and atomic upgrades are (almost) impossible to do. A fundamental flaw of almost every package system is that there can only be one state of all packages installed on the file system at once. However to support safe, atomic upgrades we would need two installs and swap between the current one and the new one.
Another fundamental flaw is that kernel, desktop environments and applications are all just packages. The user interface has the concept of applications, but the operating system doesn't and this makes hard to find which packages constitute an application and which doesn't because the package manager isn't aware of the higher-level semantics required by the user interface.
Traditional package management also prevents you from installing different versions of the same application at the same time (unless packages have a different name and don't have conflicts) and makes installing applications per-user impossible.
The PackageKit project has made a valuable effort to make packages installation and upgrade easier but it still hasn't managed to make the process of upgrading (or downgrading) one individual application a well-defined operation.
Why is that? There's not always a 1:1 match between an application and a package and even when we are dealing with a perfect match it's possible that the package containing an application could conflict with another package, meaning that installing it will uninstall something else which might be another application, a system daemon or even a kernel.
Updating a library or a DBus service introduces another problem: API and ABI compatibility.
This is a problem that is caused by both upstream and distribution developers but it's not entirely their fault.
Developers of upstream projects must ensure that no commit introduce API and ABI changes during the life cycle of a major release and sometimes it doesn't happen. One of the many reasons why Hawaii is using Qt is compatibility. The Qt Project developers take care of this aspect and deliver a quality product.
To be sure that a point release of an upstrea project doesn't introduce ABI changes, distributions should check the code and do a lot of tests before shipping an update. This is just impossible because distributions include too much stuff into their central repositories as people expect to find every toolkit, every desktop environment and every application.
Let's analyze two very different approaches here: Ubuntu and ArchLinux.
The well known 6 month release cycle with a LTS every two year of Ubuntu sometimes lead to regressions and uncomplete features (Unity took a lot of time before it was stable and not so slow). A more detailed explaination of its release cycle is here.
Developers need their time to create software, rushing in a less than 6 months is risky, but at the opposite there's the rolling release approach which might be worse because it's a moving target (although updating ArchLinux two or three times per week I always experienced less issues compared to Ubuntu).
Releasing a major version every year seems a good compromise. In a year there's time to bake new features and test them. With our build system we can update components during the development, perform some automated QA testing and ship the update to the wilde when it's ready. Since Maui can be entirely rebuilt from sources it's possible to update the base system with a new eglibc or gcc version without long transitions between the old base system version and the new one. Users will also be able to test beta versions and and rollback to the latest stable version if something is wrong.
The solution is:
- Make everyone run the same base system.
- Untangle application interactions.
- Let developers be free to change, add and experiment with the base system.
The base system needs to a well defined set of non-optional core libraries, services and programs. The whole operating system tree is versioned and you can have multiple trees in your machine.
Developers will be free to make their own tree to test new versions of every bit.
Applications are shipped as bundles, single compressed files that contain everything the application needs like executable files, libraries and data files. Bundles have metadata to list important properties like name, description, maintainer and the version of the base system image it depends on.