Fedora 43 won't drop 32-bit app support – or adopt Xlibre The Fedora community has quickly dropped a couple of recent proposed changes – one highly controversial, the other rather less so. Fedora 42 is here, and so Fedora 43 is taking shape. That means members of the Fedora community can submit proposals for changes to the distro's future direction. Many of these consist of internal …
There's nothing to stop you running non-games software on it as well as games. It looks like a good "it just works" distro for someone who can't or doesn't want to be forced to upgrade to Windows 11.
Exactly this, I needed a replacement for Win10 on my aging laptop and decided to give Bazzite a spin.
As I understand the 32-bit problem, 32-bit games aren't the issue. Steam itself is, as it's only available as a 32-bit binary on Linux and it's up to Valve to provide a 64-bit build, which they have neglected to do so far. The games themselves run under Proton which takes care of the environment and necessary libraries, rather than the distro itself.
Bazzite appeals as an entry point for the gaming-inclined. There is a "deck" flavoured version which is designed for handheld PCs, but there's a desktop version which doesn't just boot straight into Steam Big Picture mode. The selling point is that all the setup to be able to game is already done.
So far I haven't even gamed on it, but it's a weight off my mind knowing I don't have to jump through quite so many hoops when the urge takes me. My laptop is primarily for writing so my time noodling with it has been spent figuring out how to hook up TeX Live to VS Code and latex-workshop, which isn't so straightforward when everything is containerised these days. Last linux distro I used in anger was Arch about ten years ago so Fedora Atomic with its layering has a bit of a learning curve. Not unsolvable, but going straight to rpm-ostree felt a bit sinful.
> Steam itself is, as it's only available as a 32-bit binary on Linux
I think this is wrong.
I do not run it on Linux myself, but Steam is based on Chrome, and Chrome is 64-bit only on Linux.
Steam needs lots of 32-bit support to be available to run 32-bit games, but that does not mean "Steam is 32-bit".
https://steamcommunity.com/app/221410/discussions/0/1640915206447625383/
Windows and Linux run 32-bit clients apart from embedded Chromium. Their only 64-bit client is on MacOS due to Apple dropping support for 32-bit (choose your poison - 32-bit games on an outdated OS and outdated Steam client or no 32-bit games on a new OS with the new Steam client...).
One advantage of building and testing 32-bit binaries is that it helps to cross-check that you are using the right data types in your C and C++ code.
I've seen a lot of bugs in code that we exposed this way by building for a different architecture or data width. Compilers are getting better at detecting these sorts of issues, but it does help.
Compiling likely does little by itself. You'd have to extensively test whatever you compiled on a new architecture to be sure it functions as intended. And if the thing you compiled requires an entire dist, all 32-bit just to do that, then it might be seen as overkill.
It's unfortunate that Linux doesn't have some kind of thunking layer the way Windows handled the transition. Everyone is running 64-bit windows but there is backwards compatibility via a Wow64 subsystem that switches the CPU to 32-bit mode, intercepts calls to DLLs, APIs, registry etc to call the 64-bit equivalent. Some of the thunks are pretty messy (especially the way registry is handled) but it is seamless and works fairly well.
But its unnecessary for Linux. 99% of use cases can be trivially handled via virtualization. It is only things that won't perform well (or run at all due to copy protection type stuff that checks if it is running in a VM) like 3D heavy games or dongled commercial apps that VMs aren't a solution for.
It was necessary in Windows because having source code for something is the exception rather than the rule. In the Linux world it is the other way around, there aren't a lot of applications that are binary only and were only ever available in 32 bit binaries.
¿You know what would expose even more bugs in code?
Compiling for the 32-bit ARMhf ....¡oh wait! ¡they do!
¿You know what would uncover even more bugs in code?
Compiling for PowerPC 9 .... ¡oh wait! ¡they do!
¿You know what would uncover even 'moar' bugs in code?
Compiling for RISC-V .... ¡oh wait! ¡they do!
¿Want to uncover even more bugs?
Compile for obscure systems like MIPS or S390x .... ¡oh wait! ¡they do!
So, do not worry my friend, even if they drop i686/x-86-32, there is plenty of cross-check that you are using the right data types in your C and C++ code.
¡And some of these have the benefit of being Big-Endian by default! X86 is little endian only. ¡In fact S390x is Big Endian only!
Jokes aside, what I am traying to hint, is something you should have been able to pick up by yourself, but did not:
Yes, there are many reasons to keep i686/X86-32 libraries around, but "cross-check that you are using the right data types in your C and C++ code" is NOT one of them...
> Yes, there are many reasons to keep i686/X86-32 libraries around, but "cross-check that you are using the right data types in your C and C++ code" is NOT one of them...
Honestly, I don't really get the hostility. Take a f*cking chill pill for Christ's sake.
Yes, you are right. I was merely pointing out the advantage of building for a number of different platforms and bit sizes for checking code quality. Yes, I know Fedora supports a lot of different platforms. One less won't make a huge difference and it doesn't in any way negate the truth of my comment.
>” So, do not worry my friend, even if they drop i686/x-86-32, there is plenty of cross-check that you are using the right data types in your C and C++ code.”
This isn’t just a C/C++ problem, would not be surprised if Rust for example also has some interesting behaviours.
The nice thing about i686/x86-32 is that setting up such as system for test purposes is relatively trivial compared to some of the other architectures. But agree, it would be nice to have a S390x to hand to permit fuller testing…
I suspect a big driver these days is the automation of compilation and test, being able to use the same platform for two different test rigs probably helps.
It's more likely you'd run into problems compiling up to 64-bit than down to 32-bit.
Anyway, compiling code isn't going to necessarily reveal issues. I had x86 code which compiled and ran just fine on ARM except it would break on a very particular piece of code. And that turned out to be a pointer alignment issue - ARM & the compiler were having problems casting one type to another due to alignment/unalignment issues that I was inadvertently violating.
The subhead and this text may give an incorrect impression:
"The change was rejected, and for now this won't happen. The margin wasn't huge, though. At the time of writing, it was showing 51 percent "Strongly opposed," plus another 15 percent "Opposed, but could be convinced.""
Changes are not decided by community vote. The vote is purely informational. Changes are voted on by FESCo, the Fedora Engineering Steering Committee. In this case the Change did not come to a vote because the proposers withdrew it.
> The subhead
One day, Adam, one day I will write something you don't disagree with. But I do not know when.
The editors generally don't use my titles, so the titles on published stuff are usually not mine. (Slightly more often the page title -- the thing in the browser tab or title bar -- is based on my proposed title while the actual heading in the text is not. I suspect most people never notice that.)
I am not keen on the phrasing of this title but it is not my department.
Regarding the vote, though -- fair enough, point taken.
Maybe, here's a thought, someone should write a short explainer on how Fedora governance works, because from the outside it's opaque and mysterious.
Well, my comment intentionally didn't ascribe anything to any person. That was intentional, because I'm fully aware that headlines and subheads are often not written by the author of the article.
Liam, I like you and think you write good articles, that's why I read them. Adding an explanatory note is not a criticism, either personal or journalistic. You'll note my comment doesn't call you an idiot or mention your name at all.
> Liam, I like you and think you write good articles, that's why I read them.
Thank you!
> Adding an explanatory note is not a criticism,
I did not take it as such. My reply was written with a smile.
This time I'm using my fingers, though, and it's much _much_ quicker.
Regarding documentation - the Change process is documented at https://docs.fedoraproject.org/en-US/program_management/changes_policy/#_change_process .
I don't think anyone could "write a short explainer on how Fedora governance works", because it's quite complicated. In my experience, governance of anything of significant size tends to be somewhat complex unless it is run entirely by a dictator (benevolent or otherwise). Even in that case, once it's sufficiently large, the dictator probably needs to delegate *somehow*, and the details of that also get complex.
Is there a non-dictator-led distro whose governance you'd say is simpler or clearer to understand?
> Is there a non-dictator-led distro whose governance you'd say is simpler or clearer to understand?
Interesting.
I mean, for one thing, whether the model of control matters.
Look, totally off the cuff, after hours...
A few years ago, I wrote an article that the editor rejected, because he felt it showed my personal bias, as an ex-RH staffer.
I disputed this but in vain.
But it put me strongly in mind of a conversation I had with a senior Hatter (who's now left) who was struggling to determine and understand the community relation systems of other distros and compare them to Fedora.
I tried to explain to him that they _didn't have them_. Most distros are just a bunch of people, putting something together and putting it out there. That is what FOSS is all about. Scratch that itch, share it in case others have a use for it.
If people like it, they'll use it. If they don't, they won't. Provide them with places to meet up to help each other. Give them some docs.
It's enough. It created an industry.
Only one company in that industry cares who its users are and what they thing and constantly tries to find ways to involve them and engage them and get them to contribute. It seems blissfully unaware that doing so is subjecting yourself to a bureaucratic nightmare that never ends. It thinks that's normal.
That company puts out a survey that does the equivalent of Steve Ballmer lumbering around chanting "DEVELOPERS! DEVELOPERS! DEVELOPERS!" while dripping in sweat.
Only that company runs around drenched in sweat shouting "COMMUNITY! COMMUNITY! COMMUNITY!"
I wrote that anyone reading this totally anonymous 3rd party survey would know exactly who commissioned it and who wanted it and what they were asking because half of the survey was about COMMUNITY.
Nobody else cares. I think RH cares way too much and should just STFU. Just, FFS, relax already. Let it go.
You ask if others have simpler clearer models. It's a non sequitur. *Everyone* else has a simpler model, because they don't have a model, because nobody bloody cares.
"Make it work." There's the model.
All this model stuff is noise.
SUSE doesn't seem to give a stuff about community. It makes a distro, it has opinions, it gives a free version away. There are a few dozen people running it and a few dozen outside, if that, who liaise between the freeloaders and the paid folks making it.
TBH my impression is the SUSE execs don't what "Linux" even is, and don't care. They don't really know why they give away a version but it seems important to a few annoying people so they threw them a bone.
Debian: it has elections and stuff because you need some sort of decision makers but mostly a herd of volunteers just get on with it, and people just get on with using it.
All the other projects, even if they have hundreds of thousands of users, are basically small enough groups of people they could just meet in a room around 1 table and talk stuff out. They don't need all the bureaucracy.
Only one project has it and OMG it _keeps_ going on about it but nobody can be bothered to explain what it is, how it works, why it's there, and why anyone should care.
"You ask if others have simpler clearer models. It's a non sequitur. *Everyone* else has a simpler model, because they don't have a model, because nobody bloody cares."
I mean, this seems unlikely. "Most distros are just a bunch of people, putting something together and putting it out there" is a very reductive description - but it equally applies to Fedora. Governance is just the *details* of how that "bunch of people" decide what "thing" it is they're putting together, exactly, and how they're going to "put it out there".
If "nobody cares" about these kinds of details, then this is a complete non-story: from that "nobody cares" perspective, *literally nothing happened*, did it? The only things that happened were the things you say nobody cares about - the details of one specific "bunch of people" deciding not to do a thing.
So if this is a story, well, that implies governance and community processes and all of that stuff *matter*, doesn't it?
Good luck to them but sounds like the fork adds more extensions and patches (e.g. multimonitor support) that mainstream dists have no need for. They use Wayland for their local desktop and Xorg for supporting older software and don't need these things. I'm sure the conspiracy paranoia on top doesn't exactly help either.
> the fork adds more extensions and patches (e.g. multimonitor support) that mainstream dists have no need for
Hang on, what?
That's not right.
X.org has done multihead and done it well for 20+ years now.
https://wiki.archlinux.org/title/Multihead
Multihead is the term for a single computer with >=2 displays.
Originally for X.org it was in the Xinerama extension:
https://man.archlinux.org/man/extra/libxinerama/Xinerama.3.en
Or, if you use nVidia and the proprietary driver, an equivalent called Twinview:
https://wiki.archlinux.org/title/NVIDIA#TwinView
But more recently (as in, a decade ago) both have been replaced by a new and more versatile extension called Xrandr:
https://cgit.freedesktop.org/xorg/proto/randrproto/tree/randrproto.txt
It's short for "X Resize, Rotate and Reflect".
(Aside: it is becoming a pain as it is xrandr that virtualises the DPI setting across all displays; without it, it would be possible to have, say, the left screen at 144dpi and the right screen at 72dpi. Currently this is *THE* killer advantage of Wayland.)
So now you have have a mixture of portrait and landscape (which I use myself) and switch on the fly (which I rarely do but it's near essential for handhelds and tablets).
This is nothing to do with Xlibre; it's been a stock feature for 25 or so years.
In 1996 when I went freelance I built a Pentium II - 400 box for myself. I used two matching-generation Matrox cards because Matrox was great at multihead on Win NT 4, and this combination of GPUs gave me a 2048x768 desktop on 2 old 15" CRT screens I'd scrounged. To hell with 3D, that's for children and games.
By 5Y later I moved those cards to a new dual Athlon XP box I built. I ran SUSE Pro on it at first but switched to Ubuntu in 2004. Ubuntu's super-minimal screen setup control panel doobrie couldn't hack it, so I kept SUSE, used its SAX tool to configure the 2 heads, then copied `/etc/X11/xorg.conf` from SUSE's root partition into Ubuntu's root.
Reboot and boom, one big GNOME 2 desktop over two 17" CRTs at 2560x1024.
Not new. Not an optional extra. Dates back to XFree86 I think!
https://www.theregister.com/2003/03/21/xfree86_dustup_questions_x11_model/
Even before Xinerama came along you could use two monitors: they were just separate displays - typically ":0.0" and ":1.0". But they would be truly separate, running distinct sessions. You could move the mouse from one to the other but you couldn't drag windows from one to the other.
I actually used Mint 13 that way up until about 2020 - it suited me better than either Xinerama or XRandR. (I could guarantee that nothing would ever open on the wrong monitor when one of them was connected to a different device; I could play a movie on one monitor and it wouldn't disappear when I switched virtual desktops on the other.)
yep. about 21 years ago, my GF made me watch the first Harry Potter movie. That night, I went home and renamed my three-headed OpenBSD computer "Fluffy".
In fact, I very shortly after the release of the movie "The Matrix Reloaded", I was making bad jokes about my adding another Matrox card to my computer... "Matrox Reloaded" (pretty sure that was head #3).
xrandr makes it comparatively easy, but I really preferred the "independent" mode (they call it "Zaphod mode", iirc) of years past -- one monitor would have chat and e-mail clients running, another monitor would have the work that e-mail was inspiring, and the multiple desktops in X would be different projects I'd be working on based on those e-mails.
These days, I'm down to one 43-50" 4k TV being used as a monitor (same number of dots and same screen space as four 1920x1080 monitors) on my primary Unix-like machine. I'm really not sure how I used to work with 25 lines of 80 characters or 640x225 graphics anymore... Some day, I'm sure I'll attach another one, then two 4k TVs to my Unix computer, and Fluffy will Ride Again!
I don't know why you're saying "hang on, what?". Go read the change log of the project. It's not just multimonitor but setting different resolutions and display rates on those monitors to make it actually usable and sane.
And the point that I'm emphasizing is Wayland already has usable and sane multimonitor support so Xlibre is offering nothing to dists they don't already have. Same for the other improvements its bolting onto X11. So no wonder Fedora & other dists have no need for it.
The underlying reason for maintaining a 32 bit userland seems to be to support software that cannot be rebuilt to 64 bit; the overwhelming reason for this presumably would be that the software was closed source, binary only and the source has never been released.
I have certainly encountered a fair bit of academic or non-commercial software where the source was just carelessly lost and you only had the binaries - the relocatable objects (.o, .obj) if you were lucky or only executable and shared libraries if you were not.
The only 32 bit software I need to run under *EL8 these days is a Brother CUPS filter I use for a FujiXerox laser. If needed I imagine I could run the filter in a container with a minimal 32 bit user space.
The article reminded me that I have the Linux Corel WordPerfect CDs and license somewhere which I would be curious to see how it compares with modern offerings. The beauty of VMs is that you can spin up a copy of RH 7.4 or RHEL 3 and run this software.
I suppose if Intel/AMD started removing 32 bit opcodes from their future x86_64 processors' ISAs then 32 bit would be dead but even then I would assume removed opcodes would still trap to an unimplemented operation which could implement the missing ops in software.
The distro maintainers understandably want to drop the 32 bit applications which undoubtedly adds a significant extra resource load.
I would imagine just maintaining the basic 32 bit run time support (ld-linux.so.2, glibc, nss, ...) wouldn't require as much effort but could leave an opportunity for third parties to provide the rest of the 32 bit tool chain and applications (akin to a cross build environment.)
Ironically it's not 32-bit Linux apps I want to keep running, so much as 32-bit Windown apps.
For instance, I have a portable audio recorder which stores audio tracks on SD card in a proprietory format, and a small Win32 application (which works perfectly under WINE) exports the recordings in WAV format. I definitely don't want to keep a Windows install just for that.
Also, if I feel the urge to play Return to Castle Wolfenstein again I'm going to stand a much better chance of running the Windows version under WINE than running the actual Linux binary from 20 years ago - but neither will work without 32-bit support.
It strikes me that what the 'gaming systems' might need is their own, unique operating systems that are closed-source and protected, not more of an 'open-world' approach (as clearly the banking industry knew in the 70s through 90s but conveniently forgot by the late 90s and just before internet gaming became more commonplace.
Just my humble opine.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
