Fedora Workstation Technical Specification
The following technical specification document is a historical foundational document of Fedora Workstation. It is no longer an effective governing document. It is historically important and continues to inform the mission of the WG, but some parts are obsolete. This document will no longer updated.
This document aims to describe the technical characteristics Fedora Workstation product in detail. This includes provided services and APIs, installed software, etc. Some of the desired characteristics may not be entirely achievable in the first version of the Workstation product, and will be approximated.
The content of the spec unavoidably overlaps with the work of the Base Working Group, and needs to be aligned with their deliverables.
Core Services and Features
This section should describe the core services of the platform and their intended use. The items here should refer back to the PRD for a functional justification.
The default file system type for workstation installs should be btrfs. Until btrfs is considered ready for this role, we will stay with the current setup of the desktop spin.
Systemd provides ways to control and monitor the activity and status of system services, resources they require, etc. System services are expected to provide systemd units. See the systemd documentation.
The systemd journal will be used as the local storage backend for system logs. For 'managed' scenarios (e.g the 'developer in a large organization' use case of the PRD), it will be possible to collect the logs in a centralized location, off the local machine.
Applications and services can either use the syslog API or the journal APIs for their logging. See the journal API documentation.
Network devices and connections will be controlled by NetworkManager. This includes support for VPN, which is relevant for 'corporate' scenarios. Applications are advised to use higher-level APIs (such as GNetworkMonitor in GIO) to monitor online status.
A firewall in its default configuration may not interfere with the normal operation of programs installed by default.
We should detect when the system is on a public or untrusted network and prevent the user from unwanted sharing of e.g. music or other media in this situation. A firewall (and network zones as currently implemented by firewalld) may or may not be part of a solution to this.
SELinux will be enabled in enforcing mode, using the targeted policy.
Problems and error conditions (e.g. kernel oopses, Selinux AVCs, application crashes, OOM, disk errors) should all be reported in the systemd journal.
Sending this information to a central place (like abrt does for crashes today) should be possible, but not mandatory. Depending on the use case, it may be turned off, enabled manually on a case-by-case basis, or entirely automatic without user intervention.
Logind will be used as the session tracking facility.
SSSD is providing the backing storage for identity management. For 'managed' scenarios (e.g. the 'developer in a large organization' use case of the PRD), it will be possible to configure it to rely on a directory service for this information. The accountsservice is providing a D-Bus interface for user account information; this may be integrated into SSSD at some point.
Depending on their needs, application and services can either use the POSIX APIs (getpwent(), etc) or the accountsservice D-Bus interface to obtain user information.
gnome-software will use PackageKit with the hawkey backend to obtain and install software updates for packaged applications and the OS itself. The recommendation for applications is to use the PackageKit APIs to interact with the underlying packaging system.
Miscellaneous system information
libvirt-daemon will be used to manage virtualization capabilities.
gdm will be used as the display manager. It is responsible for showing a login screen on each seat. It will be able to launch both X-based sessions and Wayland sessions.
Desktop environments are expected to make themselves known as an available session option on the login screen by dropping a .desktop file into /usr/share/xsessions (or its wayland equivalent).
Other facilities provided by the display manager include screen unlock authentication and user switching.
The accessibility support in the workstation includes a screen reader, a high-contrast theme and a zoom capability, amongst others. The screen reading is provided through orca, which runs as a session service and requires the at-spi infrastructure. Applications are expected to provide suitable information to the screen reader via the toolkit's accessibility support. Applications are also expected to work acceptably in the high-contrast theme. The zoom is implemented in the desktop shell and does not need any application support.
The input method framework on the workstation is provided by ibus. Input methods and keyboard layouts can be configured in the control-center, and selected in shell keyboard menu. The supported application toolkits all support ibus.
The workstation session will switch to using a Wayland compositor as soon as feasible. Until then, it will be based on X11. Even after the switch, an X server will be included, so applications can either connect to Wayland natively, or run as an X client.
It shall be possible to calibrate the screen for accurate color reproduction.
Sound hardware and audio streams will be managed by pulseaudio. Applications are recommended to use the gstreamer framework for media playback.
The workstation will ship with a single theme, which will have support for the included toolkits: gtk3, qt and gtk2. Applications are expected to work well with this theme, as well as with the high-contrast theme that is used for accessibility. The theme will include a dark variant that applications can opt into using (this is most suitable for certain content-focused applications). The theme also includes an icon theme that provides named icons according to the icon-naming spec, plus symbolic variants.
We will be using the Adwaita theme, with a yet-to-be-written qt variant.
Installed applications are expected to install a desktop file in /usr/share/applications and an application icon in the hicolor icon theme.
Packaged applications are also expected to provide appdata for use in the application installer.
The desired installation experience for the workstation product is to limit the pre-installation user interaction to the minimum. The storage configuration UI should be focused on the classes of hardware that are expected in workstation-class machines. Package selection is not necessary: the installer will install the workstation product as defined. Tweaks, customizations and software additions should be performed after the installation.
One aspect of storage configuration that will be needed is support for dual-boot setups (preserving preexisting Windows or OS X installations), since e.g. students may be required to run software on those platforms for their coursework.
gnome-initial-setup already provides support for post-install user creation, language selection, timezone configuration, etc. If necessary, it should be extended to cover all required setup tasks.
cups will be available to support local and network printers.
TBD: containers, supported languages
Core applications are part of the Workstation product and can not be removed.
Applications can depend on any services that are listed above, and can assume that all of the packages listed below are present on the system. They can not require other applications to be installed.
gnome-software will serve as graphical application installer, offering to install and remove applications, system extensions and add-ons (such as fonts, or codecs) and other optional software. To be presented in the application installer, applications need to provide appdata.
firefox will be used as the web browser.
gnome-terminal will be installed as a terminal emulator. More powerful options, such as terminator, can be investigated.
gnome-text-editor will be installed as a simple text editor.
nautilus will be installed as a file manager.
gnome-boxes will be available for the creation and use of vms, as well as for connecting to remote systems, e.g. ovirt.
Policies for software add-ons
General rules and policies for how extra software is installed and what requirements are put on that software.
- Optional software must not interfere with the regular functionality of mandatory components. E.g. installing optional audio software must not prevent other applications from using pulseaudio and gstreamer for media playback.
- Optional software should integrate properly into the defined extension points of the OS:
- Applications should provide desktop files and icons
- Applications should provide appdata (link?) for the software installer
- System services should provide systemd units
- Desktop environments should provide a desktop file in /usr/share/xsessions
- It must be possible to remove optional software from the system again
Installation methods and media
We will produce a live .iso image. The primary target for this image will be USB sticks, but the ability to burn the image to a DVD should be preserved (since we are still getting regular requests for such media). There is no pressing reason to restrict the image to the current 1GB size target. Persistence is not an important feature of the live media, whose primary focus should be to install the system.
gnome-disks can create USB sticks on Fedora, and liveusb-creator is the tool we have to let people create USB sticks on Windows or Linux. Both of these tools may need to be extended with support for EFI (whatever that means in detail).
We expect to support 64bit machines with suitable graphics and display resolutions. High-resolution displays, touchscreens and wacom tablets are interesting hardware for some workstation use cases and should be supported in the future.
These hardware requirements are not meant to prevent the workstation product from running on other systems, but rather to determine the range of hardware that we will focus on with QA, and when it comes to determining release blockers.
Not sure if we want this section here or if we should just make this a pure description document and put the implementation roadmap in a separate document.