Announcement

Collapse
No announcement yet.

Valve Reaffirms Commitment To Linux While Also Releasing Updated Proton

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Originally posted by oiaohm View Post
    Basically ZeroPointEnergy I most likely have a longer history than you on Linux and I can see if nothing changes how 32 bit x86 is going to play out.
    Yeah sure.. I use Linux and play games on it exclusively for ~20 years now. And no, the libs will not stop working because no one is "testing" them. If people are interested in using them which they clearly are then they will be patched and continue working and that is what is happening right now. 32bit will not go away as long as we have processors that can execute those binaries.

    Containers solve absolutely nothing you could not do with a plain system. There is no advantage in containers, it is just a symptom of bad engineering habits.

    Comment


    • Originally posted by ZeroPointEnergy View Post
      Yeah sure.. I use Linux and play games on it exclusively for ~20 years now. And no, the libs will not stop working because no one is "testing" them. If people are interested in using them which they clearly are then they will be patched and continue working and that is what is happening right now.
      This is a false believe. We are already see business bundle up their 32 business dependant programs in snap or flatpak not because they want to. Because they are already running to the case where the current version of particular libraries work fine in 64 bit mode but are broken in 32bit mode. Remember multiarch/multilib demards you stay version matched.

      The cause is simple people patching libraries on 64 bit systems and only testing 64 bit mode. Since the 32 bit version was not tested the breakage was missed. Multilib/multiarch locked version means you end up in dependency hell where the newer 64 bit versions of program need the new version of library and the 32 bit versions of program need the old version before bug was added this can come quite barrier. Its not like some of these caused faults are simple fixes to find and make.

      Originally posted by ZeroPointEnergy View Post
      32bit will not go away as long as we have processors that can execute those binaries.
      I agree with this and I will go further we will still have some 32 bit around even after we don't have processors to execute those binaries due to qemu usermode.

      But by current trends it cannot be a multilib or multiarch solution. It will have to be some for of container due to lack of 32 bit x86 maintenance forcing the use of libraries out of version alignment between 32 bit and 64 bit.

      Once the solution for 32 bit is containerised all the different distributions can drop their 32 bit support other than kernel and use a share solution so reducing their workload and put the workload on someone else like Valve.

      So unless the number of 32bit x86 users stabilise on Linux this is only going to get worse. This is why Valve not releasing a 64 bit client I am so mad about. 32 bit steam client does very little so slow down the decrease in 32 bit x86 usage in the Linux world.

      Originally posted by ZeroPointEnergy View Post
      Containers solve absolutely nothing you could not do with a plain system.
      There are one thing containers can do that you really cannot in a normal system speed effective. Time namespace where you are offsetting EPOCH.

      Old 32 bit programs will be needing to offset EPOCH. Its like why Linux kernel is now implementing case insensitive in kernel space. Once you start moving the EPOCH all old applications intercommunication needs to be kept on the same EPOCH or things go wrong.

      Its allowing the out of alignment library versions is something the container solutions win against multiarch/lib as well.

      ZeroPointEnergy you don't exactly like what I am saying. What I am saying is really the current state of play. Unless something happens to change it like a increase usage of 32bit x86 everything is going to keep on going the way it is. The writing is on the wall that Multiarch/multilib is going to basically dead and we return to container solution like what was used before Multiarch/multilib existed.

      This is also Valve problem since the Linux users are after games they think anything can work. Problem is without Valve actions matched to the Linux world installs being default 64 bit only they don't get market share and they don't really have a very big voice to make distribution maintainers listen to them.

      We had a few say it find that valve puts up a 32 bit client only because that it what they do on windows. Linux is not windows. Treating Linux like windows is a method to get slapped across the face in future. Yes Valve is thinking the small market share of Linux users they are seeing is also how big the Linux games market is when it not. When then are out by a factor between 30 to 100 times.

      Comment


      • Originally posted by oiaohm View Post
        Old 32 bit programs will be needing to offset EPOCH. Its like why Linux kernel is now implementing case insensitive in kernel space. Once you start moving the EPOCH all old applications intercommunication needs to be kept on the same EPOCH or things go wrong.
        Why do you think this can only be done in a container? If all 32bit applications have this problem you will have to solve it for all of them anyway. So in the case of a multilib you solve it in those libs. In the case of containers you have to fucking do it in every single container, which is more work for nothing.

        Originally posted by oiaohm View Post
        Its allowing the out of alignment library versions is something the container solutions win against multiarch/lib as well.
        It's a dirty hack and not a solution. We rather fix those libs or make shims. Deploying old libs even in a container is always extremely bad and never a solution.

        Originally posted by oiaohm View Post
        What I am saying is really the current state of play. Unless something happens to change it like a increase usage of 32bit x86 everything is going to keep on going the way it is. The writing is on the wall that Multiarch/multilib is going to basically dead and we return to container solution like what was used before Multiarch/multilib existed.
        It works now perfectly well and will work in the future. There is no reason at all to think this will change. If you want to use a system without multilib go on, do that. But there will always be people who require a multilib system and they will build and maintain one and there is no reason this will not continue to work.

        Originally posted by oiaohm View Post
        This is also Valve problem since the Linux users are after games they think anything can work. Problem is without Valve actions matched to the Linux world installs being default 64 bit only they don't get market share and they don't really have a very big voice to make distribution maintainers listen to them.
        Valve have the biggest game store on this planet, they have a pretty big voice and a lot of money to pay developers to do what is necessary to keep things working or improve them. 32bit will not go away.

        Originally posted by oiaohm View Post
        We had a few say it find that valve puts up a 32 bit client only because that it what they do on windows. Linux is not windows. Treating Linux like windows is a method to get slapped across the face in future. Yes Valve is thinking the small market share of Linux users they are seeing is also how big the Linux games market is when it not. When then are out by a factor between 30 to 100 times.
        You think that people don't install Steam because it is 32bit? Tell you what: no one who uses steam fucking cares. Having Steam as 64bit would solve nothing as all the games would still require multilib to work.

        Comment


        • Originally posted by oiaohm View Post
          Stefan was not the developer who was from codeweavers who started testsuite. You did not notice he stopped correcting. Kind after he had a chat with the one I had worked with in past. Weasel you have not been smart enough to pick up the reason why he backed off.

          https://docs.microsoft.com/en-us/win...tibility-fixes

          Windows contains it own versions of a container system. Yes the application compatibility database applying shims to alter ABI behaviour so applications work.
          No, shims are for broken apps that misuse undocumented quirks of an API.

          I don't even know what you mean with "backed off". He told you on this forum but I can't be arsed to look for it (or it was in a thread in which you posted bullshit like always). Obviously you're going to forget everything you don't like that shatters your viewpoint on the world.

          Comment


          • Originally posted by Weasel View Post
            No, shims are for broken apps that misuse undocumented quirks of an API.
            Microsoft uses it shim for misuse of undocumented quirks of an API. Also uses it for removed functionality like shimming over 16 bit installs with a 32 bit interpreter.

            Undocumented quirks of the API means you don't have to look at the shims microsoft has in there and see its not only that.

            Comment


            • Originally posted by ZeroPointEnergy View Post
              Why do you think this can only be done in a container? If all 32bit applications have this problem you will have to solve it for all of them anyway. So in the case of a multilib you solve it in those libs. In the case of containers you have to fucking do it in every single container, which is more work for nothing.
              Once you get into EPOCH offsetting you have a nightmare. We are not to 2038 yet. But different infrastructure groups have already picked their new EPOCH values. Please note Values as in plural. So instead of EPOCH being 1 of jan 1970 we now have current 14 different EPOCH values for 32 bit applications.

              So we now have the problem that different 32 bit programs have to run with different EPOCH values. Cars are worse their EPOCH is when they were first started.

              2038 problem due to what has already been done to the EPOCH value where it come EPOCH values makes this problem a lot more complex to solve than what you can solve in multilib. This is something where I start X application in container 1 with EPOCH from A group and I start X applicaton in container 2 with EPOCH form B group and everything can work. Yes one might be like 1 Jan 2000 as EPOCH and the other might be 1 July 2010 as EPOCH. Yes these are real chosen and in usage 32 bit time_t EPOCH values.

              Originally posted by ZeroPointEnergy View Post
              It's a dirty hack and not a solution. We rather fix those libs or make shims. Deploying old libs even in a container is always extremely bad and never a solution.
              Its a question of resources. Making patches to fix the libs or make shims is having the developer time to perform that work. How long are you going to wait to get it fixed???

              Originally posted by ZeroPointEnergy View Post
              But there will always be people who require a multilib system and they will build and maintain one and there is no reason this will not continue to work.
              The number of people who need a multilib system are reducing. This will be less man hours to fix the problems as they come up.


              Originally posted by ZeroPointEnergy View Post
              Valve have the biggest game store on this planet, they have a pretty big voice and a lot of money to pay developers to do what is necessary to keep things working or improve them. 32bit will not go away.
              Valve can yell all they like but they are less than than 1% of the market share Linux Distributions take care of. Really the is same problem as those who say Linux only has a 1% desktop market share so we will not release games/software for Linux.

              Valve has talked about doing containers around their games for awhile. Ubuntu though they were far enough along they could just push it and it would work.

              Originally posted by ZeroPointEnergy View Post
              Having Steam as 64bit would solve nothing as all the games would still require multilib to work.
              Having a 64 bit version of steam will make Steam as program more visible to Linux users. So possible increase their market share of 32 bit library installs in distributions eyes so give them more voice to tell distributions what todo.

              Wine and Audio production platforms have a way louder voice to Linux distributions because they have a larger market share of users than Steam.

              Comment

              Working...
              X