i find it hard to believe that fedora will drop 32-bit support without ensuring that wine and steam will continue to work. why would they do that? that would not make sense at all.
but there is a lot of backslash on the change discussion: https://discussion.fedoraproject.org/t/f44-change-proposal-d... so i doubt this will happen until those issues are resolved.
but i am quite confused:
the example given, that eg cpython might drop 32-bit support, should not affect supporting 32-bit for applications that need it, like wine and steam.
i thought that an application that doesn't support 32-bit mode would only prevent it from running on 32-bit machines or running on an OS in 32-bit mode on 64-bit machines, which was dropped 5 years ago. so where is the problem here?
https://discussion.fedoraproject.org/t/f44-change-proposal-d...
Steam runs all games in containers anyway: https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/b...
Title should really be: Bazzite maintainers don't want to make a slight effort to maintain stuff.
> If this shipped today, to accomplish this we’d need to:
> 1: Build all of the packages Steam needs in a copr or similar
> 2: Build a custom version of Proton with experimental Wow64 features turned on
> 3: Instruct all users to manually change their steam settings to use that proton version because the ones Valve provides don’t have that.
> 4: Tell anyone using OBS game capture that they’re just gonna have to give up.
It's work for them surely. But it's not the end of the world.
I think we have all solved much harder problems as software engineers.
libGL/libVK for OpenGL and Vulkan support is a big one, you need that to be fitting the exact version of your kernel Nvidia driver if you are using Nvidia cards. Of course all other vendors play nice with Open Source and Mesa libs, but especially for gaming, a lot of people unfortunately still buy Nvidia. Games cannot just ship their own 32bit libGL for reasons of license and versioning.
On Windows, this is like telling game developers that they need to ship all the graphics drivers for their games. Let's skip the hassle for the developers' side. For the users, not only would that be a situation where you could no longer update your own drivers to fix problems, it would be a compatibility nightmare and likely introduce new problems because of interactions with the system drivers and kernel level.
1. They need to also keep the multi arch support enabled in their kernels 2. Apps such as games and steam depend on Mesa, and you don't really want to ship Mesa
A good compromise would be for Valve to support Flatpak for Steam, but if they can't be bothered to build a 64 bit Steam they sure don't want to bother with that
It seems like these developers have tunnel vision. It's like when pulseaudio came about and the whole focus was streaming Bluetooth audio. It took over the system audio and broke everything else (games, coincidentally). They know this will break some things they don't personally use, and they don't care.
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.
Only doing 32bit and not doing amd64/x86_64 is also leaving a lot of performance on the table:
x86 traditionally has very few registers to work with, amd64 gives you quite a few more general purpose registers, so your hand-fiddled assembler will be faster, and if you use compiled code, your compiler will have an easier time with optimizations, faster function calls due to more register arguments, less register-to-memory spills and more execution station parallelism.
Memory use is also an important point, your 32bit application will be limited to at best 4GB per process, usually more like 2GB (due to the kernel/user boundary at 2/2GB, absent weird tricks). With games currently being multiple times that size, you have to swap out assets and load new ones very frequently, which is why loadpoints are getting more common and level design has to add more corridors and doors to support those load points and segment level data into 2GB chunks.
And the newer processor features, especially SIMD stuff like AVX and SSE work better with 64bit registers, if they work at all. Many support libraries that can utilize SIMD only do so in 64bit versions. Some features aren't even available if the hardware is in 32bit mode. And compilers can do automatic SIMD conversions, but those work far better (if they work at all) in x86_64 mode because of the insufficient number of registers in 32bit mode for copying around and splitting up stuff from a SIMD register.
I think the real reason that especially game developers are opposed to amd64 is that they used to be stuck on 32bit on Windows for a long time and now have to be dragged into the future by force ;)
The steam client should be upgraded, though. I understand it has to do with their ancient web view library not doing 64-bit, so they would have to change it and possibly mess up some of the layouts and overlays. But they went ahead and changed it on macOS anyway, so you know it can be done.
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.
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.
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.