From Fedora Project Wiki

Fedora Workstation Technical Specification

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.

Service management

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.

Logging

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.

Networking

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.

Firewall

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

SELinux will be enabled in enforcing mode, using the targeted policy.

Problem reporting

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 use intervention.

Session tracking

Logind will be used as the session tracking facility.

Applications that need to interact with sessions can use the logind library API, the D-Bus API, or a higher-level API

Account handling

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.

Software updates

dnf will be used 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

System locale, timezone, hostname, etc. will be managed through the services provided by systemd for this purpose. See developer documentation for localed, timedated and hostnamed

Virtualization

libvirt-daemon will be used to manage virtualization capabilities.

Display manager

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.

Accessibility

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.

Input Methods

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.

Graphics

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.

Media support

Sound hardware and audio streams will be managed by pulseaudio. Applications are recommended to use the gstreamer framework for media playback.

Appearance

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.

Application Integration

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.

System 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.

Other

TBD: containers

Core Applications

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.

Application installer

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.

Web Browser

firefox will be used as the web browser.

Terminal emulator

gnome-terminal will be installed as a terminal emulator. More powerful options, such as terminator, can be investigated.

Text Editor

gedit will be installed as a simple text editor.

File Manager

nautilus will be installed as a file manager.

Virtualization frontend

gnome-boxes will be available for the creation and use of vms, as well as for connecting to remote systems, e.g. ovirt.

Developer assistant

The developer assistant will provide an easy way to set the workstation up for various software development use cases.

TODO

  • non-core, default applications ?
  • other developer-focused software

Core Package list

List the core packages of the product. This list includes all packages that will be shipping on the core media. This is the mandatory minimal list of packages that needs to be installed on a system at all times for it to qualify as a Fedora workstation install. This package list will be the priority focus for QA and bug fixing.

Package list

Here is the full list of packages that are installed as dependencies of the various aforementioned packages, in particular systemd, gdm, gnome-shell, gtk2, gtk3, orca, control-center, qt4 (qt), qt5 (qt5-qtbase and qt5-qtdeclarative), gnome-boxes, gnome-terminal, firefox, gedit, gnome-software, pulseaudio, gstreamer1, gstreamer1-plugins-good.

temporarily missing

TODOS

  • do we need to pin down versions ?
  • add vpn packages

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

Engineering Roadmap

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.