Announcement

Collapse
No announcement yet.

Valve Reaffirms Commitment To Linux While Also Releasing Updated Proton

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

  • #31
    Originally posted by oiaohm View Post

    There is a problem here.
    https://store.steampowered.com/hwsurvey/
    Click on the OS versions and notice how little 32 bit there is. All of OS X and Linux users are 64 bit installs. There is only about 2 percent 32 bit in use by OS people is using and that is all windows. Most of that is Windows 7 that goes end of life in 2020.
    You're mixing things, while there might be only two percent of windows users running 32bit windows, all of 64Bit Windows installs can run 32Bit applications.

    Think carefully about that.

    Originally posted by oiaohm View Post
    Remember https://www.phoronix.com/scan.php?pa...10-x8664&num=1 we stopped running these benchmarks because i686 was never winning against x86_64.

    Steam Client really should be 64 bit. We should be able to run some games from steam without needing 32 bit libraries. Its been years since the steam hwsurvey has shown a 32 bit Linux user. Anyone after performance with a Linux system will not be using i686 binaries they will be using x86_64.
    Again you're mixing things, the issue with 32Bit is not if a 32bit environment is faster or not than 64bit, the issue is that we need to be able to run the 32Bit applications that we do not have the source code of, and oh shock, there are applications that run fine as 32bit and that moving them to 64bits will only have a placebo effect but will cost money and effort.

    I know this is hard to believe to the youngsters here but there is plenty of commercial unix/linux software in the field that requires 32bit support, generally those are running on RH boxes, because RH will never engage in stupid shenanigans like Canonical.




    Comment


    • #32
      I wonder if a company like Valve is large enough to demand source code for the games. Even if they still withhold it from the consumers, this would still be a big win for digital preservation.

      That said, game developers are not always great software developers, it would be a pretty difficult job to get a lot of the games to compile. And this is not even throwing a slightly different architecture into the mix. Valve probably doesn't want to become a maintenance dump whilst gamer kids whine at them for not having ported a game to <next coolest arch>.

      Comment


      • #33
        Originally posted by ElectricPrism View Post
        Stats may be 2% 32 bit but what % of 96 bit has 32 bit multilib installed? I am willing to guess 90%+

        Next question, what % of those require multilib? I am willing to guesd 60-70%
        This is like asking who uses CAD software on Linux? I guess 10% of the users, let's remove all the libs that CAD software uses because "reasons" that have no basis on reality but help us achieve some perceived marketing goal.

        Originally posted by ElectricPrism View Post
        Idealism is nice when you dont have the price of practicality.

        Many games on steam include lost source code or no financial incentive and will remain 32 bit.

        Breaking compatability on peoples purchases for no good reason is not reasonable and foolish.
        Exactly, today is the games, tomorrow some obscure software or driver and when you wake up Linux is not good but for a tiny percent of people who in real life only use Linux/Unix for a very specific thing and for everything else only use Windows. These are the "it's the march of progress" type of user who will later complain it will never be the year of Linux because Linux is too hostile for end users.

        Changes like removing 32Bit multiarch screw those users who only run Linux.

        Comment


        • #34
          Very good that Valve acknowledges non corp distributions, and more, even offer them a hand.

          Comment


          • #35
            This drop multiarch support is maybe the most retarded proposal in 10 or even 20 years in history of Free Software.

            Comment


            • #36
              Originally posted by dungeon View Post
              I think you interpretating these numbers really freely but also wrongly, as better count installations manually of 686, 686-pae,etc.. so 32bit kernels installed there. These are likely not multilib installs
              How you enabled multi lib on debain.
              dpkg --add-architecture i386 And popcon checks your primary and
              dpkg --print-foreign-architectures If you have multilibs/multiarch enabled this returns i386.
              Originally posted by dungeon View Post
              Most of these are actually pure 32bit numbers, so are actually 32bit OS installs... something between 8% to 12% is right. Or if you like, believe it or not but to say optimally 10% people still uses Debian 32bit for real
              That is the way I was thinking the numbers were until I looked closer. Debian is after stats on how many users are using a particular repository. So those using multiarch/multilib on AMD64 are still depending on the i386 repository and are counted as users of it.

              As I said 13 percent is max that is being highly optimistic on possible market share for a 32 bit binary against debian that only works on 64bit systems like the steam client program. I will give you I was going intentionally on the high side. The best you could expect with a 32bit binary that in fact support running on 32 bit distribution and 64 bit distribution is 13% market share.

              If 8-10% are real 32 bit installs that means 5-3% of the userbase are using Multilib/Multiarch. Yes Valve could be ignoring 97% of the possible Linux market by the choice not to provide x86_64 binaries. This would more than explain why steam Linux user count is low.

              Comment


              • #37
                Originally posted by oiaohm View Post
                Not true. It does hamper you system. In enterprise server usage memory usage, cpu usage and disc usage is important when you are deploying on the cloud. i686 32 bit software in fact uses more disc space than its x86-64 equal. i686 32bit software consumes more cpu performing the same task as x86-64 equal so has a larger effect on the performance of your system. Horrible in most cases i686 32 bit uses more ram than x86-64 equal.
                You do realise that you do not deploy 32bit libraries unless you need them do you? and if you need them to run some enterprise software they are like any other requirement?

                We do not live on an ideal world and different users/environments have different needs, what you run on one server doesn't have to be the same you run on another or in a desktop.

                Originally posted by oiaohm View Post
                Please note that was pure i686 userspace vs pure x86-64 userspace issues. The memory issue get worse when you wake up having 32 bit software and 64 bit software loaded at the same time you have duplicated up on items like glibc in memory. Disc usage basically over doubles in places. Due more items to manage in memory even your cpu usage gets worse.
                /sarcasm

                Having all my applications written in 64bit assembler would guarantee that I use the minimum amount of resources both CPU and Disk storage-wise, we should throw away all the C++, Python, Java applications in the world which are inefficient on memory and disk space.

                sarcasm/

                Originally posted by oiaohm View Post
                Enterprise market has no interest in Multilib to support i686 32 bit software because of the harm it brings in their market. Desktop users the harm of Multilib can be ignored but those parties are not paying to the maintenance of software.
                What the Enterprise market has an interest on depends on each segment, what if I need to control hardware that requires 32bit drivers to control some industrial process?

                Is that not the Enterprise market? There is much more to Linux (or any operating system for that matter) than the latest cloud fad.

                Originally posted by oiaohm View Post
                The idea that multilib does not hamper your system is wrong. Multilib was a trade off that was thought be good idea because 32 bit pointers are smaller than 64 bit pointers so i686 programs should be more effective right? Problem is this turns out due to the improvements in the x86-64/AMD64 instruction set this is not the case. So multilib is basically a boat ancher on performance.
                At this point I have to say that you're either a troll, or a cargo cultist type of user, you clearly have no idea what are you talking about.

                Multilib is not a trade off, 32bit is not deprecated or obsolete, and having /lib32 (5.8M) on disk is not harming the performance of my computer not clogging my storage. It does enable me to run applications I could not otherwise run and will force me to run anything other than Linux

                Originally posted by oiaohm View Post
                openSUSE does not promise you that installing multilib will not leave your system unbootable. They removed direct building of 32 bit programs a long time ago.

                There is fairly much no where with enterprise support to run to get 32 bit x86 support.
                You have no clue what is that you speak of, sorry.

                As an anecdote; you sound like some people I have interviewed over the years who told me Email was an anachronic obsolete messy thing that was going to go the way of the dodo and dissappear because now we have IM. The funny part was mentioning over the course of the interview that part of these people's role was to maintain a critical system containing an email relay that is essential to the company. Ah the faces.

                Comment


                • #38
                  Originally posted by oiaohm View Post
                  Enterprise market has no interest in Multilib to support i686 32 bit software because of the harm it brings in their market.
                  I guess you are an enterprise user. The funny thing is that you only get 32 bit libraries if you opt to install them. Otherwise your system is 64 bit from the get go. So no harm if you don't have 32 bit software. No 32 bit software, no 32 bit libs. That easy.

                  I'm fully aware that 32 bit is legacy and that it needs to be phased out (gracefully). Just dropping 32 bit support isn't it though. You may be wringing your hands with hellish glee that multilib is going to be clipped in Ubuntu, but you are not the target audience of Wine and Steam.
                  1 percent of the Steam installed base is dependent on 32 bit support in Linux in one form or another. A 64 bit Steam client isn't going to solve that, because much of the catalog of sold games is 32 bit and will remain to be so. The Steam client is just a store and a launcher, it doesn't make other software automagically 64 bit capable if it runs 64 bit itself.

                  The way forward probably is in the form of a shared 32 bit (selfhosting) runtime which floats on a lightweight weight virtual machine to translate the input and output between the 32 bit environment and the 64 bit host.

                  Comment


                  • #39
                    Originally posted by oiaohm View Post
                    That is the way I was thinking the numbers were until I looked closer.
                    If you are really looked closer then you can tell me how much 686, 686-pae kernels you counted there? These kernels 64bit installer never installs, only 32bit installer gives you these And it is also highly unlikely that user will install these on 64bit OS install, etc...
                    Last edited by dungeon; 06-27-2019, 07:42 AM.

                    Comment


                    • #40
                      Originally posted by JPFSanders View Post
                      Again you're mixing things, the issue with 32Bit is not if a 32bit environment is faster or not than 64bit, the issue is that we need to be able to run the 32Bit applications that we do not have the source code of, and oh shock, there are applications that run fine as 32bit and that moving them to 64bits will only have a placebo effect but will cost money and effort.
                      There are 2 factors speed in being 64 bit over 32 bit. Address randomisation and other security things provided by the kernel either work better or work at all if you on a 64bit binary vs a 32bit one.

                      The reality is all this 32bit stuff is basically legacy and making up a smaller and smaller if install cases.

                      Originally posted by JPFSanders View Post
                      I know this is hard to believe to the youngsters here but there is plenty of commercial unix/linux software in the field that requires 32bit support, generally those are running on RH boxes, because RH will never engage in stupid shenanigans like Canonical.
                      RH does end of life stuff in time.

                      Hard part JPFSanders when you say we need 32 bit support. How small of a market are you. The reality is those needing 32 bit support are coming a serous minority and should not be surprised if distributions start going hey you want 32 bit support pay extra or do it yourself.

                      There always old saying the Silent minority. Because the minority don't make very much noise. Those wanting 32 bit support are the rowdy minority.

                      Comment

                      Working...
                      X