Linux surpasses the Mac among Steam gamers

I guess it really depends on what you expect out of a "user". I think servers and Android count but I think SteamOS is a bit tricky, because it's relying on a compatibility layers running Windows to run most games. This may not matter to the end user, but it isn't quite the developer revelation many imagine where suddenly tons of games and apps have a proper linux port.

Is that any different developer tools not supporting Windows and Windows users using WSL? We would still classify these as Windows users despite the compatibility layer. Ultimately compatibility layers are good because they reduce developer workload so that developers can focus on what really matters.

The article doesn't mention it, but you can flip SteamOS to Desktop Mode where it's just a normal Arch Linux desktop.

So it is proper Linux, as GP comment implies. Yes it's running games in Windows compatibility layers, but it is also a complete Linux system itself, with desktop. Definitely counts as running Linux.

And a decent chunk of those games are running on the Unity or Unreal runtimes. Do they count as "running on Windows"? Where are we drawing the line here?

>Is that any different developer tools not supporting Windows and Windows users using WSL?

excuse my ignorance, but are there any major developer tools that don't support Windows? I can only imagine some internal enterprise tooling doing this.

>Ultimately compatibility layers are good because they reduce developer workload so that developers can focus on what really matters

I don't mind them as a concept, but I personally want as few points of failure between me and my software as possible. Some software is already either overly bloated or buggy (or both) as is without wondering if there's now compatibility layer issues on top of it.

>And a decent chunk of those games are running on the Unity or Unreal runtimes. Do they count as "running on Windows"?

if the developer released it as a windows build but is being played though a compatibility layer, yes. Unity and Unreal both support deploying Linux builds, but it doesn't mean making a proper Linux port is as easy as pressing the "Linux" button.

>Where are we drawing the line here?

I don't personally care for what counts or not. I just personally wish for more native support.

I think there's a point to be made when one OS can actually run programs meant for another. I think this makes it even more valuable, not less.

> excuse my ignorance, but are there any major developer tools that don't support Windows? I can only imagine some internal enterprise tooling doing this.

At all, or well? Because git works on Windows, but it's meaningfully slow as a result of NT and unix having very different ideas about how filesystems should work.

>I think this makes it even more valuable, not less.

put it this way: I have the expenses and know how to simply have 2 native platforms if I need it. If I need to emulate something but don't feel like spinning a second boot, it's usually for a few niche programs I need very occasionally. Otherwise, I can just get that OS ready.

That's how I see the Steam Deck. I simply have a portable windows machine that has Steam on it, so I don't see the incremental value of having these games run through Proton while having a linux machine. Because I have "running windows games" covered. If it was running Linux games natively, I may in fact buy it simply to help say to developers that I want more native games on Linux. But if devs just keep focusing on Windows, I have that set already.

And To be honest I'm not a huge fan of the form factor nor screen to begin with, so it'd be a bigger compromise choosing to play on a Steam Deck than if I could choose other machines.

Same. I don't care about Proton compatibility for games and only look for native support. Something that works on Proton today might stop working tomorrow if the developer only cares about Windows. Even for games that do work on it, they have all sorts of bugs and glitches that may not be game-breaking but which I'm not going to put up with like a second-class citizen.

> but it doesn't mean making a proper Linux port is as easy as pressing the "Linux" button.

Depends ... It can be that easy, sometimes. I was maintaining a huge Unity based VR setup the last years which had both Linux and Windows PCs (mostly for legacy reasons). Building for both platforms was done from the same bash script with the only difference being the platform identifier.

Tbf that was a very standalone application that did not interact with the OS a lot, but otoh I would assume that a lot of games are like that.

As far as I'm concerned, this misses the point on a couple levels. One is that the focus here is very intentionally on desktop Linux. Servers and Android absolutely do not count.

The other is that the notion of a 'proper port' here doesn't really matter. Source ports are rare and don't necessarily turn out better than compatibility layer ports. If the goal is to have playable games, or for Linux to become usable as a desktop OS for gamers, what kinds of ports we get doesn't come into it.

That said, source ports are nice and it'd be nice if they were common some day. It would also better secure desktop Linux's position here.

> excuse my ignorance, but are there any major developer tools that don't support Windows?

Semgrep is one that I use at work. Nix is another. Docker¹ is a third. Many terminal emulators support multiple operating systems, but not Windows.

Windows support also often lags for new programming languages. Golang didn't run on Windows at first. Crystal is only now starting to have full-fledged Windows support. Plus there are many tools that do run on Windows but work poorly or are extremely slow or require tons of compatibility shims, like Git and Emacs.

A lot of dev tools are Unix-first. You just probably use only a few of them if you work at a Microsoft shop.

--

Not Docker itself at this point but 99.9% of all Docker containers that anyone actually uses.

> But if devs just keep focusing on Windows, I have that set already.

It is what it is. I would say they will never focus on Linux but it's not so clear anymore. A lot of things are changing fast.

> And To be honest I'm not a huge fan of the form factor nor screen to begin with, so it'd be a bigger compromise choosing to play on a Steam Deck than if I could choose other machines.

Luckily even better handhelds seem to be coming out. Asus ROG Ally (windows) is worth a look, as is Ayn Odin 2 (android..Now we have this too as a potential gaming platform to consider. Maybe not today, but who knows.). I recommend ETA PRIME's youtube channel to keep an eye on these things.

https://www.youtube.com/@ETAPRIME

> I just personally wish for more native support.

As someone who has played a lot of games with native linux "support", I want less of it.

In nearly every instance of these native ports, switching to using the windows version via Proton was a better experience, either because the Linux version was outdated, unmaintained and buggy, or it simply performed better.

Annoyingly, as far as I can tell, Steam these days doesn't make a distinction between native ports and Proton games so it's hard to tell if I'm getting served the unloved child version until something goes drastically wrong and I have to start messing around with it.

Many (maybe even most) native game ports on Linux use a WINE-like compatibility layer. So-called 'source ports' are rare.

Any kind of port can be of high or low quality, though.

>The article doesn't mention it, but you can flip SteamOS to Desktop Mode where it's just a normal Arch Linux desktop.

this is fascinating..

Is it possible to install Arch linux and add the SteamOS layer and cut over and back again as desired?

You can install any OS on it, and people have successfully recreated SteamOS behaviour on other distros (for example, NixOS).

You can also just go to the normal KDE Plasma environment from the steam menu and use it like normal Linux - or even install let's say emulators from Arch repos and add them to Steam then run them from SteamOS interface.

Many Unix-based developers have no idea how Windows works, especially the hardcore free software folks who refuse to use Windows out of principle.

I personally have not owned a Windows computer in the last 10 years, and even then I only used it for gaming and not for development. If my code works on Windows without a compatibility layer that’s a complete miracle.

Many Windows developers similarly have little idea how Unix works and stay in the Windows development ecosystem.

Ultimately you can only fit so much in your head and I don’t have room for Windows to live in mine too. I’m sure a lot of Windows devs feel the same way about Unix.

>The other is that the notion of a 'proper port' here doesn't really matter. Source ports are rare and don't necessarily turn out better than compatibility layer ports.

It does to me, but I'm not a stranger to being part of an underrepresented niche. I have windows machines to make games playable if I want to play a windows platform game.

I simply prefer control where possible, and leaving something to a compatibility layers makes me rely on two separate platforms being maintained and contributed to (and/or not enshittified) in order to not be SO, be it now or in a future. 3 if you count Steam's contributions on Proton and choosing to carry whatever game you want to play. There can still be bugs in the game proper, but a native port eliminated points of failure for me to investigate.

So? Even Windows itself has adopted some of those exact same compatibility layers to make games run properly. The Intel Arc driver on Windows uses DXVK to translate from DirectX 9 to Vulkan - which was originally developed by Valve for use in the Steam Deck.

SteamOS solved the chicken-and-egg problem and is demonstrating that Linux-based gaming is viable. 2% isn't a massive number, but it might just be enough for a game developer to justify compiling a Linux-native version too.

>either because the Linux version was outdated, unmaintained and buggy, or it simply performed better.

Sure, I can see that. My solution to that one day will hopefully be to make sure devs can keep their linux platforms updated, not give up and go around it with a windows build.

But Proton discourages that, not encourages. As you said, Steam doesn't want you to know what build you are playing, and if the audience doesn't know, then the devs won't care either.

>Even Windows itself has adopted some of those exact same compatibility layers to make games run properly.

sure, Microsoft used a compatability layer to translate microsoft's API to an API Microsoft also maintains to an open source API. As far as I see it, it doesn't introduce any further points of failure that I don't already have by relying on Microsoft.

an open source compatibility layer relying on Microsoft's API... It unfortunately isn't a communicative property here.

>SteamOS solved the chicken-and-egg problem and is demonstrating that Linux-based gaming is viable.

Sure, just not in a way I feel is productive for the long term. But again, to each their own.

>2% isn't a massive number, but it might just be enough for a game developer to justify compiling a Linux-native version too.

In my mind, it reduces the need because why not just rely on Valve to do the hard "porting" work for you? It's a win-win for a dev who simply wants to launch a game. I hope your vision is the correct one, but I'm not so optimistic.

Not a personal win for someone who wants less leverage from large corporations.

Besides SteamOS, this is another reason why Linux is more popular on Steam. I play Steam games on both Mac and Linux: I can play more and better games on Linux (using Proton), but the ease of access on Mac makes me play there more. I just break my Linux too often because it’s a work tool.

Docker for windows is a thin shim over a VM that falls apart at the seams when it comes to networking..

Git on Windows is only supported by installing a whole suite of Unix tools and a shell.

Tools like ccache/sccache treat windows (well msvc) as a second class citizen.

Go, the poster child for cross-compilation shatters that illusion when you need to use CGO.

Python, I believe things have gotten better but the last time I tried getting tensorflow up and running on Windows it was a long and painful path involving third party python distributions, native toolchains and changing drivers.

So I think this is referring to the Steam Deck. Which (as you say) can support other Linux distros, it's not locked down to SteamOS. Or even other OS's if you wanted to.

I've only run SteamOS on my Deck, but afaik if you install it on something else then you can still flip it between the gaming mode and the desktop mode. In desktop mode it behaves exactly like you'd expect an Arch Linux install to behave, and you can mess around with it as much as you'd like. In gaming mode it's like a console and really only plays games (but isn't limited to Steam games - people have got it running emulators and all sorts of other stuff too).

I think Steam Deck is getting to be a large enough market that people are going to care about Linux support in the future (even if via Proton). It may be only 2%ish of the market, but I'll bet those 2% are the high-spending end of the market. The industry has reacted to the Deck by making everything work with it. That's not going to stop. Developers are not "only caring about Windows" any more.

Depends pretty much on the Windows version, and if using Linux or Windows containers.

Docker on Windows is a shim for the Windows Jobs API, as Microsoft decided to offer the same experience instead of coming up with their own set of tooling.

In more recent Windows versions, there are other ways to manage containers, specially after containerd support improved.

The best way to distribute builds on Windows is via incredible and their VS integration.

Cross compilation never really quite works out, unless one can have a complete set of libraries and toolset of the host OS, otherwise there will always be corner cases.

Python has been quite alright when using distributions like ActiveState Python.

Git, well one cannot expect better from a SCM designed for the Linux kernel project in first place.

There was an article posted on HN a few weeks ago, about Excel's rise over Lotus 1-2-3.

Excel was acknowledged as a better software pretty early on, and could always import Lotus spreadsheets, but it really started gaining adoption once it was able to export to Lotus files.

Counter-intuitively, the ability to stay within the Lotus ecosystem (and switch back at any time) is what enabled a lot of people on the fence to try Excel out. Only once Excel became dominant did people actually switch to XLS files.

You can install the normal steam client on Arch Linux, and the "big picture mode" (or whatever they call it now) is basically the "SteamOS" mode

Surely a main reason Excel gained market share was that it was graphical i.e. on Windows. Probably gained when OS/2 and Windows 3 came out giving a decent graphical environment.

I used Excel on Windows 2 from its release but I would be an outlier.

The problem is that, long term, native games also break if they are not maintained. I trust more the wine/proton developers to fix compat issues than random game publishers.

My experience is the exact opposite.

> excuse my ignorance, but are there any major developer tools that don't support Windows?

The entire Ruby ecosystem has never had great Windows DX: the most recommended Windows builds of Ruby itself come from a "second-party" group because official upstream doesn't seem to care to bundle nice installers, there's a ton of papercuts on Windows in the base libraries even in APIs you don't think would be platform-dependent, and a large number of third-party libraries and apps just kind of invariantly assume that you will never try to use them on Windows.

Docker only supports Windows by way of a virtual machine with some extra UI wrappers on top, it's not as if you're building/running Windows native containers in there. (Unless things have changed a whole lot since I last looked.) By that logic you might as well count anything that runs under WSL2 as supporting windows.

Non-SteamOS Linux users using Steam are using that exact same compatibility layer. There's really no difference.

The only reason why SteamOS might conceivably not count, is because the users didn't explicitly, knowingly choose Linux. They chose Steam. Valve pushes the Steam deck to its users, and those users buy it, possibly not even caring that it's running Linux rather than Windows.

Doesn't matter though. It's still Linux, even if the users may not be aware of it.

So it might be they're using an outdated version of Wine, whereas leaving it to Steam means you get the latest Proton version?

My impression is the exact opposite. A native version would have to be actively maintained by the developer, and if they're not that interested the native version is likely to have more bugs, lag behind in development, not receive the latest updates, or even stop working altogether. If it's running on Proton, it's out of the devs hands, and it's either Valve or gamers maintaining the right configuration to get the best experience.

At least that's my very limited experience with linux gaming. I started only a couple of weeks ago, but so far, everything works incredibly well.

I'm using EndeavorOS (which is friendly Arch for newbies), and Steam is just an application that launches Steam games and it works great.

There are a couple of other game launchers, like Heroic, which handles both Epic and GOG games, which also works great.

But what's even better, is that if a GOG game doesn't quite run perfectly on Heroic because it lacks some of the latest refinements from Proton, you can import that game into Steam and taie advantage of Valve's nice work on Proton anyway.

I might do that; Cyberpunk on Heroic doesn't support raytracing or DLSS, and as I understand it, those do work if I were to run it on Steam. So that's a very nice option to have.

For now, it's probably better for developers to focus on Windows in such a way that Wine/Proton can easily run it on Linux. But once the percentage of Linux users grows big enough, it may become more attractive for developers to focus on a native Linux version.

That won't be for a while, though. But im the mean time, Wine/Proton/DXVK means that the Linux experience is excellent even without explicit developer support, so the Linux user base can grow beyond just the handful of die hards. Anyone can easily game on Linux now.

That is how Steam solves the chicken/egg problem.

Yes, this is Steam Deck, and the "gaming mode" of steam deck is essentially a submode of Steam Big Picture mode (used for TV-like screens).

> it's not as if you're building/running Windows native containers in there

You can. Idr if Docker Desktop supports it or not, but you can install Docker Engine for Windows and plug it into the Docker CLI and all that for sure.

Not exactly. I don't think those proprietary compatibility layers are generally (ever?) based on Wine, since Wine is LGPL. But they might have different bugs than Proton does, and in some cases they may have more bugs that affect a given game.

Around the turn of the millennium a bunch of high profiles games were ported to linux. All of those are hard to run today as rely on libraries that are no longer easily available on a common Linux distro. Yet wine runs the WIN32 version just fine.

In the mid '10s Feral (and a to a lesser extent Aspyr), ported many AAA games to linx. Many of the ports were of quite good quality. I own a few of them, yet occasionally I have to switch to the Proton version as the native one fails to start.

OSS games are the exception of course: being able to produce a good working binary from source make them future proof.