From Fedora Project Wiki

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.

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.

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.

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.

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 user 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

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.

Virtualization

libvirt-daemon will be used to manage virtualization capabilities.

Display manager

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

Graphics

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

Media support

Sound hardware and audio streams will be managed by Phonon. The default backend will be phonon-gstreamer.

Appearance

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.

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 encouraged to provide appdata for use in the application installer.

Printing

cups will be available to support local and network printers.

Other

TBD: containers, supported languages

Core Applications

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.

Application installer

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.

Web Browser

Firefox (or Rekonq) will be used as the web browser.

Terminal emulator

Konsole will be installed as a terminal emulator.

Text Editor

KWrite will be installed as a simple text editor.

File Manager

Dolphin will be installed as a file manager.

Image viewer

Gwenview will be used as the default image viewer.

Audio & music

Amarok will be used as the default music player.

Video

Dragon will be used as the default video player.

Instant messaging

KDE Telepathy (ktp) will be used as the default instant messaging application.


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 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 core packages:

TBD

TODO

  • 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 must 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, targetting the size of 1.4GB; see http://en.wikipedia.org/wiki/MiniDVD

Hardware requirements

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.

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.