Planning for an "Atomic Workstation"

[Owen Taylor]

The classic mode of updating a Linux system or upgrading it to a new
version, where we take the package set for the old system and a new
package repository and compute an individualized upgrade to the new
version works pretty well most of the time. But sometimes the local
system is outside the bounds of what has been tested, and the upgrade
fails, requiring an experienced sysadmin to recover it. Even if
upgrades succeed, a system that is serially upgraded between versions
over a long period of time will eventually be much different from a
freshly installed system. These disadvantages are a big part of the
barrier to using Fedora for the average user: with our release cycle,
the user *has* to upgrade, and eventually the result of upgrading will
be a degraded or non-functional system.

Within Fedora, we first looked these issues with the Stateless Linux
project (http://blog.ometer.com/2004/09/13/stateless-linux/), over 10
years ago. It resulted in a lot of fixes to Fedora to reduce the need
to locally modify configuration files and otherwise remove unnecessary
state. But there were two big things we never really solved: first, we
didn't have a good system for distributing updates incrementally and
updating the operating system image in an atomic way. Second there was
no way to install software on top of the base operating system. The
OLPC project subsequently worked on both areas, though in ways that
didn't obviously relate back to normal desktop Linux. 

ostree, which Colin Walters started work on in 2011, is meant to solve
the operating system update problem, and provide the ability to
efficiently distribute different operating system trees, have multiple
trees installed on the system and switch between them atomically. This
forms the basis of Project Atomic (http://www.projectatomic.io/) and
Fedora Atomic Host (https://fedoraproject.org/wiki/F21_release_announce
ment#Fedora_Atomic_Host), which target a different place where sysadmin
attention is limited: a cloud hosting environment with large numbers of
systems. With rpm-ostree, used in Fedora Atomic Host, the operating
system is still assembled from individual RPMs built the same way as
before, but it is distributed and updated as a while.

If the base operating system is a unified whole, then we need a way to install
software on top, and in particular, to install desktop applications. 
Although we can use some of the same kernel mechanisms as are used for
containerized server applications to provide encapsulation for
desktop applications, there are also a range of desktop-specific needs.
Among other things: there needs standardized integration points with the
desktop, it should be possible to install and run applications without 
having root privileges on the system, and individual applications should
be as small and lightweight to download and update as possible. Last fall, 
Alex Larsson started an effort to look at sandboxed application
installation (https://mail.gnome.org/archives/gnome-os-list/2014-September/msg00000.html),
which eventually became xdg-app
(https://mail.gnome.org/archives/gnome-announce-list/2015-June/msg00017.html).

The combination of rpm-ostree and xdg-app provide the basis for a
future version of Fedora Workstation that has a split between an
atomically updated unified core operating system, and encapsulated
applications installed on top. But there is a lot of work to be done to
get there. We need to deal with the details of creating trees,
installing the operating system, and updating it in a user-friendly and
consistent manner. We need to build out the pieces of an xdg-app
ecosystem that is as broad as possible - that isn't just for GNOME
applications, or just for Fedora.  And most of all, we need to figure
out how people continue to do all the things that they currently
accomplish with Fedora Workstation. Although the classic package-by
-package installation of Fedora isn't going to be go away for quite a
while, an Atomic Workstation can't be just for people running GUI pre
-packaged applications - it needs to be usable for the core developer
target of Fedora Workstation and even for people who are creating the
operating system.

I've created a wiki page to motivate in more detail the advantages of
such a separation, and to start figuring out in detail what we'd need
to get there:

 https://fedoraproject.org/wiki/Workstation/AtomicWorkstation

xdg-app and rpm-ostree are already in Fedora, and it's possible to
create test images right now. But overall, this is not a short term
project, and in particular, the goal of fully sandboxed applications
relies on other major technical pieces like Wayland and perhaps kdbus
that are still in progress.

At this point, I'd like to get some discussion going about having
exploring this direction be a goal for Fedora Workstation. I'd also
like to invite people to work with me on figuring out a solid developer
story: how we can make Atomic Workstation an even more friendly,
flexible and robust way to develop server and desktop software than
what we have currently?