Announcement

Collapse
No announcement yet.

Valve Reaffirms Commitment To Linux While Also Releasing Updated Proton

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

  • #21
    Originally posted by stormcrow View Post
    My guess is the Steam Windows client is probably 32 bit too. Shared source tree. Like I said earlier, on Windows that doesn't matter. The experience for the Windows end user is the same either way (roughly 96% of their clients). And before you say "Just recompile!", it's no where near that simple. When Valve is ready to move to a 64 bit client they'll probably release all supported clients as such. Till then take your 32 bit client and be grateful you even have that. There's no financial reason for Valve to support Linux. They could (very) easily get along without Linux user revenue.
    It a shared source tree between Windows, OS X and Linux. Valve have released 64 bit clients for OS X. Really take your 32 bit client and be grateful is backwards. Valve should be grateful Ubuntu has not done worse than threaten to drop 32bit support.

    Canonical(ubuntu) and Redhat could get along quite well without Valve as well. Zero income to Canonical or Redhat comes from the gamer market.

    Originally posted by slalomsk8er View Post
    Can it be, that this are nearly 100% of the desktop/workstation Debian installations? I guess I never installed multilib on my servers but on all my desktops.
    Did you pay for support on any of those desktops. I would guess no. 80 percent of the Linux userspace are not using 32 libraries. In that 80 percent are the ones paying Redhat and Canonical.

    RHEL7 in 2014 from Redhat does not have 32 bit support you cannot install steam on that or use 32 bit wine or use 32 bit printer drivers. The last version of redhat that you can install steam on is RHEL6 that was release in 2010 they have dropped the 32 bit kernel from Fedora already as they will not be needing another kernel 32 kernel for long term support for RHEL6. Redhat will not be needing to be testing client side 32 bit libraries past the end of 2020 for the products they sell.

    I am sorry to say slalomsk8er both you and Valve have basically been freeloading off the enterprise distributions.

    I serous-ally do mean freeloading. Canonical and Redhat are making zero income from x86 32 bit library support. x86 32 bit support is a drain on both Canonical and Redhat bottom line.

    SUSE may still have 32 bit support but they have removed the ability to build and they do not promise that installing 32 bit library will not bring you system crashing into complete non functional death in fact there manual goes on to warn you that using 32 bit runtime may result in your install no longer working.

    Welcome to o great. None of the major enterprise distributions have any interest in keeping 32 bit x86 going.

    Valve, Codeweavers and other parties who in fact have business models where they make money off 32 bit support working really need form a collective and form their own kind of distribution that takes care of x86 32 bit on Linux. You cannot expect to freeload forever without having to put up with the one making the money altering the rules the way they like.

    2020 the year OS X and Redhat decide they no longer need 32 bit x86. 2019 Canonical wakes up in 2020 they are going to be left holding the 32 bit x86 maintenance bill and they really don't have the volume of staff to handle it without Suse or Redhat support. Yes Canonical will be attempting to cut 32 bit library support to the bone and most likely this will still break some of valve games and Canonical going to be like suffer you are not paying us Valve and you bad mouthed us Valve.

    Valve has serous-ally responded to this problem completely the wrong way.

    Comment


    • #22
      Originally posted by r_a_trip View Post
      Multilib works right now. It doesn't hamper your system in any way. It is only called upon when running 32 bit software. The rest just hums along nicely on 64 bit.
      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.

      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.

      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.

      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.

      Originally posted by r_a_trip View Post
      Oh well, at least this got me reacquainted with openSUSE Tumbleweed KDE. It's nice to be back where I started. It was SuSE Linux 7.0 that made me switch full time to Linux.
      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.

      Comment


      • #23
        I hope they focus on Debian and Arch.
        With Debian you basically have support for Ubuntu, Pop OS and Mint, which are great for people who want it simple.
        Arch is like Debian the base for a lot of distributions (although their users usually know what their doing anyway).

        Comment


        • #24
          Valve should better draw a line and adopt a policy to promt future productions to be 64bit. It is unavoidable. They will have to do it at some point in time.

          Other than that I wonder how much of a burden is for distributions and ubuntu in particular to provide these 32bit libraries. Is it a matter of compiling with certain compiler flags? Is the process automated? Do they even create the packages themselves or do they get them from debian?

          Comment


          • #25
            Originally posted by zoomblab View Post
            Valve should better draw a line and adopt a policy to promt future productions to be 64bit. It is unavoidable. They will have to do it at some point in time.
            Nothing makes me happy until I can run games on a ARM or RISC-V Computer. x86 support should be scrapped altogether. (Just as we talk about some arbitrary ideas how it should be)
            Originally posted by zoomblab View Post
            Other than that I wonder how much of a burden is for distributions and ubuntu in particular to provide these 32bit libraries. Is it a matter of compiling with certain compiler flags? Is the process automated? Do they even create the packages themselves or do they get them from debian?
            I think the biggest issue is testing them for subtle breakage. Probably the sanest way would be to just pick 32bit libs from a older version, but unfortunately sometimes the 32/64 bit versions need to match. On debian/ubuntu the arch-independent stuff is in separate packages, referenced by all architectures - that implicitly means you can only install the matching version for 64bit or the version for 32bit (so you dont want the versions to differ)

            Comment


            • #26
              Originally posted by zoomblab View Post
              Valve should better draw a line and adopt a policy to promt future productions to be 64bit. It is unavoidable. They will have to do it at some point in time.

              Other than that I wonder how much of a burden is for distributions and ubuntu in particular to provide these 32bit libraries. Is it a matter of compiling with certain compiler flags? Is the process automated? Do they even create the packages themselves or do they get them from debian?
              You forget, that Canonical not have to compile only a few 32 bits libraries/programs. There are thousands of them. Many of them are practical not used anymore.

              One reason to drop 32 bits is that compiling a library or a program requires time. Some of them, more than a day. So removing many of the 32 bit packages would save this time.

              I am pretty sure, that are more cases, where dropping 32 bits library would save time and money.

              Comment


              • #27
                I could only say here that on Debian 10 32bit is actually never better

                Everything is working, but OK devs might decide to break it in near future or maybe not in so near future

                Comment


                • #28
                  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.
                  Actually, installing :i386 multiarch libs doesn't do any harm to your system at all. The 32bit versions of the packages only run for programs that are linked to them. Your argument is as false as saying that having a static binary on your system that you don't run slows it down. For software that will never be ported to 64 bit (i.e. unmaintained software) 32 bit multiarch libs are the only way to get them to execute. Doing away with multiarch means it is much much harder for "normal" (i.e. non platform support) devs (and users) to install, update, maintain their systems if they use 32 bit software that won't or can't be ported to 64 bit.

                  Once this change goes through you won't be able to deboostrap a 32 bit chroot on your system, so you can't even bug fix your own system any more. Under this situation if you buy a new GPU you probably won't be run Wine 32 bit programs any more; where as with multiarch this isn't an issue. LXDs won't fix this issue, in fact it will make it much harder as every coder will need their own build farm and full OS 32 bit repo just to fix one lib. LXDs aren't the fix they're just a different flavour of the problem. The number of user submitted fixes will fall to zero and "many eyes make bug shallow" will be a thing of the past for 32 bit.

                  Comment


                  • #29
                    Originally posted by dungeon View Post
                    I could only say here that on Debian 10 32bit is actually never better

                    Everything is working, but OK devs might decide to break it in near future or maybe not in so near future
                    In another post in a different thread I screwed my debian popcon https://popcon.debian.org/ maths up.

                    I forgot you have a AMD64 bit system with i386 enable in popcon it counts twice. I was thinking 12 percent i386 systems was high.
                    i386/AMD64
                    22886/170889=~ 13 percent people max who have AMD64 bit Debian have 32 bit libraries installed. Popcon numbers may not be 100 percent right.

                    85 percent+ of the Debian AMD64 users cannot install Steam or 32bit wine by popcon. They don't have 32 bit installed.

                    This image at Debian shows a really scary trend for i386 on Debian. i386(your 32 bit multi lib and you 32 bit system usage) usage is on a nice constant dropping like that if nothing changes it will basically hit zero in 6 years. Yes that trend started 2014 the same year RHEL7 was released without 32 bit support. Yes the trigger was pulled on i386/x86 32bit multilib in 2014 by redhat with the release of RHEL7 and bullet is slowly killing i386 with no sign of recovery.

                    The amount of testing Ubuntu is getting for free using i386 from Debian parts is also dropping like this chart is.

                    There is no where to go with high quality assurance and keep x86-32 multilib support with the current trends.

                    We will be lucky if this levels out at 5% currently there is no sign that this trend is levelling off any time soon. No matter how you look at the number those who need 32 bit multi lib on debian without question are in the minority.

                    Yes these numbers make Valve steam client lacking x86_64/AMD64 binary support and claiming Linux support seam stupid. Not support 85+% of the userbase of platform and saying you support is kind of stupid. Worse when you work out the user base Valve is targeting in Debian is shrinking rapidly.

                    These numbers are not a growth in new users causing the stats to move. This is simple case the exist i386 users are disappearing as they update their systems and they find they don't need i386 stuff to get their work done.

                    Comment


                    • #30
                      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

                      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

                      Couple years ago that was like 15%, so number goes surely down, but it is still quite high

                      Popcon numbers may not be 100 percent right.
                      Of course, someone might use complete 32bit install but just 64bit kernels or so... it is impossible to be 100% sure there

                      Still, i dunno why you keep saying multilib, multilib... as most of these are just pure 32bit OS installs
                      Last edited by dungeon; 06-27-2019, 07:17 AM.

                      Comment

                      Working...
                      X