Announcement

Collapse
No announcement yet.

Valve Reaffirms Commitment To Linux While Also Releasing Updated Proton

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

  • oiaohm
    replied
    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.

    Leave a comment:


  • oiaohm
    replied
    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.

    Leave a comment:


  • Weasel
    replied
    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.

    Leave a comment:


  • ZeroPointEnergy
    replied
    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.

    Leave a comment:


  • oiaohm
    replied
    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.

    Leave a comment:


  • ZeroPointEnergy
    replied
    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.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by ZeroPointEnergy View Post
    Cry as much as you want. 32bit will stay, if not in Ubuntu then in other libs. Luckily this is Linux so we can do what we want with the open source software and we don't have to listen to people like you who don't care about not breaking the userland.
    Ubuntu will have reduced multilib/arch for 32bit x86 as a temporary measure with 32 bit in containers long term. The userland is changing.

    I was not crying. I was just stating that you need to be aware how low the 32 bit x86 usage in fact is on Linux. Also the fact 32 bit x86 usage dropping.

    Redhat and Ubuntu both started working on containerised solutions a while back.

    Also its false theory that you can do what you want with open source software. If the major distributions end up only looking for 64 bit graphics drivers so Intel and amd and Nvidia are only testing those. Can you now describe how screwed you are.

    The reality with the declining multilib usage there is going to come a point where libraries games need will not be tested on 32bit x86 so are broken badly. If this is something like mesa you need to interface with your graphics card you are mega screwed.

    Reality is nothing you have said changes what the statistics are saying. Now I do believe that if steam does release a 64 bit client more end users will see steam and this might be able to level out the multilib/multiarch decline heck it might even increase it usage.

    ZeroPointEnergy have you tried to run any a.out format binaries recently on distributions. That right those are gone. We saw the same kind of decline before kernels removed support for those. Yes there are a few closed source games and programs that were on linux that don't work because a.out support went as well.

    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. Unless 32 bit x86 programs truly do increase their market share on linux the support is doomed. Yes when a.out disappeared we had people say these other parties would pick up the workload some of them tried then gave up on it.

    Leave a comment:


  • ZeroPointEnergy
    replied
    Man, I don't even know where to start, I did not even made it half to your latest drivel without head-desking twice. I have to agree with Weasel that you are completely retarted.

    Cry as much as you want. 32bit will stay, if not in Ubuntu then in other libs. Luckily this is Linux so we can do what we want with the open source software and we don't have to listen to people like you who don't care about not breaking the userland.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by ZeroPointEnergy View Post
    They are open source games from the repo, they are not representative for the 5000+ games we have available trough Steam today which are mostly 32bit.
    Lets look at debian most popular installed games.
    https://debtags.debian.org/search/?w...ag:game::board
    Do take note of the percentage there. 33% on games-board on that page is 33% of the debian install base has that installed. There is absolutely no use for that on server. Most popular games on debian are somewhere around 1/3 of the debian userbase installed. Steam is less than 1 percent installed on Debian by popcon.

    Reality here is if you are talking top 100 games installed on Linux all of them are open source from the distribution repos. Steam top 100 has to be offset by at least 200-300 places on Linux due to how popular the open source ones are due to low cost, simple to find and simple to install.

    Originally posted by ZeroPointEnergy View Post
    Linux is mainly used as a server OS, so it is to be expected that in those usecases multilib is not used. But we are talking about the Desktop here and there IF you play games (except if you play the hand full of open source games from the repo) then multilib is REQUIRED.
    I don't exactly call 200-400 games depending on your distribution a handful. Yes Debian is 400+ games in the repo. So competition from the host OS against buying games is a lot harder on Linux than on Windows or OS X due to how many games Linux Distributions come with. This is why steam not having a 64 bit binary on Linux for their store so not showing their wares is harming them.

    Looking at popcon you have to have 33% of debian installs are desktops of people who play games. 13 percent or less have multilib. So restricting to know debian gamer its less than 50% have the installed the means to run 32 bit programs and dropping.

    You said 5000+ games in steam. Less than 1 percent of Debian users have steam installed. So those 5000+ games only effect 1 percent of Debian users over all or maybe 3% of people on debian who run desktop and play games. So steam is accessing less than 1/30 at best of the debian user-space they could this could be a lot to-do with the fact they don't provide a 64 bit installer so are invisible.

    Originally posted by ZeroPointEnergy View Post
    Look, in the end there are enough people who need multilib and if Ubuntu and whatever distro removes it some other distro will pick it up. There are companies paying for the development and the Linux gaming community is big enough to support all the required stuff on it's own.
    The reality is over 50% of the Linux game players will not give a rats if multilib disappears and this number is growing. Less than 3% of Linux gamers give a rats if steam disappears because they are not using it.

    Wine users are a way higher percentage than steam users this is a lot todo with wine having a 64 bit client so findable. Wine users are still less than 50% of the Linux game market. Linux top 100 games installed are all 64 bit and all open source.

    I know the reality is hard. Steam is a big thing on Windows and OS X. Reality on Linux it a drop in the bucket to the point of being unknown. Lot of this is Valve fault for not putting out a 64 bit client. Please note 64 bit steam client does not mean the provided games have to be 64bit. Sometimes you have to bite the bullet and do particular things to be visible and have market share. The lack of steam market share on Linux distributions means Linux distributions can at times say stuff it we will not do what Valve wants as it does not effect enough of our user base.

    If the Ubuntu person was looking at the market uptake number of steam of course Ubuntu people would be right to say we are only going to effected a small not that important part of our user base if we do this. Its less than 5% user base loss for a 50%+ save in build time and maintenance.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by Weasel View Post
    Most are just corner cases or undocumented features. Some stuff is not stable because it's not documented, you're not supposed to rely on it. In fact, this is just subtle behavior change. In most other ABI breaks, like you see in Linux, you get total different prototypes aka stack smash or page faults. So stop this pathetic attempt at grasping for straws as if Windows is as unstable as Linux userland. It's not even close. Not even close.
    I did not say that the Linux ABI breaks are not worse. Most of the Linux stuff that breaks is from packages that do not give ABI promises either. As I have pointed out to you in the past some packages on Linux give ABI promises others don't.

    Originally posted by Weasel View Post
    I mean, Stefan from CodeWeavers also told you it's stable when you argued the exact same point, but clearly it's like talking to a wall. You're just hopeless like that. Keep going with that technobabble.
    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.

    So some of windows ABI flux is in fact documented. Yes when Microsoft does a major ABI break they normally do a shim to hide it and you are hoping that your application gets put on the list to get the shim or it just does not work any more if it effected by the change. Yes stack smashing or page faults happen from some of these changes. So this is no different to Linux except Linux does not have a shim system to mask this over..

    Basically the Windows ABI is unstable. Windows has form of container system that detects the application starting and applies shims to alter the appearance of the ABI the application sees. On top of this you have other variations in the ABI.

    The windows ABI is not stable like it or not. Windows design as application like ABI containers due by shims. So if a old application works or not depends on if the ABI fix it needs is in the application compatibility database or not lot of the time. Windows 10 microsoft had to trim the application compatibility database breaking a lot of applications.

    Leave a comment:

Working...
X