if you care at all about running linux fulltime instead of windows/macos, the work valve has been doing is nothing short of revolutionary. a few years ago, steam would have issues launching most of my games - even games advertised with linux support.
i persisted because i’m a weirdo, but many of my friends gave up because of how finicky things were.
i tried again recently, and was blown away by how much the user experience has improved. and not just proton - the whole steam application seems to be more self contained, faster, etc. it’s pretty clear that supporting the steam deck has “lifted all boats”.
i hesitate to even imagine what the landscape would look like if epic/blizzard owned valve’s assets.
a few years ago, steam would have issues launching most of my games - even games advertised with linux support.
Strangely it seems that Proton/Wine is a better long term runtime for Linux games than native executables. I have a bunch of older games that had native Linux builds but I ended up switching them to Proton because library changes or other bitrot has made the Linux executables difficult to run or the Linux port was low quality and performance or some other aspect of the game experience was better with Proton.
I actually think about this problem a lot, because IMO this is one of the biggest gaps in the Linux app development story - on Windows and macOS you can write a “regular” app (i.e. one that doesn’t muck around with deep system APIs) and then forget about it for years, and there’s a pretty decent chance it will still run fine. On Linux the only way to do this is by vendoring the world with e.g. Flatpak, but that’s no good because Flatpak runtimes get deprecated pretty fast so now you’re effectively not getting OS security updates. The problem is that the only(?) way to fix the bonkers pace the system-wide ABI/API changes (pick your preferred definition for this - say, the libraries that get installed by default on Ubuntu Desktop) is to convince a bunch of independent open source hackers to do a bunch of additional work to maintain backwards compatibility, which is obviously never going to happen.
Even though I’m convinced glibc symbol versioning results in a technically worse and honestly, aesthetically displeasing system, over the years I’ve come to appreciate it because it does actually solve this very real market dynamics problem. Even if it’s worse to have all the broken functions around, it’s pretty clear at this point that extreme backwards compatibility is an enormous selling feature, both to developers picking a platform to target and to users who want a rich app library. (This dynamic exists in other places, too.)
I actually think about this problem a lot, because IMO this is one of the biggest gaps in the Linux app development story - on Windows and macOS you can write a “regular” app (i.e. one that doesn’t muck around with deep system APIs) and then forget about it for years, and there’s a pretty decent chance it will still run fine.
Just for fun, as I was reading this, I went through the applications I have pinned on the taskbar on one of my work machines. Several of those are older than Fedora. At least one of them (Total Commander) is as older than… pretty much any Linux desktop environments.
And they’re not old as in unmaintained. If you want to run XMMS, the one true Linux music player today, you can do it (after having some fun compiling GTK 1.x and so on) but XMMS aside, its dependencies are basically a walk-in CVE exhibition with barely any Unicode support at this point. The apps I’m talking about are still maintained and developed, and one of the reasons why their developers can do that is that they don’t have to spend an average of several hours a month impedance-matching their code to whatever UI library they’re using.
Ahh, suddenly it all makes sense. Yeah, that’s a really impressive lifespan. Hard to imagine that on Linux, even with source available. God help you if you want to run a binary.
On Linux the only way to do this is by vendoring the world with e.g. Flatpak, but that’s no good because Flatpak runtimes get deprecated pretty fast so now you’re effectively not getting OS security updates.
To be fair to Flatpak, the “vendoring the world” part is essentially what Microsoft’s doing in the OS itself with technologies like WinSxS… they just provide long-term support for all the different ABI releases they’re bundling side-by-side.
If support windows could be lengthened, Flatpak would be the superior solution since you don’t need to have every runtime release installed just in case it’s needed for an application that either has no installer or has an installer that expects the dependencies to just be there.
Libs that aren’t technically Linux mostly, not even the GNU part. Often enough libcurl, SDL, or in more modern games often enough Mono and its dependencies.
Stuff target Linux as in “a bunch of system calls” is actually pretty stable, which is why SmartOS, FreeBSD, etc. are able to (for the most part) have modules allowing binary compatibility where you can choose which distro you want to run.
Pretty old games for Linux - old enough that Windows struggles with their Windows versions - when they target Linux tend to run surprisingly well, if they either packages libs themselves or you’re able to install, find, enforce these libraries and there versions. Sometimes it’s even enough to add symbolic links.
Really depends on where you draw the line. And you are absolutely right about the Linux runtimes that Steam installs of course.
Steam also takes advantage of this. Nearly all games run in a valve-provided “runtime environment” which is basically a set of libraries so that the game only really depends on the users kernel.
(Graphics drivers are the main exception here as they more or less need to come from the base system. So they get linked in and cause problems. I don’t see many crashes on games but when I do the stack tracked or abort messages often seem like problems with developers freeing a malloc pointer with the video driver free or vice versa which doesn’t always work)
You are absolutely right that there’s also a lot of non-backwards compatible stuff in userland.
But I did mean Linux Kernel ABI which offers no real guarantees of stability, which makes it different from e.g. FreeBSD or windows in this regard iiuc.
I believe things like FreeBSDs Linux compat layer just uses the same versions as CentOS for their definition of “Linux”? That’s also pretty much what i.e. manylinux does in the python world to widen binary compatibility on Linux.
Pretty old games for Linux - old enough that Windows struggles with their Windows versions
True but I wasn’t talking about Windows, which I don’t really know anymore, but about wine and proton which seem to handle older games often just as well in my experience?
I was talking about syscalls which is the main API that Linux (the kernel) provides.
CentOS, Debian, Ubuntu and others are the user land, mostly C libs and base utile that you can install if required. But say you tale a binary without any such dependencies (for example because it’s completely static) and you compile it for Linux you can just run it on these systems because of the compatibility the kernels provide. And that’s because Linux (the kernel) is very stable.
There are some outbursts of Linus when he complained about breaking changes.
The ABI of proton/wine is basically frozen in time
I remember in 2009 playing the original starcraft with a bunch of friends and it ran waaaay better on wine than any version of windows my friends were using.
What might make or break this is the trajectory of kernel-level anticheat. Games that use this simply do not work on Proton or SteamOS. They are currently in the minority but if this becomes established practice among game publishers (which I’d hate to see), it’ll be kind of bleak for Valve.
There’s been murmurs that kernel-level software for Windows is going to start getting kneecapped because of the CrowdStrike fiasco last year, and this would have implications for anticheat stuff.
This in conjunction with Valve being like “hey we have an install base of N millions of happy SteamOS users #dealwithit” is so far our best hope for not letting this practice take off.
The implication of the parent is that Valve gets to complete monopoly territory with control of the platform and the OS, then dictate the world revolves around them however they want.
fingers crossed. they somehow got apex legends to run on the deck, and i think that game uses a pretty sophisticated piece of malware anti-cheat system.
I strongly agree with this. I’ve been intermittently using Linux full-time (i.e. for stretches of 6 to 36 months, to the exclusion of most other things) as a desktop OS since the late 1990s.
Usually I wind up back on an Apple machine either because I need to work off battery frequently (it has been better than Linux and Windows for that very consistently for the past 20 years) or because I need to make iOS things. When I wind up on Windows for a while, it’s usually because I’ve been hired to make a Windows installer for some piece of software I’m working on, and I just can’t build a good installer without significant dogfooding.
I also used to use Windows because I needed some specific piece of software that wasn’t available on Linux. Since Valve started doing their Steam OS work and JetBrains started treating it as a first class platform, that doesn’t really happen to me anymore.
If Affinity would start treating Linux as a first class platform, it might never happen to me anymore. They’re the last thing I ever boot Windows for on the regular other than building Windows installers. And I can mostly get by with iPad for their stuff lately.
The Steam Deck has been really mind-blowing in terms of how well it works and how seamless it makes my Linux experience. Providing users easy access to a Linux desktop experience with terminal and having that work with the standard Steam Deck launcher has been a real masterclass in how to provide open access to end users while still preserving the plug and play element that people want from a console.
As someone with not a lot of time to play, the ability to easily load up a trainer for a single-player game and give myself unlimited random resource cannot be overstated. It means I still get to see the content without having to put in the 25 hours of running around and grinding random things to get there.
SteamOS is an operating system built by Valve. It features a seamless user experience optimized for gaming…
Seems a bit disingenuous to not mention that it’s based on Linux and is derived from Arch Linux. I.e. they did not build it single-handedly from scratch, and are benefiting from vast amounts of volunteer time to be able to build their distribution on top of it. They do mention it’s Linux based later, but only as part of the “Can this run every game on Steam?”.
I didn’t say it was. I was suggesting they give some credit to all the people’s effort it was built upon instead of claiming it is “an operating system built by Valve”.
Sure, that would be nice, but it’s not in any way required, nor should it be expected by the contributors to the Linux kernel or the Arch distro.
Valve has done some non-trivial amount of work to get Proton/SteamOS working on the hardware they’ve chosen. I think they deserve to take some credit, especially in a press release.
Messaging can be tailored to different audiences. People in the know know SteamOS is based on Linux.
This is the same argument as “Linux” vs “GNU/Linux”. Which is needlessly cumbersome, selective, and subjective. There’s no reasonable way to “credit all the people’s effort” here. Leave it to the documentation.
I don’t think I completely agree. This isn’t targeted at Linux users and the fact that they only need to mention Linux in one small section is sort of the beauty of their work. They are really putting polish on to make it so that the average user doesn’t even need to know.
It’s not like they are hiding it, or freeloading. Valve has put huge amounts of effort both into their distribution and upstream and has been very open about it.
Maybe in an ideal world they would have tagged some extra note about some of the projects they build on I find it hard to get mad at them for not going out of their way to say this in every press release they make.
If every consumer device running some weird bespoke Arch or Debian or whatever were to advertise “Linux (TM) Inside” then I don’t think it would be a net win for the community, in terms of public relations.
Sometimes just being quietly good at something is better publicity than piggybacking on existing brand reputation.
Seems a bit disingenuous to not mention that it’s based on Linux
Can be said about Android and all its variations as well. But then one should probably mention a lot more than just a kernel. No, I don’t mean GNU/Linux or something like that, but simply that it’s also based on a lot of software that only tangentially has anything to do with Linux, other than (also) running on it.
I would note if you’re running an Nvidia card in your desktop, you’re going to miss a lot of features going to Linux. Things will work, but graphically intensive games will not work anywhere near as well. DLSS 4 looks like it’s going to be great. I can’t find any evidence DLSS 3 is supported on Linux.
FYI, DLSS 3 frame generation landed in Proton Experimental a couple months ago. Although it seems like it’s not perfect for every game yet; e.g. Diablo IV works great with frame generation, but Starfield doesn’t. Like most Proton things I’m sure with time more of the bugs will get ironed out.
It’s true on Linux you’ll probably lag the nicest Nvidia rendering perf enhancements by 1-2 years, but that’s a very far cry from the past where you couldn’t play the games at all. I switched full time a few months ago, and in comparison to the overall experience on Windows, Linux is just a huge breath of fresh air. If all you use your desktop for is to play games, Windows is still probably better… But if you use your desktop both for general-purpose computing stuff, and play games too, IMO Linux is just a lot nicer.
SteamOS currently officially ships on Steam Deck and will soon ship with certain Legion Go S models. Valve is working on SteamOS support for more devices in the future.
This is great news, although not exactly surprising. I expect that they will continue to carefully limit the set of officially supported hardware, but as that expands so will the larger set of practically supported hardware.
Meanwhile, there’s a noncommercial project https://chimeraos.org/ for those willing and able to get their hands a little dirtier. I don’t pay a whole lot of attention to this space, but Chimera seems healthy. There are some other game-centric distros I’m even less familiar with too. It’s good to have options!
if you care at all about running linux fulltime instead of windows/macos, the work valve has been doing is nothing short of revolutionary. a few years ago, steam would have issues launching most of my games - even games advertised with linux support.
i persisted because i’m a weirdo, but many of my friends gave up because of how finicky things were.
i tried again recently, and was blown away by how much the user experience has improved. and not just proton - the whole steam application seems to be more self contained, faster, etc. it’s pretty clear that supporting the steam deck has “lifted all boats”.
i hesitate to even imagine what the landscape would look like if epic/blizzard owned valve’s assets.
Strangely it seems that Proton/Wine is a better long term runtime for Linux games than native executables. I have a bunch of older games that had native Linux builds but I ended up switching them to Proton because library changes or other bitrot has made the Linux executables difficult to run or the Linux port was low quality and performance or some other aspect of the game experience was better with Proton.
I don’t think that’s too strange: The ABI of proton/wine is basically frozen in time iiu, while Linux is a moving target.
As a friend likes to say: Linux userspace is a waste of a perfectly good stable ABI.
I actually think about this problem a lot, because IMO this is one of the biggest gaps in the Linux app development story - on Windows and macOS you can write a “regular” app (i.e. one that doesn’t muck around with deep system APIs) and then forget about it for years, and there’s a pretty decent chance it will still run fine. On Linux the only way to do this is by vendoring the world with e.g. Flatpak, but that’s no good because Flatpak runtimes get deprecated pretty fast so now you’re effectively not getting OS security updates. The problem is that the only(?) way to fix the bonkers pace the system-wide ABI/API changes (pick your preferred definition for this - say, the libraries that get installed by default on Ubuntu Desktop) is to convince a bunch of independent open source hackers to do a bunch of additional work to maintain backwards compatibility, which is obviously never going to happen.
Even though I’m convinced glibc symbol versioning results in a technically worse and honestly, aesthetically displeasing system, over the years I’ve come to appreciate it because it does actually solve this very real market dynamics problem. Even if it’s worse to have all the broken functions around, it’s pretty clear at this point that extreme backwards compatibility is an enormous selling feature, both to developers picking a platform to target and to users who want a rich app library. (This dynamic exists in other places, too.)
Just for fun, as I was reading this, I went through the applications I have pinned on the taskbar on one of my work machines. Several of those are older than Fedora. At least one of them (Total Commander) is as older than… pretty much any Linux desktop environments.
And they’re not old as in unmaintained. If you want to run XMMS, the one true Linux music player today, you can do it (after having some fun compiling GTK 1.x and so on) but XMMS aside, its dependencies are basically a walk-in CVE exhibition with barely any Unicode support at this point. The apps I’m talking about are still maintained and developed, and one of the reasons why their developers can do that is that they don’t have to spend an average of several hours a month impedance-matching their code to whatever UI library they’re using.
Not quite following, sorry - these are Windows apps? Or Linux apps?
Windows apps. Total Commander’s last release was a few days ago, I think, and its first release was in 1993. It dates back to the 3.x era.
Ahh, suddenly it all makes sense. Yeah, that’s a really impressive lifespan. Hard to imagine that on Linux, even with source available. God help you if you want to run a binary.
To be fair to Flatpak, the “vendoring the world” part is essentially what Microsoft’s doing in the OS itself with technologies like WinSxS… they just provide long-term support for all the different ABI releases they’re bundling side-by-side.
If support windows could be lengthened, Flatpak would be the superior solution since you don’t need to have every runtime release installed just in case it’s needed for an application that either has no installer or has an installer that expects the dependencies to just be there.
(not disagreeing per se, but adding)
Libs that aren’t technically Linux mostly, not even the GNU part. Often enough libcurl, SDL, or in more modern games often enough Mono and its dependencies.
Stuff target Linux as in “a bunch of system calls” is actually pretty stable, which is why SmartOS, FreeBSD, etc. are able to (for the most part) have modules allowing binary compatibility where you can choose which distro you want to run.
Pretty old games for Linux - old enough that Windows struggles with their Windows versions - when they target Linux tend to run surprisingly well, if they either packages libs themselves or you’re able to install, find, enforce these libraries and there versions. Sometimes it’s even enough to add symbolic links.
Really depends on where you draw the line. And you are absolutely right about the Linux runtimes that Steam installs of course.
Steam also takes advantage of this. Nearly all games run in a valve-provided “runtime environment” which is basically a set of libraries so that the game only really depends on the users kernel.
(Graphics drivers are the main exception here as they more or less need to come from the base system. So they get linked in and cause problems. I don’t see many crashes on games but when I do the stack tracked or abort messages often seem like problems with developers freeing a malloc pointer with the video driver free or vice versa which doesn’t always work)
A set of libraries being pretty much a whole Ubuntu system with many.gaming related things on top.
You are absolutely right that there’s also a lot of non-backwards compatible stuff in userland. But I did mean Linux Kernel ABI which offers no real guarantees of stability, which makes it different from e.g. FreeBSD or windows in this regard iiuc.
I believe things like FreeBSDs Linux compat layer just uses the same versions as CentOS for their definition of “Linux”? That’s also pretty much what i.e. manylinux does in the python world to widen binary compatibility on Linux.
True but I wasn’t talking about Windows, which I don’t really know anymore, but about wine and proton which seem to handle older games often just as well in my experience?
Linux syscalls is the stable API. BSDs stabilize on the C-library level.
FreeBSD doesn’t ever actually change released syscalls – they are stable, even though they aren’t public.
I was talking about syscalls which is the main API that Linux (the kernel) provides.
CentOS, Debian, Ubuntu and others are the user land, mostly C libs and base utile that you can install if required. But say you tale a binary without any such dependencies (for example because it’s completely static) and you compile it for Linux you can just run it on these systems because of the compatibility the kernels provide. And that’s because Linux (the kernel) is very stable.
There are some outbursts of Linus when he complained about breaking changes.
I remember in 2009 playing the original starcraft with a bunch of friends and it ran waaaay better on wine than any version of windows my friends were using.
I’ve found that a bunch of Linux-native games that used to be broken now work again, after Valve implemented https://www.gamingonlinux.com/2024/10/valve-makes-a-big-improvement-for-native-linux-games-in-a-steam-beta-update/ . Still, having the choice between Proton and Linux native is really nice.
It is also better long term runtime for ancient Windows games, in my experience.
What might make or break this is the trajectory of kernel-level anticheat. Games that use this simply do not work on Proton or SteamOS. They are currently in the minority but if this becomes established practice among game publishers (which I’d hate to see), it’ll be kind of bleak for Valve.
There’s been murmurs that kernel-level software for Windows is going to start getting kneecapped because of the CrowdStrike fiasco last year, and this would have implications for anticheat stuff.
This in conjunction with Valve being like “hey we have an install base of N millions of happy SteamOS users #dealwithit” is so far our best hope for not letting this practice take off.
It’s not great that a monopoly gets to dictate software development practices for an entire industry.
They don’t. Many games don’t work on the Steam Deck. But if Valve and Microsoft disallow kernel level anti-cheat, that’d probably stop it.
The implication of the parent is that Valve gets to complete monopoly territory with control of the platform and the OS, then dictate the world revolves around them however they want.
The key word is “conjunction”.
And uh yeah? Valve decides how their OS works, just like how Microsoft decides how Windows works, and Apple decides how macOS works…
fingers crossed. they somehow got apex legends to run on the deck, and i think that game uses a pretty sophisticated
piece of malwareanti-cheat system.Realistically I doubt either of them would have the foresight to execute on a long term plan like valve has
I strongly agree with this. I’ve been intermittently using Linux full-time (i.e. for stretches of 6 to 36 months, to the exclusion of most other things) as a desktop OS since the late 1990s.
Usually I wind up back on an Apple machine either because I need to work off battery frequently (it has been better than Linux and Windows for that very consistently for the past 20 years) or because I need to make iOS things. When I wind up on Windows for a while, it’s usually because I’ve been hired to make a Windows installer for some piece of software I’m working on, and I just can’t build a good installer without significant dogfooding.
I also used to use Windows because I needed some specific piece of software that wasn’t available on Linux. Since Valve started doing their Steam OS work and JetBrains started treating it as a first class platform, that doesn’t really happen to me anymore.
If Affinity would start treating Linux as a first class platform, it might never happen to me anymore. They’re the last thing I ever boot Windows for on the regular other than building Windows installers. And I can mostly get by with iPad for their stuff lately.
The Steam Deck has been really mind-blowing in terms of how well it works and how seamless it makes my Linux experience. Providing users easy access to a Linux desktop experience with terminal and having that work with the standard Steam Deck launcher has been a real masterclass in how to provide open access to end users while still preserving the plug and play element that people want from a console.
As someone with not a lot of time to play, the ability to easily load up a trainer for a single-player game and give myself unlimited random resource cannot be overstated. It means I still get to see the content without having to put in the 25 hours of running around and grinding random things to get there.
Seems a bit disingenuous to not mention that it’s based on Linux and is derived from Arch Linux. I.e. they did not build it single-handedly from scratch, and are benefiting from vast amounts of volunteer time to be able to build their distribution on top of it. They do mention it’s Linux based later, but only as part of the “Can this run every game on Steam?”.
It’s a press release, not a GPL compliance document.
I didn’t say it was. I was suggesting they give some credit to all the people’s effort it was built upon instead of claiming it is “an operating system built by Valve”.
Sure, that would be nice, but it’s not in any way required, nor should it be expected by the contributors to the Linux kernel or the Arch distro.
Valve has done some non-trivial amount of work to get Proton/SteamOS working on the hardware they’ve chosen. I think they deserve to take some credit, especially in a press release.
Messaging can be tailored to different audiences. People in the know know SteamOS is based on Linux.
I don’t think this is needed by the press-release.
I do think they could update the
steamospage though.https://store.steampowered.com/steamos
This is the same argument as “Linux” vs “GNU/Linux”. Which is needlessly cumbersome, selective, and subjective. There’s no reasonable way to “credit all the people’s effort” here. Leave it to the documentation.
about what you’d expect, no?
I don’t think I completely agree. This isn’t targeted at Linux users and the fact that they only need to mention Linux in one small section is sort of the beauty of their work. They are really putting polish on to make it so that the average user doesn’t even need to know.
It’s not like they are hiding it, or freeloading. Valve has put huge amounts of effort both into their distribution and upstream and has been very open about it.
Maybe in an ideal world they would have tagged some extra note about some of the projects they build on I find it hard to get mad at them for not going out of their way to say this in every press release they make.
If every consumer device running some weird bespoke Arch or Debian or whatever were to advertise “Linux (TM) Inside” then I don’t think it would be a net win for the community, in terms of public relations.
Sometimes just being quietly good at something is better publicity than piggybacking on existing brand reputation.
Can be said about Android and all its variations as well. But then one should probably mention a lot more than just a kernel. No, I don’t mean GNU/Linux or something like that, but simply that it’s also based on a lot of software that only tangentially has anything to do with Linux, other than (also) running on it.
Actually they did mention it on the specifications of Steam Deck in Software section, https://store.steampowered.com/steamdeck/
I want to install this on my desktop when Windows 10 goes out of support. I only use my desktop for Firefox, Thunderbird and Steam these days…
There are already good options for that. Have you checked out Bazzite OS?
https://bazzite.gg/
Why wait? Do you have a specific game that doesn’t work under proton?
I would note if you’re running an Nvidia card in your desktop, you’re going to miss a lot of features going to Linux. Things will work, but graphically intensive games will not work anywhere near as well. DLSS 4 looks like it’s going to be great. I can’t find any evidence DLSS 3 is supported on Linux.
FYI, DLSS 3 frame generation landed in Proton Experimental a couple months ago. Although it seems like it’s not perfect for every game yet; e.g. Diablo IV works great with frame generation, but Starfield doesn’t. Like most Proton things I’m sure with time more of the bugs will get ironed out.
It’s true on Linux you’ll probably lag the nicest Nvidia rendering perf enhancements by 1-2 years, but that’s a very far cry from the past where you couldn’t play the games at all. I switched full time a few months ago, and in comparison to the overall experience on Windows, Linux is just a huge breath of fresh air. If all you use your desktop for is to play games, Windows is still probably better… But if you use your desktop both for general-purpose computing stuff, and play games too, IMO Linux is just a lot nicer.
Which is why you enable WSL2 and have the best of both worlds.
Obviously a matter of taste, but I’d struggle to describe having to use the windows desktop environment as “best of both worlds”.
This is great news, although not exactly surprising. I expect that they will continue to carefully limit the set of officially supported hardware, but as that expands so will the larger set of practically supported hardware.
Meanwhile, there’s a noncommercial project https://chimeraos.org/ for those willing and able to get their hands a little dirtier. I don’t pay a whole lot of attention to this space, but Chimera seems healthy. There are some other game-centric distros I’m even less familiar with too. It’s good to have options!