This article introduces projects available in Flathub with installation instructions.
Flathub is the place to get and distribute apps for all of Linux. It is powered by Flatpak, allowing Flathub apps to run on almost any Linux distribution.
Flatseal is a graphical utility to review and modify permissions from your Flatpak applications. This is one of the most used apps in the flatpak world, it allows you to improve security on flatpak applications. However, it needs to be used with caution because you can make your permissions be too open.
It’s very simple to use: Simply launch Flatseal, select an application, and modify its permissions. Restart the application after making the changes. If anything goes wrong just press the reset button.
You can install “Flatseal” by clicking the install button on the web site or manually using this command:
Reco is an audio recording app that helps you recall and listen to things you listened to earlier.
Some of the features include:
Recording sounds from both your microphone and system at the same time.
Support formats like ALAC, FLAC, MP3, Ogg Vorbis, Opus, and WAV
Timed recording.
Autosaving or always-ask-where-to-save workflow.
Saving recording when the app quits.
I used it a lot to help me record interviews for the Fedora Podcast
You can install “Reco” by clicking the install button on the web site or manually using this command:
flatpak install flathub com.github.ryonakano.reco
Mini Text
Mini Text is a very small and minimalistic text viewer with minimal editing capabilities. It’s meant as a place to edit text to be pasted, it doesn’t have saving capabilities. It uses GTK4 and it’s interface integrates nicely with GNOME.
I found this to be very useful just to keep data that I want to paste anywhere, it doesn’t have unwanted and/or unneeded rich text capabilities, just plain text with minimal editing features.
You can install “Mini Text” by clicking the install button on the web site or manually using this command:
This article introduces projects available in Flathub with installation instructions.
Flathub is the place to get and distribute apps for all of Linux. It is powered by Flatpak, allowing Flathub apps to run on almost any Linux distribution.
Authenticator is a simple app that allows you to generate Two-Factor authentication codes. It has a very simple and elegant interface with support for a a lot of algorithms and methods. Some of its features are:
Time-based/Counter-based/Steam methods support
SHA-1/SHA-256/SHA-512 algorithms support
QR code scanner using a camera or from a screenshot
Lock the application with a password
Backup/Restore from/into known applications like FreeOTP+, Aegis (encrypted / plain-text), andOTP, Google Authenticator
You can install “Authenticator” by clicking the install button on the site or manually using this command:
Secrets is a password manager that integrates with GNOME. It’s easy to use and uses the KeyPass file format. Some of its features are:
Supported Encryption Algorithms:
AES 256-bit
Twofish 256-bit
ChaCha20 256-bit
Supported Derivation algorithms:
Argon2 KDBX4
Argon2id KDBX4
AES-KDF KDBX 3.1
Create or import KeePass safes
Add attachments to your encrypted database
Generate cryptographically strong passwords
Quickly search your favorite entries
Automatic database lock during inactivity
Support for two-factor authentication
You can install “Secrets” by clicking the install button on the site or manually using this command:
flatpak install flathub org.gnome.World.Secrets
Flatsweep
Flatsweep is a simple app to remove residual files after a flatpak is unistalled. It uses GTK4 and Libadwaita to provide a coherent user interface that integrates nicely with GNOME, but you can use it on any desktop environment.
You can install “Flatsweep” by clicking the install button on the site or manually using this command:
We all have people around us, whom we hold dear. Some of them might even rely on you to keep them save. And since the world is constantly changing, that can be a challenge. No more is this apparent than with children, and Linux has long been lacking simple tools to help parents. But that is changing, and here we’ll talk about the new parental controls that Fedora Linux provides.
Users and permissions
First, it’s important to know that any Linux system has a lot of options for user, group, and permission management. Many of these advanced tools are aimed at professional users, though, and we won’t be talking about those here. In this article we’ll focus on home users.
Additionally, parental controls are not just useful for parents. You can use them when helping family members who are technically illiterate. Or perhaps you want to configure a basic workstation for simple administrative tasks. Either way, parental control can offer many security and reliability benefits.
Creating users
From the Settings panel, you can navigate to Users and from there you can select Add User… (after unlocking) to add a new user. You can give them a personal name, a username and their own icon. You can even decide if somebody else should also be an administrator.
Adding a user to your machine is as simple as going to settings, users, and clicking Add User…
You can also set a default password, or even allow a computer to automatically log in. You should help others understand digital security and the value of passwords, but for some people it might be better to just auto-login.
Admin rights
When you give somebody administrator rights, that user will have the same powers as you have on the system. They will be able to make any system change they prefer, and they can also add and remove users themselves.
Users who do not have admin rights, will not be able to make fundamental changes to the computer. They can still use all applications that are already on the system, and they can even download applications from the internet to their home folder. Still, they are ultimately blocked from doing anything that could damage the system.
Accessing the user-directories of others. Only administrator users will be able to do this.
Don’t forget that as an administrator, you can always reset a password. You can also enter another user’s home directory in case you have to. As with all ‘sudo’ rights, you should be careful and you should be considerate of other’s privacy.
Application control
Once one or multiple users are created, you can choose to tweak and control what applications somebody can use. This is done from within Settings > Users by selecting the new user then selecting Parental Controls and then Restrict Applications. Other options are available there, as well.
changing Parental Controls for a single user.
However, there is a big caveat
Parental controls come with a big caveat: If you want a simple home-user solution, you MUST use Flatpaks.
The problem is as follows. The existing Linux application landscape is quite complex, and it would be almost impossible to introduce a new user-friendly application-control system this late into its life cycle. Thus, the second best solution is to ensure that the next generation of packaging has such functionality from the start.
To use Flatpaks, you can use the Fedora’s repository, or the Flathub repository. If you want to know all the fine details about those projects, then don’t forget to read this recent comparison.
Compromise and limitations
No article would be complete without mentioning the inherit limitations of the parental controls. Besides all the obvious limits of computers not knowing right from wrong, there are also some technical limits to parental controls.
Parental Control’s limits
The security that Parental Controls provides will only work as long as Fedora Linux is running in working order. One could easily bypass all controls by flashing Fedora on a USB stick and starting from a clean, root-powered, installation image. At this point, human supervision is still superior to the machine’s rules.
Adding to that, there are the obvious issues of browsers, store fronts like Steam, and other on-line applications. You can’t block just parts of these applications. Minecraft is a great game for children, but it also allows direct communication with other people. Thus, you’ll have to constantly juggle permissions. Here too, it is better to focus on the human element instead of relying to much on the tools.
Finally, don’t forget about protecting the privacy and well-being of others online. Blocking bad actors with Ublock Origin and/or a DNS based blocker will also help a lot.
Legacy applications
As mentioned before, Fedora and Parental Controls only work with Flatpaks. Every application that is already on the system can be started by users who otherwise don’t have the permissions.
As a rule of thumb; If you want to share a computer with vulnerable family members, don’t install any software that’s inappropriate using the RPM Repositories. Instead, consider using a Flatpak.
Starting the system-wide installation of Firefox from the Terminal. The Flatpak version of Firefox though, will not start.
Summary
There is much that you can do to help those who are less experienced with computers. By simply giving these users their own account and using Flatpaks, you can make their lives a lot easier. Age restrictions can even offer additional benefits. But it’s not all perfect, and good communication and supervision will still be important.
The Parental Controls will improve over time. They have been given more priority in the past few years and there are additional plans. Time-tracking is, for example planned. As the migration to Flatpaks continues, you can expect that more software will respect age-restrictions in the future.
So, let’s start a small collaboration here. We’ve all been younger, so how did you escape your parents’ scrutiny? And for those who are taking care of others… how are you helping others? Let’s see what we can learn from each other.
In the previous article in this series, we looked at how to get started with Fedora Flatpaks and how to use it. This article compares and contrasts between the Fedora Flatpaks remote and the Flathub remote. Flathub is the de-facto standard Flatpak remote, whereas Fedora Flatpaks is the Fedora Project’s Flatpak remote. The things that differ between the remotes include but are not limited to their policies, their ways of distribution, and their implementation.
Goals and motivation
Fedora Flatpaks and Flathub share the same goals but differ in motivation. The goal is to make applications accessible in their respective field, maximize convenience and minimize maintenance.
Fedora Flatpaks’s motivation is to push RPMs that come directly from the Fedora Project and make them accessible throughout Fedora Linux regardless of the versions, spin, etc. So, in theory, it would be possible to get the latest and greatest applications from the Fedora Project without needing to upgrade to the latest version of Fedora Linux. Of course, it’s always advisable to keep everything up-to-date.
Flathub’s motivation is to simply make applications and tools as accessible as possible regardless of the distribution in use. Hence, all tools are available on GitHub. Filing issues for applications provided by Flathub is the same as filing issues on any project on GitHub.
Packages
Fedora Flatpaks and Flathub create Flatpak applications differently. First and foremost, Fedora Flatpaks literally converts existing RPMs to Flatpak-compatible files where developers can then easily bundle as Flatpak and redistribute them. Flathub, on the other hand, is more open when it comes to how developers bundle applications.
Types of packages published
Fedora Flatpaks only publishes free and open source software, whereas Flathub publishes free and open source software as well as proprietary software. However, Flathub plans to separate proprietary applications from free and open source applications, as stated by a recent blog post from GNOME.
Sources
Flathub is open with what source a Flatpak application (re)uses, whereas Fedora Flatpaks strictly reuses the RPM format.
As such, Flathub has tons of applications that reuse other package formats. For example, the Chrome Flatpak reuses the .deb package, the UnityHub Flatpak reuses the AppImage, the Spotify Flatpak reuses the Snap package, the Android Studio Flatpak uses a tar.gz archive, etc.
Alternatively, Flathub also compiles directly from source. Sometimes from a source archive, from running git clone, etc.
Number of applications
Fedora Flatpaks has fewer applications than Flathub. To list the applications available from a remote, run flatpak remote-ls --app $REMOTE. You can go one step further and get the number of applications by piping to wc -l:
Here, at the time of writing this article, we can see that Flathub has 1518 applications available, whereas Fedora Flatpaks has only 86.
OSTree and OCI formats
Implementations are quite different too. Both Fedora Flatpaks and Flathub use Flatpak to help you install, remove, and manage applications. However, in terms of how these applications are published, they fundamentally work differently. Flathub uses the OSTree format to publish applications, whereas Fedora Flatpaks uses the OCI format.
OSTree format
OSTree (or libostree) is a tool to keep track of system binaries. Developers consider OSTree as “Git for binaries” because it is conceptually analogous to git. The OSTree format is the default format for Flatpak, which Flathub uses to publish packages and updates.
When downloading an application, OSTree checks the differences between the installed application (if installed) and the updated application, and intelligently downloads and changes the differences while keeping everything else unchanged, which reduces bandwith. We call this process delta updates.
OCI format
Open Container Initiative (OCI) is an initiative by several organizations to standardize certain elements of containers. Fedora Flatpaks uses the OCI format to publish applications.
This format is similar to how Docker works, which makes it fairly easy to understand for developers who are already familiar with Docker. Furthermore, the OCI format allows the Fedora Project to extend the Fedora Registry, the Fedora Project’s Docker registry, by creating Flatpak applications as Docker images and publishing them to a Docker registry.
This avoids the burden and complications of having to use additional tools to maintain an additional infrastructure just to maintain a Flatpak remote. Instead, the Fedora Project simply reuses the Fedora Registry, to make maintenance much easier and manageable.
Runtimes
Flatpak runtimes are core dependencies where applications reuse these dependencies without duplicating data, also known as “deduplication”. Runtimes may be based on top of other runtimes, or built independently.
Flathub decentralizes these runtimes, meaning runtimes are only available for specific types of applications. For example GTK applications use the GNOME runtime (org.gnome.Platform), Qt applications use the KDE runtime (org.kde.Platform), almost everything else uses the freedesktop.org runtime (org.freedesktop.Platform). The respective organizations maintain these runtimes, and publish them on Flathub. Both the GNOME and KDE runtimes are built on top of the freedesktop.org runtime.
Fedora Flatpaks, on the other hand, uses one runtime for everything, regardless the size of the application. This means, installing one application from Fedora Flatpaks will download and install the whole Fedora runtime (org.fedoraproject.Platform).
Conclusion
In conclusion, we can see that there are several philosophical and technical differences between Fedora Flatpaks and Flathub.
Fedora Flatpaks focuses on fully taking advantage of the existing infrastructure by providing more to an average user without using more resources. In contrast, Flathub strives to make distributing/publishing applications and using them as painless as possible for the developers and for users.
Both remotes are quite impressive with how rapid they improved in very little time. We hope both remotes get better and better, and become the standard across the majority of desktop Linux distributions.
The previous article looked at how the Web of Trust works in concept, and how the Web of Trust is implemented at Fedora. In this article, you’ll learn how to do it yourself. The power of this system lies in everybody being able to validate the actions of others—if you know how to validate somebody’s work, you’re contributing to the strength of our shared security.
Choosing a project
Remmina is a remote desktop client written in GTK+. It aims to be useful for system administrators and travelers who need to work with lots of remote computers in front of either large monitors or tiny netbooks. In the current age, where many people must work remotely or at least manage remote servers, the security of a program like Remmina is critical. Even if you do not use it yourself, you can contribute to the Web of Trust by checking it for others.
The question is: how do you know that a given version of Remmina is good, and that the original developer—or distribution server—has not been compromised?
For this tutorial, you’ll use Flatpak and the Flathub repository. Flatpak is intentionally well-suited for making verifiable rebuilds, which is one of the tenets of the Web of Trust. It’s easier to work with since it doesn’t require users to download independent development packages. Flatpak also uses techniques to prevent in‑flight tampering, using hashes to validate its read‑only state. As far as the Web of Trust is concerned, Flatpak is the future.
For this guide, you use Remmina, but this guide generally applies to every application you use. It’s also not exclusive to Flatpak, and the general steps also apply to Fedora’s repositories. In fact, if you’re currently reading this article on Debian or Arch, you can still follow the instructions. If you want to follow along using traditional RPM repositories, make sure to check out this article.
Installing and checking
To install Remmina, use the Software Center or run the following from a terminal:
Open a terminal here and find the following directories using ls -la:
total 44
drwxr-xr-x. 2 root root 4096 Jan 1 1970 bin
drwxr-xr-x. 3 root root 4096 Jan 1 1970 etc
drwxr-xr-x. 8 root root 4096 Jan 1 1970 lib
drwxr-xr-x. 2 root root 4096 Jan 1 1970 libexec
-rw-r--r--. 2 root root 18644 Aug 25 14:37 manifest.json
drwxr-xr-x. 2 root root 4096 Jan 1 1970 sbin
drwxr-xr-x. 15 root root 4096 Jan 1 1970 share
Getting the hashes
In the bin directory you will find the main binaries of the application, and in lib you find all dependencies that Remmina uses. Now calculate a hash for ./bin/remmina:
sha256sum ./bin/*
This will give you a list of numbers: checksums. Copy them to a temporary file, as this is the current version of Remmina that Flathub is distributing. These numbers have something special: only an exact copy of Remmina can give you the same numbers. Any change in the code—no matter how minor—will produce different numbers.
Like Fedora’s Koji and Bodhi build and update services, Flathub has all its build servers in plain view. In the case of Flathub, look at Buildbot to see who is responsible for the official binaries of a package. Here you will find all of the logs, including all the failed builds and their paper trail.
Getting the source
The main Flathub project is hosted on GitHub, where the exact compile instructions (“manifest” in Flatpak terms) are visible for all to see. Open a new terminal in your Home folder. Clone the instructions, and possible submodules, using one command:
This indicates that you need the GNOME SDK, which you can install with:
flatpak install org.gnome.Sdk//3.38
This provides the latest versions of the Free Desktop and GNOME SDK. There are also additional SDK’s for additional options, but those are beyond the scope of this tutorial.
Generating your own hashes
Now that everything is set up, compile your version of Remmina by running:
After this, your terminal will print a lot of text, your fans will start spinning, and you’re compiling Remmina. If things do not go so smoothly, refer to the Flatpak Documentation; troubleshooting is beyond the scope of this tutorial.
Once complete, you should have the directory ./build-dir/files/, which should contain the same layout as above. Now the moment of truth: it’s time to generate the hashes for the built project:
sha256sum ./bin/*
You should get exactly the same numbers. This proves that the version on Flathub is indeed the version that the Remmina developers and maintainers intended for you to run. This is great, because this shows that Flathub has not been compromised. The web of trust is strong, and you just made it a bit better.
Going deeper
But what about the ./lib/ directory? And what version of Remmina did you actually compile? This is where the Web of Trust starts to branch. First, you can also double-check the hashes of the ./lib/ directory. Repeat the sha256sum command using a different directory.
But what version of Remmina did you compile? Well, that’s in the Manifest. In the text file you’ll find (usually at the bottom) the git repository and branch that you just used. At the time of this writing, that is:
Here, you can decide to look at the Remmina code itself:
git clone --recurse-submodules https://gitlab.com/Remmina/Remmina.git cd ./Remmina git checkout tags/v1.4.8
The last two commands are important, since they ensure that you are looking at the right version of Remmina. Make sure you use the corresponding tag of the Manifest file. you can see everything that you just built.
What if…?
The question on some minds is: what if the hashes don’t match? Quoting a famous novel: “Don’t Panic.” There are multiple legitimate reasons as to why the hashes do not match.
It might be that you are not looking at the same version. If you followed this guide to a T, it should give matching results, but minor errors will cause vastly different results. Repeat the process, and ask for help if you’re unsure if you’re making errors. Perhaps Remmina is in the process of updating.
But if that still doesn’t justify the mismatch in hashes, go to the maintainers of Remmina on Flathub and open an issue. Assume good intentions, but you might be onto something that isn’t totally right.
The most obvious upstream issue is that Remmina does not properly support reproducible builds yet. The code of Remmina needs to be written in such a way that repeating the same action twice, gives the same result. For developers, there is an entire guide on how to do that. If this is the case, there should be an issue on the upstream bug-tracker, and if it is not there, make sure that you create one by explaining your steps and the impact.
If all else fails, and you’ve informed upstream about the discrepancies and they to don’t know what is happening, then it’s time to send an email to the Administrators of Flathub and the developer in question.
Conclusion
At this point, you’ve gone through the entire process of validating a single piece of a bigger picture. Here, you can branch off in different directions:
Try another Flatpak application you like or use regularly
Try the RPM version of Remmina
Do a deep dive into the C code of Remmina
Relax for a day, knowing that the Web of Trust is a collective effort
In the grand scheme of things, we can all carry a small part of responsibility in the Web of Trust. By taking free/libre open source software (FLOSS) concepts and applying them in the real world, you can protect yourself and others. Last but not least, by understanding how the Web of Trust works you can see how FLOSS software provides unique protections.
Fedora Silverblue provides a useful workstation build on an immutable operating system. In “What is Silverblue?“, you learned about the benefits that an immutable OS provides. But what pieces go into making it? This article examines some of the technology that powers Silverblue.
The filesystem
Fedora Workstation users may find the idea of an immutable OS to be the most brain-melting part of Silverblue. What does that mean? Find some answers by taking a look at the filesystem.
At first glance, the layout looks pretty much the same as a regular Fedora file system. It has some differences, like making /home a symbolic link to /var/home. And you can get more answers by looking at how libostree works. libostree treats the whole tree like it’s an object, checks it into a code repository, and checks out a copy for your machine to use.
libostree
The libostree project supplies the goods for managing Silverblue’s file system. It is an upgrade system that the user can control using rpm-ostree commands.
libostree knows nothing about packages—an upgrade means replacing one complete file system with another complete file system. libostree treats the file system tree as one atomic object (an unbreakable unit). In fact, the forerunner to Silverblue was named Project Atomic.
The libostree project provides a library and set of tools. It’s an upgrade system that carries out these tasks.
Pull in a new file system
Store the new file system
Deploy the new file system
Pull in a new file system
Pulling in a new file system means copying an object (the entire file system) from a remote source to its own store. If you’ve worked with virtual machine image files, you already understand the concept of a file system object that you can copy.
Store the new file system
The libostree store has some source code control qualities—it stores many file system objects, and checks one out to be used as the root file system. libostree’s store has two parts:
a repository database at /sysroot/ostree/repo/
file systems in /sysroot/ostree/deploy/fedora/deploy/
libostree keeps track of what’s been checked in using commit IDs. Each commit ID can be found in a directory name, nested deep inside /sysroot .A libostree commit ID is a long checksum, and looks similar to a git commit ID.
$ ls -d /sysroot/ostree/deploy/fedora/deploy/*/
/sysroot/ostree/deploy/fedora/deploy/c4bf7a6339e6be97d0ca48a117a1a35c9c5e3256ae2db9e706b0147c5845fac4.0/
rpm-ostree status gives a little more information about that commit ID. The output is a little confusing; it can take a while to see this file system is Fedora 31.
$ rpm-ostree status
State: idle
AutomaticUpdates: disabled
Deployments:
● ostree://fedora:fedora/31/x86_64/silverblue Version: 31.1.9 (2019-10-23T21:44:48Z) Commit: c4bf7a6339e6be97d0ca48a117a1a35c9c5e3256ae2db9e706b0147c5845fac4 GPGSignature: Valid signature by 7D22D5867F2A4236474BF7B850CB390B3C3359C4
Deploy the new filesystem
libostree deploys a new file system by checking out the new object from its store. libostree doesn’t check out a file system by copying all the files—it uses hard links instead. If you look inside the commit ID directory, you see something that looks suspiciously like the root directory. That’s because it is the root directory. You can see these two directories are pointing to the same place by checking their inodes.
$ ls -di1 / /sysroot/ostree/deploy/fedora/deploy/*/
260102 /
260102 /sysroot/ostree/deploy/fedora/deploy/c4bf7a6339e6be97d0ca48a117a1a35c9c5e3256ae2db9e706b0147c5845fac4.0/
This is a fresh install, so there’s only one commit ID. After a system update, there will be two. If more copies of the file system are checked into libostree’s repo, more commit IDs appear here.
Upgrade process
Putting the pieces together, the update process looks like this:
libostree checks out a copy of the file system object from the repository
DNF installs packages into the copy
libostree checks in the copy as a new object
libostree checks out the copy to become the new file system
You reboot to pick up the new system files
In addition to more safety, there is more flexibility. You can do new things with libostree’s repo, like store a few different file systems and check out whichever one you feel like using.
Silverblue’s root file system
Fedora keeps its system files in all the usual Linux places, such as /boot for boot files, /etc for configuration files, and /home for user home directories. The root directory in Silverblue looks much like the root directory in traditional Fedora, but there are some differences.
The filesystem has been checked out by libostree
Some directories are now symbolic links to new locations. For example, /home is a symbolic link to /var/home
/usr is a read-only directory
There’s a new directory named /sysroot. This is libostree’s new home
Juggling file systems
You can store many file systems and switch between them. This is called rebasing, and it’s similar to git rebasing. In fact, upgrading Silverblue to the next Fedora version is not a big package install—it’s a pull from a remote repository and a rebase.
You could store three copies with three different desktops: one KDE, one GNOME, and one XFCE. Or three different OS versions: how about keeping the current version, the nightly build, and an old classic? Switching between them is a matter of rebasing to the appropriate file system object.
The Flatpak project provides a way of installing applications like LibreOffice. Applications are pulled from remote repositories like Flathub. It’s a kind of package manager, although you won’t find the word package in the docs. Traditional Fedora variants like Fedora Workstation can also use Flatpak, but the sandboxed nature of flatpaks make it particularly good for Silverblue. This way you do not have to do the entire ostree update process every time you wish to install an application.
Flatpak is well-suited to desktop applications, but also works for command line applications. You can install the vim editor with the command flatpak install flathub org.vim.Vim and run it with flatpak run org.vim.Vim.
toolbox
The toolbox project provides a traditional operating system inside a container. The idea is that you can mess with the mutable OS inside your toolbox (the Fedora container) as much as you like, and leave the immutable OS outside your toolbox untouched. You pack as many toolboxes as you want on your system, so you can keep work separated. Behind the scenes, the executable /usr/bin/toolbox is a shell script that uses podman.
A fresh install does not include a default toolbox. The toolbox create command checks the OS version (by reading /usr/lib/os-release), looks for a matching version at the Fedora container registry, and downloads the container.
$ toolbox create
Image required to create toolbox container.
Download registry.fedoraproject.org/f31/fedora-toolbox:31 (500MB)? [y/N]: y
Created container: fedora-toolbox-31
Enter with: toolbox enter
Hundreds of packages are installed inside the toolbox. The dnf command and the usual Fedora repos are set up, ready to install more. The ostree and rpm-ostree commands are not included – no immutable OS here.
Each user’s home directory is mounted on their toolbox, for storing content files outside the container.
Put the pieces together
Spend some time exploring Fedora Silverblue and it will become clear how these components fit together. Like other Fedora variants, all these of tools come from open source projects. You can get as up close and personal as you want, from reading their docs to contributing code. Or you can contribute to Silverblue itself.
Fedora Silverblue is becoming more and more popular inside and outside the Fedora world. So based on feedback from the community, here are answers to some interesting questions about the project. If you do have any other Silverblue related questions, please leave it in the comments section and we will try to answer them in a future article.
What is Silverblue?
Silverblue is a codename for the new generation of the desktop operating system, previously known as Atomic Workstation. The operating system is delivered in images that are created by utilizing the rpm-ostree project. The main benefits of the system are speed, security, atomic updates and immutability.
What does “Silverblue” actually mean?
“Team Silverblue” or “Silverblue” in short doesn’t have any hidden meaning. It was chosen after roughly two months when the project, previously known as Atomic Workstation was rebranded. There were over 150 words or word combinations reviewed in the process. In the end Silverblue was chosen because it had an available domain as well as the social network accounts. One could think of it as a new take on Fedora’s blue branding, and could be used in phrases like “Go, Team Silverblue!” or “Want to join the team and improve Silverblue?”.
What is ostree?
OSTree or libostree is a project that combines a “git-like” model for committing and downloading bootable filesystem trees, together with a layer to deploy them and manage the bootloader configuration. OSTree is used by rpm-ostree, a hybrid package/image based system that Silverblue uses. It atomically replicates a base OS and allows the user to “layer” the traditional RPM on top of the base OS if needed.
Why use Silverblue?
Because it allows you to concentrate on your work and not on the operating system you’re running. It’s more robust as the updates of the system are atomic. The only thing you need to do is to restart into the new image. Also, if there’s anything wrong with the currently booted image, you can easily reboot/rollback to the previous working one, if available. If it isn’t, you can download and boot any other image that was generated in the past, using the ostree command.
Another advantage is the possibility of an easy switch between branches (or, in an old context, Fedora releases). You can easily try the Rawhide or updates-testing branch and then return back to the one that contains the current stable release. Also, you should consider Silverblue if you want to try something new and unusual.
What are the benefits of an immutable OS?
One of the main benefits is security. The base operating system is mounted as read-only, and thus cannot be modified by malicious software. The only way to alter the system is through the rpm-ostree utility.
Another benefit is robustness. It’s nearly impossible for a regular user to get the OS to the state when it doesn’t boot or doesn’t work properly after accidentally or unintentionally removing some system library. Try to think about these kind of experiences from your past, and imagine how Silverblue could help you there.
How does one manage applications and packages in Silverblue?
For graphical user interface applications, Flatpak is recommended, if the application is available as a flatpak. Users can choose between Flatpaks from either Fedora and built from Fedora packages and in Fedora-owned infrastructure, or Flathub that currently has a wider offering. Users can install them easily through GNOME Software, which already supports Fedora Silverblue.
One of the first things users find out is there is no dnf preinstalled in the OS. The main reason is that it wouldn’t work on Silverblue — and part of its functionality was replaced by the rpm-ostree command. Users can overlay the traditional packages by using the rpm-ostree install PACKAGE. But it should only be used when there is no other way. This is because when the new system images are pulled from the repository, the system image must be rebuilt every time it is altered to accommodate the layered packages, or packages that were removed from the base OS or replaced with a different version.
Fedora Silverblue comes with the default set of GUI applications that are part of the base OS. The team is working on porting them to Flatpaks so they can be distributed that way. As a benefit, the base OS will become smaller and easier to maintain and test, and users can modify their default installation more easily. If you want to look at how it’s done or help, take a look at the official documentation.
What is Toolbox?
Toolbox is a project to make containers easily consumable for regular users. It does that by using podman’s rootless containers. Toolbox lets you easily and quickly create a container with a regular Fedora installation that you can play with or develop on, separated from your OS.
Is there any Silverblue roadmap?
Formally there isn’t any, as we’re focusing on problems we discover during our testing and from community feedback. We’re currently using Fedora’s Taiga to do our planning.
What’s the release life cycle of the Silverblue?
It’s the same as regular Fedora Workstation. A new release comes every 6 months and is supported for 13 months. The team plans to release updates for the OS bi-weekly (or longer) instead of daily as they currently do. That way the updates can be more thoroughly tested by QA and community volunteers before they are sent to the rest of the users.
What is the future of the immutable OS?
From our point of view the future of the desktop involves the immutable OS. It’s safest for the user, and Android, ChromeOS, and the last macOS Catalina all use this method under the hood. For the Linux desktop there are still problems with some third party software that expects to write to the OS. HP printer drivers are a good example.
Another issue is how parts of the system are distributed and installed. Fonts are a good example. Currently in Fedora they’re distributed in RPM packages. If you want to use them, you have to overlay them and then restart to the newly created image that contains them.
What is the future of standard Workstation?
There is a possibility that the Silverblue will replace the regular Workstation. But there’s still a long way to go for Silverblue to provide the same functionality and user experience as the Workstation. In the meantime both desktop offerings will be delivered at the same time.
How does Atomic Workstation or Fedora CoreOS relate to any of this?
Atomic Workstation was the name of the project before it was renamed to Fedora Silverblue.
Fedora CoreOS is a different, but similar project. It shares some fundamental technologies with Silverblue, such as rpm-ostree, toolbox and others. Nevertheless, CoreOS is a more minimal, container-focused and automatically updating OS.
Now you just need to click on Flathub repository file. Open the downloaded file with the Software Install application.
Flathub repository file button on flatpak.org/setup/Fedora
The GNOME Software application opens. Next, click on the Install button. This action needs sudo permissions, because it installs the Flathub repository for use by the whole system.
Install button in GNOME Software
Install the Steam flatpak
You can now search for the Steam flatpak in GNOME Software. If you can’t find it, try rebooting — or logout and login — in case GNOME Software didn’t read the metadata. That happens automatically when you next login.
Searching for Steam
Click on the Steam row and the Steam page opens in GNOME Software. Next, click on Install.
Steam page in GNOME Software
And now you have installed Steam flatpak on your system.
Enable Steam Play in Steam
Now that you have Steam installed, launch it and log in. To play Windows games too, you need to enable Steam Play in Steam. To enable it, choose Steam > Settings from the menu in the main window.
Settings button in Steam
Navigate to the Steam Play section. You should see the option Enable Steam Play for supported titles is already ticked, but it’s recommended you also tick the Enable Steam Play option for all other titles. There are plenty of games that are actually playable, but not whitelisted yet on Steam. To see which games are playable, visit ProtonDB and search for your favorite game. Or just look for the games with the most platinum reports.
Steam Play settings menu on Steam
If you want to know more about Steam Play, you can read the article about it here on Fedora Magazine:
You’re now ready to play plenty of games on Linux. Please remember to share your experience with others using the Contribute button on ProtonDB and report bugs you find on GitHub, because sharing is nice.
