[Discussion] Proton/WINE good in principle or not?

Lots of discussions on this already, NoTuxNoBux and all that, but one thing I think is often overlooked is that Proton/Wine enables treating closed source games a bit like emulation roms, thus freeing the system around it to innovate.

What I mean with that is that binary backwards compatibility is a sort of poisoned sweet of the Windows world. It has resulted in the monstrous instable thing that Windows is, but admittedly is much better at running a few years old binary only software (although not perfectly though, and in some cases WINE is better already).

In the GNU/Linux world backwards compatibility is usually much less of a concern as with open-source software a library dependency is usually fixed quite easily.

But with closed source game ports it becomes quite apparent that this model doesn’t work with unmaintained binaries, as Linux game binaries very often become unusable very quickly.

Of course in an ideal world all software was FOSS, but in our less than ideal world we need to think of ways to deal with this fact.

Of course GNU/Linux could become more like Windows in that regard (worst outcome IMHO), or some sort of containers could be wrapped around those games that include the older libraries.

Or we could just consider old windows games to be similar to ROMs for emulators and run them through Proton/WINE…

P.S.: in before WINE Is Not an Emulator ;)

@yogthos
114M

I see WINE/Proton as net positive since it makes Linux more accessible. I haven’t thought of it from ROM/emulation perspective before, but that’s an excellent point as well.

I think Wine is a very important project. Not just for playing recent Windows-only games but also as a documentation of Windows APIs and to keep old software functional on modern systems.

Linux binaries being so troublesome to get up and running is an interesting issue too. In my opinion many developers just do it wrong by dynamically linking their binaries and thus depending on specific libraries being available on the users OS. Instead they should ship their own libraries by statically linking them into the binary itself or using some start script that preloads those libraries from their own folder. This would fix the majority of issues people encounter with running random binaries. There could still be problems since the Linux desktop keeps evolving, so APIs that were available 10 years ago might not be there anymore. Examples of this would be OSS which was replaced by ALSA, and the current progression from X11 to Wayland. When developing something new this could easily be avoided by using a library like SDL2, which at the same time also makes it easier to write cross platform applications. That’s not a solution for abandoned or huge projects though

poVoq
mod
creator
2
edit-2
4M

Yeah for sure there are ways to avoid many of the problems, but lets be honest: most ports are not of the highest quality in the first place and we can often be happy that it runs at all.

Travis Skaalgard
6
edit-2
4M

Proton/WINE would be unnecessary in a perfect world. However, in our current reality it is excellent, since it allows users to use (even proprietary) software in a better environment that respects their freedom.

Only if that perfect world with no Windows ever existing. Otherwise it makes perfect sense to exist, if nothing else than for archival purposes.

Well yeah, in a perfect world, free/libre software would be all there was and all that had ever been. No Windows ever.

@Ninmi@sopuli.xyz
1
edit-2
4M

It really pisses me off that the way we deal with the issue only prolongs the problem. But I guess the issue isn’t all that one dimensional. It’s sort of the same thing with Steam; it’s a proprietary walled garden, yet Valve does an incredible amount of work that benefits Linux gaming in general, so it would be silly to bite the hand that feeds. It really does seem like a lot of Linux gamers don’t realize just how unbealivibly valuable Valve’s work is for them.

Linux doesn’t need a majority to make it profitable for developers, the threshold is much lower. Wine/Proton and Steam are simply necessary evils until we have the leverage to choose another service to force change.

@kt1
6
edit-2
4M

deleted by creator

@UnreliantGiant
3
edit-2
4M

You’re correct with Wine safety. It basically just parses the exe files, extracts their code, creates a native Linux process with the code, and provides its own implementation of the Windows API to it. This code can be any valid CPU instruction and it could theoretically even do native Linux syscalls and make use of other available APIs on the system. There’s little reason for a program to do that, but it’s absolutely possible. You should secure Wine processes just like you would secure native Linux processes, because they are exactly that.

poVoq
mod
creator
3
edit-2
4M

Newer Proton versions run it in a sandbox container though. I guess that functionality is also available in WINE these days.

I don’t think Proton does sandboxing. It uses the Steam runtime and Valve is working on some containerization thing to support x86 games after distributions fully stop supporting x86 libraries, but as far as I know it’s not out yet

poVoq
mod
creator
34M

The container thing is enabled by default in Proton 5.13 and later I think. Maybe sandbox is too strong a description but (to my limited understanding) this container also somewhat limits what the windows binaries can access.

Gaming on the GNU/Linux operating system.

Recommended news sources:

Related chat:

Related Communities:

  • 0 users online
  • 2 users / day
  • 14 users / week
  • 31 users / month
  • 118 users / 6 months
  • 929 subscribers
  • 180 Posts
  • 321 Comments
  • Modlog