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, ans 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 ;)

  • ☆ Yσɠƚԋσʂ ☆@lemmy.ml
    9·
    4 years ago

    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.

  • UnreliantGiant@lemmy.ml
    6·
    4 years ago

    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@lemmy.mlOP
      2·
      4 years ago

      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.

  • kt1@lemmy.ml
    3·
    4 years ago

    This is why I use Godot engine, beside ease of use, it runs and compiles to a single program with no dependencies.

    I don’t think WINE is safe to run proprietary games with, but maybe I am wrong since I hear it often break DRM and stuff. And you could create user with no internet or filesystem access etc…

    • UnreliantGiant@lemmy.ml
      2·
      4 years ago

      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@lemmy.mlOP
        2·
        4 years ago

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

        • UnreliantGiant@lemmy.ml
          2·
          4 years ago

          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@lemmy.mlOP
            2·
            4 years ago

            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.

  • Ninmi
    1·
    4 years ago

    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.