I’ve spent a fair amount of time with Fedora over the years. Actually, it has been the most used distro of Linux for the nearly 20 years I’ve used the operating system. So, when the time came to test it out for the BigDaddyLinux Live distro challenge, I was pretty excited. Having used Fedora in my personal life and Red Hat/CentOS in my professional life I feel really at home with this choice. The tools that are available for this platform are top notch.

First, the package manager: DNF. It has an unfortunate name, frequently found in racing as Did Not Finish, it is quite useful and robust. DNF offers the standard package management of installing, searching and removing software packages. However, it offers much more. There is a History feature in DNF that allows you to roll back entire changes made by the package manager. If an update goes awry, you can simply use DNF’s history function to roll it back. DNF is also extensible by plugins. These plugins can facilitate different tasks such as repo management and system upgrades. The configuration file is also flexible in that you can add and remove core functionality from one point. Things, like searching for the fastest mirror for your location automatically and being able to control whether or not unused dependencies are removed when removing a package, are just a couple of examples.

Being a Red Hat product, there are many conventions that people coming from Debian-based distros might find funny. Fedora tries to adhere to the standard hierarchy of the Linux filesystem. Thus, temporarily mounted volumes are under /run/media as opposed to /media. The distro is also highly plugged into systemd. I know there are people out there who cannot stand the integration of systemd into modern Linux, and those people would be advised not to use this distro. Support for technologies, such as KVM, is built into the distro as well.

As I am not a developer, casually or professionally, I cannot personally speak to the efficiency of Fedora as a dev platform. However, I do know that the Fedora team make sure to ship as new libraries as is reasonable for developers. The GNOME Builder app is also available for people who are interested in developing GTK-based GNOME apps in a variety of languages like Vala, C, and Python. There are also offerings of popular dev tools like Visual Studio Code and IDEA IntelliJ that are available as Flatpaks.

That brings me to Flatpaks in general. They are wonderfully integrated into GNOME and Fedora in such a way that offers them as first-class citizens on the desktop. You won’t find server- or terminal-based applications in here, though. Flatpak is simply a way to package and deliver graphical applications to the modern Linux desktop. After visiting the Flathub website and installing the Flathub repo you are opened to a nice spread of useful apps. There are terminal commands for installing Flatpaks that are simple and easy to use, but you can also install them simply from the GNOME Software app. I’ve encountered a couple of issues with Flatpaks, though. Attempting to use the GPU acceleration in the Blender or Darktable Flatpaks is a futile exercise. OpenCL is just not surfaced for the apps due to the sandboxing. The Steam Flatpak also had issues using a different Vulkan library than that which was shipped with it for my AMD card. Attempting to use the AMDVLK driver with the Flatpak just wasn’t going to happen. While not a completely perfect solution, I do think they serve a purpose in our increasingly fragmented Linux world.

The graphics stack used on Fedora might be a bit confusing to some given that it uses Wayland by default. Wayland is still rather young when compared to solutions such as X and what is available on other platforms. However, it is a very capable display server provided you have well-supported hardware to drive it. Those with Intel and AMD hardware should have no issue. Those with Nvidia hardware might be presented with more difficulties. The Nouveau drivers, open source Nvidia drivers, are not a good choice for anyone outside of one or two older generations of the card. For the rest of humanity, you will be using the proprietary driver to get the most out of your experience. There are ways to enable Wayland on the proprietary driver, as the GNOME compositor does support EGLStreams that the Nvidia cards use. However, this experience is met with performance issues and is not as feature complete as the AMD and Intel experiences. So, the Fedora devs have placed a udev rule that will detect the presence of the Nvidia driver and fall back to X so there are no issues.

There are third-party repos for Fedora as well. RPMFusion and UnitedRPM are the most common. I have had mixed results when using the UnitedRPM repo, but RPMFusion has provided a good experience. Negativo17, another repo, includes many packages that people might want, but I still think RPMFusion will cover what most people need. Then there’s the COPR system. Anyone who is familiar with the Open Build Service or PPAs will immediately understand COPR repos. They are user-created repos that offer packages that are not packaged by the Fedora team or RPMFusion due to scope, niche, or simply time and resources. There are some COPR repos that can give the latest Mesa builds and others who can provide open source applications that may be prohibitively difficult for most users to build and package. Regardless of the repos you add, they are all fine choices. Just be careful about mixing them and finding yourself in a repo mess.

Honestly, there isn’t much to dislike about Fedora in my opinion. It’s a solid release with many great things going for it. This is one BDLL challenge that I am more than happy to participate in. If any of you are curious about Fedora and all it has to offer, just head on over to the Fedora Project page and download it today. It’ll definitely be worth your time.