It may not look like it now, but I think Linux is not viable long-term as a desktop OS. There should probably be an effort to specifically make FreeBSD a gaming-ready OS. We know it can be done since Sony already did it for PlayStation (but that's proprietary).
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. Graphics is integral to all mobile and desktop computing and should be part of the operating system.
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.
> It may not look like it now, but I think Linux is not viable long-term as a desktop OS.
I'm using Linux on the desktop since the early Slackware days, in the nineties.
The one thing that changed since then is that Linux now powers 500 of the world's Top 500 supercomputers and that's it. Wait, no, I forgot... It powers as well as billions if not tens of billions of phones, routers, servers, TVs, etc. It's in space, in cars, at sea, underground, etc.
It's typically also powering OCI containers, containers host, VMs, Kubernetes (even Talos is still Linux), etc.
Now of course the one thing that hasn't changed is the "This year is the year of Linux on the desktop" joke. But somehow, in the face of billions of devices running Linux, that joke doesn't have the same punch to it anymore.
What makes you think that an OS that basically now powers the entire world isn't suitable long term as a desktop OS?
It's become so easy to use Linux as a desktop OS that even my wife is on Debian: not exactly a "newbie friendly desktop distro".
Is the whole Gnome/KDE/Xorg/Wayland a mess? Sure is. And yet Linux is definitely here to stay.
Linux shall still exist, even on the desktop, long after I'm gone.
The claim seems quite self explanatory. As someone who isn't against my WiFi router or NAS matching my desktop, I don't understand why graphics as a fundamental element of the OS is a plus. I also think Linux not being as broken as Windows was probably a reason WSL's development path wasn't the same disaster Microsoft usually has.
> 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?
It may not look like it, but I say the opposite is true and FreeBSD is unviable for the desktop. I skip to provide even a scintilla of an thought why that would be tho.
See how well discourse works when I make a bold claim and leave filling out the blanks as an exercise to the reader?
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.
Is there any reason games don’t just ship everything they need? If the use is downloading 50gb of media assets, what’s another 20mb to ship the libraries too. And that way it’ll be extremely stable.
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.
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.
Making a custom OS for a gaming console is relatively easy compared to an actual, full desktop. You just need to allow games to access rendering directly (DRM or equivalent) and you make an "app" for your store that'll also launch the games.
FreeBSD was chosen as the kernel so that Sony could keep it locked down and not share the source, no other reason.
Nothing is stopping apps from shipping with 32 bit libraries if they need them. This isn't like what happened with ARM where processors dropped support for 32 bit code.
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.
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
Seems like an extreme response… other distros still exist. Plus they can still ship the 32bit binaries themselves. Fedora isn’t preventing you from using 32bit libs- fedora is just saying “hey we aren’t going to invest energy in maintaining something just 5% of our users use.”
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
It's absolutely this. They have the ability to put these into their build pipelines and include them. Or just grab the latest 32bit versions and just use those.
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.
Also their days are counted as SteamOS is now going to other handheld devices apart from the Steam Deck so... Not sure their project will still exist one year down the road.
you (fedora that is) build the libraries needed by 32-bit application. you stop building everything else, but you keep multilib support. that's what this proposal got wrong. it should have been only about stopping to build the 10.000 packages that nobody needs for 32-bit support.
if i understand this correctly, bazzite is like SteamOS but based on fedora. it needs 32-bit support to run wine and steam.
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.
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?
currently only kernel and installers for 32-bit are dropped, but all packages are still built for 32-bit. why? that too doesn't make much sense either. are they still supporting running on 32-bit systems with an old or custom kernel? what for?
so that seems to be the problem then. somehow fedora is still supporting running on 32-bit systems. well, yes. do change that. but that doesn't mean that multilib support needs to be dropped. is there a problem to limit the build of 32-bit packages to only those that are needed?
1. The article is clickbait, leaving out important but complicated context of what sort of process is happening. If you want to understand what’s actually going on, watch this instead of getting alarmed at the article title: https://m.youtube.com/watch?v=XgabGSI82M0
2. These kind of change proposals are just that. Proposals only, by whoever wants to make one. Fedora is not about to suddenly drop 32bit support. Proposals are for discussion and consideration of how changes would affect things, they are not acceptance of the change or even a commitment to do so.
3. The comment on shutting down from the Bazzite founder is about what would happen if the proposal were accepted right now. Which isn’t happening. Outlining the consequences of a proposal is exactly what needs to happen. Dropping 32bit support would be catastrophic to multiple projects. But it’s not happening right now, and Bazzite is not about to shut down.
4. Things on both Fedora and Bazzite’s side are taking place such that removing 32bit support is reasonable and doesn’t break everything. This will take some time.
5. The proposal was badly worded, and is being redone.
but these points were obvious from the start. ubuntu went through that before and did it right the first time. like they actually talked to valve about it. this proposal was not thought through and should not have been made in this form in the first place. i am not involved with these decisions (but i use fedora and would be affected) but i would get annoyed if people kept making proposals that they don't think through. therefore i think the response is justified, because how otherwise do you stop bad proposals?
41 comments
[ 0.27 ms ] story [ 71.7 ms ] threadFreeBSD 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. Graphics is integral to all mobile and desktop computing and should be part of the operating system.
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.
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.
I'm using Linux on the desktop since the early Slackware days, in the nineties.
The one thing that changed since then is that Linux now powers 500 of the world's Top 500 supercomputers and that's it. Wait, no, I forgot... It powers as well as billions if not tens of billions of phones, routers, servers, TVs, etc. It's in space, in cars, at sea, underground, etc.
It's typically also powering OCI containers, containers host, VMs, Kubernetes (even Talos is still Linux), etc.
Now of course the one thing that hasn't changed is the "This year is the year of Linux on the desktop" joke. But somehow, in the face of billions of devices running Linux, that joke doesn't have the same punch to it anymore.
What makes you think that an OS that basically now powers the entire world isn't suitable long term as a desktop OS?
It's become so easy to use Linux as a desktop OS that even my wife is on Debian: not exactly a "newbie friendly desktop distro".
Is the whole Gnome/KDE/Xorg/Wayland a mess? Sure is. And yet Linux is definitely here to stay.
Linux shall still exist, even on the desktop, long after I'm gone.
Linux is perfectly viable on the desktop.
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.
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?
See how well discourse works when I make a bold claim and leave filling out the blanks as an exercise to the reader?
https://www.freebsd.org/platforms/
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.
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.
FreeBSD was chosen as the kernel so that Sony could keep it locked down and not share the source, no other reason.
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.
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
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.
Title should really be: Bazzite maintainers don't want to make a slight effort to maintain stuff.
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.
> 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.
Bazzite seems to be just a big Dockerfile built on top of bootc and bootc image builder right?
https://github.com/ublue-os/bazzite/blob/main/Containerfile
https://discussion.fedoraproject.org/t/f44-change-proposal-d...
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://ostechnix.com/fedora-32-bit-i686-support-withdrawal-...
currently only kernel and installers for 32-bit are dropped, but all packages are still built for 32-bit. why? that too doesn't make much sense either. are they still supporting running on 32-bit systems with an old or custom kernel? what for?
so that seems to be the problem then. somehow fedora is still supporting running on 32-bit systems. well, yes. do change that. but that doesn't mean that multilib support needs to be dropped. is there a problem to limit the build of 32-bit packages to only those that are needed?
2. These kind of change proposals are just that. Proposals only, by whoever wants to make one. Fedora is not about to suddenly drop 32bit support. Proposals are for discussion and consideration of how changes would affect things, they are not acceptance of the change or even a commitment to do so.
3. The comment on shutting down from the Bazzite founder is about what would happen if the proposal were accepted right now. Which isn’t happening. Outlining the consequences of a proposal is exactly what needs to happen. Dropping 32bit support would be catastrophic to multiple projects. But it’s not happening right now, and Bazzite is not about to shut down.
4. Things on both Fedora and Bazzite’s side are taking place such that removing 32bit support is reasonable and doesn’t break everything. This will take some time.
5. The proposal was badly worded, and is being redone.
For fucks sake.