Fedora 40 firms up for release [LWN.net]

By Joe Brockmeier
April 16, 2024

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.

to post comments

Fedora 40 firms up for release

Posted Apr 17, 2024 0:43 UTC (Wed) by JoeBuck (subscriber, #2330) [Link] (7 responses)

I won't miss delta RPMs. When present, they typically save well less than half a percent, and the extra complexity isn't worth the tiny savings.

Fedora 40 firms up for release

Posted Apr 17, 2024 0:56 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

> I won't miss delta RPMs. When present, they typically save well less than half a percent, and the extra complexity isn't worth the tiny savings.

While I agree that delta RPMs are likely not worth the effort for many today, I have to note that when it originally introduced in Fedora the percentage of download savings was regularly well over 50% and sometimes over 90% as seen for instance in the test results from 2009.

https://fedoraproject.org/wiki/Test_Day:2009-04-16_Presto

This was a frequent source of delight for users at that time and I am glad Jonathan Dieter, a community volunteer stepped up to make this happen along with others in Fedora. In recent releases however, it appears that Fedora infrastructure stopped producing the delta RPM packages consistently resulting in the advantages largely being lost. Hopefully broadband internet access has caught up elsewhere in the world that this isn't a barrier to getting updates.

Fedora 40 firms up for release

Posted Apr 17, 2024 3:47 UTC (Wed) by Subsentient (guest, #142918) [Link] (4 responses)

The problem with delta RPMs for me is the extra CPU overhead.
It's not uncommon at all for me to be running some weak silicon that can download all 1GB of updates in a minute or two, but takes forever to rebuild RPMs from .drpms.

I get the noble intention, but if you're dealing with weak hardware, the savings is usually not worth seeing all your cores maxxed out for 10 minutes straight.

Fedora 40 firms up for release

Posted Apr 17, 2024 21:08 UTC (Wed) by jccleaver (guest, #127418) [Link] (3 responses)

>The problem with delta RPMs for me is the extra CPU overhead.
>It's not uncommon at all for me to be running some weak silicon that can download all 1GB of updates in a minute or two, but takes forever to rebuild RPMs from .drpms.
>I get the noble intention, but if you're dealing with weak hardware, the savings is usually not worth seeing all your cores maxxed out for 10 minutes straight.

The answer, of course, is to do both. Have full RPMs for those who have lots of bandwidth and little CPU, and deltarpms for those on weak connections running normal box, or a VM on a normal box. The kvetching about the time/energy used to create deltarpms when high-compression and compute-intensive actions being done once for the benefit of many users always seemed symptomatic of larger problems with Fedora Linux as a whole -- near-complete obliviousness to the myriad use-cases out there.

Lesson learned: If someone on the systemd team or anywhere else isn't actively affected by an issue or use of a feature that you are, don't rely on it in Fedora Linux, because it'll be pulled whenever someone decides to toss out the babies to scratch a bathwater itch.

Fedora 40 firms up for release

Posted Apr 18, 2024 7:59 UTC (Thu) by zdzichu (subscriber, #17118) [Link]

The most glaring problem with delta-rpms is how to create the for all the combination of package versions which may be involved in the upgrade. No one found a viable solution for that.

Fedora 40 firms up for release

Posted Apr 24, 2024 0:37 UTC (Wed) by motk (subscriber, #51120) [Link]

Uh, what does systemd have to do with this?

Fedora 40 firms up for release

Posted Apr 24, 2024 10:02 UTC (Wed) by farnz (subscriber, #17727) [Link]

I just looked over my logs for Fedora 39; for various reasons, delta RPMs have cost me more network transfer than they've saved (usually because the kernel's delta RPMs did not reconstruct cleanly, so having downloaded a 20 MiB delta, it's followed up by downloading the 100 MiB full RPM).

So, the tradeoff with the current state of delta RPMs is you either use less CPU and less network transfer by not using delta RPMs, or you use more CPU and more network transfer to do delta RPMs then fall back to downloading the full RPM. And that's on the basis that you update daily, and thus the current generation strategy of only producing a delta against the previous RPM version actually creates deltas you can use; if you update less frequently (to reduce the amount of network transfer you use for metadata), you get access to fewer deltas, since you're more likely to have missed an intermediate update.

If people actually cared about delta RPMs, they'd be working on fixing those issues; but nobody cares, so they're getting disabled instead.

Fedora 40 firms up for release

Posted Apr 18, 2024 14:49 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

I remember filing an issue to first check HEAD for the drpm manifest file's size before downloading it. If it was bigger than the proposed transaction's download…just don't as the manifest will eat up any and all savings the drpms might at that point. That did get fixed IIRC. When trying to save network, one needs to check *all* network downloads on the way to computing such savings.

Fedora 40 firms up for release

Posted Apr 17, 2024 8:00 UTC (Wed) by eru (subscriber, #2753) [Link] (13 responses)

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

FTP removal in wget looks like a bad change. It is used much less than it used to, but FTP servers still exist, typically inside organisations.

Fedora 40 firms up for release

Posted Apr 17, 2024 8:53 UTC (Wed) by vadim (subscriber, #35271) [Link] (10 responses)

FTP can't die soon enough. It's terrible technology.

And if organizations care about it, maybe they can pay the wget project to maintain the FTP functionality.

Fedora 40 firms up for release

Posted Apr 17, 2024 21:10 UTC (Wed) by jccleaver (guest, #127418) [Link] (6 responses)

>FTP can't die soon enough. It's terrible technology.
> And if organizations care about it, maybe they can pay the wget project to maintain the FTP functionality.

Thank you for clearly demonstrating the mentality in my above comment about Fedora Linux -- if the small cabal of leaders and/or systemd junkies doesn't rely on your feature, or finds something annoying even if it has no impact to them -- they'll have no compunctions about yoinking it, leaving a busy sysadmin to find out long after the fact that some expected behavior has changed and it's too late to fix it. Upon query or remark, they'll then be told to go pound sand for thinking that something like crontabs or *fricking FTP* might be something someone could be expected to rely on in a Linux distro.

Fedora 40 firms up for release

Posted Apr 17, 2024 21:40 UTC (Wed) by vadim (subscriber, #35271) [Link] (2 responses)

FTP is a terrible protocol. I don't know why anybody uses it anymore.

* There's the NAT/firewall problems (okay, not a problem internally)
* There's the awful ASCII/binary mode that corrupts data.
* Awful support for SSL
* End of transfer is not signaled in any elegant manner. Socket is just closed.
* No protection against corruption.
* Opens a connection per file, leading to bad performance.
* Directory listings are non-standard, with a dozen possible varieties.
* Designed for interactive command-line usage and overall ill-fit for automation (some old school servers will want you to read the MOTD)

So yeah, FTP is dead and removed from web browsers for very good reasons.

Here's a good alternative: WebDAV. Runs on top of HTTP, doesn't have trouble with firewalls, doesn't have trouble with detecting ends of files, doesn't corrupt data, well supported out of the box everywhere, actually standard protocol, piggybacks on top of HTTP so saves you a second setup.

If you think the old relic is that valuable, convince your company to pay somebody to maintain this.

Fedora 40 firms up for release

Posted Apr 17, 2024 22:04 UTC (Wed) by vstinner (subscriber, #42675) [Link]

FTP client also sends the password in clear text, which is not great in terms of security.

Fedora 40 firms up for release

Posted Apr 18, 2024 8:51 UTC (Thu) by seyman (subscriber, #1172) [Link]

> If you think the old relic is that valuable, convince your company to pay somebody to maintain this.

Or just use one of several ftp clients (ncftp, lftp, filezilla, ...) that the fictional cabal has somehow forgotten to remove from the distribution.

Fedora 40 firms up for release

Posted Apr 17, 2024 22:06 UTC (Wed) by vstinner (subscriber, #42675) [Link] (1 responses)

Red Hat is not behind every single choice in the open source community. I don't see the relationship between Wget2 and systemd.

Fedora 40 firms up for release

Posted Apr 18, 2024 7:16 UTC (Thu) by amacater (subscriber, #790) [Link]

Agreed: Red Hat isn't behind every choice. Now that Fedora is effectively further upstream, even less so.
Fedora has a thriving set of developers of its own.

One thing, however: as a relative outsider, my viewpoint is that no-one should _rely_ on Fedora to be stable. It is a cutting edge release for things to be tried. If you want to rely on it long term - say as the basis for Amazon Linux 2023 which seems to be put together from three Fedora releases and CentOS stream - you're doing it wrong, given that the lifecycle is 13 months.

Fedora 40 firms up for release

Posted Apr 24, 2024 0:42 UTC (Wed) by motk (subscriber, #51120) [Link]

A cabal? Really? Touch grass.

Fedora 40 firms up for release

Posted Apr 18, 2024 10:21 UTC (Thu) by rwmj (subscriber, #5474) [Link] (1 responses)

FTP is fine - I know because I wrote a whole FTP server from scratch. The original mode where the FTP server would connect back to the client (active mode) was a bad idea in hindsight, but every FTP client and server now defaults to passive mode.

Fedora 40 firms up for release

Posted Apr 18, 2024 15:39 UTC (Thu) by vadim (subscriber, #35271) [Link]

Passive mode still leaves problems server-side.

For instance for a server behind NAT, you need a kernel module to rewrite packets. This is ugly, makes firewalling harder, doesn't work with SSL, and is a serious performance impact on fast networks because it can require very extensive packet inspection and rewriting.

Fedora 40 firms up for release

Posted Apr 18, 2024 15:04 UTC (Thu) by jond (subscriber, #37669) [Link]

I wanted to make the same comment but in respect of WARC support. At least there are many other options for FTP clients.

In WARCs case, it seems that it wasn’t removed so much as never implemented in wget2 in the first place: it seems wget2 is a different code lineage to wget1.

Fedora 40 firms up for release

Posted Apr 18, 2024 10:04 UTC (Thu) by cyperpunks (subscriber, #39406) [Link]

Just switch to lftp

Fedora 40 firms up for release

Posted Apr 24, 2024 0:40 UTC (Wed) by motk (subscriber, #51120) [Link]

I'm currently working in an area where ftp has been de facto for decades, but now you get very serious people from insurance companies looking at you if you're still using it, so we're unpicking twenty years of various scripts to do away with it. We're not even allowed to use scp anymore. Pleae let it die.

Fedora 40 firms up for release

Posted Apr 18, 2024 14:31 UTC (Thu) by Karellen (subscriber, #67644) [Link] (2 responses)

I'm kind of surprised that address conflicts are a problem on DHCP-managed address ranges.

Given that DHCP leases tend to be managed by routers, I'd have thought that if a device tries to send an IP packet with a source IP address that is in the DHCP-managed range but was not assigned to it, that the router would either return an error packet to the originator, or just drop the packet on the floor. I would not have expected it to forward the packet to any other devices on the subnet, or to pass it further upstream.

Fedora 40 firms up for release

Posted Apr 18, 2024 14:42 UTC (Thu) by farnz (subscriber, #17727) [Link]

Most routers route completely separately to DHCP assignment, so there's no knowledge that an IP was manually assigned (or claimed in error) rather than DHCP-managed. Thus, no way to drop packets on the floor if they're from the "wrong" device.

And routers aren't involved at all if the packet is going on the same subnet; packets go direct if you're on the same subnet, and only go via the router if you're going upstream.

Fedora 40 firms up for release

Posted Apr 19, 2024 20:38 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

If this were the case, I'd have a hard time communicating with the router when DHCP is misconfigured (usually my fault) and not doing its job properly. Today, I can claim a static IP, set up routes, and fix my problem over the network.

Fedora.next project

Posted Apr 20, 2024 16:05 UTC (Sat) by swilmet (subscriber, #98424) [Link]

The Fedora.next project is done!

Fedora.next is an umbrella phrase for the planning for the second decade of the Fedora Project.

"Done", i.e., the second decade has passed (Fedora 20 to 40) and so much has been achieved. A retrospective would be worthwhile. As well as plans or guesses of what will happen for the next 20 releases!

Fedora 40 firms up for release

Posted Apr 25, 2024 12:15 UTC (Thu) by Tet (subscriber, #5433) [Link] (3 responses)

I'll be disappointed when network scripts are removed. One of the first things I do when I build a new box is to remove NetworkManager. It provides literally zero functionality that I didn't already have and brings with it increased complexity, lack of visilibity and unreliability. If you're on a laptop and your network connection is likely to change then it or something like it is needed. For me, with a fixed network with static IPs it's simply not and I'd rather live without it. But it looks like this is only a temporary reprive and that I'll be forced to use it in the next Fedora release :-(

Fedora 40 firms up for release

Posted Apr 25, 2024 14:16 UTC (Thu) by Wol (subscriber, #4433) [Link]

Or is it just appallingly documented (like so many things) because it's "intuitive" and it "just works"?

Having finally managed to get my laptop to connect over wi-fi, the grief ... and in the end - having thought I'd uninstalled NM because it steadfastly refused to play ball - it was NM that got me online!

However, having had it refuse to use the wifi link because it thought the RJ45 was working, now it claims the RJ45 isn't working because the wifi is ...

Cheers,
Wol

Fedora 40 firms up for release

Posted Apr 25, 2024 14:34 UTC (Thu) by farnz (subscriber, #17727) [Link] (1 responses)

The big problem with network scripts at the moment is that they're unmaintained, and depend on dhclient, which is being removed from the distro. I don't get the impression that there's huge opposition to keeping them around for now, just to putting work in to maintain them; if you want them to stay around, it might be worth volunteering to update them to not depend on dhclient.

Or consider systemd-networkd if you want something less dynamic than NetworkManager.

Fedora 40 firms up for release

Posted Apr 28, 2024 15:00 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

Agreed. I had used `wpa_supplicant` for the longest time with `ifup`/`ifdown`, but `iwd` and `systemd-network` do work better for me.