Atomic Workstation
The idea of an "Atomic Workstation" is to use the ideas of "Project Atomic" to have a core operating system for a workstation that updates atomically as a whole, and then layer extra software on top of that. This is as opposed to the traditional model, where the operating system is dynamically composed on the end users system out of individual packages.
Advantages
The basic advantage of the atomic model is enhanced reliability -the
- Reliable and consistent upgrades between versions - F22 is the same as F21-upgraded
- Testing that is done for the project tests the actual operating system that is on users machines
- There is no possibility that an upgrade of the operating system runs into problems halfway through and leaves the system in a trashed state.
- Can rollback from unsuccessful updates, or if new operating system doesn't work with the user's apps
Currently, many problems with an unbootable Fedora system are bootloader or initrd issues; bootloader configuration issues are still a potential problem with the Atomic model. The ostree handling of /etc, which allows arbitrary modification by the user, also means that there is a gap between the goal of an unbreakable system and the reality.
Use cases
Pretty much anything that the normal Workstation is used for.
Installing applications
Applications are installed via xdg-app. If we provide a "fedora runtime", we can rebuild Fedora RPMs into applications in a pretty transparent fashion. introduction update
Development
The primary target of Fedora Workstation is different types of developers, and currently developers often install things that don't fit well into the application model: they install daemons like web servers and databases to test apps they are developing locally. They install developer headers. They install modules for interpreted languages like Python or Ruby. And they install developer tools like gdb or valgrind.
Doing development in containers is one way to handle these sorts of scenarios. Ideally integration between IDE and container systems could make this very transparent to developers.
But pushing all development towards containers can reduce the extent that existing documentation is useful on Fedora.
Layering on arbitrary RPMS
https://github.com/projectatomic/rpm-ostree/pull/107/commits is a prototype of how layering packages of an rpm-ostree works - this seems to create a new tree locally with the specified packages layered on top, which is not necessarily useful for the developer usecase, since rebooting to install new devel headers or tools is not going to be attractive to users at all.