Fedora Plasma Technical Specification
This document aims to describe the technical characteristics Fedora Plasma 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 Plasma 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.
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.
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.
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.
Apper will use PackageKit 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.
libvirt-daemon will be used to manage virtualization capabilities.
kdm (or sddm) 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).
The workstation session will be based on X11, with a switch to using a Wayland compositor as soon as feasible. 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 using colord-kde
Sound hardware and audio streams will be managed by Phonon. The default backend will be phonon-gstreamer.
The workstation will ship with a single theme (oxygen) which will have support for the included toolkits: qt, gtk3 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.
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 encouraged to provide appdata for use in the application installer.
cups will be available to support local and network printers.
TBD: containers, supported languages
Core applications are part of the Plasma 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.
Apper 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.
Firefox (or Rekonq) will be used as the web browser.
Konsole will be installed as a terminal emulator.
KWrite will be installed as a simple text editor.
Dolphin will be installed as a file manager.
Gwenview will be used as the default image viewer.
Audio & music
Amarok will be used as the default music player.
Dragon will be used as the default video player.
ktp will be used as the default instant messaging application.
The developer assistant will provide an easy way to set the workstation up for various software development use cases.
- non-core, default applications ?
- other 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.
Here is the full list of core packages:
- Add fonts, non-core applicatoins
- Do we need to pin down versions ?
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 Phonon for media playback.
- Optional software should integrate properly into the defined extension points of the OS:
- Applications should provide desktop files and icons
- Applications may 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 expect to support both 32 and 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.
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.