Bazzite would shut down if Fedora goes ahead with removing 32-bit

Obvious stoppers: man power, expertise, incompatibilities,...

No, they said: we don't want to build all 32-bit packages no one is using. libs which are used by games and such will be kept. So they need to keep gcc, glibc and binutils for 32bit also. Just not multilib, i686 cross is good enough

I think the fundamental problem is that there are many different 5% groups and that you are very likely to be in some 5% groups.

In some way I feel dropping 32bit is capitulation to bloat.

I for one use 32bit libs in x86 32bit mode quite a lot to test software I build for memory bugs such that it works on actual 32bit systems.

None of the BSDs provide the requisite long term ABI compatibility; or rather, the only long-term ABI compatibility offered by FreeBSD is its (incomplete) implementation of the stable Linux ABI.

https://wiki.freebsd.org/Linuxulator

https://wiki.freebsd.org/VendorInformation

Major releases are cut from the main development trunk every 24 month ... No compatibility for API and ABI is guaranteed from one to the next major release, though an effort is made to make the upgrade process and source code changes as untroubled as possible.

Valve solves this problem in steam by shipping a stable runtime. Programs pick what stable runtime they want to target and because it is stable it does not shift around under them.

This works great for the sort of closed source programs Valve is targeting to market for. However as an end user it probably best to not think too hard about the implications of a stable runtime. Because in short "stable" implies "out of date" I think steam's newest runtime is Ubuntu 12.

Now like I said, as an end user this does not matter, your goal is to get the final program, you don't care about the runtime. and as a developer you may be slightly horrified, but in the end it is a relief to have something fixed you can target instead of the horrible shifting sand that is the normal Linux experience.

Current FreeBSD 14 is the latest branch to support x86 32-bit. The upcoming 15 won't support it.

https://www.freebsd.org/platforms/

> It may not look like it now, but I think Linux is not viable long-term as a desktop OS.

This is a ridiculous claim to make without giving any explanation or justification, especially when you go on to state that FreeBSD is the way to go.

> "FreeBSD also needs an OS-level graphics/window API just like Windows"

Do you realize how many thousands or tens of thousands or even hundreds of thousands of hours have been put into this effort over the years? Maybe once AI is at a point where we can just tell an agent to build it we'll be able to get that done, but as of right now this is Fantasyland.

> Linux is still trying to pretend like its the 60s where text was the only way to interact with a computer. Graphics is integral to all mobile and desktop computing and should be part of the operating system.

This is also a silly thing to say. At this point you can do almost anything with a GUI on modern Linux desktops. If you're getting at the underlying modularization of Linux distributions, that is a potentially interesting technical argument, but it's just an implementation detail. The average end user is just going to take a packaged Linux distribution and use that, and that has never been easier and has never worked better than it does now. Fedora in particular is remarkably well integrated and feels like a cohesive system.

I have absolutely nothing against FreeBSD, and in fact I really like FreeBSD. But as an end user system, it is absolutely nowhere usable for even many technical people with hardware that is less than 5 years old, let alone less technical people that just want to run a game.

FreeBSD was not chosen as the basis for those consoles because FreeBSD is superior, it was primarily chosen because it's license allowed them to keep everything super locked up and proprietary, whereas the GPL license on Linux would have forced them to release their changes, which obviously they do not want to do.

> FreeBSD also needs an OS-level graphics/window API just like Windows. Linux is still trying to pretend like its the 60s where text was the only way to interact with a computer.

You have no idea what you're talking about. Linux has DRM and Mesa. You can do hardware accelerated rendering in a TTY with next to no dependencies if you feel the need for whatever reason.

Unless your objection is the lack of a "blessed" display server or GUI toolkit or something? But I don't think anyone wants that sort of monoculture. Perhaps the systemd folks will take you up on it if you file a feature request?

What is it about Linux that leads you to believe that?

None of this is really related to the issue though. You could fix this by uprooting all of your software and switching to another OS... or with Bubblewrap and a Steam Flatpak. Containerization was always the future of UNIX-like gaming, even "native" Steam installations use it with pressure-vessel. Same goes for Linuxulator on FreeBSD.

FreeBSD is an excellent example of how much development you can expect from a license that allows full commercial exploitation of it's codebase. You will sooner see Sony sell $600 PS3s than you will have a graphical installer or hardware-accelerated Chromium. If Linux is running the race with a bum leg, BSD is drafting it's will in the hospital bed.

> There should probably be an effort to specifically make FreeBSD a gaming-ready OS

This will only happen for consoles as it is the case already, due to the driver issue.

It's one thing to create a specialized Linux distribution, it's another thing to try to support thousands of SKUs found in common desktops, roll your own modern WiFi stack, etc.