We took Red Hat’s bleeding-edge desktop distribution for an extended spin.
Today’s Linux distro review is one I’ve been wanting to do for quite some time—Fedora Workstation. Fedora is one of the heavyweight desktop distros of the Linux world, with a vibrant community and a strong presence at every open source convention I’ve ever attended. (Remember physically attending events? Ars remembers.)
I never felt particularly drawn to Fedora myself, because it’s a bleeding-edge distro—one targeted to the very newest software, possibly at the expense of stability. That’s not what I personally want in an operating system—I fix broken things professionally; I’d prefer not to fix them personally any more than I have to.
But as one of the few distros using the next-generation Wayland display server by default, Fedora made me very curious indeed. Although the screenshots taken throughout this review are of virtual machines, my first installation of Fedora Workstation (ever!) was bare metal, on the HP Dragonfly Elite G1.
A chat with Fedora project leader Matthew Miller
Before getting started with Fedora, I put out some feelers on Twitter to see if I could get a project leader to answer some questions about the distro. Matthew Miller was gracious enough to respond at some length. (The interview has been lightly edited for length and readability.)
Ars: I’m particularly interested in—and clueless about!—Wayland. I’ve been hearing it’s the super amazing next generation of window manager for years, but I’ve never actually used it. What should I look for to see it to my best advantage?
Miller: OK, so, I’m going to have to get a little geeky on this one. But first let me give the perhaps-surprising answer for most people: when Wayland is working as it should, you won’t even notice it. Nothing flashy or new or amazing at all—just better performance and a smoother experience.
So, Wayland is simply a… more lightweight design [display server] that connects applications more directly with the hardware. It can also better take advantage of modern graphics cards, allowing for flicker-free animation and tear-free video. And, it allows applications to run on the same display but be isolated from each other—the X11 design actually makes it so any running application can snoop on key-presses intended for another application. This makes it safer to run sandboxed applications that might be from a less-trusted source or at least to contain a compromise from spreading to another application.
Additionally, since Wayland is where the development energy is, new features like hardware acceleration for Firefox and improvements to high DPI rendering are only available there. It’s not that these couldn’t theoretically be done in X11 (with more effort), it’s just that no one is doing that work.
All this means Wayland is definitely the way forward, and we made Wayland the default four years ago in Fedora 25. But really, the improvements are all under the hood. You definitely see enthusiasts for whom this is a big deal, but that’s like car enthusiasts talking about a new engine design. For most users, you’ll see the equivalent of better gas mileage and smoother performance, but it won’t be something you actually directly care about—and that’s a good thing.
Ars: I’d love to hear you talk about how Fedora sits in the Red Hat and overall Linux ecosystem—do you have a direct upstream?
Miller: Fedora is one of those few distributions which is at the head of a river, to stretch the upstream/downstream analogy. In fact, I’m going to go ahead and keep stretching—the spring at the start of a river doesn’t create water; that water comes from rains and snow melt and so on.
Likewise, most of the software that goes in the Fedora distribution isn’t written by the Fedora Project, but rather in thousands of other projects like the Linux kernel, systemd, the Wayland graphics stack, Firefox, the GCC compiler, and so on. Those are our upstreams, and we collect and integrate them into the flow that is the Fedora distribution.
Ars: How direct is the downstream—if that’s an accurate description—to CentOS and Red Hat Enterprise Linux?
Miller: Very direct! Every few years—now officially three—Red Hat takes a release of the Fedora OS and branches it into an alpha version of Red Hat Enterprise Linux. We’re actually working to make this even more transparent.
In parallel with the in-progress Fedora 33 release, we have a build environment that mimics that used for RHEL (see https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose), and the goal is for that to eventually flow smoothly into CentOS Stream, and that branch of CentOS Stream will then become RHEL 9.0.
CentOS Stream as a mid-stage is new. Traditional CentOS Linux used to be simply a rebuild of the sources of RHEL, and very far downstream. So we’re looking forward to this new closer relationship to Fedora as it develops!
Ars: Can you tell me about best practices for end user maintenance of a Fedora system?
Miller: I guess I have two answers for this. First, if you’re someone who likes to tinker with your system, feel free to do so. You may break things, but that’s how you learn, and that’s why we have a great community who will help you in that journey. Bring your problems to https://ask.fedoraproject.org!
Second, though, if you just want to use your system… no problem. Fedora’s various options like Fedora Workstation are meant for end users, and deep maintenance isn’t necessary. Make sure to apply updates on a regular basis and you should have many years of hassle-free Linux.
Ars: Does that change any with long-term use? What about upgrades?
Miller: A few years ago, I frequently saw people ask for us to make Fedora either have a long-term support edition or switch to a rolling-release model—where updates flow continuously, with no whole-version upgrades.
This struck me as curious, because these are nearly opposite approaches. When I dug into it, the real concern is generally that people are afraid of upgrades: they seem like a lot of work with a lot of potential for disruption.
So, we’ve tried to address that directly. Long-term support is very expensive to implement—and Fedora is primarily volunteers who have limited time.
A rolling release sounds good, but Linux distributions integrate so much upstream software that it’s inevitable that eventually some big change will affect you. So a rolling release really means that those upgrade surprises can come at any time, and we don’t want to surprise our users in a negative way.
We decided to keep to our six-month release schedule and focus on making updates smooth. This focus has worked out: I upgraded my main laptop from Fedora Workstation 31 to 32 while I had lunch, and I’ve seen many people reporting similar experiences. It’s basically: push the button, come back to an updated system.
We do maintain an overlap between supported releases, so if you’re not ready for change, you can skip a release and upgrade once a year. But generally, we’ve worked to make it be no big deal to stay up to date—while leaving in your hands exactly when you want to make the update.
Ars: Can you tell me about the distro’s overall project goals and/or mission statement?
Miller: I hope you find our Mission and Foundations page useful on this. Fedora is a community project, and our goal is to enable interested teams to provide specific Linux distro solutions for areas they care about.
The most popular of these is Fedora Workstation, our main desktop offering—the team working on this wants to build a polished and well-engineered desktop operating system that brings the power of open source to anyone who wants it.
We also have Fedora CoreOS, for next-generation compute clusters and container-based workflows in the server room. And Fedora IoT takes some of the technology developed for CoreOS and brings it to edge computing and smaller ARM devices that might power your home automation or data-gathering and processing in the field.
But we also encourage much more niche uses really tailored for specific cases. For example, new with Fedora 32 we have a Computational Neuroscience Lab. It turns out that a lot of volunteers in Fedora work in this field, and they decided to work together to make a collection of the important open source software they use for their work so that other scientists can get productive quickly. Fedora Jam is the exact same thing—but for an audience of musicians and audio enthusiasts.
I’m obviously very happy to see big successes for Fedora Workstation, Fedora CoreOS, and Fedora IoT—the recent Lenovo announcement is huge!—but ultimately I measure success for Fedora as a project in how well we do at fostering these various communities of interest and how we build a collaborative environment, so each team can grow their own user communities as part of Fedora as a whole.
Installing Fedora Workstation 32
I spent about an hour playing with Fedora Workstation on bare metal—an HP Dragonfly Elite G1 laptop—before spinning it up as a VM on my main workstation. But screenshots are a lot easier to manage and nicer looking than photos of a laptop screen, so that’s what you’re going to see here.
Once you select your keyboard layout, Fedora presents the need to choose a disk layout in a disconcerting way—instead of just leading you into the screen, it throws an error/warning icon at you. Clicking the warning icon leads you to Installation Destination, where you’ll find an automatic disk partitioner pre-selected. You can just click “done” here to accept the automatic layout, or you can partition your disks and choose filesystems manually.
I poked at the advanced setup—a GUI called Blivet—that looked both straightforward and capable. Ultimately, I canceled out of Blivet and re-selected the automatic partitioner to get an idea of what a default Fedora install would really look like.
Disk layout
Fedora’s default disk layout turned out to be one relatively small ext4 boot partition—1.1GB on a 40GB virtual disk—with the rest of the disk set up as an LVM physical volume.
Within the LVM volume occupying the majority of the disk, 4GB was allocated as swap (matching my VM’s RAM), and the other 36GB as an ext4 root filesystem. Interestingly, Fedora’s “Disks” application—which I used to examine the layout on my freshly installed VM—chooses to display sizes in powers-of-ten GB, not powers-of-two GiB.
This matches the marketing-friendly big numbers hard drive vendors like to use—but clashes with most other applications, and most users’ expectations. Although the version of Gnome Files installed on Fedora also reports in GB, when we drop to the terminal and look at fdisk, we see it reporting in GiB as it normally would.
First impressions
I spent roughly an hour playing with Fedora 32 on the HP Dragonfly Elite G1, mostly trying to get a sense of whether its next-gen Wayland display server felt unusually “fast and smooth.” I opened and closed lots of windows, dragged them around on the desktop, and played a probably unhealthy amount of WWE videos on YouTube in the default Firefox installation. (Don’t judge—they’ve got lots of rapid action, with no CGI.)
I can’t honestly say that Wayland made any impression on me. While the display certainly felt snappy, and there were no screen tearing issues during video playback, I wouldn’t expect there to be—I spent significant time with the same laptop running Ubuntu 19.10, using the Xorg display server, and it didn’t have any problems either. Wayland might make a difference on lesser hardware—this is an eight-generation i7—but it didn’t seem to register on a fast laptop one way or another.
What I did notice, unfortunately, was that Fedora felt noticeably more sluggish than I was used to. Human perception can be tricky and unreliable—and I hadn’t actually used Ubuntu on that hardware since reviewing it in January—so I set up a pair of identically provisioned VMs, one with Fedora 32 and one with Ubuntu 20.04, and ran a “drag race” on my Ryzen 7 3700X workstation.
Each VM had four CPU threads, 4GB of RAM, and a 40GB raw backing file hosted on a ZFS mirror vdev, itself on a pair of Samsung 860 Pro 2TB SSDs. I initiated a reboot on each VM first—and despite clicking Fedora’s reboot button before Ubuntu’s, Ubuntu got to the desktop noticeably faster. A similar test with a first launch of Firefox after the reboot also came in quicker on Ubuntu. This confirmed my “seat-of-the-pants” impression on the laptop itself—Fedora can be a bit slower than Ubuntu with some tasks.
Rearranging the launcher
Fedora’s configuration of the Gnome3 desktop is much closer to upstream than I’m accustomed to—and I can’t say I really enjoy the Gnome project’s defaults. In particular, the launcher isn’t visible without clicking “Activities” in the global top menu bar, which just drives me bonkers.
I knew this should be easily fixable, and a quick Internet search for “fedora show launcher” later, I headed to gnome-extensions.org to install the Dash to Dock extension. This is a painless and quick process in Fedora, using the Firefox browser—the extension can be downloaded, installed, and enabled directly from the webpage itself.
Unfortunately, after installing Dash to Dock I still had complaints. In particular, the launcher still auto-hides itself behind maximized windows. I know a lot of people who like that behavior—but I’m not one of them. The next step was to check Dash to Dock’s settings—and to do that, I needed to install Gnome Tweaks.
I’m happy to say that Software Center is one place that Fedora decidedly does not feel sluggish. I’m used to Software Center on Ubuntu feeling weirdly laggy—but it was quick and responsive in Fedora. Searching for “gnome tweak” brought me directly to the gnome-tweaks package, and clicking Install downloaded and installed it every bit as quickly and smoothly as using Fedora’s dnf package manager in the Terminal would have.
I had more trouble finding Gnome Tweaks after it was installed. There’s a curious intermittent display bug when it comes to the Utilities folder within Applications—on both the Dragonfly Elite G1 laptop and my virtual machine, the bottom row of the folder was chopped off, hiding the names of the last row of icons entirely. No amount of scrolling up and down would bring them into view—and hovering over them didn’t spawn a popup, either.
After a system update and reboot, the bug resolved itself for no apparent reason, and Tweaks was finally visible in the last position of the Utilities folder. A few reboots later, the bug unfortunately resurfaced—and the last row of icons had no visible labels again. They are at least visible, so hopefully users will learn to recognize them by the icon and without the text label.
Once I was finally in the Tweaks applet, I found Dock to Dash under its Extensions tab. Clicking its gear icon, Dock to Dash had ready-to-go settings for everything I wanted.
First, I disabled “Intelligent autohide” to keep the launcher permanently visible. This brought the launcher back out, and a maximized Firefox window that had been hiding it shifted and docked to its right instead.
This left me with ugly “holes” to the desktop wallpaper above and below the launcher—but Dock to Dash has a “panel mode” checkbox that fixes that, extending the launcher to the top and bottom of the screen. Finally, I cut the icon size in half—from 48px to 24px—and all of my appearance woes were resolved. Well, most of them—it still annoys me that there are no minimize or maximize buttons for application windows—just a close button. (You can maximize by double-clicking the titlebar.)
The short answer to the question I ask of every distro—will it Chrome?—is “yes, and easily.” Clicking the big blue install button on Chrome’s landing webpage within Firefox prompts you to select a .deb or an .rpm, with the RPM labeled as for “Fedora/openSUSE.” Simple enough.
From there, you’re asked if you’d like Software Install (a subset of Software Center) to intercept and open the RPM for you. Normally, on Ubuntu, I’d decline here, save the .deb, and install it manually from the terminal using dpkg -i—not because I’m an 31337 sysadmin, but because Software Center is weirdly laggy and slow on Ubuntu. But with new distros, you try new things—so I allowed Software Install to open it.
To my pleasant surprise, Software Install fired up very quickly indeed, showing me Chrome’s landing dialog with no wait. Clicking Install again from here prompted me to elevate. After feeding the elevation dialog my password, Chrome promptly installed, just as quickly and smoothly as it would from the command line.
Interestingly, the Chrome application itself launched very quickly—every bit as quickly as I would expect Ubuntu to, and in fact another impromptu “drag race” showed no difference between the two. This leaves me to conclude that the difference in Firefox 76.0.1 launch times between the two distros isn’t due to an unavoidable sluggishness of the distro as a whole but merely a packaging quirk.
Will it ZFS?
Getting ZFS working on Fedora turned out to be a much bigger chore. Finding Fedora installation instructions on the OpenZFS wiki wasn’t at all difficult, and on the surface they looked pretty straightforward—download package information with dnf, then install the package itself with dnf, then if necessary swap out Fedora’s own zfs-fuse native package for the OpenZFS zfs package in dnf‘s dependency manager.
The reality was quite a bit uglier than that, unfortunately. After installing the zfs package, the command line utilities were present on the system, but they complained that the kernel module wasn’t loaded. I hadn’t noticed a DKMS module building during the first couple of steps, so I figured maybe I needed to do that dnf swap zfs-fuse zfs thing after all—which, to my surprise, pulled in an absolute ton of dependencies.
After all the dependencies installed, I tried running zpool status again—still with no joy and a complaint that zfs.ko was not loaded. Neither modprobe zfs nor dkms --force install zfs/0.8.4 produced results, with the latter complaining that the kernel headers weren’t available. Kernel headers are in a package creatively named kernel-headers, and what I’d installed was kernel-devel, so I tried a direct installation—but according to Fedora, the headers were already installed. Well… crap.
At this point, I decided to do a full dnf update, hoping that perhaps this would trigger a resolution to the problem. It didn’t fix anything zfs-related—but it did completely break the Dash to Dock Gnome extension I’d installed, and my launcher disappeared again. Viewing the extension in Tweaks, it was errored out—so I sighed and gave the Fedora VM the trusty three-finger salute. Maybe things would look better after a reboot.
After a reboot, the ZFS kernel module still wasn’t loaded… but this time, a manual modprobe zfs actually worked, and the module loaded successfully. Yay! Creating a test pool from sparse files in /tmp also worked just fine; we finally have a functional ZFS on Fedora!
Well… mostly. After a reboot, the zfs.ko module still wasn’t automatically loaded. Searching the Internet for information about Fedora and automatically loading ZFS modules leads to a ton of bug reports and workarounds that make it clear that I wasn’t the only one scratching my head. I didn’t want to have to write my own systemd service just to load a kernel module!
Manually doing a systemctl enable zfs-mount ; systemctl enable zfs-import-cache ; systemctl enable zfs-import-scan still didn’t fix things—after another reboot, still no module loaded. Finally, I came across a bug report that suggested that if you manually loaded the kernel module once, then created a pool, that the default systemd timers would actually work, load the module, and import the pool. It further noted that this only worked with an actual disk from /dev—not with sparse files.
So I added another disk to my VM at /dev/vdb, did a sudo modprobe zfs and a sudo zpool create test /dev/vdb, and rebooted once more… and sure enough, this time the ZFS module was loaded, and a zpool status showed my little baby pool without any further complaints.
Although we did finally get ZFS working, it’s much clearer to me now why people who aren’t using Ubuntu tend to report ZFS on Linux as being wonky. It has been in better shape than this under Ubuntu for roughly a decade—even before Canonical added a ZFS package to its own repos, the zfsonlinux PPA “just worked” with nothing more than an apt-get install zfsutils-linux and Bob’s your uncle, no further faffing about.
Conclusions
Fedora is a pretty different beast than what I’m used to from my Ubuntu daily drivers. It’s a lot closer to the Gnome upstream than Ubuntu is… and while some people might like that, I discovered that I really don’t.
The use of the Wayland display server instead of the much older Xorg didn’t make much difference on the i7-powered HP Dragonfly Elite G1 I tested it on. Windows dragged smoothly and videos were tear-free—but they had been on an Xorg-powered distribution, too. I don’t think Wayland is a big draw for me personally—at least not yet. I’m more than content to let it cook for however much longer it needs to before it succeeds in supplanting Xorg.
For the most part—and to my surprise—Fedora felt more sluggish than I’m used to. Reboots were significantly slower and Firefox application launches laggier than Ubuntu on the same hardware, and I believe on, eg, Clear Linux or GhostBSD either. There were exceptions to this rule, though—Gnome’s Software Center was much snappier on Fedora than I’m used to in Ubuntu.
I’m unlikely to switch to Fedora any time soon—but if I did, it would probably be for Matthew Miller’s promise of routine, painless six-month upgrades. I normally keep to Ubuntu’s every-two-year LTS (Long Term Support) releases, because I don’t like broken stuff. Then again, I encountered more broken stuff just in the course of a daily package upgrade here than I expected.
Fedora is probably best-suited to people who like to tinker and get really, really antsy if they don’t have the absolute latest version of every software package. Both its repositories and its kernel tend to get updated considerably faster than Ubuntu’s. For example, even though Ubuntu 20.04 is less than a month old, Fedora 32 already has a newer kernel—5.6.12, to Ubuntu’s 5.4.0.
The good
- It’s nice to see the absolute-latest kernel showing up so rapidly—kernels are less likely to be buggy than most software, and new kernels mean more new hardware supported
- Software Center is considerably nicer to use than I’m used to, with no lag or sluggishness
- With six-month release cycles and no LTS, the Fedora project takes in-place upgrades very seriously
- Refugees from other distros can mostly make Fedora look and feel “like home” with a couple of extensions and a few clicks
The bad
- Overall sluggish feel compared to Ubuntu—slower reboots, slower launch of some applications
- If you’re a ZFS fan, the support for it in Fedora feels second-class at best
The ugly
- Dash to Dock breaking after a
dnf updateand staying broken until a reboot was disquieting - No minimize or maximize buttons on windows
- Minor, intermittent display bugs in Applications
Contact Information:
JIM SALTER
Tags:
, Wire, United States, English
Contact Information:
JIM SALTER
