Home FedoraFedora’s 32-bit (i686) Support Withdrawal Postponed – Here’s Why

Fedora’s 32-bit (i686) Support Withdrawal Postponed – Here’s Why

By sk
Published: Updated: 1091 views 5 mins read

Recently, Fedora project sparked a lively debate with a major proposal to stop supporting older 32-bit computer systems. This change, aimed at Fedora Linux 44, would have dramatically impacted how many people use their computers, especially for gaming. But why did Fedora want to drop 32-bit (i686) support, and why did it cause such a strong reaction? Let's find out.

The proposal: Dropping i686 (32-bit) Support in Fedora 44

Fabio Valentini and other project owners put forward a proposal for Fedora Linux 44. The main idea was twofold:

  • Stop including 32-bit software libraries – often called "multilib" – on 64-bit Fedora systems.
  • Completely stop creating new software for 32-bit computers (the 'i686' architecture).

Fedora had already taken steps in this direction, having stopped offering 32-bit kernel packages and installer images since Fedora 31.

This proposal was seen as the "next two (and last) steps" in phasing out older 32-bit support.

The first part of the plan (removing libraries from repositories) was designed to be reversible, but the second step (stopping new software builds) would have been nearly impossible to undo.

Why Did Fedora Want to Remove 32-bit Support?

The Fedora team proposed this for several good reasons, mainly to make things easier and more efficient for everyone involved.

  • Less work for maintainers: It's getting harder to build and update software for 32-bit systems because many software projects no longer support them. This change would remove a growing burden.
  • Simpler engineering: The way 32-bit libraries are currently included is complicated and relies on "brittle heuristics and rules". Removing them would simplify the process of creating Fedora's software repositories.
  • Better use of resources: Not building 32-bit software would free up computer power. This means 64-bit software could be built much faster.
  • Faster for users: Dropping about 10,000 32-bit software packages would make Fedora's software lists smaller. This could speed up downloading updates and managing software.

The Big Impact: What Would Change for Users?

While the proposal had clear benefits for Fedora's developers, it also had significant consequences for users.

  • Software removal: Any 32-bit software already installed on a 64-bit Fedora system would be removed when upgrading to the new version.
  • Third-party software issues: Other software that needs these 32-bit libraries would no longer be able to install on Fedora.
  • Gaming concerns: This was a major point of contention. The change would particularly impact gaming software like Wine (used to run Windows games) and Steam (a popular game platform). Older Wine setups might need to be recreated.
  • Other Linux distributions affected: Fedora-based distributions, like Bazzite and Nobara, which are popular for gaming, would also be affected. It would also break the FEX root filesystem, which helps run x86 software on ARM computers.
  • Older games at risk: Many worried that a large number of older "native" Linux games (made before the mid-2010s) and some Windows games that don't work well with newer Wine technologies would simply stop working easily.

Community Reaction

The proposal received a very strong reaction.

Fabio Valentini, the person who put forward the proposal, expressed disappointment, noting that "hundreds of people" were "shouting 'DON’T DO THIS WHY DON’T YOU CARE ABOUT YOUR USERS I WILL SWITCH DISTROS IMMEDIATELY'".

He felt that "clickbait 'tech press' or YouTubers" contributed to this intense response.

Many users were worried about their games breaking and the hassle of finding workarounds. Some pointed out that even Windows still supports 32-bit software for compatibility.

The overall sentiment became a "devs vs users" situation for many.

At the time of writing this post, the poll results are as follows:

Poll Result - Dropping 32-bit (i686) Support in Fedora Linux 44
Poll Result - Dropping 32-bit (i686) Support in Fedora Linux 44

The poll results clearly show a significant majority in opposition to the proposal, with 51% "Strongly opposed" and an additional 16% "Opposed, but could be convinced", totalling 67% opposition.

Were There Any Solutions or Workarounds?

During the discussion, several ideas for managing the change were brought up:

  • Wine's "new WoW64": This is a way for Wine to run 32-bit Windows applications on a 64-bit system without needing all 32-bit libraries from the operating system itself. While it's improving, some still report bugs or performance issues with certain games.
  • Flatpaks: These are self-contained software packages. Steam, for instance, is available as a Flatpak and includes its own 32-bit libraries. However, some users dislike Flatpaks due to potential "performance ranges from slightly worse to abysmally worse," increased disk space usage, and "interoperability problems" with features like SteamVR or Gamescope.
  • Containers (Podman/Docker/Toolbx): These tools could potentially run older 32-bit operating systems or applications in a separate environment.
  • Partial 32-bit support: Like Ubuntu did in 2019, Fedora could choose to keep a small, essential set of 32-bit libraries specifically needed for gaming. This was seen by some as a good compromise.

The Outcome: Fedora Drops Plan to End i686 Support in Version 44

On June 28, 2025, Fabio Valentini withdrew the proposal. Yes, Fedora Keeps 32-bit (i686) Support, for Now.

He explained that targeting Fedora 44 was "too early". He also noted that the discussion probably wouldn't have been much different if a later release, like Fedora 46, had been targeted.

While many in the Reddit community saw this as a "win" for users and gamers, others argued it was a "loss" for maintainers and simply "kicked the can further down the road".

They stressed that the underlying problem of 32-bit software support isn't going away. Software projects continue to drop 32-bit support, and Fedora will eventually need to address this challenge.

Fabio Valentini is now actively "looking forward to seeing actual (and actionable) counter-proposals". This suggests the conversation is far from over, and a more gradual or targeted solution might be proposed in the future to balance the needs of both developers and users.

Related Read:

You May Also Like

Leave a Comment

* By using this form you agree with the storage and handling of your data by this website.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Home Linux KernelTyr: A New Rust-written Linux Kernel Graphics Driver for ARM Mali GPUs

Tyr: A New Rust-written Linux Kernel Graphics Driver for ARM Mali GPUs

By sk
359 views 3 mins read

Get ready for Tyr, a brand-new Linux kernel DRM graphics driver for your Linux system! Tyr isn't just another GPU driver. It's a port of Panthor, an existing driver, and aims to match all of Panthor's features over time.

This exciting project is written in Rust, a modern programming language. Tyr works with ARM Mali GPUs, specifically those using the Command Stream Frontend (CSF) firmware. This means it supports newer Mali graphics hardware, from "Gen10" onwards.

A joint effort by Collabora, ARM, and Google engineers, Tyr's initial version offers limited functionality, primarily for validating new abstractions within the Linux kernel.

The developers plan to iteratively submit driver components upstream to reduce regressions and prove the viability of in-progress kernel abstractions.

What is Tyr?

Tyr is a Rust-based DRM (Direct Rendering Manager) graphics driver for ARM Mali CSF-based GPUs. This driver is a Rust port of the existing Panthor driver, aiming for feature parity through incremental development.

The name "Tyr" even comes from Norse mythology, just like ARM's other GPU names!

But here's the truly exciting part: Tyr is a joint initiative by some very important names in technology:

  • Collabora
  • ARM
  • Google

Yes, engineers from these leading companies are collaborating to build this driver. This combined effort shows a strong commitment to Rust in critical system components.

What Can Tyr Do Right Now?

This first version of Tyr is just the beginning. It can successfully power on your GPU and allow the driver to "probe" (meaning it can be detected and initialized). It can also extract and log important diagnostic information about your GPU.

While it can't fully boot the GPU's microcontroller (MCU) yet – that needs more underlying "GPUVM abstraction" work – this initial release is crucial.

It helps test and validate new Rust abstractions being developed for the Linux kernel. This step-by-step approach helps reduce potential problems as development moves forward.

The Power of Rust in the Linux Kernel

Rust is gaining popularity, especially for system-level programming. Why? Because it offers major advantages:

  • Enhanced Memory Safety: Rust is designed to prevent common errors like "buffer overflows" or "dangling pointers" right at the compile time. This means your system can be much more reliable and secure.
  • Safe Concurrency: Writing code that handles multiple tasks at once can be tricky, but Rust's design helps prevent "data races" and other related issues. This makes parallel programming much safer.
  • Performance: Rust can often match the speed of languages like C and C++ because it compiles directly to machine code and doesn't use a garbage collector.

Linus Torvalds, the creator of Linux, even supports bringing Rust into the Linux kernel! This is a huge vote of confidence for the language.

Tyr's development is a proof to the growing role of Rust in vital system software. It shows that creating secure and robust drivers is a top priority for some of the biggest names in tech.

The Road Ahead for Tyr GPU Driver

The teams behind Tyr have a more advanced version already working internally. This version can boot the MCU and perform some basic graphics tasks.

The goal is to gradually bring all these features upstream into the main Linux kernel. Let us wait and see how it evolves in the days to come.

Resource:

You May Also Like

Leave a Comment

* By using this form you agree with the storage and handling of your data by this website.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

This website uses cookies to improve your experience. By using this site, we will assume that you're OK with it. Accept Read More