Not sure if this best fits in ~tech, ~games, or ~comp since it’s a little bit of all (feel free to move it if needed!). I’m curious to see what people here have to say about this — especially...
Not sure if this best fits in ~tech, ~games, or ~comp since it’s a little bit of all (feel free to move it if needed!).
I’m curious to see what people here have to say about this — especially long-time Linux users and aficionados.
I don’t really have strong enough knowledge of the “under the hood” functioning of computers to have an opinion. Like the author mentions, when Proton works, it essentially becomes invisible to me. On most games I submit ProtonDB reports for, I genuinely have to check whether or not I was even running it through Proton in the first place. Unless I ran into issues (rare) or had to load it through GloriousEggroll’s fork (less rare), the experience via Proton is identical to that of a native build for me — to the point that I forget which it was.
I think Proton is a hinderance to Linux-native games. It's a crutch. It's a sturdy one that keeps getting better features, but it's there so Valve doesn't have to change anything to retain the...
I think Proton is a hinderance to Linux-native games. It's a crutch. It's a sturdy one that keeps getting better features, but it's there so Valve doesn't have to change anything to retain the Linux market/business liferaft.
The problem with this crutch is it that while it makes it easy to play Windows games, it is also used as a club against Linux support. Not many, but some, devs have said "Just use proton" when asked about Linux support. However, I think this is generally a more rare occurrence, but a minor hinderance is still there.
The question I'd ask is, from a practical sense, does the difference matter for games with full Proton support from their devs? Including anti-cheat for those games that require it. I'd say it's not a meaningful difference for the normal end user, but it's a huge difference to the purist.
I've sort of run out of thoughts here, but my main point is it depends what you want for Linux: Games that run on it, or games for it.
I mean, it's not like there were lots of developers dying to support Linux before Proton. The choice was never between Proton and a bunch of native Linux games, but rather between Proton and...
I mean, it's not like there were lots of developers dying to support Linux before Proton. The choice was never between Proton and a bunch of native Linux games, but rather between Proton and pretty much nothing .
I view Proton as a framework that happens to be almost identical to Windows. If a developer actively works to make sure their game will play nice in Proton, then the game is as good as native in...
I view Proton as a framework that happens to be almost identical to Windows. If a developer actively works to make sure their game will play nice in Proton, then the game is as good as native in my book.
One benefit to targeting Proton is better potential longevity. I've had a number of "native" Linux games that slowly became more and more difficult to play as time moves on. They rely on old versions of libraries that no longer ship with some popular distros. Some were just not well made ports. With Wine/Proton abstracting most of those problems away to a compatibility layer that the community maintains, I feel games that run well in it today will still be easy to run in 10 or 15 years.
Linux does not have the market share to demand native ports of commercial games, especially when you factor in that this tiny market share is disproportionately over-represented in support tickets with games that do take this route.
I'll be honest, I'll sometimes use Proton instead of a native version without even checking the quality of the native game because my experiences have been so bad.
I'll be honest, I'll sometimes use Proton instead of a native version without even checking the quality of the native game because my experiences have been so bad.
There is a trend in software development these days to eliminate all eternal dependencies by including all external libraries in the application package. You'll notice that no Java application...
There is a trend in software development these days to eliminate all eternal dependencies by including all external libraries in the application package. You'll notice that no Java application will ask you to install Java anymore; that's because the current practice is to include the entire JRE alongside the application now. And it's the same in a lot of different places; snaps, flatpaks, appimages, and other containerized apps all do the same thing (though it's out of necessity for those applications).
Of course I say it's a trend, but as you can see it's pretty much just how things are done now.
That can still break if any of your bundled dependencies make assumptions about the OS that are no longer true 10 years from now. When Steam first launched on Linux, it came with the Steam...
That can still break if any of your bundled dependencies make assumptions about the OS that are no longer true 10 years from now.
When Steam first launched on Linux, it came with the Steam Runtime, against which all native Linux games on the platform are written, in order to smooth over inconsistencies in available libraries and other things across distros. Anything not included with the Steam Runtime has to be bundled with the game itself. It is still not perfect, and there are at least two games I have native versions of that have become very unstable in recent years.
Yeah, it's good that Proton exists - I'm glad that I don't have to fuck around with Winetricks to get stuff to run. However, it's not actually the same; for example, Supreme Commander's...
Yeah, it's good that Proton exists - I'm glad that I don't have to fuck around with Winetricks to get stuff to run. However, it's not actually the same; for example, Supreme Commander's multimonitor support is broken and always will be, because it's not open source, so even though Gas Powered Games went out of business years ago, nobody can fix it.
Proton is better than no games on Linux, but it's strictly worse than having native games, and that is strictly worse than companies releasing their games open source after their profitable life has run. See, for example, Warzone 2100, which was a proprietary PS1 game everyone would have forgotten about, except that its developer gave its source code away for free after it stopped being profitable and it's now a popular and free RTS, native on Linux, Windows, and Mac OS, with a large community playing and making improvements and mods.
Open code - open culture - is strictly better. ¯\_(ツ)_/¯
Id used to have the same attitude when they released the Doom source code, which is probably a major contributing factor to why in part the DOOMWAD community is still so active even after nearly...
Id used to have the same attitude when they released the Doom source code, which is probably a major contributing factor to why in part the DOOMWAD community is still so active even after nearly 30 years!
I think the "true" purist stabdpoint would be to only run FOSS on your system, which most games are not and "never" will be. by compromising on something that big the compromise between native (...
I think the "true" purist stabdpoint would be to only run FOSS on your system, which most games are not and "never" will be. by compromising on something that big the compromise between native ( which the article points out cleary is not really well definable) and translation is moot in my eyes.
I meant it more from the perspective of Linux gamers, who tend to accept more proprietary software, either via games or launchers. Frankly, people who demand every game be FOSS are out of scope...
I meant it more from the perspective of Linux gamers, who tend to accept more proprietary software, either via games or launchers. Frankly, people who demand every game be FOSS are out of scope here as they're not technically in the gaming market as it generally exists.
There are great FOSS games, but they're not generally subject to the Proton vs Native debate because they'll typically support Windows and Linux.
I can respect this perspective, but I'd like to chime in with a newbie's perspective. I'm stuck on Windows for work (since my job's engineering stack is .NET), but I really want to shift...
I can respect this perspective, but I'd like to chime in with a newbie's perspective. I'm stuck on Windows for work (since my job's engineering stack is .NET), but I really want to shift personally to Linux, which consists predominantly of gaming.
Proton helps my demographic - gamers who predominantly live on Windows who are seeking a transition to Linux but don't have the time, ability, or bandwidth to deeply understand every single facet of a leisure aspect of my OS. We want to "just work", and keep the mental/time/effort cost as close to zero as possible. Proton encapsulates a large portion of that complexity to even get the game running, and I think that's fantastic.
Now, I'm personally more willing to eventually break away from that demographic and eventually get to learn the deeper aspects of getting a random Windows game binary running, but I definitely appreciate Proton as a starting series of training wheels to get me there.
That said, my time is limited, and I just flat-out wouldn't be able to consider moving to Linux if I didn't have Proton to help me migrate.
To be clear, I don't think this is what knockless is suggesting. The question here is whether it's okay that Proton pushes some (I'd say many) devs to not actually build their games for Linux,...
I'm personally more willing to eventually break away from that demographic and eventually get to learn the deeper aspects of getting a random Windows game binary running, but I definitely appreciate Proton as a starting series of training wheels to get me there.
To be clear, I don't think this is what knockless is suggesting. The question here is whether it's okay that Proton pushes some (I'd say many) devs to not actually build their games for Linux, even when using a tool (like Unity) where that is literally a few clicks of effort.
Moonglow Bay is a great example of this. It's a beautiful game, made in no small part by my favorite composer, Lena Raine, which I don't own a copy of, because not only does it not have a Linux version, but when I asked for one on Twitter, the developers were entirely dismissive and, frankly, uncharacteristically mean.
It does work in Proton, but you have to set some override flags, and it's clear that the devs' thought process here is that of so many others - Linux and its users are more trouble than they're worth, and we should be required to have a second-class experience, when (according to SteamDB) it uses Unity and FMOD as core technologies, both of which are perfectly capable of exporting binaries to Linux.
Proton is great. I'm glad it exists. But the phenomenon of games that absolutely could be easily made to run on Linux with ten minutes of the developers' time not being available natively really rubs me the wrong way.
I have to disagree with the premise that Linux support is just "a few clicks of effort" even for tools built with cross-platform support in mind. Software development is complicated and building...
I have to disagree with the premise that Linux support is just "a few clicks of effort" even for tools built with cross-platform support in mind. Software development is complicated and building support for multiple operating systems isn't always easy.
I'll give a quick example from work I've done. A few months back, we had a software service that we wanted to move from running on a Windows server to running on Linux server to maintain consistency with our other services. The service was built using .NET Core, a cross-platform framework that, for the most part, works really well whether you run it on Windows or Linux. But when we tried to run the service in Linux, it wasn't working as expected. After a day of troubleshooting, we realized that some Time zone related code was Windows-specific. So even though the code compiled and nothing looked broken, we were using the Windows way of getting Time zone info, not the Linux way. All of that to say that even when a tool claims to be fully cross-platform, there are always caveats. In our case, it was a small change, but it's impossible to say how much code is Windows-specific in the game example you gave.
Beyond that, advertising a game as Linux native can be a risk, especially for small game companies. Only 1% of steam users use Linux (compared to the 96% that use Windows). By offering Linux support, the company now has to expect user support issues from Linux users. Addressing those issues would likely cost the company more than they would be gaining from the additional 1% of Steam users buying the game on Linux. It sucks, but as it stands, advertising a game as Linux native is just not in a company's best interest. Maybe that will change with the Steam Deck and the growing interest in Linux from non-technical users, but who knows.
It literally is that easy in Unity, though. I've done tons of VR dev in Unity, and even using weird VR APIs it works fine - you just add it to the build target list. Yeah, it does suck, and that's...
I have to disagree with the premise that Linux support is just "a few clicks of effort" even for tools built with cross-platform support in mind. Software development is complicated and building support for multiple operating systems isn't always easy.
It literally is that easy in Unity, though. I've done tons of VR dev in Unity, and even using weird VR APIs it works fine - you just add it to the build target list.
It sucks, but as it stands, advertising a game as Linux native is just not in a company's best interest.
Yeah, it does suck, and that's all I said. I said it sucks.
Any framework that's designed to be fully cross platform like Unity or Qt should be very straightforward to build a project for a whatever target, -- as long as you fully stay within their API...
It literally is that easy in Unity, though. I've done tons of VR dev in Unity, and even using weird VR APIs it works fine - you just add it to the build target list.
Any framework that's designed to be fully cross platform like Unity or Qt should be very straightforward to build a project for a whatever target, -- as long as you fully stay within their API wrappers. I'm not a game dev so I don't really know but would you have any reason to include <windows.h> in a Unity project?
Edit: I guess Unity is .NET so forgive me for some reason I was thinking it was C++.
I never did, but I was not making commercial games. It's possible that people feel the need to use native APIs for their Unity games; of course, we can never know, because they're not open source....
I never did, but I was not making commercial games. It's possible that people feel the need to use native APIs for their Unity games; of course, we can never know, because they're not open source. Based on my experience, though, those cases should be in the minority. That's the whole point of Unity; you're supposed to be able to do everything through C#'s managed environment.
EDIT: Just saw your edit. Yeah, it's confusing; the other major engine, Unreal, uses C++.
Yea sorry I tried to beat your reply with my edit -- I forgot Unity was .NET and not C++. It seems like you're correct, it should be pretty easy to support Linux in those cases.
Yea sorry I tried to beat your reply with my edit -- I forgot Unity was .NET and not C++. It seems like you're correct, it should be pretty easy to support Linux in those cases.
In your scenario it's an application written in a cross-platform framework not using cross-platform code. It's quite a bit different than using an engine that by its very nature supports...
In your scenario it's an application written in a cross-platform framework not using cross-platform code. It's quite a bit different than using an engine that by its very nature supports cross-platform building with no/minimal platform-specific code.
Part of the support issue, as somebody who tends to be in "non-standard" distrubitons like Arch more, is we as users have a responsibility to understand where the bug is. I agree that many people run to devs with issues that aren't caused by the game, because in general games should "just work" with Steam runtimes.
That's fair. I wrote the comment mostly from the perspective of the game as a user, not as a developer who just says "don't worry about it, Proton's got it." That sucks, and crappy attitudes are...
That's fair. I wrote the comment mostly from the perspective of the game as a user, not as a developer who just says "don't worry about it, Proton's got it."
Moonglow Bay is a great example of this. It's a beautiful game, made in no small part by my favorite composer, Lena Raine, which I don't own a copy of, because not only does it not have a Linux version, but when I asked for one on Twitter, the developers were entirely dismissive and, frankly, uncharacteristically mean.
That sucks, and crappy attitudes are just plain uncool.
I'm not saying Proton is bad. In a way, I'm not saying much that is a negative valuation of Proton. There's more to Proton than steam integration: Controller support, graphics API improvements,...
I'm not saying Proton is bad. In a way, I'm not saying much that is a negative valuation of Proton. There's more to Proton than steam integration: Controller support, graphics API improvements, and more. When I want to play a game, I don't want to think about getting it to run. The exception to that is performance testing old games in WINE vs Windows (WINE usually works better).
I even state that for most end-users there's not a significant difference between Proton and native games: They don't care, they just want the game to run. The only point of contention is if somebody wants the native games. There's nothing wrong with just using Linux and not learning how anything works under the hood.
Though I'm not a dev myself, the main reason I have heard for this attitude is because Linux is not that easy to support natively, especially for smaller indie studios. There have been devs that...
Not many, but some, devs have said "Just use proton" when asked about Linux support.
Though I'm not a dev myself, the main reason I have heard for this attitude is because Linux is not that easy to support natively, especially for smaller indie studios. There have been devs that did go ahead and make a native linux version. The result? Their support channels were basically inundated almost exclusively by people with issues on their Linux distro, even though Linux players made up a microscopic fraction of the playerbase.
When small devs see that kind of stuff, it's only a given that most will prefer not even to approach Linux with a ten foot pole and instead let steam deal with it so they can spend their resources elsewhere.
I'm not saying it's all Linux's fault or anything, I'm sure there are things you can do to mitigate bugs on Linux and all that, but I think it's completely reasonable for small devs not to want to spend their already limited resources on a platform that may not that easy to develop for and has a tiny user base. They'd much rather try to be compatible with Steam which everyone is already running anyway and avoid the trouble.
You can call it a crutch, but there's not a limitless pool of resources either and knowing where to focus your time and money is important.
Most game developers don't have the time or political influence on their publisher to target linux directly. Most games are released with known bugs and multiple gigabytes of day 1 patches. Even...
Most game developers don't have the time or political influence on their publisher to target linux directly. Most games are released with known bugs and multiple gigabytes of day 1 patches. Even if they only target the steam linux runtime, linux will not be as well tested and you're basically asking the devs to at the minimum double the testing surface, i.e. now the multiple machine configs need to be tested across both windows and linux, with varying levels of graphic drivers, etc.
Adding all that extra work for a small userbase that is more likely to add bad reviews for a bad port, or polute your bug tracker with linux support issues is unrealistically to expect from developers that already delay games and suffer from crunch culture. Don't forget that linux is one of the more elitist and toxic cultures that exists in the tech world, most devs don't want to deal with that shit.
Would it be nice if companies would release linux native ports of their games? Absolutely. But it simply ignores the reality that is the game dev world.
Proton is not a crutch, but a bridge for game devs to get the linux userbase to try their games. Wine is an amazing piece of software, and while I'm not familiar with the internals like a wine dev is, I used to follow the wine-devel mailing list back in the mid-2000s and I'm aware at a surface level what the devs need to do to get stuff running on linux. It's much less emulation or translation, and more like teaching linux how to speak Windows, in the sense that while it's not it's main tongue, it can get pretty damn close.
Classic. "You don't deserve nice things because some people who use the same software as you are mean." Like... Do no jerks use Windows? Does Microsoft's behavior towards users not count as toxic? 🙄
Classic. "You don't deserve nice things because some people who use the same software as you are mean."
Like... Do no jerks use Windows? Does Microsoft's behavior towards users not count as toxic? 🙄
True. I'd argue that such a perception is pretty unfair to the majority of people who just use Linux as an operating system and don't participate in the community at all beyond bug reports, let...
True. I'd argue that such a perception is pretty unfair to the majority of people who just use Linux as an operating system and don't participate in the community at all beyond bug reports, let alone community drama.
So, in the ship of Theseus, each part of the ship is replaced with a part that is identical in all respects but one [1] to the one it replaces. This means that it must not only look identical, but...
So, in the ship of Theseus, each part of the ship is replaced with a part that is identical in all respects but one [1] to the one it replaces. This means that it must not only look identical, but also function identically, and, in a modern approach, it must also be identical down to it's atomic structure, in such a way that no one would be able to perceive any difference whatsoever, regardless of the instruments that they use.
The author uses this though experiment to comment on the process by which a game originally developed for Windows is allowed to run on Linux. But, unlike the ship of Theseus, this is not a thought experiment, which brings a few complications.
First of all, looking and feeling the same is not enough to be identical. Granted, the base code of the game is, I suppose, entirely the same. But the illusion is weaker than at first it seems. I won't even bring a concrete example, since the mere possibility that a game will not always run in exactly the same way is enough to demonstrate that this is way far from "identicality". If a game consistently runs at 5 frames more or 5 frames less, this is more than enough to demonstrate that there are significative differences between a game on Windows and a game on Linux.
Additionally, one might ask, what is a videogame, more precisely? Is a videogame the same as its source code?
Suppose I wrote the source code for a complete videogame without ever running it. Afterwards I safely delete it's code, break the hard drive into pieces, and, just for safe measure, throw every remaining bits into the Sun. Was that a videogame? Not exactly, I would say. That was the source code for a videogame that never were, because a videogame is something someone or something plays.
If a videogame is something you play, it can't possibly be the same in two entirely distinct operating systems. I don't play GTA V, I play Xbox's GTA V. On Linux, you don't play Cyberpunk. You play Linux/Steam/Proton's Cyberpunk.
Besides, videogames have no aura, they are reproducible by nature. It's an entirely different argument because ships and games work very differently. This is no ship of Theseus because the parts are not absolutely identical.
I won't elaborate much on that, but, when you talk about digital patterns like videogames, does it even make sense to think that there is any single source of identity? In what way is my copy of Cyberpunk more or less truthful than everyone else's? Or, to further the analogy, do videogames' ontogical status allow for that comparison in the first place?
Sorry for the comment which is not really about videogames, technology, or computer science :P
[1] they are not identical from a historical standpoint, since one came to be part of the ship before the other
So I commited the primary sin of commenting before actually reading the article and ended up rewriting it. If you want to read it all again I don't know if you're interested in a pragmatic answer,...
So I commited the primary sin of commenting before actually reading the article and ended up rewriting it.
If you want to read it all again
I don't know if you're interested in a pragmatic answer, but here's one anyways.
Software is more than just an executable file. If you look at the files that make up your game you'll see a bunch of files. One of them is the main binary - the part that orchestrates the whole thing. And of course a lot of the files are resource files - sound, graphics, videos, etc. The third major file you'll see are libraries, which are basically bits of code that have been written by some other group of people. But the thing about software that people tend to forget is that the fundamental thing they rely on are functions that are actually built into the operating system itself.
If you've ever used a cross-platform application, you'll probably have noticed that when you try to open a file within it, it will show you a file browser that matches the look and feel of your operating system. That's because that file browser is actually part of the operating system - the software just tells the OS that it wants to use that feature.
That's just the most visable part of how programs make use of the operating system, but the truth is that any program you run is going to be built on top of the operating system and depends on it on a very fundamental level. Any time that software has to use any bit of your hardware, it's basically just asking the OS to pass messages to it. The OS is even in charge of scheduling when the program is allowed to run and what memory locations it can use.
You're right to equate Proton to the Ship of Thesius; it's basically an alternative implementation of the Windows operating system, with the exception being that it's not actually an operating system; instead of passing along instructions between the hardware and the program, it acts like a middleman that listens to how the program and the operating systems talk and translates them so they can understand the meaning and cooperate to fulfill the program's goal.
(It should be noted that a cohort project to Wine, Proton's older brother, is ReactOS - a project that intends to be an entire reimplementation of Windows as an operating system.)
But software is the sum of the whole, including the operating system and even the firmware built into the devices that make up the computer. So running the game on Windows is fundamentally different than running the game on Linux via Proton. But the same is true about running on differing versions of Windows - and that includes minor differences like updates. The same can also be true when talking about running it on different hardware configurations!
This is why even though a lot of Windows games can be run on Proton, it doesn't mean that the people who made the game are going to support you doing that. But on the other hand, there is a surprising number of games that use Wine, Proton, or Mono to provide native Linux or MacOS versions even though the original game was only written with Windows on mind. I've mainly seen this on indie titles like Always Sometimes Monsters - which should be noted came out years ago, so this isn't a new phenomenon. It's something you may have experienced without even knowing.
This is all very off-topic. Yeah... Everything you say is perfectly reasonable, but I'm more interested in the metaphysics of it all. I don't think the author's choice for using the Ship of...
This is all very off-topic.
Yeah... Everything you say is perfectly reasonable, but I'm more interested in the metaphysics of it all. I don't think the author's choice for using the Ship of Theseus as a metaphor was a very good one, and I tried to demonstrate that.
You made a pragmatic comment, I'll try something more in that vein, using a somewhat simpler example, asking the question: what is a film? In the old days, some might say (and many did) that a film is equivalent to celluloid, the film stock in which the light impress photosensitive silver halide crystals. Video, first analog and now digital, rendered this notion obsolete. So, if a film is not the thing in which the images are engraved then what it is? I could say, in 2022, that film is nothing more than a pattern on the magnetic coating of a hard drive, or whatever makes the inside of an SSD. That doesn't sound very satisfying.
In Godfather, when Michael Corleone plots the death of Virgil Sollozzo and the chief of police, the story unfolds in front of me. Staging, acting, music, and performances manipulate both my emotions and my cognition. I create hypotheses, entertain expectations. I'm not watching celluloid, I'm watching a film! Because that is what a film is meant to be, it only produces its effects when appreciated by an observer.
A film is a film when it is projected, or rendered on a screen. Not when it is only an idea, not when it is just a screenplay, not when it is being filmed, not when it is recorded on celluloid. A film is only a film when it produces its effects, in the same way that flour, eggs, fat, and sugar are not a cake, and in the same way that source, by itself, however it is organized, is not relay a game. Celluloid, source code, as well as sheet music, are not themselves film, program, and music. They're sets of instructions that, when executed correctly, allow film, program, and music to exist.
Going back to the ship, one could say that its atoms are constantly shifting, vibrating, etc (I'm no physicist, but you get the idea), and whatever we think constitutes its identity is itself only an illusion of permanence. But I digress.
Just in case you didn't infer it from my comment earlier, I think that all interpretations are valid. The filmstock is the film, the copies are the film, the transcoded digital versions are the...
Just in case you didn't infer it from my comment earlier, I think that all interpretations are valid. The filmstock is the film, the copies are the film, the transcoded digital versions are the film, each display of the visual contents is the film, the ideas of the people who made it are the film, and the interpretation of the viewer is also the film.
But when we as people talk about film, what version of that concept are we talking about? I would argue that it's the subjective experience of the person who viewed the film. And the reason I'm bringing this up is because I think it provides a stronger answer to the questions you're bringing up. When people compare them they're effectively talking about different things. A person who watched Seinfeld when it was originally airing is essentially talking about a different show compared to a young person who just started watching it, and the former viewer is going to have a version that is much more enjoyable than the latter's.
So yes, I am basically agreeing with you that permanence is an illusion. The world is chaos and things only stay around if they are copied, and no copy is ever the same.
Human beings are probably the best example of this concept. Sleeping and waking is like a daily cycle of death and rebirth. Scientifically our cells are constantly dying and being replaced with new cells. Every human being is their own Ship of Thesius in progress.
Not sure if this best fits in ~tech, ~games, or ~comp since it’s a little bit of all (feel free to move it if needed!).
I’m curious to see what people here have to say about this — especially long-time Linux users and aficionados.
I don’t really have strong enough knowledge of the “under the hood” functioning of computers to have an opinion. Like the author mentions, when Proton works, it essentially becomes invisible to me. On most games I submit ProtonDB reports for, I genuinely have to check whether or not I was even running it through Proton in the first place. Unless I ran into issues (rare) or had to load it through GloriousEggroll’s fork (less rare), the experience via Proton is identical to that of a native build for me — to the point that I forget which it was.
I think Proton is a hinderance to Linux-native games. It's a crutch. It's a sturdy one that keeps getting better features, but it's there so Valve doesn't have to change anything to retain the Linux market/business liferaft.
The problem with this crutch is it that while it makes it easy to play Windows games, it is also used as a club against Linux support. Not many, but some, devs have said "Just use proton" when asked about Linux support. However, I think this is generally a more rare occurrence, but a minor hinderance is still there.
The question I'd ask is, from a practical sense, does the difference matter for games with full Proton support from their devs? Including anti-cheat for those games that require it. I'd say it's not a meaningful difference for the normal end user, but it's a huge difference to the purist.
I've sort of run out of thoughts here, but my main point is it depends what you want for Linux: Games that run on it, or games for it.
I mean, it's not like there were lots of developers dying to support Linux before Proton. The choice was never between Proton and a bunch of native Linux games, but rather between Proton and pretty much nothing .
I view Proton as a framework that happens to be almost identical to Windows. If a developer actively works to make sure their game will play nice in Proton, then the game is as good as native in my book.
One benefit to targeting Proton is better potential longevity. I've had a number of "native" Linux games that slowly became more and more difficult to play as time moves on. They rely on old versions of libraries that no longer ship with some popular distros. Some were just not well made ports. With Wine/Proton abstracting most of those problems away to a compatibility layer that the community maintains, I feel games that run well in it today will still be easy to run in 10 or 15 years.
Linux does not have the market share to demand native ports of commercial games, especially when you factor in that this tiny market share is disproportionately over-represented in support tickets with games that do take this route.
I'll be honest, I'll sometimes use Proton instead of a native version without even checking the quality of the native game because my experiences have been so bad.
There is a trend in software development these days to eliminate all eternal dependencies by including all external libraries in the application package. You'll notice that no Java application will ask you to install Java anymore; that's because the current practice is to include the entire JRE alongside the application now. And it's the same in a lot of different places; snaps, flatpaks, appimages, and other containerized apps all do the same thing (though it's out of necessity for those applications).
Of course I say it's a trend, but as you can see it's pretty much just how things are done now.
That can still break if any of your bundled dependencies make assumptions about the OS that are no longer true 10 years from now.
When Steam first launched on Linux, it came with the Steam Runtime, against which all native Linux games on the platform are written, in order to smooth over inconsistencies in available libraries and other things across distros. Anything not included with the Steam Runtime has to be bundled with the game itself. It is still not perfect, and there are at least two games I have native versions of that have become very unstable in recent years.
Yeah, it's good that Proton exists - I'm glad that I don't have to fuck around with Winetricks to get stuff to run. However, it's not actually the same; for example, Supreme Commander's multimonitor support is broken and always will be, because it's not open source, so even though Gas Powered Games went out of business years ago, nobody can fix it.
Proton is better than no games on Linux, but it's strictly worse than having native games, and that is strictly worse than companies releasing their games open source after their profitable life has run. See, for example, Warzone 2100, which was a proprietary PS1 game everyone would have forgotten about, except that its developer gave its source code away for free after it stopped being profitable and it's now a popular and free RTS, native on Linux, Windows, and Mac OS, with a large community playing and making improvements and mods.
Open code - open culture - is strictly better. ¯\_(ツ)_/¯
Id used to have the same attitude when they released the Doom source code, which is probably a major contributing factor to why in part the DOOMWAD community is still so active even after nearly 30 years!
I think the "true" purist stabdpoint would be to only run FOSS on your system, which most games are not and "never" will be. by compromising on something that big the compromise between native ( which the article points out cleary is not really well definable) and translation is moot in my eyes.
I meant it more from the perspective of Linux gamers, who tend to accept more proprietary software, either via games or launchers. Frankly, people who demand every game be FOSS are out of scope here as they're not technically in the gaming market as it generally exists.
There are great FOSS games, but they're not generally subject to the Proton vs Native debate because they'll typically support Windows and Linux.
I can respect this perspective, but I'd like to chime in with a newbie's perspective. I'm stuck on Windows for work (since my job's engineering stack is .NET), but I really want to shift personally to Linux, which consists predominantly of gaming.
Proton helps my demographic - gamers who predominantly live on Windows who are seeking a transition to Linux but don't have the time, ability, or bandwidth to deeply understand every single facet of a leisure aspect of my OS. We want to "just work", and keep the mental/time/effort cost as close to zero as possible. Proton encapsulates a large portion of that complexity to even get the game running, and I think that's fantastic.
Now, I'm personally more willing to eventually break away from that demographic and eventually get to learn the deeper aspects of getting a random Windows game binary running, but I definitely appreciate Proton as a starting series of training wheels to get me there.
That said, my time is limited, and I just flat-out wouldn't be able to consider moving to Linux if I didn't have Proton to help me migrate.
To be clear, I don't think this is what knockless is suggesting. The question here is whether it's okay that Proton pushes some (I'd say many) devs to not actually build their games for Linux, even when using a tool (like Unity) where that is literally a few clicks of effort.
Moonglow Bay is a great example of this. It's a beautiful game, made in no small part by my favorite composer, Lena Raine, which I don't own a copy of, because not only does it not have a Linux version, but when I asked for one on Twitter, the developers were entirely dismissive and, frankly, uncharacteristically mean.
It does work in Proton, but you have to set some override flags, and it's clear that the devs' thought process here is that of so many others - Linux and its users are more trouble than they're worth, and we should be required to have a second-class experience, when (according to SteamDB) it uses Unity and FMOD as core technologies, both of which are perfectly capable of exporting binaries to Linux.
Proton is great. I'm glad it exists. But the phenomenon of games that absolutely could be easily made to run on Linux with ten minutes of the developers' time not being available natively really rubs me the wrong way.
I have to disagree with the premise that Linux support is just "a few clicks of effort" even for tools built with cross-platform support in mind. Software development is complicated and building support for multiple operating systems isn't always easy.
I'll give a quick example from work I've done. A few months back, we had a software service that we wanted to move from running on a Windows server to running on Linux server to maintain consistency with our other services. The service was built using .NET Core, a cross-platform framework that, for the most part, works really well whether you run it on Windows or Linux. But when we tried to run the service in Linux, it wasn't working as expected. After a day of troubleshooting, we realized that some Time zone related code was Windows-specific. So even though the code compiled and nothing looked broken, we were using the Windows way of getting Time zone info, not the Linux way. All of that to say that even when a tool claims to be fully cross-platform, there are always caveats. In our case, it was a small change, but it's impossible to say how much code is Windows-specific in the game example you gave.
Beyond that, advertising a game as Linux native can be a risk, especially for small game companies. Only 1% of steam users use Linux (compared to the 96% that use Windows). By offering Linux support, the company now has to expect user support issues from Linux users. Addressing those issues would likely cost the company more than they would be gaining from the additional 1% of Steam users buying the game on Linux. It sucks, but as it stands, advertising a game as Linux native is just not in a company's best interest. Maybe that will change with the Steam Deck and the growing interest in Linux from non-technical users, but who knows.
It literally is that easy in Unity, though. I've done tons of VR dev in Unity, and even using weird VR APIs it works fine - you just add it to the build target list.
Yeah, it does suck, and that's all I said. I said it sucks.
Any framework that's designed to be fully cross platform like Unity or Qt should be very straightforward to build a project for a whatever target, -- as long as you fully stay within their API wrappers. I'm not a game dev so I don't really know but would you have any reason to include <windows.h> in a Unity project?
Edit: I guess Unity is .NET so forgive me for some reason I was thinking it was C++.
I never did, but I was not making commercial games. It's possible that people feel the need to use native APIs for their Unity games; of course, we can never know, because they're not open source. Based on my experience, though, those cases should be in the minority. That's the whole point of Unity; you're supposed to be able to do everything through C#'s managed environment.
EDIT: Just saw your edit. Yeah, it's confusing; the other major engine, Unreal, uses C++.
Yea sorry I tried to beat your reply with my edit -- I forgot Unity was .NET and not C++. It seems like you're correct, it should be pretty easy to support Linux in those cases.
In your scenario it's an application written in a cross-platform framework not using cross-platform code. It's quite a bit different than using an engine that by its very nature supports cross-platform building with no/minimal platform-specific code.
Part of the support issue, as somebody who tends to be in "non-standard" distrubitons like Arch more, is we as users have a responsibility to understand where the bug is. I agree that many people run to devs with issues that aren't caused by the game, because in general games should "just work" with Steam runtimes.
That's fair. I wrote the comment mostly from the perspective of the game as a user, not as a developer who just says "don't worry about it, Proton's got it."
That sucks, and crappy attitudes are just plain uncool.
I'm not saying Proton is bad. In a way, I'm not saying much that is a negative valuation of Proton. There's more to Proton than steam integration: Controller support, graphics API improvements, and more. When I want to play a game, I don't want to think about getting it to run. The exception to that is performance testing old games in WINE vs Windows (WINE usually works better).
I even state that for most end-users there's not a significant difference between Proton and native games: They don't care, they just want the game to run. The only point of contention is if somebody wants the native games. There's nothing wrong with just using Linux and not learning how anything works under the hood.
Though I'm not a dev myself, the main reason I have heard for this attitude is because Linux is not that easy to support natively, especially for smaller indie studios. There have been devs that did go ahead and make a native linux version. The result? Their support channels were basically inundated almost exclusively by people with issues on their Linux distro, even though Linux players made up a microscopic fraction of the playerbase.
When small devs see that kind of stuff, it's only a given that most will prefer not even to approach Linux with a ten foot pole and instead let steam deal with it so they can spend their resources elsewhere.
I'm not saying it's all Linux's fault or anything, I'm sure there are things you can do to mitigate bugs on Linux and all that, but I think it's completely reasonable for small devs not to want to spend their already limited resources on a platform that may not that easy to develop for and has a tiny user base. They'd much rather try to be compatible with Steam which everyone is already running anyway and avoid the trouble.
You can call it a crutch, but there's not a limitless pool of resources either and knowing where to focus your time and money is important.
Most game developers don't have the time or political influence on their publisher to target linux directly. Most games are released with known bugs and multiple gigabytes of day 1 patches. Even if they only target the steam linux runtime, linux will not be as well tested and you're basically asking the devs to at the minimum double the testing surface, i.e. now the multiple machine configs need to be tested across both windows and linux, with varying levels of graphic drivers, etc.
Adding all that extra work for a small userbase that is more likely to add bad reviews for a bad port, or polute your bug tracker with linux support issues is unrealistically to expect from developers that already delay games and suffer from crunch culture. Don't forget that linux is one of the more elitist and toxic cultures that exists in the tech world, most devs don't want to deal with that shit.
Would it be nice if companies would release linux native ports of their games? Absolutely. But it simply ignores the reality that is the game dev world.
Proton is not a crutch, but a bridge for game devs to get the linux userbase to try their games. Wine is an amazing piece of software, and while I'm not familiar with the internals like a wine dev is, I used to follow the wine-devel mailing list back in the mid-2000s and I'm aware at a surface level what the devs need to do to get stuff running on linux. It's much less emulation or translation, and more like teaching linux how to speak Windows, in the sense that while it's not it's main tongue, it can get pretty damn close.
Classic. "You don't deserve nice things because some people who use the same software as you are mean."
Like... Do no jerks use Windows? Does Microsoft's behavior towards users not count as toxic? 🙄
Certainly, but one could perceive Linux as being more toxic because there are less users to dilute the jerks.
True. I'd argue that such a perception is pretty unfair to the majority of people who just use Linux as an operating system and don't participate in the community at all beyond bug reports, let alone community drama.
So, in the ship of Theseus, each part of the ship is replaced with a part that is identical in all respects but one [1] to the one it replaces. This means that it must not only look identical, but also function identically, and, in a modern approach, it must also be identical down to it's atomic structure, in such a way that no one would be able to perceive any difference whatsoever, regardless of the instruments that they use.
The author uses this though experiment to comment on the process by which a game originally developed for Windows is allowed to run on Linux. But, unlike the ship of Theseus, this is not a thought experiment, which brings a few complications.
First of all, looking and feeling the same is not enough to be identical. Granted, the base code of the game is, I suppose, entirely the same. But the illusion is weaker than at first it seems. I won't even bring a concrete example, since the mere possibility that a game will not always run in exactly the same way is enough to demonstrate that this is way far from "identicality". If a game consistently runs at 5 frames more or 5 frames less, this is more than enough to demonstrate that there are significative differences between a game on Windows and a game on Linux.
Additionally, one might ask, what is a videogame, more precisely? Is a videogame the same as its source code?
Suppose I wrote the source code for a complete videogame without ever running it. Afterwards I safely delete it's code, break the hard drive into pieces, and, just for safe measure, throw every remaining bits into the Sun. Was that a videogame? Not exactly, I would say. That was the source code for a videogame that never were, because a videogame is something someone or something plays.
If a videogame is something you play, it can't possibly be the same in two entirely distinct operating systems. I don't play GTA V, I play Xbox's GTA V. On Linux, you don't play Cyberpunk. You play Linux/Steam/Proton's Cyberpunk.
Besides, videogames have no aura, they are reproducible by nature. It's an entirely different argument because ships and games work very differently. This is no ship of Theseus because the parts are not absolutely identical.
I won't elaborate much on that, but, when you talk about digital patterns like videogames, does it even make sense to think that there is any single source of identity? In what way is my copy of Cyberpunk more or less truthful than everyone else's? Or, to further the analogy, do videogames' ontogical status allow for that comparison in the first place?
Sorry for the comment which is not really about videogames, technology, or computer science :P
[1] they are not identical from a historical standpoint, since one came to be part of the ship before the other
So I commited the primary sin of commenting before actually reading the article and ended up rewriting it.
If you want to read it all again
I don't know if you're interested in a pragmatic answer, but here's one anyways.
Software is more than just an executable file. If you look at the files that make up your game you'll see a bunch of files. One of them is the main binary - the part that orchestrates the whole thing. And of course a lot of the files are resource files - sound, graphics, videos, etc. The third major file you'll see are libraries, which are basically bits of code that have been written by some other group of people. But the thing about software that people tend to forget is that the fundamental thing they rely on are functions that are actually built into the operating system itself.
If you've ever used a cross-platform application, you'll probably have noticed that when you try to open a file within it, it will show you a file browser that matches the look and feel of your operating system. That's because that file browser is actually part of the operating system - the software just tells the OS that it wants to use that feature.
That's just the most visable part of how programs make use of the operating system, but the truth is that any program you run is going to be built on top of the operating system and depends on it on a very fundamental level. Any time that software has to use any bit of your hardware, it's basically just asking the OS to pass messages to it. The OS is even in charge of scheduling when the program is allowed to run and what memory locations it can use.
You're right to equate Proton to the Ship of Thesius; it's basically an alternative implementation of the Windows operating system, with the exception being that it's not actually an operating system; instead of passing along instructions between the hardware and the program, it acts like a middleman that listens to how the program and the operating systems talk and translates them so they can understand the meaning and cooperate to fulfill the program's goal.
(It should be noted that a cohort project to Wine, Proton's older brother, is ReactOS - a project that intends to be an entire reimplementation of Windows as an operating system.)
But software is the sum of the whole, including the operating system and even the firmware built into the devices that make up the computer. So running the game on Windows is fundamentally different than running the game on Linux via Proton. But the same is true about running on differing versions of Windows - and that includes minor differences like updates. The same can also be true when talking about running it on different hardware configurations!
This is why even though a lot of Windows games can be run on Proton, it doesn't mean that the people who made the game are going to support you doing that. But on the other hand, there is a surprising number of games that use Wine, Proton, or Mono to provide native Linux or MacOS versions even though the original game was only written with Windows on mind. I've mainly seen this on indie titles like Always Sometimes Monsters - which should be noted came out years ago, so this isn't a new phenomenon. It's something you may have experienced without even knowing.
This is all very off-topic.
Yeah... Everything you say is perfectly reasonable, but I'm more interested in the metaphysics of it all. I don't think the author's choice for using the Ship of Theseus as a metaphor was a very good one, and I tried to demonstrate that.
You made a pragmatic comment, I'll try something more in that vein, using a somewhat simpler example, asking the question: what is a film? In the old days, some might say (and many did) that a film is equivalent to celluloid, the film stock in which the light impress photosensitive silver halide crystals. Video, first analog and now digital, rendered this notion obsolete. So, if a film is not the thing in which the images are engraved then what it is? I could say, in 2022, that film is nothing more than a pattern on the magnetic coating of a hard drive, or whatever makes the inside of an SSD. That doesn't sound very satisfying.
In Godfather, when Michael Corleone plots the death of Virgil Sollozzo and the chief of police, the story unfolds in front of me. Staging, acting, music, and performances manipulate both my emotions and my cognition. I create hypotheses, entertain expectations. I'm not watching celluloid, I'm watching a film! Because that is what a film is meant to be, it only produces its effects when appreciated by an observer.
A film is a film when it is projected, or rendered on a screen. Not when it is only an idea, not when it is just a screenplay, not when it is being filmed, not when it is recorded on celluloid. A film is only a film when it produces its effects, in the same way that flour, eggs, fat, and sugar are not a cake, and in the same way that source, by itself, however it is organized, is not relay a game. Celluloid, source code, as well as sheet music, are not themselves film, program, and music. They're sets of instructions that, when executed correctly, allow film, program, and music to exist.
Going back to the ship, one could say that its atoms are constantly shifting, vibrating, etc (I'm no physicist, but you get the idea), and whatever we think constitutes its identity is itself only an illusion of permanence. But I digress.
Just in case you didn't infer it from my comment earlier, I think that all interpretations are valid. The filmstock is the film, the copies are the film, the transcoded digital versions are the film, each display of the visual contents is the film, the ideas of the people who made it are the film, and the interpretation of the viewer is also the film.
But when we as people talk about film, what version of that concept are we talking about? I would argue that it's the subjective experience of the person who viewed the film. And the reason I'm bringing this up is because I think it provides a stronger answer to the questions you're bringing up. When people compare them they're effectively talking about different things. A person who watched Seinfeld when it was originally airing is essentially talking about a different show compared to a young person who just started watching it, and the former viewer is going to have a version that is much more enjoyable than the latter's.
So yes, I am basically agreeing with you that permanence is an illusion. The world is chaos and things only stay around if they are copied, and no copy is ever the same.
Human beings are probably the best example of this concept. Sleeping and waking is like a daily cycle of death and rebirth. Scientifically our cells are constantly dying and being replaced with new cells. Every human being is their own Ship of Thesius in progress.