Fedora 40 firms up for release

Fedora 40 Beta was released on March 26, and the final release is nearing completion. So far, the release is coming together nicely with major updates for GNOME, KDE Plasma, and the usual cavalcade of smaller updates and enhancements. As part of the release, the project also scuttled Delta RPMs and OpenSSL 1.1.

A Fedora release is not really a release. The project has five official editions: Workstation for desktop users, Server for "traditional" server use, CoreOS for running container-based applications, IoT aimed at edge-computing applications, and Cloud for (unsurprisingly) running Fedora as a virtual machine in cloud environments. The project also offers a wide selection of Spins targeting specific desktops and use cases. All of that is a bit much to cover in a single article. The focus here is desktop use and system-wide changes that impact most or all of the various Fedora editions and spins.

Desktop

Fedora Workstation is updated to GNOME 46, which we covered on its release in March. It is not a huge leap from GNOME 45, so Fedora Workstation users who are upgrading from Fedora 39 will find few surprises. Upgrading from Workstation 39 to 40, even prior to the beta release, went smoothly.

Performing a fresh install of Workstation also went well, and the Anaconda installation workflow will be familiar to anyone who's installed Fedora recently. That was not the original plan for this release, however. Fedora has been working on an Anaconda web-based installation interface based on Cockpit (which we looked at back in March) to replace the standard installer for Fedora Workstation. The web-based installer was originally scheduled to debut in Fedora 39, but it was delayed to this release and then postponed again to Fedora 41. The fly in the ointment is the partitioning workflow, which doesn't (at least yet) provide the same features as the traditional "expert" mode for partitioning. For example, the new tooling makes changes to partitions immediately—rather than batching them—which makes it more likely that a user could accidentally delete a partition they wish to keep. The discussion about the right approach to partitioning is still underway.

The KDE spin has been updated to KDE Plasma 6. LWN covered the Plasma 6 release in February. As expected, packages for KDE Plasma X11 are not installed by default with Fedora's KDE spin. The packages are available, however, for users who want or need X11 support. It is a good to have a fallback to X11 if needed, but it's been unnecessary on my test systems. Plasma on Wayland has been stable on two laptops and one mini-PC.

I've rotated between GNOME and KDE for the past several weeks for daily use, to give (roughly) equal time to each, but using my normal set of applications. This includes Firefox, Emacs, Claws Mail, Strawberry music player, GNOME Terminal or Konsole depending on which desktop is in use, and Distrobox to run packages from other distributions. My daily use also includes a lot of shuffling the primary laptop from the desk to the couch, connecting and disconnecting an external monitor, keyboard, and mouse via USB-C. Twice, over several weeks, the primary laptop failed to wake from suspend. That is not a perfect track record, but it's tolerable (especially for pre-release software), and the problem was neither persistent nor reproducible.

Since it was tax season in the US, it was also necessary to dust off the laser printer and print a few things. It was a pleasant surprise to find that the printer utility in both GNOME and KDE found my networked printer and set it up correctly with a few clicks. The surprise may speak more to how infrequently the printer is used than anything else, but they can be difficult devices to tame.

LWN is, blissfully if unusually, a largely meeting-free workplace. This meant few opportunities to test out video calls, which are an unavoidable part of daily life for many Linux users. I did log a few hours of video calls using Google Meet, and those were (again) uneventful. A few screen-sharing tests also went well, including sharing individual windows instead of the entire screen. However, it is worth mentioning that Fedora 40 did not detect the newest laptop's microphone. It did, however, happily detect and make use of a USB-connected Logitech webcam without any problems.

Even with the major KDE update, this Fedora update is more iterative than innovative. None of the changes have added major new functionality that I've noticed, nor had a dramatic impact on daily desktop use. That's not a bad thing, though, because none of the changes have removed any features or functionality that I'd miss.

Looking under the proverbial hood one will also find a number of iterative changes that are worthy of note.

Progress on unified kernel images (UKI)

The six-month development cycle for Fedora means that some features have to be tackled over two or more releases. Such is the case with UKI, which combines the kernel image, initrd, signature, and other components. The usefulness of this, according to the phase one change proposal is to make Fedora "more robust and secure". LWN covered the project's early UKI plans in January 2023. Support for UKI has been making steady progress, with the first phase, putting the pieces in place to work with UKIs for use in virtual machines, spanning the Fedora 38 and 39 releases. A UKI for virtual machines is available for Fedora 38 and 39, and the default size of the EFI system partition (ESP) was increased to a minimum of 500MB in part to accommodate UKIs.

Part of the phase two plan required changes in Koji (Fedora's build system) to support KIWI in order to build cloud images with a unified kernel. That, too, has been completed and the project is now building Fedora Cloud base images with the unified kernel. It's unclear whether these images will be advertised on the Fedora Cloud download page for the final release. The images do not yet show up with other beta images for download. It should be noted that regular kernel images are not going away, and there are no plans to switch to UKI as the default.

Goodbye Delta RPMs

Delta RPMs have gone away, however. This has been in the works for some time but the plug was finally pulled in Koji in November of last year, so Delta RPMs are no longer being produced for Fedora and DNF/DNF5 have had support turned off in their default configurations.

The discussion of the change was largely in favor of removing support. Jonathan Dieter said: "As the one who did most of the original work of getting deltarpms into Fedora, I wholeheartedly support this change. I'm sorry to see them go, but it's time." Some users were less pleased. Flo pointed out that there are still many Fedora users on slow and metered connections who would benefit from the promise (if not reality) of Delta RPMs. "It would be more inclusive to fix delta rpm and enable bandwidth savings for those who need it." Fedora Project Leader Matthew Miller suggested that alternative spins of Fedora like Silverblue that use rpm-ostree images with delta updates may be a better option.

Miscellaneous upgrades and changes

The Podman container-management tool has gotten a major version update to 5.0.1 (from 4.9.4 currently in Fedora 39). The 5.0 series has a laundry list of minor feature updates and a few breaking changes as well. Some of the new Podman features are meant to achieve better compatibility with Docker. For example, the --gpus option for podman create and podman run, which give containers access to the host's GPUs, now supports NVIDIA GPUs, in addition to other GPUs. Podman had support for NVIDIA GPU pass-through previously, but it required a different option (--devices) that was incompatible with applications expecting Docker-compatible flags.

Container networking interface (CNI) support had been deprecated prior to Podman 5 and is no longer included in builds. Podman has picked up a new tool called pasta that provides user-mode networking without requiring additional capabilities or privileges.

The default configuration for NetworkManager has changed slightly for this release to provide individual, stable MAC addresses for WiFi connections. The idea is to make it harder to identify and track users by their MAC address. When a system connects to a new WiFi network, it will generate a random MAC address for that specific network. For example, if a users connects to a WiFi network at their office, they'll have a MAC address for that network. But if they take the laptop down the street to a coffee shop, NetworkManager will generate a new MAC address for that network. Upon returning to work, NetworkManager will use the same MAC address it generated before.

IP-address conflicts are not uncommon on home and work networks, at least in my experience. When these conflicts happen, the symptoms can be puzzling and make it hard to assess the actual cause. Much better, then, to prevent conflicts in the first place. That's the theory behind enabling IP-address-conflict detection by default. This may make initial connections to networks slower, while the host checks for duplicate addresses, but should prevent two systems trying to fight for the same IP. The feature works with both DHCP and static addresses.

GNU Wget has been upgraded to Wget2, which will replace the old Wget on upgraded systems. Wget2 adds support for multithreaded downloads, HTTP/2, Atom and RSS feeds, and more. The change proposal notes that this is "mostly transparent to users" as a drop-in replacement. "Mostly" here means that Wget2 has a number of user-facing changes in the form of changed CLI options and the removal of FTP and web archive (WARC) support.

A somewhat stealthy removal of the network-scripts portion of the initscripts package landed in Fedora 40 in February. Adam Williamson credited Michel Lind for spotting the removal and argued that the change had not been properly communicated, if it had been communicated at all. While these are legacy networking scripts that have mostly been replaced by NetworkManager, Williamson pointed out that he still uses these scripts to work with Open vSwitch and to pre-create TAP devices; both features that NetworkManager is lacking. Miller pointed out several proposed changes that relate to the package, but did acknowledge that prior change proposals did not specifically say this package was going away:

The words "the network-scripts subpackage is deprecated and will be removed" do not seem to have appeared in the release notes, and in retrospect that probably should have been stronger.

Williamson has asked the Fedora Engineering Steering Council (FESCo) to require the service be reinstated. At the April 15 meeting, FESCo voted to reinstate the package on release.

In contrast, the planned GNU toolchain update has landed as scheduled. This updates Fedora to GCC 14.0.1, GNU C Library (glibc) 2.39, Binutils 2.41, and the GNU Debugger (gdb) 14.1.

Fedora moved to OpenSSL 3.0 with Fedora 36, and deprecated OpenSSL 1.1 in 37, but the package remained for third-party applications that still depended on the older version. The 1.1 release went end-of-life (EOL) in September 2023, but it was still packaged for Fedora 39. It is finally removed in 40 and Rawhide.

Python 3.7 reached EOL in September 2023, but remained in Fedora 39 for developers who were targeting other distributions such as Debian 10 that still included 3.7. With Debian 10 going EOL in June, 3.7 was retired in Fedora 40. The default Python is now 3.12. Users can also find packages for versions 3.8 through 3.11 as well as a pre-release 3.13 package. Python 3.6 remains available for developers who need compatibility with Red Hat Enterprise Linux (RHEL) 8.

Release date

The original ship date for the final release was set for April 16, but several blocker bugs have gotten in the way. Aoife Moloney announced that the new target date is April 23. The next Go/No-Go meeting will be on April 18 to determine whether that holds or slips further. Assuming that the final release is as stable as the beta, it's a safe if not mandatory upgrade for Fedora 39 users and a good time for new users to dip their toes in the Fedora waters.