Various engineers that work on the Fedora Linux product line are brewing up a storm again. To find out more about their plans for world domination, check out this video!
Various engineers that work on the Fedora Linux product line are brewing up a storm again. To find out more about their plans for world domination, check out this video!

Back in the day, it used to irk me as to how GNU/Linux[1] distributions could not be even considered to be in the proximity of video games enthusiasts – less because of the performance of the video games themselves and more because of how inconvenient it could be for them to set it all up. Admittedly, it had been quite a while since an avid video games fan like me did that, so it was almost a no-brainer for me to try it out and see if things have changed. What I ended up finding surprised me – I like to think that it would be just as pleasing to both enthusiasts who have been playing video games on GNU/Linux distributions and to newcomers who have been scoping this, alike.
On a testing bench using an AMD RDNA2-based[2] GPU, the video game was configured to the highest possible graphical preset[3] to really stress the hardware into performing as much as its limiting factor. If the RDNA2 architecture reminds you of something, allow me to share that it is what forms the foundation of the GPU that no other than the widely acclaimed Steam Deck[4] makes use of. For that matter, if you factor in some performance scaling with respect to the handheld nature of the device and the optimized Proton compatibility layer, this article can be representative of what the Steam Deck is capable of when you use Fedora Workstation[5] as a platform of your choice for playing your favourite video games.

To have an apples to apples comparison, we set up two environments – one with Windows 10 21H2[6] and one with Fedora Workstation 35. On the former, I installed MSI Afterburner[7] and ensured that the graphics drivers are up-to-date while I did not have to bother doing the same on the latter as they came preinstalled. The only extra thing that I did was to configure the Lutris v7.1 runner[8] after clicking my way through installing Lutris[9] and MangoHUD[10] from GNOME Software[11]. It is downright astonishing how much you can do these days on GNU/Linux distributions without actually having to interact with the command line, making the entry barrier very low and welcoming.

Before we get into some actual performance testing and comparison results, let me talk a bit about the video game that is at the centre of the case study. Control[12] is an action-adventure video game developed by Remedy Entertainment[13] and published by 505 Games[14]. The video game is centred around a fictitious organization about paranormal activities and takes inspiration from the likes of the SCP Foundation[15]. It is a well-optimized video game that exhibits great graphics and is a showcase of what the underlying hardware is capable of. I ran tests on both DirectX 11[16] and DirectX 12[17] versions of the video game with their compatibility layers[18], DXVK[19] and VKD3D[20], respectively.

Following are the results of the tests. I made use of OBS Studio[21], which is available as both an installer binary and as a package in the RPM Fusion[22] repositories, to record around 15 seconds of in-menu gameplay and around 60 seconds of in-game gameplay. As the video game does not have any intrinsic benchmarking tool, the footage had to be broken down into segments of equal time periods to be able to pick up performance statistics on CPU usage, GPU usage and framerate. Please do note, even when OBS Studio introduces a certain overhead to the performance, the comparison still remains valid as in both the platforms the recording software is configured identically.
Please feel free to let your inner enthusiast loose in the statistics and try sharing as many performance differences as you have inferred so far in the comments section below. In the meanwhile, allow me to share mine –
For someone who looked into GNU/Linux distributions as a platform for using interactive and entertainment software applications without having any fancy hardware requirements, these results almost feel like a breath of fresh air. With Valve[24] working on strengthening Proton[25] and other communities working on great solutions like Bottles[26] and Lutris, gaming on GNU/Linux distributions is no longer an elusive dream. Things are only going to get better with a great number of video games running at near-native performance as we go on. I do not know for certain if 2022 would be the year of Linux Desktop or not, but if you ask me whether 2022 would be the year of Linux Gaming – I would answer that with a resounding yes. Let me know your thoughts down below!
Homebrew is a package manager for macOS to install UNIX tools on macOS. But, it can be used on Linux (and Windows WSL) as well. It is written in Ruby and provides software packages that might not be provided by the host system (macOS or Linux), so it offers an auxiliary package manager besides the OS package manager. In addition, it installs packages only to its prefix (either /home/linuxbrew/.linuxbrew or ~/.linuxbrew) as a non-root user, without polluting system paths. This package manager works on Fedora Linux too. In this article, I will try to show you how Homebrew is different from Fedora Linux package manager dnf , why you might want to install and use it on Fedora Linux, and how.
You should always inspect the packages and binaries you are installing on your system. Homebrew packages usually run as a non-sudoer user and to a dedicated prefix so they are quite unlikely to cause harm or misconfigurations. However, do all the installations at your own risk. The author and the Fedora community are not responsible for any damages that might result directly or indirectly from following this article.
Homebrew uses Ruby and Git behind the scenes. It builds software from source using special Ruby scripts called formulae which look like this (Using wget package as an example):
class Wget < Formula homepage "https://www.gnu.org/software/wget/" url "https://ftp.gnu.org/gnu/wget/wget-1.15.tar.gz" sha256 "52126be8cf1bddd7536886e74c053ad7d0ed2aa89b4b630f76785bac21695fcd" def install system "./configure", "--prefix=#{prefix}" system "make", "install" end
end
Homebrew is a package manager that provides up-to-date versions of many UNIX software tools and packages e.g. ffmpeg, composer, minikube, etc. It proves useful when you want to install some packages that are not available in Fedora Linux rpm repositories for some reason. So, it does not replace dnf.
Before starting to install Homebrew, make sure you have glibc and gcc installed. These tools can be installed on Fedora with:
sudo dnf groupinstall "Development Tools"
Then, install Homebrew by running the following command in a terminal:
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
During the installation you will be prompted for your sudo password. Also, you will have the option to choose the installation prefix for Homebrew, but the default prefix is fine. During the install, you will be made the owner of the Homebrew prefix, so that you will not have to enter the sudo password to install packages. The installation will take several minutes. Once finished, run the following commands to add brew to your PATH:
echo 'eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"' >> ~/.bash_profile eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"
To install a package using a formula on Homebrew, simply run:
brew install <formula>
Replace <formula> with the name of the formula you want to install. For example, to install Minikube, simply run:
brew install minikube
You can also search for formulae with:
brew search <formula>
To get information about a formula, run:
brew info <formula>
Also, you can see all the installed formulae with the following command:
brew list
To uninstall a package from your Homebrew prefix, run:
brew uninstall <formula>
To upgrade a specific package installed with Homebrew, run:
brew upgrade <formula>
To update Homebrew and all the installed Formulae to the latest versions, run:
brew update
Homebrew is a simple package manager that can be a helpful tool alongside dnf (The two are not related at all). Try to stick with the native dnf package manager for Fedora to avoid software conflicts. However, if you don’t find a piece of software in the Fedora Linux repositories, then you might be able to find and install it with Homebrew. See the Formulae list for what is available. Also, Homebrew on Fedora Linux does not support graphical applications (called casks in Homebrew terminology) yet. At least, I didn’t have any luck installing any GUI apps.
To learn more about Homebrew, check out the following resources:
There are two upcoming test weeks in the coming weeks. The first is Monday 28 February through Monday 07 March. It is to test GNOME 42. The second is Monday 07 March through Sunday 13 March. It focuses on testing internationalization. Come and test with us to make the upcoming Fedora 36 even better. Read more below on how to do it.
GNOME is the default desktop environment for Fedora Workstation and thus for many Fedora users. As a part of the planned change the GNOME megaupdate will land on Fedora which then will be shipped with Fedora 36. To ensure that everything works fine The Workstation Working Group and QA team will have this test week Monday 28 February through Monday 07 March. Refer to the GNOME test week wiki page for links and resources.
i18n test week focuses on testing internationalization features in Fedora Linux. The test week is March 07 through March 13.
A test day is an event where anyone can help make sure changes in Fedora work well in an upcoming release. Fedora community members often participate, and the public is welcome at these events. If you’ve never contributed before, this is a perfect way to get started.
To contribute, you only need to be able to download test materials (which include some large files) and then read and follow directions step by step.
Detailed information about both test days are on the wiki pages above. If you’re available on or around the days of the events, please do some testing and report your results.
Fedora test days are events where anyone can help make sure changes in Fedora work well in an upcoming release. Fedora community members often participate, and the public is welcome at these events. If you’ve never contributed to Fedora before, this is a perfect way to get started.
Again, The two upcoming test days in the upcoming week are:
Come and test with us to make the upcoming Fedora 36 even better.

We’ve upgraded the Fedora shirt and sweatshirt collection we announced in March 2020.

What’s new?
OK, but is it made with Linux?
A lot of questions come about as to how exactly do we make the embroidery. Do we use Windows for that? There is a short explanation on our website, but let’s give some more details.
You might have read here at Fedora Magazine that there is a good, fully free (as in freedom) solution to making embroidery designs with Inkscape and Inkstitch. This is the future for us too, and sooner or later we will make all of our embroidery with them. But — mainly because Inkstitch is quite new, and we have been embroidering Linux shirts for a decade — we are still using a manufacturer-independent, but “non-free” program, called Embird. We run it with Wine under Debian. This one is the only proprietary piece of software used here. And it must go, soon…

The other software we use is quite standard for Linux: Inkscape, GIMP, ImageMagick, and of course all of the everyday tools you are using on your Fedora Linux desktop and server.
Check out the embroidered Fedora collection here! Don’t forget to use the FEDORA5 coupon code, for the $5 discount on every shirt and sweatshirt.
Hello everyone. My name is Yasin and I live in Turkey. I am 28 years old and have used Fedora Silverblue for two months and I am an active Fedora Kinoite user. I want to share the information I’ve learned in the process of using the systems. So I’ve decided to write this article. I hope you like it. Let’s get started.
When one says Fedora Linux, the first edition that comes to mind is Fedora Workstation. However, do not overlook the emerging editions Fedora Silverblue (featuring the GNOME desktop environment) and Fedora Kinoite (featuring the KDE desktop environment). Both of these are reprovisionable operating systems based on libostree. They are created exclusively from official RPM packages from the Fedora Project. In this article, I will demonstrate some common steps you might take after a clean installation of Fedora Silverblue or Fedora Kinoite. Everything listed in this article is optional. Exactly what you want to install or how you want to configure your system will depend on your particular needs. What is demonstrated below is just meant to give you some ideas and to provide some examples.
Disclaimer: Packages from Flathub, RPM Fusion, the Copr build system, GitHub, GitLab, et al. are not managed by the Fedora release team and they do not provide official software builds. Use packages from these sources at your own risk.
Fedora Linux in particular releases feature updates and security updates quite often. So you will want to run the below command regularly to keep your system up-to-date. Open the terminal and enter the following command. Afterwards, restart the computer so the changes will take effect.
$ rpm-ostree upgrade
If you want to preview which packages will be updated, use the follow command first.
$ rpm-ostree update --preview
It is also possible to configure automatic updates by editing the rpm-ostreed.conf file as demonstrated below.
$ sudo nano /etc/rpm-ostreed.conf
Change AutomaticUpdatePolicy to check. Then save the change and quit the editor. After that you need to reload rpm-ostree and enable the automatic timer.
$ rpm-ostree reload $ systemctl enable rpm-ostreed-automatic.timer --now
Fedora Silverblue and Fedora Kinoite come preloaded with the basic Fedora Linux repos. In addition, you might want Flatpak, RPM Fusion or some Copr repos.
Flatpak is at the top of the list of ways to install applications on Fedora Silverblue and Fedora Kinoite because it is container-based and it does not require a reboot after installation. To add some remote software libraries and try it out, open the terminal again and enter the following commands.
Fedora Flatpaks remote:
$ flatpak remote-add --if-not-exists fedora oci+https://registry.fedoraproject.org
Flathub remote:
$ flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
Flabhub Beta remote:
$ flatpak remote-add --if-not-exists flathub-beta https://flathub.org/beta-repo/flathub-beta.flatpakrepo
KDE nightly remote:
$ flatpak remote-add --if-not-exists kdeapps --from https://distribute.kde.org/kdeapps.flatpakrepo
GNOME nightly remote:
$ flatpak remote-add --if-not-exists gnome-nightly https://nightly.gnome.org/gnome-nightly.flatpakrepo
After the repositories are added, you need to enter the code below in order to update the application catalog in the GNOME Software and Discover stores. In this way, you will be able to manage applications directly from the store without going to flathub.org.
$ flatpak update --appstream
After that, you can use the store to update Flatpak applications, or if you want to update directly from the terminal, you can enter the code below.
$ flatpak update
If you want to see all installed Flatpaks:
$ flatpak list
Another remote software library you can add is RPM Fusion. To add it on Fedora Silverblue or Fedora Kinoite, open the terminal, enter the following commands and restart.
$ sudo rpm-ostree install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm
$ sudo rpm-ostree install https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm
Copr repos are yet another source of applications that can be installed on Fedora Silverblue and Fedora Kinoite. To add the repos, enter commands in the following form.
$ sudo ostree remote add <name-of-repo> <repository-url>
Example (Heroic Games launcher repo):
$ sudo ostree remote add heroic-games-launcher https://download.copr.fedorainfracloud.org/results/atim/heroic-games-launcher/fedora-$releasever-$basearch/
If you want another option, you can download the repository configuration file from Copr‘s own site and put it in the /etc/yum.repos.d folder.
Libre Office
$ flatpak install flathub org.libreoffice.LibreOffice
Lutris
$ flatpak install —user flathub-beta net.lutris.Lutris//beta
Steam
$ flatpak install flathub com.valvesoftware.Steam
VLC
$ flatpak install flathub org.videolan.VLC
Firefox
$ flatpak install flathub org.mozilla.firefox
Note: Fedora Firefox normally comes preloaded with Fedora Silverblue and Fedora Kinoite. However, the Flatpak version of Firefox has more comprehensive codec support.
If you have installed RPM Fusion repositories, you can install the Nvidia driver by entering the code below and restarting the computer so the changes will take effect.
$ sudo rpm-ostree install akmod-nvidia xorg-x11-drv-nvidia
If you are using the Nvidia System Management Interface (nvidia-smi) or CUDA:
$ sudo rpm-ostree install akmod-nvidia xorg-x11-drv-nvidia-cuda
If you want to install specific kernel, you can always download a kernel from Koji and install it on Fedora Silverblue or Fedora Kinoite using the following command:
$ sudo rpm-ostree override replace ./kernel*.rpm
If you want to install multiple kernels, you will need to pin your deployment by issuing the ostree admin pin 0 command then use the same code above. After restarting, if you pin the new kernel, then you will have two deployments with specific kernels. Remember that you must update them individually because you cannot pin two deployments at the same time.
The Toolbx utility is used primarily for CLI apps, development and debugging tools, etc. However, you can install supported any operating system. In this article, I will give an example of Fedora 35 Workstation installation and use. Fedora Silverblue and Fedora Kinoite come preloaded with Toolbx. So you can start directly.
First, create a toolbox.
$ toolbox create
When the above is complete, enter:
$ toolbox enter
When you see the code that starts with toolbox, then you are in the container operating system. You can list the container(s) by means of:
$ toolbox list
If you want to remove the container, enter:
$ toolbox rmi <container name>
If you need more help, enter:
$ toolbox --help
Thanks to Toolbx, your main operating system will never break. You can pretend to be on Fedora Workstation, install and delete packages, and do things you cannot do on the libostree-based host system. Let’s illustrate with a few examples.
Many users use Toolbx for their developer tools. But it is a really useful tool for regular users as well. For example, you can install Xtreme Download Manager and combine it with Firefox to download content such as music and videos from the internet. It will make your job even easier if you download the file manager before downloading XDM. Now that you are in Toolbx, try installing Nautilus.
$ sudo dnf install nautilus
After that, you can get XDM from here:
https://github.com/subhra74/xdm/releases/download/7.2.11/xdm-setup-7.2.11.tar.xz
Start Nautilus with sudo nautilus while in Toolbx. Then unarchive XDM, open the folder, right click on some empty space and select Open in Terminal. Then enter the below code.
$ su -c ./install.sh
Congratulations! You have successfully installed XDM. After that you will need to open XDM, install Firefox and then open XDM again. Finally, you will want to make the XDM plugin available for Firefox.
$ sudo xdm
$ sudo dnf install firefox
$ sudo firefox
A few more example things that you could do in Toolbx include:
The package layering method modifies the existing installation. You can permanently install almost any RPM package on Fedora Silverblue or Fedora Kinoite. However, you should only layer packages that you consider essential because, after the layering is complete, you will need to reboot the system before you will be able to use the package. For most packages, I recommend using Toolbx.
Package layering is almost identical to installing a RPM package on Fedora Workstation. It’s just rpm-ostree replacing dnf. For example:
$ rpm-ostree install htop
If you want to remove layered packages:
$ rpm-ostree uninstall htop
If you want to see the all layered packages:
$ rpm-ostree status
If you want to remove all layered packages:
$ rpm-ostree uninstall --all
If you are wondering which packages I’ve chosen to layer on my libostree systems, here are my favorites.
Some ways of playing games on Fedora Silverblue or Fedora Kinoite include the following.
People are often advised to play games designed to run on Linux or Windows using Proton on Steam. However, not all Windows games are compatible with Proton; especially online games with cheat protection software. So it is useful to check the site below before installing the game.
In Fedora Silverblue or Fedora Kinoite, there are two ways to install Proton.
From Flathub (using the terminal):
$ flatpak install com.valvesoftware.Steam.CompatibilityTool.Proton
From GitHub (manually):
https://github.com/GloriousEggroll/proton-ge-custom
My advice is to use the proton-ge-custom version (Gloruious Eggroll) because it contains extra patches and fixes for many popular games. You can read about how to install proton-ge-custom and how to activate it on Steam in the README.md file in the above GitHub repo.
If you do not want to use an online platform, it is possible to play the game using Wine. But you need to go to Wine‘s official site and read the reports about the game or try it yourself to see if the game works. Also, don’t think of it as just a game engine. Wine can run a wide verity of Windows programs. So how do you install Wine? Unfortunately, Wine cannot be directly installed on Fedora Silverblue or Fedora Kinoite as a layered package due to rpm-ostree’s lack of 32-bit support. It is possible, however, to install Wine using some indirect methods. The Winepak repo is dead now. So I’ll skip that.
Method 1: Use a Flathub application as a Wine launcher.
Lutris, Bottles, ProtonUp-Qt and finally Phoenicis PlayOnLinux
Method 2: Install Wine or Lutris in Toolbx with Steam.
$ sudo dnf install wine lutris steam
Method 3: Partially install Wine on rpm-ostree.
$ rpm-ostree install wine-core wine-core.i686 lutris
There are other methods of playing games on Linux. Native Linux games, for example, are available in many repositories. Browser games are also easy to access. Installing Windows in a virtual machine is another method. However, while a virtual machine may work for simpler games, I do not recommend it for games that require a lot of processing power.
In this final section, I would like to mention a few more things that do not depend on anything mentioned earlier in this article.
You can use the override sub-command to manage base packages. For example, to remove the pre-loaded Firefox:
$ rpm-ostree override remove firefox
If you want to remove all overlays, overrides and initramfs:
$ rpm-ostree ex reset
rpm-ostree provides an experimental live update feature so that you can avoid rebooting after installing packages.
$ rpm-ostree install --apply-live htop
Since you are on Fedora Silverblue or Fedora Kinoite, switching systems or updating to rawhide can be done with just a few commands. Also, reverting is easier than ever.
Substitute system with kinoite or silverblue in the below examples.
Switch systems:
$ rpm-ostree rebase fedora/35/x86_64/system
Upgrade to rawhide:
$ rpm-ostree rebase fedora/rawhide/x86_64/system
Rollback to a previous version:
$ rpm-ostree rollback fedora/35/x86_64/system
On Fedora Workstation you can use dnf to list the packages in the repositories. But this does not work on Fedora Silverblue or Fedora Kinoite. So how do you do it? If you want to list the installed RPM packages on your system, you can use the following command.
To list the installed RPM packages:
$ rpm -qa
However, if you want to list the packages in the repositories, you must either layer the dnfdragora package or enter Toolbx. Then you can use the following dnf commands.
To list all RPM packages (both installed and available):
$ dnf list
To search for a specific RPM package:
$ dnf search <packagename>
Note: For now, do not install Dolphin from Flatpak because it replaces the preinstalled Dolphin on the system. With the Flatpak version of Dolphin, you will not be able to preview videos because it does not contain the packages mentioned above
Dear friends, you have come to the end of this article. If you have anything you want to add to this topic or if you have questions, I am waiting for you in the comments section below. Also, special thanks to Badhshah, Timothée Ravier and Daniels for helping me with some information in preparing this article. Finally, if you want to contribute to Fedora Silverblue or Fedora Kinoite or get more information, check the links below. Thank you for reading.
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.
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.
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.
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.
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.
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:
[Terminal ~]$ flatpak remote-ls --app fedora | wc -l 86 [Terminal ~]$ flatpak remote-ls --app flathub | wc -l 1518
Here, at the time of writing this article, we can see that Flathub has 1518 applications available, whereas Fedora Flatpaks has only 86.
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 (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.
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.
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).
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 Fedora Project, through the Marketing team, is happy to announce the first FedoraShareYourScreen week!
We know that even though the stock look of Fedora Linux is awesome, most people love to tweak and adapt their systems to their own workflow. We want to see how your Fedora Linux desktop looks.
).Feel proud of your customization and show it to us! From January 31st to February 6th we will be looking, commenting and sharing feedback on the screenshots shared with the hashtag #FedoraShareYourScreen on Twitter, Instagram and Mastodon!
It will start this on January 31st and it will end on February 6th. We will collect all the screenshots on February 7th and the slide show will be published on February 10th.
Of course! We want to see everyone’s ideas with all the new stuff that Fedora Linux adds each release. We will be doing this in the middle of each Fedora Linux release. This will give everyone time to customize the desktop and show it in all it’s shininess!

You do not want someone else to be able to monitor or even control your computer and you usually work hard to cut off any such attempts using various security mechanisms. However, sometimes a situation occurs when you desperately need a friend, or an expert, to help you with a computer problem, but they are not at the same location at the same time. How do you show them? Should you take your mobile phone, take pictures of your screen, and send it to them? Should you record a video? Certainly not. You can share your screen with them and possibly let them control your computer remotely for a while. In this article, I will describe how to allow sharing the computer screen in Gnome.
A server is a computer that provides (serves) some content that other computers (clients) will consume. In this article the server runs Fedora Workstation with the standard Gnome desktop.
By default, the ability to share the computer screen in Gnome is off. In order to use it, you need to switch it on:


A client is a computer that connects to a service (or content) provided by a server. This demo will also run Fedora Workstation on the client, but the operating system actually should not matter too much, if it runs a decent VNC client.
Sharing the computer screen in Gnome between the server and the client requires a working network connection and a visible “route” between them. If you cannot make such a connection, you will not be able to view or control the shared screen of the server anyway and the whole process described here will not work.
To make sure a connection exists
Find out the IP address of the server.
Start Gnome Control Center, a.k.a Settings. Use the Menu in the upper right corner, or the Activities mode. When in Activities, type
and click on the corresponding icon.
Select the Network tab.
Click on the Settings button (cogwheel) to display your network profile’s parameters.
Open the Details tab to see the IP address of your computer.
Go to your client’s terminal (the computer from which you want to connect) and find out if there is a connection between the client and the server using the ping command.
$ ping -c 5 192.168.122.225
Examine the command’s output. If it is similar to the example below, the connection between the computers exists.
PING 192.168.122.225 (192.168.122.225) 56(84) bytes of data. 64 bytes from 192.168.122.225: icmp_seq=1 ttl=64 time=0.383 ms 64 bytes from 192.168.122.225: icmp_seq=2 ttl=64 time=0.357 ms 64 bytes from 192.168.122.225: icmp_seq=3 ttl=64 time=0.322 ms 64 bytes from 192.168.122.225: icmp_seq=4 ttl=64 time=0.371 ms 64 bytes from 192.168.122.225: icmp_seq=5 ttl=64 time=0.319 ms --- 192.168.122.225 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4083ms rtt min/avg/max/mdev = 0.319/0.350/0.383/0.025 ms
You will probably experience no problems if both computers live on the same subnet, such as in your home or at the office, but problems might occur, when your server does not have a public IP address and cannot be seen from the external Internet. Unless you are the only administrator of your Internet access point, you will probably need to consult about your situation with your administrator or with your ISP. Note, that exposing your computer to the external Internet is always a risky strategy and you must pay enough attention to protecting your computer from unwanted access.
Remmina is a graphical remote desktop client that can you can use to connect to a remote server using several protocols, such as VNC, Spice, or RDP. Remmina is available from the Fedora repositories, so you can installed it with both the dnf command or the Software, whichever you prefer. With dnf, the following command will install the package and several dependencies.
$ sudo dnf install remmina
If there is a connection between the server and the client, make sure the following is true:
Then you can attempt to connect to the session from the client:


When you return back to the server, you will notice that there is now a yellow icon in the upper bar which indicates that you are sharing the computer screen in Gnome. If you no longer wish to share the screen, you can enter the menu and click on Screen is being shared and then on select Turn off to stop sharing the screen immediately.

By default, the connection will always terminate when the session locks. A new connection cannot be established until the session is unlocked.
On one hand, this sounds logical. If you want to share your screen with someone, you might not want them to use your computer when you are not around. On the other hand, the same approach is not very useful, if you want to control your own computer from a remote location, be it your bed in another room or your mother-in-law’s place. There are two options available to deal with this problem. You can either disable locking the screen entirely or you can use a Gnome extension that supports unlocking the session via the VNC connection.
In order to disable the screen lock:
Now, the session will never lock (unless you lock it manually), so it will be possible to start a VNC connection to it.
If you do not want to switch off locking the screen or you want to have an option to unlock the session remotely even when it is locked, you will need to install an extension that provides this functionality as such behavior is not allowed by default.
To install the extension:


Now, it will be possible to start a VNC connection any time. Note, that you will need to know the session password to unlock the session. If your VNC password differs from the session password, your session is still protected a little.
This article, described the way to enable sharing the computer screen in Gnome. It mentioned the difference between the limited (view-only) access or not limited (full) access. This solution, however, should in no case be considered a correct approach to enable a remote access for serious tasks, such as administering a production server. Why?
There are several ways, you can set up a protected VNC connection. You could tunnel it via the SSH protocol for better security, for example. However, these are beyond the scope of this article.
Disclaimer: The above workflow worked without problems on Fedora 35 using several virtual machines. If it does not work for you, then you might have hit a bug. Please, report it.
Quarkus is a foundation for building Java based applications; whether for the desktop, server or cloud. An excellent write up on usage can be found at https://fedoramagazine.org/using-the-quarkus-framework-on-fedora-silverblue-just-a-quick-look/. This article is primer for coding asynchronous processes using Quarkus and Mutiny.
So what is Mutiny? Mutiny allows streaming of objects in an event driven flow. The stream might originate from a local process or something remote like a database. Mutiny streaming is accomplished by either a Uni or a Multi object. We are using the Uni to stream one object — a List containing many integers. A subscribe pattern initiates the stream.
A traditional program is executed and results are returned before continuing. Mutiny can easily support non-blocking code to run processes concurrently. RxJava, ReactiveX and even native Java are alternatives. Mutiny is easy to use (the exposed API is minimal) and it is the default in many of the Quarkus extensions. The two extensions used are quarkus-mutiny and quarkus-vertx. Vert.x is the underlying framework wrapped by Quarkus. The Promise classes are supplied by quarkus-vertx. A promise returns a Uni stream when the process is complete. To get started, install a Java JDK and Maven.
The minimum requirement is either Java-11 or Java-17 with Maven.
With Java-11:
$ sudo dnf install -y java-11-openjdk-devel maven
With Java-17:
$ sudo dnf install -y java-17-openjdk-devel maven
Bootstrap Quarkus and Mutiny with the Maven call below. The extension quarkus-vertx is not included to demonstrate how to add additional extensions. Locate an appropriate directory before executing. The directory mutiny-demo will be created with the initial application.
$ mvn io.quarkus.platform:quarkus-maven-plugin:2.6.2.Final:create \ -DprojectGroupId=fedoramag \ -DprojectArtifactId=mutiny-demo \ -DprojectVersion=1.0.0 \ -DclassName="org.demo.mag.Startup" \ -Dextensions="mutiny" \ -DbuildTool=gradle
Now that Gradle is bootstrapped, other extensions can be added. In the mutiny-demo directory execute:
$ ./gradlew addExtension --extensions='quarkus-vertx'
To view all available extensions execute:
$ ./gradlew listExtensions
To get all of the defined Gradle tasks execute:
$ ./gradlew tasks
The className entry on the Quarkus bootstrap is org.demo.mag.Startup which creates the file src/main/java/org/demo/map/Startup.java. Replace the contents with the following code:
package org.demo.mag; import java.util.List;
import java.util.concurrent.ExecutionException;
import java.util.function.IntSupplier;
import java.util.stream.Collectors;
import java.util.stream.IntStream; import io.quarkus.runtime.Quarkus;
import io.quarkus.runtime.QuarkusApplication;
import io.quarkus.runtime.annotations.QuarkusMain;
import io.smallrye.mutiny.Uni;
import io.smallrye.mutiny.tuples.Tuple2;
import io.vertx.mutiny.core.Promise; @QuarkusMain
public class Startup implements QuarkusApplication { public static void main(String... args) { Quarkus.run(Startup.class, args); } @Override public int run(String... args) throws InterruptedException, ExecutionException { final Promise<String> finalMessage = Promise.promise(); final String elapsedTime = "Elapsed time for asynchronous method: %d milliseconds"; final int[] syncResults = {0}; Application.runTraditionalMethod(); final Long millis = System.currentTimeMillis(); Promise<List<Integer>> promiseRange = Application.getRange(115000); Promise<Tuple2<Promise<List<Integer>>, Promise<List<Integer>>>> promiseCombined = Application.getCombined(10000, 15000); Promise<List<Integer>> promiseReverse = Application.getReverse(24000); /* * Retrieve the Uni stream and on the complete event obtain the List<Integer> */ promiseRange.future().onItem().invoke(list -> { System.out.println("Primes Range: " + list.size()); if(syncResults[0] == 1) { finalMessage.complete(String.format(elapsedTime, System.currentTimeMillis() - millis)); } { syncResults[0] = 2; } return; }).subscribeAsCompletionStage(); promiseReverse.future().onItem().invoke(list -> { System.out.println("Primes Reverse: " + list.size()); return; }).subscribeAsCompletionStage(); /* * Notice that this finishes before the other two prime generators(smaller lists). */ promiseCombined.future().onItem().invoke(p -> { /* * Notice that "Combined Range" displays first */ p.getItem2().future().invoke(reverse -> { System.out.println("Combined Reverse: " + reverse.size()); return; }).subscribeAsCompletionStage(); p.getItem1().future().invoke(range -> { System.out.println("Combined Range: " + range.size()); /* * Nesting promises to get multple results together */ p.getItem2().future().invoke(reverse -> { System.out.println(String.format("Asserting that expected primes are equal: %d -- %d", range.get(0), reverse.get(reverse.size() - 1))); assert range.get(0) == reverse.get(reverse.size() - 1) : "Generated primes incorrect"; if(syncResults[0] == 2) { finalMessage.complete(String.format(elapsedTime, System.currentTimeMillis() - millis)); } else { syncResults[0] = 1; } return; }).subscribeAsCompletionStage(); return; }).subscribeAsCompletionStage(); return; }).subscribeAsCompletionStage(); // Note: on very fast machines this may not display first. System.out.println("This should display first - indicating asynchronous code."); // blocking for final message String elapsedMessage = finalMessage.futureAndAwait(); System.out.println(elapsedMessage); return 0; } public static class Application { public static Promise<List<Integer>> getRange(int n) { final Promise<List<Integer>> promise = Promise.promise(); // non-blocking - this is only for demonstration(emulating some remote call) new Thread(() -> { try { /* * RangeGeneratedPrimes.primes is blocking, only returns when done */ promise.complete(RangeGeneratedPrimes.primes(n)); } catch (Exception exception) { Thread.currentThread().interrupt(); } }).start(); return promise; } public static Promise<List<Integer>> getReverse(int n) { final Promise<List<Integer>> promise = Promise.promise(); new Thread(() -> { try { // Generating a new object stream promise.complete(ReverseGeneratedPrimes.primes(n)); } catch (Exception exception) { Thread.currentThread().interrupt(); } }).start(); return promise; } public static Promise<Tuple2<Promise<List<Integer>>, Promise<List<Integer>>>> getCombined(int ran, int rev) { final Promise<Tuple2<Promise<List<Integer>>, Promise<List<Integer>>>> promise = Promise.promise(); new Thread(() -> { try { Uni.combine().all() /* * Notice that these are running concurrently */ .unis(Uni.createFrom().item(Application.getRange(ran)), Uni.createFrom().item(Application.getReverse(rev))) .asTuple().onItem().call(tuple -> { promise.complete(tuple); return Uni.createFrom().nullItem(); }) .onFailure().invoke(Throwable::printStackTrace) .subscribeAsCompletionStage(); } catch (Exception exception) { Thread.currentThread().interrupt(); } }).start(); return promise; } public static void runTraditionalMethod() { Long millis = System.currentTimeMillis(); System.out.println("Traditiona1-1: " + RangeGeneratedPrimes.primes(115000).size()); System.out.println("Traditiona1-2: " + RangeGeneratedPrimes.primes(10000).size()); System.out.println("Traditiona1-3: " + ReverseGeneratedPrimes.primes(15000).size()); System.out.println("Traditiona1-4: " + ReverseGeneratedPrimes.primes(24000).size()); System.out.println(String.format("Elapsed time for traditional method: %d milliseconds\n", System.currentTimeMillis() - millis)); } } public interface Primes { static List<Integer> primes(int n) { return null; }; } public abstract static class PrimeBase { static boolean isPrime(int number) { return IntStream.rangeClosed(2, (int) (Math.sqrt(number))) .allMatch(n -> number % n != 0); } } public static class RangeGeneratedPrimes extends PrimeBase implements Primes { public static List<Integer> primes(int n) { return IntStream.rangeClosed(2, n) .filter(x -> isPrime(x)).boxed() .collect(Collectors.toList()); } } public static class ReverseGeneratedPrimes extends PrimeBase implements Primes { public static List<Integer> primes(int n) { List<Integer> list = IntStream.generate(getReverseList(n)).limit(n - 1) .filter(x -> isPrime(x)).boxed() .collect(Collectors.toList()); return list; } private static IntSupplier getReverseList(int startValue) { IntSupplier reverse = new IntSupplier() { private int start = startValue; public int getAsInt() { return this.start--; } }; return reverse; } }
}
The Quarkus install showcases the quarkus-resteasy extension by default. We are not using it, replace the contents of src/test/java/org/demo/mag/StartupTest.java with:
package org.demo.mag; import io.quarkus.test.junit.QuarkusTest;
import io.vertx.mutiny.core.Promise; import java.util.List; import org.demo.mag.Startup;
import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.Tag;
import org.junit.jupiter.api.Test; @QuarkusTest
public class StartupTest { Promise<List<Integer>> promise = Promise.promise(); Promise<Void> promiseAndAwait = Promise.promise(); List<Integer> testValue; @Tag("DEV") @Test public void testVerifyAsync() { Assertions.assertEquals( null , testValue); promise.future().onItem().invoke(list -> { testValue = list; promiseAndAwait.complete(); }).subscribeAsCompletionStage(); Assertions.assertEquals(null, testValue); promise.complete(Startup.ReverseGeneratedPrimes.primes(100)); promiseAndAwait.futureAndAwait(); Assertions.assertNotNull(testValue); Assertions.assertEquals(2, testValue.get(testValue.size()-1)); }
}
To reduce download volume, remove the following entries from the build.gradle file.
implementation 'io.quarkus:quarkus-resteasy' testImplementation 'io.rest-assured:rest-assured'
The next step is to build the project. This includes downloading all dependencies as well as compiling and executing the Startup.java program. Everything is included in one file for brevity.
$ ./gradlew quarkusDev
The above command produces a banner and console output from Quarkus and the program.
This is development mode. Notice the prompt: “Press [space] to restart”. To review edits hit the space-bar and enter-key to re-compile and execute. Enter q to quit.
To build an Uber jar (all dependencies included) execute:
$ ./gradlew quarkusBuild -Dquarkus.package.type=uber-jar
This creates a jar in the build directory named mutiny-demo-1.0.0-runner.jar. To run the jar file, enter the following command.
$ java -jar ./build/mutiny-demo-1.0.0-runner.jar
To remove the banner and console logs, add the following lines to the src/main/resources/application.properties file.
%prod.quarkus.log.console.enable=false %prod.quarkus.banner.enabled=false
The output might look similar to the following.
Traditional-1: 9592 Traditional-2: 1229 Traditional-3: 2262 Traditional-4: 2762 Elapsed time for traditional method: 67 milliseconds Combined Range: 1229 This should display first - indicating asynchronous code. Combined Reverse: 2262 Primes Reverse: 2762 Asserting that expected primes are equal: 2 -- 2 Primes Range: 9592 Elapsed time for asynchronous method: 52 milliseconds
You will still get the banner and logs in development mode.
To go one step further, Quarkus can generate an executable out of the box using GraalVM.
$ ./gradlew build -Dquarkus.package.type=native
The executable generated by the above command will be ./build/mutiny-demo-1.0.0-runner.
The default GraalVM is a downloaded container. To override this, set the environment variable GRAALVM_HOME to your local install. Don’t forget to install the native-image with the following command.
$ ${GRAALVM_HOME}/bin/gu install native-image
The code, generates prime numbers for a range, reversed on a limit and a combination of the two. For example, consider the range: “Promise<List<Integer>> promiseRange = Application.getRange(115000);”.
This generates all primes between 1 and 115000 and displays the number of primes in the range. It is executed first but displays its results last. The code near the end of the main method — System.out.println (“This should display first – indicating asynchronous code.”); — displays first. This is an example of asynchronous code. We can run multiple processes concurrently. However, the order of completion is unpredictable. The traditional calls are orderly and the results can be collected when completed.
Execution can be blocked until a result is returned. The code does exactly that to display the asynchronous elapsed time message. At the end of the main method we have: “String elapsedMessage = finalMessage.futureAndAwait();”. The message arrives from either promiseRange or promiseCombined — the two longest running processes. But even this is not guaranteed. The state of the underling OS is unknown. One of the other processes might finish last. Normally, asynchronous calls are nested to co-ordinate results. This is demonstrated in the promiseCombined promise to evaluate the results of range and reversed primes.
The comparison between the traditional method and asynchronous method suggests that the asynchronous method can be up to 25% faster on a modern computer. An older CPU that does not have the resources and computing power produces results faster with the traditional method. If a computer has many cores, why not use them‽
More documentation can be found on the following web sites.