Fedora Core Archive
I’m sure this won’t make anybody mad, and we can all have a reasonable discussion about this. A change proposal for Fedora suggests Fedora should drop the X11 GNOME session from Fedora 43, moving GNOME’s target of removing X11 in GNOME 50 to the Fedora release carrying GNOME 49. Fedora 43 will be released in roughly six months. The reasoning behind the proposal should be no surprise. This Change effectively implements the GNOME 50 target in GNOME 49 because there is no one to support any issues with GNOME X11 upstream. The X11 session is already quite buggy, with serious unfixed issues in Mutter (like rhbz#2179566 and glgo#GNOME/mutter#3868) and recently Phoronix could not benchmark GNOME X11 vs Wayland because “GNOME on X11 wasn’t even working due to bugs”. Dropping the GNOME X11 session now allows us to reconcile with reality that the GNOME X11 session is simply not supported anymore (either by us or upstream GNOME). ↫ Fedora change proposal If you’re still using legacy X11 on Fedora GNOME for some reason, upgrading to Fedora 43 would mean being moved to Wayland. If you would want to continue using X11, you’d need to install a different login manager than GDM, and a desktop environment that still supports X11 (like Cinnamon or Xfce). Since all of this is the plan anyway, what this proposal effectively does is move the removal of X11 from Fedora GNOME ahead by six months. Do note that this is only a change proposal for now, and it will have to be voted on and agreed upon before it becomes official policy. This is just yet another nail in the coffin of X11 on Linux, as more and more distributions and desktop environments move to eliminate it entirely from their installations and stacks in favour of Wayland. Big concerns here for some X11 users are definitely accessibility, where tools are still relatively young, and to a lesser degree NVIDIA users, whose GPU drivers are a bit of a mess when it comes to Wayland. To this day, NVIDIA with Wayland can be very hit or miss. Regardless, we all know which way the wind’s blowing.
Only a few weeks ago we talked about Blue95, a Fedora-based distribution focused on bringing the Windows 95 look to the Linux world by integrating a set of existing Windows 95 Xfce themes. Since Fedora 42 has just been released, the Blue95 project also pushed out a new release, called Blue95 Topanga. It brings with it all the improvements from Fedora 42, but also goes a step further be integrating new applications to further add to the Windows 95 vibe. First, there’s Winblues Paint, a faithful recreation of Windows 95’s Paint, using jspaint.app. Second, they’ve recreated the classic Plus! experience with Chicago95 Plus!, a tool that allows you to take any existing Windows 95/98/ME/XP theme and apply it as-is on Xfce. Topanga also further improves the theming experience with custom Windows 95 icons for LibreOffice as well as custom themes for Audacious and Flatpost, a desktop-agnostic Flatpak client. I adore that this project aims to be more than just a vessel for the existing Chicago95 theme, and in fact goes so far as to create its own applications. I hope this continues from here on out and doesn’t fizzle out.
Fedora 42 has been released, bringing with it a major policy change: the Fedora KDE version now has the same status as the GNOME version. This means that Fedora KDE will be getting the same promotion, website space, and potential blocker status as the GNOME version. For now, the naming is a bit weird – Fedora Workstation for GNOME, Fedora KDE Plasma Desktop for KDE – but they intend to fix this down the line. Feodra 42 also brings with it a brand new installation interface, which replaces the old one with a newer, step-by-step wizard-style interface. Anaconda is now also a native Wayland application, instead of running in Xorg. This release also marks the official availability of the Fedora COSMIC spin, bringing System76’s Rust-based COSMIC desktop on the same footing as Xfce, LXQt, and others. Another cool addition is FEX for those of us running Fedora on ARM. Fedora now provides FEX, a fast emulator that allows one to run x86 and x86-64 binaries on an AArch64 Linux host. FEX requires a number of supporting components, including a RootFS image, and integration with muvm to support 16k page-size hosts. The purpose of this Change is to integrate FEX itself and its supporting components into Fedora Linux, to provide a delightful out-of-box experience for users that want to run x86 and x86-64 binaries on their aarch64 systems. This also includes integration into the AArch64 Fedora KDE spin as a non-blocking component of the spin. ↫ Fedora 42 release notes You can download and install Fedora 42, or if you’re already a Fedora user, you can upgrade through your graphical update utility or the command line using DNF.
The effort to ensure that open-source software is reproducible has been gathering steam over the years, and gaining traction with major Linux distributions. Debian, for example, has been working toward reproducible builds for more than a decade; it can now produce official live CDs of the current stable release that are reproducible. Fedora started on the path much later, but it has progressed far enough that the project is now considering a change proposal for the Fedora 43 development cycle, expected to be released in October, with a goal of making 99% of Fedora’s package builds reproducible. So far, reaction to the proposal seems favorable and focused primarily on how to achieve the goal—with minimal pain for packagers—rather than whether to attempt it. ↫ Joe Brockmeier at LWN.net In the case of individual packages, reproducibility means that if you set up a build environment at home according to Fedora’s specifications, you can create an exact, bit-by-bit identical copy of a package. This is important because it can help detect and guard against supply chain attacks like the infamous xz backdoor attempt that was thwarted only by mere luck. As the LWN article notes, however, it’s impossible for Fedora to achieve the original “bit-by-bit” part of the definition because of how RPMs are built. RPMs include the signature inside the RPM, and a few other metadata bits are problematic as well. The actual contents of an RPM – the thing you actually install, run, and use – meet the definition of “bit-by-bit”, though. By this point, Fedora has pretty much done all it can through its own infrastructure when it comes to reproducibility, which has brought the project to 90% of packages being reproducible. It’s going to be up to the individual package maintainers and software developers to get to the desired goal of 99% by Fedora 43, though. To ensure package maintainers take this issue seriously, a change proposal has been proposed to treat reproducibility issues as bugs, with a degree of wiggle room for now (think should instead of must). It’s only a proposal for now, but it’s looking like it will make it. The excellent – as always – LWN article has a lot more detail about both the proposes changes as well as the various points of view.
Blue95 is a modern and lightweight desktop experience that is reminiscent of a bygone era of computing. Based on Fedora Atomic Xfce with the Chicago95 theme. ↫ Blue95 GitHub page Exactly as it says on the tin. This is by far the easiest way to get the excellent Chigaco95 theme for Xfce set up and working in a polished way, and it also contains a few different application choices from the regular Fedora Xfce desktop to improve the illusion even further.
Unlike most (all?) other distributions with built-in Flatpak support, Fedora maintains its own repository of Flatpak applications. Everyone else defaults to using Flathub, where developers of applications themselves tend to publish their Flatpaks. Fedora’s ‘shadow Flathub’ sometimes leads to problems, with Fedora-made Flatpaks containing bugs and brokenness, while presenting themselves as official, developer-made Flatpaks. In turn, users complain to the developers, while the issues they experience are actually caused by Fedora making its own Flatpaks. One of the applications this happened to is OBS, and over three weeks ago the OBS project requested that either the broken, unofficial Fedora Flatpak be removed, or that it be made clear that the Flatpak was third-party. This request seems entirely reasonable to me, and it would be fairly trivial for Fedora to do this. In fact, I think respecting this request is merely common decency. Sadly, the Fedora project thought differently, and just… Ignored the request. And so the OBS project escalated the issue. This is a formal request to remove all of our branding, including but not limited to, our name, our logo, any additional IP belonging to the OBS Project, from your distribution. Failure to comply may result in further legal action taken. We expect a response within the next 7 business days (By Friday, February 21st, 2025). ↫ Joel Bethke It seems this caught the attention of the Fedora project, as within less than 24 hours, a formal request was made by the maintainer of Fedora’s OBS RPM package to have the broken OBS Flatpak removed. It seems there’s no official process to follow for making such a request, but I hope it gets through and honoured, if only because, like I said above, it would be common decency to do so. I do wish to go back to the original OBS complaint, though, as it poses the question most of you are asking yourselves at this point. I would also like some sort of explanation on why someone thought it was a good idea to take a Flatpak that was working perfectly fine, break it, and publish it at a higher priority to our official builds. We spend an enormous amount of effort on our official Flatpak published to Flathub to ensure everything is working as well as it can be. ↫ Joel Bethke Why does Fedora maintain its own shadow-Flathub, set at a higher priority than the real Flathub? There’s a few reasons, as detailed in this Fedora Magazine article from 2022. There’s the obvious stuff like Fedora only allowing free and open source software, whereas Flathub also allows proprietary software, meaning that if Fedora ships with the Flathub repository enabled and prioritised, it would violate Fedora’s policies. You can argue back and forth about this, but Fedora’s policy being what it is, I can see where they’re coming from. The article mentions Flathub will split proprietary applications from free and open source ones, but I can’t find any word on if this has happened already. A second big difference are the sources where the Flatpaks are drawn from. While Flathub allows and all sources, with their packages reusing Debian packages, Ubuntu Snaps, tarballs, AppImages, and more, Fedora exclusively reuses its own RPM packages when creating its Flatpak packages. Furthermore, Fedora Flatpaks use the Docker-like OCI format to publish applications (which ties into the Fedora Registry), while Flathub uses OSTree. Lastly, Fedora Flatpaks use one, single, big underlying runtime, while Flathub has a number of different, smaller runtimes. The issue here seems to be that the motivations for maintaining a Flatpak repository differ greatly between Flathub and Fedora, but one has to wonder how much of that actually matters to users. Maintaining your own, separate Flatpak repository that effectively duplicates the work developers do when publishing to Flathub is not only wasteful, but also prone to cause bugs, issues, and outdated Flatpaks – which in turn causes strife with the original developers of the applications who have to deal with problems causes not by their own work, but by Fedora – problems that they can’t even fix. I don’t think this situation makes any sense to perpetuate, and it’s high time Fedora defaults to Flathub for Flatpak applications. It will reduce the workload on package maintainers, prevent needless packaging bugs, improve the experience for users, and make developers happier. It’s a no-brainer at this point.
Fedora is proposing to stop building their Atomic desktop versions for PPC64LE. PopwerPC 64 LE basically comes down to IBM’s POWER architecture, and as far as desktop use goes, that exclusively means the POWER9 machines from Raptor Computing Systems. I reviewed their small single-socket Blackbird machine in 2021, and I also have their dual-socket Talos II workstation. I can tell you from experience that nobody who owns one of these is opting for an immutable Fedora variant, and on top of that, these machines are getting long in the tooth. Raptor passed on POWER10 because it required proprietary firmware, so we’ve been without new machines for years now. As such, it makes sense for Fedora to stop building Atomic desktops for this architecture. We will stop building the Fedora Atomic Desktops for the PowerPC 64 LE architecture. According to the count me statistics, we don’t have any Atomic Desktops users on PPC64LE. Users of Atomic Desktops on PPC64LE will have to either switch back to a Fedora package mode installation or build their own images using Bootable Containers which are available for PPC64LE. ↫ Timothée Ravier I’ve never written much about the Talos II, surmising that most of my Blackbird review applies to the Talos II, as well. If there’s interest, I can check to see what the current state of Fedora and/or other distributions on POWER9 is, and write a short review about the experience. I honestly don’t know if there’s much interest at this point in POWER9, but if there is, here’s your chance to get your questions answered.
As Michel Lind mentioned back in August, we wanted to form a Special Interest Group to further the development and adoption of Btrfs in Fedora. As of yesterday, the SIG is now formed. ↫ Neal Gompa Since I’ve been using Fedora on all my machines for a while now, I’ve also been using Btrfs as my one and only file system for just as much time, without ever experiencing any issues. In fact, I recently ordered four used 4TB enterprise hard drives (used, yes, but zero SMART issues) to set up a storage pool whereto I can download my favourite YouTube playlists so I don’t have to rely on internet connectivity and YouTube not being shit. I combined the four drives into a single 16TB Btrfs volume, and it’s working flawlessly. Of course, not having any redundancy is a terrible idea, but I didn’t care much since it’s just downloaded YouTube videos. However, it’s all working so flawlessly, and the four drives were so cheap, I’m going to order another four drives and turn the whole thing into a 16TB Btrfs volume using one of the Btrfs RAID profiles for proper redundancy, even if it “costs” me half of the 32TB of total storage. This way, I can also use it as an additional backup for more sensitive data, which is never a bad thing. The one big downside here is that all of this has to be set up and configured using the command line. While that makes sense in a server environment and I had no issues doing so, I think a product that calls itself Fedora Workstation (or, in my case, Fedora KDE, but the point stands) should have proper graphical tools for managing the file system it uses. Fedora should come with a graphical utility to set up, manage, and maintain Btrfs volumes, so you don’t have to memorise a bunch of arcane commands. I know a lot of people get very upset when you even suggest someting like this, but that’s just elitist nonsense. Btrfs has various incredibly useful features that should be exposed to users of all kinds, not just sysadmins and weird nerds – and graphical tools are a great way to do this. I don’t know exactly what the long-term plans of the new Btrrfs SIG are going to be, but I think making the useful features of Btrfs more accessible should definitely be on the list. You shouldn’t need to be a CLI expert to set up resilient, redundant local storage on your machine, especially now that the interest in digital self-sufficiency is increasing.
Earlier this year, a proposal was made to replace the primary edition of Fedora from the GNOME variant to the KDE variant. This proposal, while serious, was mostly intended to stir up discussion about the position of the Fedora KDE spin within the larger Fedora community, and it seems this has had its intended effect. A different, but related proposal, to make Fedora KDE equal in status to the Fedora GNOME variant, has been accepted. The original proposal read: After a few months of being live, the proposal has now been unanimously accepted, which means that starting with Fedora 42, the GNOME and KDE versions will have equal status, and thus will receive equal marketing and positioning on the website. Considering how many people really enjoy Fedora KDE, this is a great outcome, and probably the fairest way to handle the situation for a distribution as popular as Fedora. I use Fedora KDE on all my machines, so for me, this is great news.
It’s a big day for Fedora users such as myself – and especially for Fedora KDE users, also such as myself. Fedora 40 has been released today, and while the main focus is always on the GNOME release – although not everyone is happy about that – the various other spins, in Fedora parlance, have also seen major updates. Most prominently among them is the KDE spin, which ships with KDE’s recent megarelease, KDE Plasma 6. Starting at the top, Fedora 40 Workstation comes with the latest GNOME release, 46, which we covered when it was released earlier this year. It also comes with IPV4 Address Conflict Detection to resolve duplicate IPV4 addresses in the same physical network, and the PyTorch machine learning framework is now in the Fedora software repositories for easier installation and implementation by developers – a harbinger of what’s to come. The KDE spin comes, as already mentioned, with KDE Plasma 6, and inherits the non-GNOME improvements and fixes as well, of course. There’s also countless other spins covering pretty much every desktop environment and window manager under the sun, and Fedora 40 is also the first release to implement the new naming scheme for Fedora’s various immutable editions – the Atomic Desktops.
All weekend, I’ve been mulling over a recent blog post by Fedora Project Leader Matthew Miller, which he wrote and published on behalf of the Fedora Council. Fedora (the KDE version) is my distribution of choice, I love using it, and I consider it the best distribution for desktop use, and not by a close margin either. As such, reading a blog post in which Fedora is announcing plans to make extensive use of “AI” was bound to make me a feel a little uneasy. Miller states – correctly – that the “AI” space as it stands right now is dominated so much by hyperbole and over-the-top nonsense that it’s hard to judge the various technologies underpinning “AI” on merit alone. He continues that he believes that stripped of all the hyperbole and techbro bullshit, there’s “something significant, powerful”, and he wants to make “Fedora Linux the best community platform for AI”. So, what exactly does that look like? In addition to the big showy LLM-based tools for chat and code generation, these advances have brought big jumps for more tailored tasks: for translation, file search, home automation, and especially for accessibility (already a key part of our strategy). For example, open source speech synthesis has long lagged behind proprietary options. Now, what we have in Fedora is not even close to the realism, nuance, and flexibility of AI-generated speech. ↫ Matthew Miller Some of these are things we can all agree are important and worthwhile, but lacking on the Linux desktop. If we can make use of technologies labelled as “AI” to improve, say, text-to-speech on Linux for those who require it for accessibility reasons, that’s universally a great thing. Translation, too, is, at its core, a form of accessibility, and if we can improve machine translations so that people who, for instance, don’t speak English gain more access to English content, or if we can make the vast libraries of knowledge locked into foreign languages accessible to more people, that’s all good news. However, Fedora aims to take its use of “AI” even further, and wants to start using it in the process of developing, making, and distributing Fedora. This is where more and more red flags are starting to pop up for me, because I don’t feel like the processes and tasks they want to inject “AI” into are the kinds of processes and tasks where you want humans taken out of the equation. We can use AI/ML as part of making the Fedora Linux OS. New tools could help with package automation and bug triage. They could note anomalies in test results and logs, maybe even help identify potential security issues. We can also create infrastructure-level features for our users. For example, package update descriptions aren’t usually very meaningful. We could automatically generate concise summaries of what’s new in each system update — not just for each package, but highlighting what’s important in the whole set, including upstream change information as well. ↫ Matthew Miller Even the tools built atop billions and billions of euros of investments by Microsoft, Google, OpenAI, Facebook, and similar juggernauts are not exactly good at what they’re supposed to do, and suck at even the most basic of tasks of providing answers to simple questions. They lie, they make stuff up, they bug out and produce nonsense, they’re racist, and so on. I don’t want any of that garbage near the process of making and updating the operating system I rely on every day. Miller laments how “AI” is currently a closed-source, black box affair, which obviously doesn’t align with Fedora’s values and goals. He doesn’t actually explain how Fedora’s use of “AI” is going to address this. They’re going to have to find ethical, open source models that are also of high quality, and that’s a lot easier said than done. Sourcing doesn’t even get a single mention in this blog post, even though I’m fairly sure that’s one of the two major issues many of us have with the current crop of “AI” tools. The blog post also completely neglects to mention the environmental cost of training these “AI” tools. It costs an insane amount of electricity to train these new tools, and with climate change ever accelerating and the destruction of our environment visible all around us, not mentioning this problem when you’re leading a project like Fedora seems disingenuous at best, and malicious at worst. While using “AI” to improve accessibility tools in Fedora and the wider Linux world is laudable, some of the other intended targets seem more worrisome, especially when you take into account that the blog post makes no mention of the two single biggest problems with “AI”: sourcing, and its environmental impact. If Fedora truly intends to fully embrace “AI”, it’s going to have to address these two problems first, because otherwise they’re just trying to latch onto the hype without really understanding the cost. And that’s not something I want to hear from the leaders of my Linux distribution.
Update: the proposal has now been formally announced on the devel mailing list and Fedora Discussions. I have been assured by the main author of the proposal itself that this is very much not an April Fools joke, but of course, there’s still the very real possibility we’re being led on here. Still, I’m taking the risk and treating this as a serious change proposal for Fedora, even though it’s likely to cause some controversy in the wider Fedora community. The proposal is written by Joshua Strobl, the lead developer of Budgie. Yes, this is a change proposal to make KDE the default desktop environment of Fedora Workstation. The reasoning is that KDE is more approachable for new users than GNOME, it supports standards better, the industry seems to be making moves to KDE (see the Steam Deck), and so on. KDE also has more advanced features people have come to expect from a desktop, like HDR, VRR, and more, and it’s the more advanced Wayland desktop. The important note here is that in the highly unlikely event this proposal would be accepted, it’s not like current Fedora GNOME users will be ‘upgraded’ to KDE when Fedora 42 gets released. The idea is to promote the current Fedora Plasma spin to the main Fedora Workstation release, and demote the Fedora GNOME release to a mere Fedora spin, like KDE is now. While I would personally support this change, it’s pretty much 100% unlikely this change proposal will make it through. Red Hat and Fedora are entirely GNOME-first, and no matter how much I believe that’s misguided when looking at the state of the two primary open source desktops today, that’s not going to change. Still, it’s an interesting discussion point, if only to highlight that the frustrations with GNOME run a lot deeper than people seem to think.
Fedora Workstation has long defaulted to using GNOME’s Wayland session by default, but it has continued to install the GNOME X.Org session for fallback purposes or those opting to use it instead. But for the Fedora Workstation 41 release later in the year, there is a newly-approved plan to no longer have that GNOME X.Org session installed by default. ↫ Michael Larabel Expect more and more of the major distributions to abandon X.org completely. For the KDE version of Fedora, X.org will be dropped entirely in Fedora 40 already, so one release earlier.
We are happy to announce the creation of a new family of Fedora Linux spins: Fedora Atomic Desktops! As Silverblue has grown in popularity, we’ve seen more of our mainline Fedora Linux spins make the jump to offer a version that implements rpm-ostree. It’s reached the point where it can be hard to talk about all of them at the same time. Therefore we’ve introduced a new brand that will serve to simplify how we discuss rpm-ostree and how we name future atomic spins. ↫ Joseph Gayoso for Fedora Magazine You can get pretty much any major desktop environment as an rpm-ostree (inaccurately referred to as ‘immutable’) version of Fedora, so it makes sense to standardise the naming scheme.
The split between /bin and /sbin is not useful, and also unused. The original split was to have “important” binaries statically linked in /sbin which could then be used for emergency and rescue operations. Obviously, we don’t do static linking anymore. Later, the split was repurposed to isolate “important” binaries that would only be used by the administrator. While this seems attractive in theory, in practice it’s very hard to categorize programs like this, and normal users routinely invoke programs from /sbin. Most programs that require root privileges for certain operations are also used when operating without privileges. And even when privileges are required, often those are acquired dynamically, e.g. using polkit. Since many years, the default $PATH set for users includes both directories. With the advent of systemd this has become more systematic: systemd sets $PATH with both directories for all users and services. So in general, all users and programs would find both sets of binaries. ↫ Proposal on the Fedora wiki I think Arch already made this move a while ago, and it seems to make sense to me. There’s a lot of needless, outdated cruft in the directory structure of most Linux distributions that ought to be cleaned up, and it seems a lot more distributions have started taking on this task recently.
Fedora Workstation now features GNOME 45, which brings better performance and many usability enhancements, including a new workspace switcher and a much-improved image viewer. If you’re looking for a different desktop experience, our Budgie Special Interest Group has created Fedora Onyx, a Budgie-based “Atomic” desktop in the spirit of Fedora Silverblue. Of course, that’s not all — we also have updated desktop flavors featuring KDE Plasma Desktop, Xfce, Cinnamon, and more. As with every Fedora release, it comes with the latest and greatest every one of the Linux desktops has to offer, as well as all the newest versions of the various frameworks and underlying layers, down to the kernel. Fedora KDE is my desktop of choice, so I’m definitely a bit biased, but I can’t wait to load up the upgrade and install it.
The tradeoff is that we are pivoting away from work we had been doing on desktop applications and will cease shipping LibreOffice as part of RHEL starting in a future RHEL version. This also limits our ability to maintain it in future versions of Fedora. We will continue to maintain LibreOffice in currently supported versions of RHEL (RHEL 7, 8 and 9) with needed CVEs and similar for the lifetime of those releases (as published on the Red Hat website). As part of that, the engineers doing that work will contribute some fixes upstream to ensure LibreOffice works better as a Flatpak, which we expect to be the way that most people consume LibreOffice in the long term. I’m no fan of Flatpak for a multitude of reasons, but at the same time, I can’t blame Red Hat and other distribution makers for not wanting to maintain a complex set of packages such as LibreOffice. This does give me pause regarding my current use of Fedora on two of my three machines, as I do not wish to rely on Flatpak for anything serious.
Two major Linux distributions released major new versions this week. First, Ubuntu: There’s a big user experience uplift courtesy of GNOME 44 and enhancements, and a brand new Ubuntu installer helps improves the onboarding experience. Foundationally, Ubuntu 23.04 runs on the latest Linux kernel 6.2 release, ships Mesa 23.0 graphics drivers (with in-distro access to proprietary NVIDIA drivers for those who need them), plus updates all of the requisite tooling, toolchains, and programming packages developers need. I’m curious to try the new installer if someone else adopts it (I have no need for Ubuntu), but other than that, this is a fairly small release that won’t rock the boat too much. Second we have Fedora: Fedora Workstation focuses on the desktop experience. As usual, Fedora Workstation features the latest GNOME release. GNOME 44 includes a lot of great improvements, including a new lock screen, a “background apps” section on the quick menu, and improvements to accessibility settings. In addition, enabling third-party repositories now enables an unfiltered view of applications on Flathub. With this release, we’ve shortened the default timeout when services shut down. This helps your system power off faster — important when you need to grab your laptop and go. Fedora is, in my view, the best desktop Linux distribution, and I use it myself on two of my three main PCs. So far, Fedora 38 doesn’t feel like a major new release either, but just more of what you already know.
Red Hat and Fedora engineers are plotting a path to supporting Unified Kernel Images (UKI) with Fedora Linux and for the Fedora 38 release in the spring they are aiming to get their initial enablement in place. Unified Kernel Images have been championed by the systemd folks for better securing and trusting Linux distributions. Unified kernel images are a combination of the kernel image, initrd, and UEFI stub program all distributed as one. This seems like a fairly no-brainer move, and I’m sure there will be agreement and jolly cooperation on this step forward from all involved in the Linux community.
Fedora 36 is releasing this morning as what is yet another release in recent times of being a very robust and bleeding-edge yet stable and reliable Linux distribution. I’ve already been running Fedora Workstation 36 and Fedora Server 36 snapshots on various systems in my benchmarking lab and this release has proven to be quite solid while adding new features and polish on top of the excellent Fedora 35. I have no reservations about stating that Fedora is by far the best desktop Linux distribution you can get today (assuming you prefer GNOME, that is). It’s polished to an insane degree, not afraid to both develop and implement new technologies that bring the Linux desktop forward – kicking and screaming, lots of kicking and screaming – and sports excellent community support through things like RPM Fusion. Linux Mint if you prefer less bleeding edge, Fedora if you want the best the Linux desktop has to offer.
