What is PureOS and how is it built?

Zlatan Todorić

Zlatan Todorić

Director of PureOS
Zlatan Todorić

Latest posts by Zlatan Todorić (see all)

PureOS is a general purpose operating system that is based on the Linux kernel and is focused on being an entirely Free (as in freedom) OS. It is officially endorsed by the Free Software Foundation. We adhere to the Debian Social Contract and the GNU FSDG.

PureOS aims to match and surpass mainstream operating systems (such as Windows and macOS) by striking the balance between security and usability, to provide the best possible out-of-the-box experience paired with the best privacy, security, and software freedom protections possible. The idea is to make it easy to feel safe and secure with an operating system you can trust from the ground up and with appropriate tools.

PureOS comes bundled with a few desktop apps preinstalled for users, but its software library contains thousands of other apps they can install. All apps are Free Software.

For developers,  PureOS tries to be a nice base platform that will help extend and improve the reach of the Free & Open-Source software community. Before we dive into the community aspect, lets first explain how PureOS is built.

Debian—the best parent one can have

PureOS is a Debian based rolling release distribution. To be more precise, PureOS merges packages from the Debian “testing” main archive (and only main, since the Debian main archive is the one containing only Freedom respecting software) into a suite called landing. For those familiar with Debian and how some Linux distros are built, imagine PureOS landing as Debian’s unstable.

In order to facilitate maintenance and contributions, we have designed the PureOS technical architecture with a very innovative approach, and the infrastructure and technologies allowing this are developed and funded by Purism. One important example is Laniakea, an integrated suite of tools layered on top of the Debian Archive Kit (dak) to manage many aspects of the OS building process. These managed aspects include building packages, performing package QA, synchronizing them with Debian, creating live images, etc. Much of the code is written in the D programming language and Python, using PostgreSQL as the database (replacing MongoDB that was used before) and ZeroMQ for message passing.

How PureOS differs

From our Debian roots, we push additional PureOS-specific changes into “landing”, such as:

  • applying general kernel patches to improve the user experience or security;
  • modifying desktop default settings;
  • adding freedom respecting patches (e.g. removing offending add-ons from various packages and removing recommendations on non-free code);
  • enabling sudo by default;
  • modifying the system’s default PATH;
  • adding a lot of customizations to how we build our live images and how our installation process works (based on the Calamares installer framework and GNOME Initial Setup);
  • adding new artwork;
  • setting GRUB to run in fastboot mode;
  • Wayland-based GNOME desktop session by default (PureOS was among the first distributions to adopt that technology as default for the desktop user session, a couple of days faster than Fedora even);
  • AppArmor enabled by default (as a great security practice that doesn’t break everyday usage);
  • PureBrowser (our fork of Firefox with added extensions for improving security and privacy, and additional changes to make it FSF FSDG-compliant) provided as the default browser;

…and many more changes that we think will improve the usability of the system, make it more free (by the FSF’s definition of free software), or improve security. For example, the usage of torsocks is also being researched as a possible new default way to run network-oriented applications. We may also apply additional kernel patches or make general system improvements as the need arises.

Testing the landing changes before they go green

In order for packages to move from the initial “landing” suite into the “green” suite (what our users actually run), certain criteria needs to be met that are set in what is called a “migration policy”. The policy includes an urgency-dependent timer (typically, the new package upload has to stay in “landing” for 4 to 10 days) and also pass some basic quality checks (e.g. must be installable and check for other packages that need to migrate to “green” first).

While PureOS currently has a very basic QA process on package migrations (future infrastructure will be extended with openQA), it does benefit from a lot of work done by Debian and additional tests run for Debian on Debian infrastructure. It is rare that critical bugs find their way into Debian testing because most of them get caught before a package reaches testing. Catching these defects before they get into Debian testing occurs for several reasons. Besides the fact that every package has at least one human maintainer and that Debian has a massive pool of developers and users that that report bugs, Debian also has:

  • dependency checks;
  • dose checks (e.g. non-installable packages, missing conflicts);
  • piuparts (testing of installation, removal or upgrade of packages);
  • archive rebuilds (to find Fails To Build From Source (FTBFS) packages);
  • custom rebuilds (to test breakage of toolchain versions);
  • lintian checks (to ensure a package follows Debian’s technical policy and packaging guidelines);
  • a couple of continuous integration tools (some with autopkgtest);
  • security trackers;
  • etc.

Being based on Debian is a good choice, but people often ask, “Why is PureOS based on the testing suite of Debian in particular?” The answer is simple: it is a middle ground for development, stability, and freshness of packages; nice for everyday usage while still giving freedom to explore fresh new things. Today, there is also the need for a phone development platform, and staying on Debian “stable” would simply not be possible for such a fast-moving project relying on many core packages being closer to more recent upstream releases.

After packages have migrated from the “landing” stage to “green” and are available to users via regular updates, there is still the possibility that an issue has slipped through our QA—since there is of course no such thing as ultimate perfect stability, anywhere—that much is clear if you recall recent Windows update issues (updates working, not working, breaking usage etc.) and, even in the Linux distros world, Ubuntu sometimes pulled off its ISO images due to installer bugs. So, presuming that perfect stability and bug-free software does not exist, PureOS has a transparent bug tracking system where users can report bugs and help resolve them. Just visit tracker.pureos.net and join the community! Additionally, a large part of the PureOS infrastructure is visible at master.pureos.net. In the future it will be easy to search online for packages at software.pureos.net. These are the basic steps and a basic overview of PureOS and its infrastructure. Next stop: PureOS and its community.

PureOS as a community project

Purism acknowledges that PureOS is a community project that needs to be able to stand on its own and Purism absolutely wants to encourage community development. Besides currently funding the entire infrastructure and development, Purism will soon create dedicated mailing lists for community members who want to help with the development of PureOS itself. The motto of PureOS development is very simple: create the best possible everyday mainstream OS while pushing for the best security, freedom, and privacy features. So any such feature that will enhance the user experience and not break the everyday workflow is going to be discussed and can make its way into the PureOS defaults. Of course PureOS can include patches to make it run better on Purism’s Librem devices but it will never be locked down, so that it can always be used on any hardware that supports entirely Freedom-oriented operating systems.

As you know, PureOS is based on Debian with its own set of defaults. While it will most likely always be different and carry patches specific to it (sometimes more, sometimes less), the goal is to not maintain a huge and unnecessary number of deltas (changes) relative to Debian. That is why PureOS developers are encouraged to try to implement their (reasonable) changes directly into Debian. This already has happened on multiple occasions; a few PureOS-related patches are now in Debian and thus PureOS dropped those patches for itself (making the life of its maintainers easier).

Future plans and community involvement

With the Librem 5 now in development, PureOS is also looking into Librem 5-specific image builds so that besides the ARM64 architecture we are also researching usage of OSTree, Flatpak, and a couple of other new technologies to use by default in PureOS on the desktop and/or the phone.

There are a lot of features in the FLOSS world that could be implemented in PureOS but this always requires time and manpower. Anyone willing to suggest improvements and to contribute to the work effort is encouraged to do so by reporting and assigning such tasks to themselves while coordinating with the current core team. We plan to expand the core team outside of the Purism staff and, as things progress, hope that a majority of PureOS devs will be individuals from the community. We believe that PureOS is also great for upstream developers and maintainers since it is easier to include patches—so there is more room to make changes and try out new things.

Also, with the emerging importance of Flatpaks, PureOS is planning to host its own Flathub instance (dedicated to Freedom, of course) so upstream developers can just package their app and submit it to PureOS’s flathub if they don’t want to trouble themselves with system-wide dependencies. Flatpaks have downsides as well, especially regarding the case of potentially slow upstream security patches (at least in theory), but it is not an issue specific to the FLOSS world.

PureOS (and Purism) also acknowledges that apps are a major factor in the adoption of an OS. While the look and feel is very important, the most important thing for the OS is to stay out of the way and enable apps to do the work.

  • The GNU/Linux desktop has caught up with Windows and macOS, and is even more advanced in some respects, but what often turns people off is the absence of apps they are familiar with or can easily transition to, or problems with existing apps.
  • In general, the GNU/Linux world has very powerful tools, yet in some areas they are missing user interface refinements, require some additional features, and more often than not there is a lack of public funding to sustain the development of those pieces of software.
  • We hope to develop an ethical app store that will provide users with an option to donate, “pay what you want”, or “subscribe” (support as a patron) the apps you use. This way, we believe we could play a part in a more sustainable Free Software society and economic system; after all, these projects are a “public good” and we should ensure they have a sustainable future. Globally, this approach should encourage the development of ethical software applications to replace the walled gardens we see today on proprietary app platforms.

Also while PureOS currently defaults to GNOME, it is no stranger nor hesitant to adapt and use other default collections and configurations of software. For example, we already have experimental builds of a PureOS Plasma spinoff—a technology that excites us greatly—so that users would have even more options for default installations. That said, there are no walls in the FLOSS world—you can already install Plasma alongside GNOME today (and vice versa) on PureOS!