EU OS

Appearance

Frequently Asked Questions (FAQs) ​

Is EU OS a project of the European Union? ​

EU OS is a community-led Proof-of-Concept. This means it is lead by a community of volunteers and enthusisasts. The project goal is to become a project of the European Commission in the future and use https://code.europa.eu. So far, EU OS relies on https://gitlab.com/eu-os

References:

Is EU OS another Linux distribution that I can try out? ​

EU OS is not another Linux distribution. EU OS is a community-led Proof-of-Concept, which employs existing Linux distributions. The challenge of the proof is not that an individual can use Linux on their own computer. Instead, the challenge is to proof that an admin team can manage users and their data, software and devices with or without Active Directory and without Microsoft Windows within a migration period of rather 2 years than 20 years.

For this, EU OS wants to propose a common Linux OS and desktop environment as a base and, more importantly, a common method to manage users and their data, software and devices.

EU OS is not meant for home users, but for system administrators who want to deploy automatically Linux to many corporate computers/laptops.

References:

How can EU OS achieve its goals of being secure and sovereign when it relies software from other countries (e.g. the US)? ​

EU OS shall not confound sovereignty and protectionism. There is no problem per se in relying on international FOSS components and often times it is in practice unavoidable.

However, EU OS promotes to maintain strict control on business data and telemetry data. This includes the free choice where to store such data (on-premise or cloud of choice). Furthermore, the availability of know-how for a given FOSS component within the EU shall be considered.

It remains to be studied if EU OS FOSS components (such as the Linux kernel, systemd, Wayland, Pipewire, Fedora or AlmaLinux), could face export limitations, which would pose a threat to the sovereignty offered by EU OS. Such threads cannot be mitigated by EU OS alone and should be addressed through industry supply chain security policy.

Why does EU OS propose to rely on Fedora-based Linux distributions? ​

WARNING

This section is work in progress. Related issue: #10

First of all, EU OS is not a product (yet), but only a Proof-of-Concept. The choice of Fedora-based Linux distributions or the desktop environment KDE is not a core concern as it does not impact much how admins manage users and their data, software and devices.

Nevertheless, EU OS cannot avoid to pick one base Linux distribution to start with. The founding project member Robert has previously used:

Immutable Operating Systems ​

Immutable operating systems offer some interesting properties that can help convince organisations to switch their corporate computers for their staff to Linux:

  • GitDevOps deployment patterns applied to the level of the OS
  • no system drift from accumulated state changes over time
  • interruption-free A/B updates with rollback functionality
  • read-only base system for enhanced security and robustness
  • signed images and in the future reproducable and signed file directories (fosdem 2025 talk, composefs)

References:

As of March 2025, immutable linux distributions rely mostly on one of the following technologies:

Transactional Updates ​

The transactional-update command enables you to modify a read-only file system. The modifications are performed in a separate snapshot and do not influence the running system until you boot into the snapshot.

Pro:

  • flexibility to introduce quickly local changes while maintaining rollback functionality

Contra:

  • as the final image is composed iteratively with every update on each machine individually, no guartantees to avoid configuration drift and to achive reproducability between different computers

References:

Image Based Linux with Bootable Container Images (ostree, bootc and composefs) ​

Any OCI container build pipeline can be used to (re)build the container images from that system definition in version control build pipelines, tested, and pushed to a typical OCI container registry. In order to be bootable, these container images include their own Linux kernel and a system manager, usually systemd. […] The bootc tool applies a container image as an update on an already running Linux system. The contents are written to the existing filesystem, switching out the /usr and /boot directories of the Linux system. One then reboots into the new behavior of the system. […] Using the boot loader it is possible to switch back to the previous operating system image, thus enabling rollback to the previous behavior of the system.

Pro:

  • all computers with the same patch-level run the same image: no configuration drift
  • reuse of container image pipelines that many public sector organisations have already (pipelines for security vetting, generation of SBOM, etc.)
  • reuse of existing know-how on containers
  • easy switching of operating system images on computers with bootc switch (bootc documentation)
  • large custom OS community around bootc/ostree (universal blue, BlueBuild, secureblue, heliumOS)
  • many conference talks and code examples available
  • bootc has been gifted to the Cloud Native Computing Foundation
  • distribution agnostic: in principle all traditional linux distributions can support bootc
  • nesting/layering to customise images for downstream is very transparent (via OCI Containerfile or receipe.yml)

Contra:

  • customisation for individual computers are more cumbersome (though this is not a problem given the goal and use cases of EU OS)
  • bootc has not reached 1.0 yet, but ostree is stable with large userbase (flatpak and Fedora Atomic OS Silverblue/Kinoite)
  • composefs for signed directory trees not integrated yet

References:

mkosi and systemd-sysupdate ​

[mkosi is] a fancy wrapper around dnf --installroot, apt, pacman and zypper that generates customized disk images with a number of bells and whistles.

systemd-sysupdate atomically updates the host OS, container images, portable service images or other sources, based on the transfer configuration files described in sysupdate.d(5). This tool implements file, directory, or partition based update schemes, supporting multiple parallel installed versions of specific resources in an A/B (or even: A/B/C, A/B/C/D/, …) style.

Pro:

  • mkosi and systemd-sysupdate belong to the freedesktop project and integrate well with systemd that many traditional linux disributions use anyway

Contra:

  • few computers use it as of March 2025: not battle-tested (was also topic in this talk)
  • small ecosystem
  • while dynamically loaded configuration files would allow to mimik layering somewhat, organisations would not maintain full autonomy when their computers load common configurations from elsewhere

References:

Linux Distributions with support for bootc ​

Given these technologies, Robert decided to adopt for its Proof-of-Concept rpm-ostree/bootc given its many advantages explained above. As of March 2025, rpm-ostree/bootc has been demonstrated to work with:

Consultations and Conclusion ​

Then, Robert received advice from individuals in their personal capacity of the following organisations:

Considering the advice received, Robert decided to advance the Proof-Of-Concept with Fedora. For a production deployment after the Proof-of-Concept, any Fedora-based Linux distribution with longer release cycles could be used. Also, a switch to any other bootc-supported Linux distribution is still possible.