• 1 Post
  • 9 Comments
Joined 2 years ago
Cake day: June 5th, 2023
  • INeedMana@lemmy.worldtoLinux@lemmy.ml•Wine 10.0 Released With Native Wayland Support, Better HiDPI
    0·
    7 days ago

    Which wine though?

    Most of Proton code is Wine. So basically if you have Wine in your system, library dependencies are not an issue anymore, apart from DLLs that some games require

    Valve needs to control the version you use and to provide additional stuff not part of vanilla wine

    And that is one of the reasons why I expect them to pull the rug at some point. Why are they doing a fork instead of contributing?

    The one part of proton that is built and delivered to your system by Valve? They would have to compile and support it for every set of dependency versions out there.

    Then why not let us manage Wine runners, like for example Lutris does?

    I don’t see a technical reason that you can’t disable the isolation of shared memory or any other resource. The issue is whether you are given access to disable it.

    And that is my issue

    But there’s no reason why you shouldn’t be able to install custom containers alongside the default ones in the same way that you can install custom proton versions. Steam just doesn’t provide the interface for it

    And that’s exactly my gripe. But I expect it will be easier to push back on using containerization in Proton, than making Valve allow us such control

    I believe you would always be able to gain access to the container because it remains a chroot + namespace + cgroup isolation, all of which you can control on your system

    I’m less optimistic. I expect they will in the future make it as hard as possible

    App developers don’t control what’s on your system either. The container is a huge improvement for them because it at least gives them a known target to build for. They can still bundle dependencies in any way that they would on a non-containerized system. There’s no loss of control from their perspective.

    That parenthesis was a tangent on Android Google apps, to show what I am afraid will happen in the future. Currently, in order for Android app to appear in the official Store, developer has to allow Google to repackage their app and sign it with Google key. So while we can inspect what is there in the code of the app in git, we don’t really know what lands on our phones if installed via Google Play

    And as for taking the topic back to game developers, when we are talking about games ran with Proton, their known target is Windows anyway

    That’s what pressure-vessel is and as shown above you can modify it. And if you couldn’t it would be a tooling issue, not an inherent container disadvantage.

    I couldn’t find a way to disable memory separation. And if that’s not available, that is an issue with pressure-vessel, not tools

    Compatibility significantly increased after Valve got involved

    I think that was only because of additional work spent on games. I haven’t seen an example where a game would not work at all with Wine but would work with Proton. There are improvements on how it runs, of course. But my argument is that if some implementation in Proton makes a game work better, then it should land in mainline Wine

    there’s nothing inherent to container technology that prevents you from tinkering with it. Anything that you can’t do currently is because Steam is not designed to allow you to do it. It’s got nothing to do with whether Steam uses containers or not

    Yes. But “please, don’t fuck us up” is not something we can enforce

    They could remove the containers and still prevent tinkering, eg by using a bundled wine with no way for you to modify it or its launch options

    We can always just go back to running Windows version of whole Steam via Wine, as we were doing before Proton

  • INeedMana@lemmy.worldtoLinux@lemmy.ml•Wine 10.0 Released With Native Wayland Support, Better HiDPI
    0·
    8 days ago

    Containers are absolutely necessary to provide reliability across a wide range of distros and to keep games working in the future.

    We are going through more or less Wine anyway, the libraries on the system don’t matter as long as Wine compiles

    In ideal world it would be pure Wine, with Valve putting merge requests for things they want to change, instead of another EEE that’s only waiting to happen. More like AMD interacts with kernel driver. Valve already runs SteamOS, they can use it to have a stable 100% supported platform for their decks etc

    better tooling and documentation to interact with the container

    One of the core features of containers is process and process memory separation from host. So in case of headtracking (accessing game’s shared memory), containerization is directly working against it working. It’s not the tooling, it’s the choice of what to use

    Linux has had chroot since a long time if we are really afraid about supporting dwindling native client games

    How so? The end result is probably the opposite. Without the containers Steam would be less reliable on unsupported distros, which might mean your only choice would be to use Ubuntu LTS. That would be a much bigger loss of control.

    We have no control over what they put in those containers. Similar (to put perspective) as we have no control over what Google does in their Gapps (and app developers neither have!), So far we can go inside and inspect what are they running apart from the game’s exe directly. Once they disable the PRESSURE_VESSEL_SHELL=instead we will have no insight into what’s inside. And the other option - if it doesn’t work for some reason (with Wine I don’t really see it happening as what we run doesn’t rely on our OS libraries directly), you can create chroot, additional library packages with old versions, etc. Worst case scenario, Linux community will figure something out