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? -- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/desktop
