UBUNTU VS FEDORA

• What makes them great, again?
• Stepping up a gear
• FREE AS IN “WHY WON’T MY FREEKING WIRELESS WORK?”
• What’s in a top-tier distro?
• Chains of command
• Support levels
• STOP BUGGING ME
• Harness your hardware for smoother streaming
• Intel Inside, but is it working?
• Nvidia and AMD
• PLODDING TOWARDS ACCELERATION
• Flavours, spins, upgrades
• So come up to the Lab…
• Upgrading your distro of choice
• SWITCH PULSEAUDIO FOR PIPEWIRE IN UBUNTU

FREE AS IN “WHY WON’T MY FREEKING WIRELESS WORK?”

Apropos to our licencing feature (wow our technical editor is good), Ubuntu and Fedora have fairly divergent policies as to what can and what cannot live in each distributions repositories. We mentioned ZFS earlier, which has its origins in Sun’s Solaris operating system. It was open sourced in 2003, but done so under the Common Development and Distribution License (CDDL). As such it can’t be part of the Linux Kernel proper, since CDDL code can’t be relicenced under GPLv2. But the ZFS on Linux (ZoL) project has engineered a kernel module that Canonical is apparently happy enough to distribute with its OS. Fedora doesn’t have any truck with non-free offerings, and as such ZoL, the proprietary Nvidia driver and various bits of Wi-Fi firmware all require remedial steps to install there.

This stance on software freedom shouldn’t necessarily be a reason to not use Fedora. It’s easy for owners of Nvidia hardware to get Fedora to be set up for AAA-gaming. Just add the RPMFusion-Nvidia repository in the same way as (over the page) we add the non-free repository for the Intel Media SDK.

Fedora generally gets new technology working before other distros, with the exception of bleeding-edge ones like Arch and Gentoo. However, in those distros even though the new technology is there, getting it to actually work without breaking something else is often a challenge (that we enjoy, right? – Ed). 

What’s in a top-tier distro?

Just as anyone can contribute to the Linux Kernel, so anyone can contribute to Fedora or Ubuntu. You don’t need to be a seasoned coder – there are always translation and documentation tasks to do. If you’re a dab hand with a (virtual) paintbrush maybe you could contribute some icons, themes and logos too. Distro development isn’t some communist free for all, though. There are committees and managerial structures, though these are in general much less rigid than you’d find in a similar-sized company. In 2015 some 35 per cent of the 2,000-odd Fedora contributors were Red Hat employees, though the remaining 65 per cent may well have been working for someone else.

We won’t get into the technical minutia of how a distro is actually made. Look at the appropriate -next branch of any distro’s GitHub and you can get an idea of the process. For illustration though, a week after the release of Ubuntu 21.10, the first daily builds of 22.04 (Jammy Jellyfish) appeared. These at the time of writing hardly differ at all from the 21.10 release, since the first steps are to decide on the build environment and get everyone’s toolchains synced. You can find the release schedule at https://discourse.ubuntu.com/t/jammy-jellyfish-release-schedule/23906, which shows when new software planned for inclusion is released.

THE ART OF GOOD REPORTING

“If you think you’ve found a bug then familiarise yourself with the bug-reporting process for each distro, so that the developers can fix it”

OpenSSL 3 and Ruby 3.0 are both slated for release in November, for example. If you’re upset that Ubuntu 21.10 missed out on Gnome 41 (by dint of misaligned release schedules), you’ll be pleased to hear that Gnome 42 will (assuming no delays to its release) be powering the Ubuntu 22.04 desktop.

Chains of command

Fedora is governed primarily by the Fedora Council, which includes representatives from all over the project, Red Hat-nominated members and a few others. Beneath that are FESCo, the Fedora Engineering Steering Committee, and MindShare. FESco is responsible for deciding on the technical direction of the project and MindShare is all about community outreach, conducting liaison between teams and encouraging contributors to mix with other teams. Reporting into FESCo and MindShare are many smaller Engineering and Community teams. See the diagram (below left).

Like Fedora, Ubuntu’s development releases feed into its big, stable releases (the LTSes) which is what people will run on their servers and will be supported for 10 years (with an Ubuntu Advantage subscription). It’s these releases, in conjunction with Canonical’s support for enterprise tooling (OpenStack, Kubernetes, Ceph, etc), that fill its coffers, so it’s in its interests to make the LTS editions fantastic. Also like Fedora, contributions to each new release don’t just come from Canonical employees, but also from other companies and volunteers. Oversight is apportioned between the Ubuntu Technical Board and the Ubuntu Community Council, which are analagous to FESCo and MindShare. A key difference is that Ubuntu has a SABDFL (self-appointed benevolent dictator for life) in the form of Mark Shuttleworth, who has a casting vote on both of these committees.

Ubuntu’s Technical Board and Community council both meet fortnightly on IRC. This might seem like an outdated (or, if you’ve never used IRC before, complicated) way to do meetings. But it’s better than Zoom and, since it’s how a great deal of open source projects are co-ordinated, is unlikely to go away soon. Fedora boards also use IRC, and have a great guide for newcomers at https://fedoramagazine.org/beginners-guide-irc.

Perhaps an overlooked part of making a distro is baking the files (ISO or USB images) that people will download and install. Fedora and Ubuntu both have their own tools for doing this non-trivial task.

Support levels

Both Canonical and Red Hat make money from providing support to their Enterprise customers. For machines on your own infrastructure, Canonical offers Ubuntu Advantage for Infrastructure (UA-I) and a quick glance at https://ubuntu.com/pricing shows that comes in three tiers. Its cheapest Essential support offering is available to those using the LTS releases on servers ($225 per machine per year), virtual machines ($75) and desktops. This doesn’t include phone support, but you can pay extra ($525 per annum) for that, and is only available for their LTS offerings. If you’re looking for paid support with installation, drivers or anything else consumer oriented then this isn’t really for you. It’s more aimed at infrastructure and server management (using Canonical’s Landscape administration tool).

That said, the Essential tier is available for free on up to three machines (or 50 if you’re an Official Community Member), and includes Extended Security Maintenance for older releases (namely 14.04 and 16.04) and access to the kernel live patching service. Again, kernel patching is only available for the standard LTS kernel, so no use for Ubuntu 21.10. Fedora is a community supported distribution, so there’s no paid support there. Red Hat supports Red Hat Enterprise Linux, which technology tested in Fedora (and now CentOS Stream too) will eventually find its way into once it’s stabilised. If you want support (beyond updates) with Kubernetes or OpenStack then you need to move up to the Standard tier. If you’re running Ubuntu on a public cloud, i.e. AWS, Azure or GCP, then you can, for a tiny bump on your hourly costs, switch to Ubuntu Pro instead.

For community support, there are official Ask Fedora and an Ask Ubuntu websites (run on Discourse and StackOverflow, respectively). These both receive dozens of questions a day, and both have easily accessible information on how to ask good questions and be a good human. There are also more traditional forums at The Fedora Lounge (https://forums.fedoralounge.com) and https://ubuntuforums.org). If you think you’ve found a bug then familiarise yourself with the bug-reporting process for each distro, so that the developers can fix it. If you’re a beginner, or angry, then please resist the temptation to post until you’re familiar with this process or have calmed down.

For tracking bugs Fedora uses the popular Bugzilla application where as Ubuntu uses the equally popular Launchpad. Both platforms have much the same workflow: bug reports are triaged, tested and (hopefully) fixed, but they might also be marked as “Won’tFix” (where the issue is judged not to be a problem) or as a duplicate of another bug. The Bugzilla application is also used for feature requests, but again you should familiarise yourself with the etiquette here. Launchpad enables more advanced users to file ‘blueprints’ for desired features.

It goes without saying that you should perform due diligence and check your bug (or feature request) hasn’t already been reported before filing a new one. Fedora maintains a list of common bugs at https://fedoraproject.org/wiki/Bugs/Common, which you should scrutinise for the aberration you’re planning on reporting. Sometimes the same bug will manifest itself in different ways, so inevitably some seemingly different bugs will end up being marked as duplicates.

STOP BUGGING ME

Besides manually reporting bugs, you can also send crash information to the relevant teams. Fedora’s Automatic Bug Reporting Tool (ABRT) will spring into action whenever a Fedora-packaged application crashes, and automatically sends an anonymised crash report to its Abrt Analytics server. This (without human intervention) collates similar reports and if a solution is available the user is given appropriate instructions. If no fix has been identified reports will be looked at by packagers who hopefully will come up with something soon.

ABRT can add stack traces as well as prompt the user for details. Ubuntu’s apport does much the same, reporting to the Ubuntu Bug Control and Bug Squad teams. Study these reports at https://bugs.launchpad.net/ubuntu/+source/plasma-workspace/+bug/1945904. There are a few relics listed there so sort them by number to see what’s new in the world of Ubuntu crashes. For more details on reporting Ubuntu bugs, or joining the bug squishing teams, check out https://help.ubuntu.com/stable/ubuntu-help/report-ubuntu-bug.html.en.

Sometimes bug reporters will be invited to test packages from each distro’s proposed updates repository. These are easy to set up, but in general it’s a bad idea to enable them universally, since this might end up upgrading every package, for which there’s a proposed fix. This makes it very likely that, even if some bugs get fixed, other packages will break. Fedora’s Bodhi system (http://bodhi.fedoraproject.org) is used to track bugs with proposed updates, where as for Ubuntu everything is more or less unified on Launchpad.net.

Harness your hardware for smoother streaming

Since browsing the web constitutes a great deal of most people’s computing time, we thought we’d see if we could find any subtle differences between each distro’s out-of-the-box Firefox configuration. We’ve said before that Firefox can be made smoother by enabling the WebRender backend and activating VA-API for hardware-accelerated video decoding. But getting this to work in the real world takes a bit of trial and error.

Both distros ship Firefox 93, and if you do a fresh install of Ubuntu this uses Mozilla’s Snap. Users upgrading from previous Ubuntus will get the DEB version from the repos. The first step is getting VA-API working, which on Ubuntu was pretty easy. A simple sudo apt install vainfo pulled in all the required video drivers. Then running vainfo and not getting an error message showed that iHD (the MediaSDK driver for newer Intel graphics) was ready for VA-API processing. On Fedora the process was harder. The package containing vainfo is called libva-utils on Fedora, but just installing this (with dnf install libva-utils) was not enough – no drivers were pulled in. We searched the base repositories for libva and found libva-intel-hybrid-driver, which turned out to be no use – that driver is for older chips and we had a 10th Gen Dell XPS. So a bit of Googling evinced that the required drivers were available in the RPMfusion repositories.

RPMfusion hosts various popular packages that can’t be included in Fedora’s stock offerings. There are two RPMfusion repositories, free and nonfree and they’re really easy to enable nowadays. So easy you don’t even need to type anything: just browse to https://rpmfusion.org/Configuration and click the “RPM Fusion free” link for Fedora 35 (or whatever version you’re running). Firefox on Fedora is already set up to open RPM files with Package Installer, so follow the prompts (don’t worry about the “missing security signature” warning) and the repository will be added. Inside the free repo you’ll find the libva-intel-driver package, which contains the i965 libva-accelerated driver.

Intel Inside, but is it working?

This works for all but the most recent (Icelake and above) Intel chips, but on Gen8 graphics (Broadwell) and above you may want to try the iHD driver. This contains some proprietary bits, and as such can be found in the nonfree RPMfusion repo. Add that in the same way as we added the free one (you can’t enable only RPMfusion-nonfree). Then install the iHD driver with a swift sudo dnf install intel-media-driver, and a quick look at vainfo will show if you’re in business. To decode the video you’ll also want the ffmpeg-libs package from RPMfusion-nonfree.

Actually getting VA-API playback enabled in Firefox 93 took a bit of headscratching. Fortunately the same options worked on both distros, so we’ll summarise them here. Open about:config in Firefox and set the following options to true :

gfx.webrender.all

media.ffmpeg.vaapi.enabled

media.navigator.

mediadatadecoder_vpx_ enabled

The last one will speed up VPx-encoded WebRTC traffic, which is what’s used for video chatting.

There are a number of posts online that suggest other options, but this is a fast-moving area, so some of these will be out of date. Some contained bad advice to begin with – in particular, anyone telling you to disable Firefox’s RDD (remote data decoder) process by unsetting media.rdd-process. enabled or via the MOZ_DISABLE_RDD_SANDBOX environment variable should be ignored. The current situation is that the RDD sandbox blocks VA-API, causing a seccomp sandbox violation error if you start Firefox from the terminal. But turning it off altogether is a security risk, so don’t do that. Instead, selectively disable it for video decoding by setting media.rdd-ffvpx.enabled and media.rdd-vpx.enabled to false.

You can check if it’s working by starting Firefox with this doozy:

$ MOZ_LOG=”PlatformDecoderModule:5,Dmabuf:5” firefox

This generates a huge amount of output to pore over and will probably overrun your terminal’s scrollback buffer in no time. Try pausing the video after a very short time to check you’re not missing some early error messages. If you see messages like VAAPI releasing dmabuf surface among it then this is indicative of success. Different hardware supports different formats, in particular decoding AV1 (denoted AV01 in the Stats for Nerds overlay in the YouTube player) requires very new hardware (newer than our 10th Gen XPS). VP8/9 and h264 (AVC in YouTube) video are more widely supported. For new hardware using the iHD driver it’s currently required to set security.sandbox.content.syscall_whitelist to 220 and start Firefox with $ MOZ_SANDBOX_ALLOW_SYSV=1 firefox in order to let a required syscall out of the sandbox and not upset the iHD driver.

If all that seemed like hard work, rest assured that getting VA-API working with the Firefox Snap (the default browser on Ubuntu) proved much harder. In fact, at the time of writing it seems downright impossible because the Gnome platform Snap is missing those driver libraries we mentioned earlier. A fix is on the way, but if it hasn’t landed yet you can uninstall the Snap and use the version from the repositories without issue. Just use the options we’ve given here, some combination of them will surely work.

There’s another reason you might not want to use the Firefox (or Chromium) Snap in Ubuntu, particularly if you’re a fan of Gnome extensions. Cast your eye at https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1741074 and you’ll see that both browsers refuse to load the native host connector plugin. That’s what the website extensions.gnome.org uses to manage your Gnome extensions, and without it these can’t be managed in the browser. It’s not the end of the world – there’s a desktop tool called Gnome Extensions available in Ubuntu Software. Or install it manually with:

We’re not proud of the number of times we watched this video just to get the Video bar in intel_gpu_top to read something other than zero.

$ sudo apt install gnome-shell-extension-prefs

There, your extensions are yours again, but popular password managers also use native messaging to talk to browser plugins, so if you use those you’ll want to avoid Snap-based browsers for now. Rob Gibbon, product manager at Canonical, assured us that there are plans to fix this in time for the LTS release. And this is a healthy reminder that, while annoying, it’s good that such bugs get visibility through the interim releases. In general, using a Firefox build that comes directly from Mozilla is a good move. One of the main motivations behind Snaps (and Flatpaks) was to enable developers to ship their software independently of distro packagers. It’s a sentiment echoed by Rob: “Mozilla wants to deliver Firefox directly to the user, which is great for everyone involved. From a QA perspective, we worked with Mozilla to ensure its QA processes met our needs for Ubuntu”.

Nvidia and AMD

We tested the libva situation pretty thoroughly on Intel graphics, and thanks to the Mesa drivers the situation should be much the same on AMD hardware, or with the Nouveau driver. The proprietary Nvidia driver has its own Nvdecode and Nvencode API, which is supported on some applications, but not web browsers. There’s another API libvdpau, again lacking support in popular web browsers, but widely supported by media players and AMD and Nvidia hardware. Interestingly, The Gnome web browser (sometimes known as Epiphany) supports all these APIs through Gstreamer. As usual, the Arch Wiki is the best place to get the lowdown on all this, in particular the lovely tables at the end of the video acceleration page at https://wiki.archlinux.org/title/Hardware_video_acceleration.

PLODDING TOWARDS ACCELERATION

Back in 2010, some enthusiastic fellow filed a bug at the Mozilla bugtracker asking for HTML5 video acceleration in Firefox. That seemed like a reasonable ask, seeing as it was already implemented for other platforms (well, Windows at least). The bug report was closed in 2019, but you can still read it at https://bugzilla.mozilla.org/show_bug.cgi?id=563206. Or there’s another one, still open, at https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1424201. The first few responses show that this was never going to be an easy thing to implement. And our efforts over these two pages show that even with all the bits now in place (technically they’ve been there since Firefox 78), getting everything working is far from straightforward.

You might think that the situation was better in Chrome/Chromium, and you would be right, but only just. VA-API acceleration for Linux did make it into Chromium via an unsupported patch in 2018, which was later included in some distro packages. The option has been available in official Chrome (and Brave, Vivaldi and Opera) since 2020, too. But Chromium is only available as a Snap on Ubuntu. And guess what? That Snap doesn’t yet support VA-API. There’s an experimental build you can try with:

$ sudo snap install chromium –channel=candidate/vaapi

but we couldn’t make it work, even after starting with the –enable-features=VaapiVideoDecoder option and spending hours messing around in chrome://flags. The RPMfusion repos for Fedora host the chromium-freeworld package, but we didn’t have time to go down another rabbit hole.

Flavours, spins, upgrades

Besides the flagship desktop offerings, there are a number of other official editions of Fedora and Ubuntu that you might be interested in. For fun and games (although it actually wasn’t fun at all) we tried installing both OSes on an old machine that, with its 2GB RAM and ancient (but still 64-bit) Celeron processor, fell well below the recommended specifications.

Once the installs were complete (which took ages because cheap laptop hard drives of the early 2010s are not fast), both OSes were surprisingly useable. But what turned out to be much more useable was working with the LXQt-powered flavour of each. Gnome had a fairly large, but not surprising given its reputation as the fattest desktop environment, 700MB memory footprint. LXQt had a much more slimline 450MB.

Even if you’re not on old hardware, you might not like the Gnome desktop. And if you are, you might like that there’s still a Fedora Spin that uses LXDE, the lightweight desktop built on the venerable GTK2. For a different kind of nostalgia check out the MATE-compiz spin, which brings back Gnome 2 aesthetics with a wobbly windows twist. Kubuntu and the KDE Plasma Fedora spin are among the most popular alternative offerings, but you’ll find there’s a spin/flavour for any desktop you could care to name. There’s also Fedora Kinoite, an atomically updating (like the official Silverblue release) Plasma spin. Similar to the desktop spins are Fedora Labs. These are special editions that cater to a particular area of interest with bespoke software bundles. If you’re into computational neuroscience, for example, try the Comp Neuro Lab. It has all of the best open source neural network simulation software (is that too niche a genre for a future Roundup? – Ed).

So come up to the Lab…

Most of the Labs are of a scientific theme, but there’s also the Design Suite (for art and creativity) and Jam (for music and audio). There’s also a Games Lab, which bundles some quite entertaining (though some very old) FOSS titles. It doesn’t include any tweaks or drivers, but we’ll look at how both distros fair at modern gaming in a moment. Fedora also has Special Interest Groups (SIGs) which aren’t necessarily tied to a particular spin or Lab, but whose mission it is to get the software that’s the subject of its Special Interest Group packaged and working nicely on Fedora. We were glad to see that i3 (the lightweight tiling window manager that’s favoured by developers and fans of keyboard shortcuts) has its own SIG now.

The Ubuntu Flavours are easier to enumerate. There are seven of them, and six of those are desktop flavours. That leaves Ubuntu Studio, which is very much like a union of Fedora’s Jam and Visual Design spins. As such it’s a rather large 4.1GB download, which is beginning to push what can physically fit on a DVD (oh dear–Ed). Ubuntu Studio used to offer a patched real-time kernel, but since those patches can now be activated in the official kernel sources, and generally cause problems for desktop systems, it’s no longer needed. Instead, the low-latency kernel from the Ubuntu repository is used, which should be of a low-enough latency for all but the most fastidious of audiophiles.

On the subject of multimedia, one thing which we haven’t mentioned yet is that Pipewire is now installed in both distros. Pipewire was once described as “Pulseaudio for video”, which may not have been the best way to advertise it (given many users didn’t appreciate Pulseaudio when it went mainstream), and certainly doesn’t tell the whole story. Instead, one should see Pipewire as the key to taming multimedia in an age of Wayland, streaming and screen recording. It’s actually the default audio subsystem in Fedora, but unless you went looking you’d never notice anything had changed. That part of it should be a complete drop in replacement for Pulseaudio, except in the most edgiest of edge cases. It runs as a Systemd user daemon, so to check it’s running just enter

$ systemctl –user status pipewire-pulse

You can get some more information by running pactl info (this requires the pulseaudio-utils package). If you want to see how it fares in Ubuntu, see the box (left). Besides managing PulseAudio, PipeWire can also handle audio from JACK, ALSA and Gstreamer. It’s also designed with sandboxing in mind, so (unlike our web-browser experiments on the previous pages) it works with Snaps and Flatpaks Wayland.

Upgrading your distro of choice

With relatively short lifecycles, you’d expect upgrading to the next release to be nice and easy on both distros. And indeed it is, or at least it should be. We realised that Fedora 35 would be out by the time you were reading this, even though at the time of writing the beta had only just been released. Upgrading to the next release, beta or no, on Fedora involves just a few steps. First, ensure the system is fully updated with:

$ sudo dnf –refresh update

The next step is to download the new version, and you’ll be reminded that you really ought to have done the previous step before doing this one:

$ sudo dnf system-upgrade download – releasever=35

Once the new package lists are downloaded you’ll have one last chance to bail out of the upgrade. Otherwise it’s a case of waiting for a couple of thousand packages to download. In short, a fine time to prepare a cup of tea. When you return, you’ll have to confirm importing of the package signing key to the new release and then you’re ready to reboot:

$ sudo dnf system-upgrade reboot

As with regular Fedora updates, the new packages will be installed post-reboot, outside of any GUI. When that’s done, which might necessitate another cup of tea, you will be one reboot away from your new version of Fedora. Once you’ve booted the latest edition, you can easily tidy up any cruft from its predecessor with:

$ sudo dnf system-upgrade clean

If you’ve used any of the popular desktop Ubuntu derivatives, you’ll be familiar with the friendly alert from the Software application telling you that a new version is available. If, for some reason, you don’t see this, and you’re fully upgraded and rebooted, then there’s a new command line incantation to force the upgrade:

$ sudo apt full-upgrade

$ update-manager -c

And that is largely it for this month’s dive into the latest and greatest editions of Ubuntu and Fedora. But over the page you can see what the ever-reliable, straight-talking Mayank Sharma has to say in his head-to-head comparison.

SWITCH PULSEAUDIO FOR PIPEWIRE IN UBUNTU

Most of the PipeWire subsystem is already present in Ubuntu, but you’ll need its PulseAudio daemon, and some auxilliary client libraries if you want it to handle your audio. These bits can be retrieved with:

$ sudo apt install pipewire-pulse

pipewire-audio-client-libraries

Now we reload Systemd so that it knows about the new units, and then disable dirty ol’ PulseAudio. Note there’s no sudo here that we’re still operating on the side. This should mean if it doesn’t work at least only one user’s (i.e. yours, sorry) audio will be broken:

$ systemctl –user daemon-reload

$ systemctl –user –now disable pulseaudio.service pulseaudio.socket

And finally we can launch our new audio subsystem:

$ systemctl –enable –now pipewire pipewire-pulse

You can check it’s working with pactl info, the tell-tale line will look like:

Server Name: PulseAudio (on PipeWire 0.3.32)

If you want to try out the latest bleeding-edge version then there’s a PPA and instructions available at https://pipewire-debian.github.io/pipewire-debian. Because this is new technology, don’t be surprised if it doesn’t work, particularly on complicated multimedia setups. If it seems like the tooling from the PPA (or indeed any PPA) hasn’t had the desired effect, then remember the accurately named ppa-purge is available in the repos.