Announcement

Collapse
No announcement yet.

Ubuntu 19.10 To Drop 32-bit x86 Packages

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

  • #61
    Originally posted by birdie View Post
    Where are you getting your shat from? [B]99% of games are 32bit only.
    Obviously, older games will still need some compatibility layer - but Steam already provides that. Feel free to name 3 or 4 modern games that are 32-bit only.. I'll do the same...

    For 64-bit any game with Unreal Engine - https://wiki.unrealengine.com/Linux_Support. as well:
    * Stellaris - just went 64-bit only (https://www.gamingonlinux.com/articl...-out-now.14274)
    * Counter Strike: GO (https://www.gamingonlinux.com/articl...-on-linux.7286 )
    * Civilization VI

    Comment


    • #62
      Originally posted by xfcemint View Post
      Wait...

      Shouldn't it be realtively straightforward to import 32-bit libraries packages from Debian? Perhaps some Ubuntu derivatives will do this (like Mint). I mean, Mint already has a Debian-based edition.
      Dude, I know damn well that you know damn well who used to suggest importing Ubuntu packages into Debian. That method in reverse is not an acceptable method.

      Comment


      • #63
        Originally posted by shmerl View Post

        I wouldn't count on it. They quoted lack of resources reason. Complaints aren't going to help that. Rather, those who need it will just migrate to other distros.



        Exactly. Steam doesn't matter. Games which are 32-bit do.
        Ubuntu became one of the most popular distros in the world. However, a company needs money to stay afloat, and they really don't have a way to make money. They've tried to make money a few different ways, but they are clearly struggling due to the lack of a revenue stream. As a result, recent releases have seen more loss of features than anything (Unity, Mir, etc.) Hopefully they find a way to remain relevant soon. Other distros (like Mint) rely on them downstream.

        As an earlier poster stated, maybe we should all just move back to Debian and focus efforts there.

        Comment


        • #64
          I think I get why are they doing it.

          Ubuntu is a distribution for noobs. They compose most of their users. The other segment they cover are servers.

          Those segments don't need 32-bit support. Noobs will just install snaps. Steam can ship with their own libraries, perhaps as a snap.

          Therefore, by dropping 32-bit, they're making it harder for all the downstream distros, which now need to add support for 32-bit manually, thereby losing valuable time and introducing bugs.

          On the other hand, Ubuntu can say goodbye to many knowledgeable users.

          At Ubuntu, they're gambling, but it should work. They are betting a lot on snaps working fine. Most users just won't notice the change.

          What a bunch of idiots. Or perhaps they are just mean and selfish? I don't know. What the f*** is happening?

          Comment


          • #65
            Originally posted by birdie View Post
            Where are you getting your shat from? 99% of games are 32bit only.
            That 99% does not line up for Linux native games.

            Originally posted by birn1107164
            Evendie; if modern games are mostly 64bit, and that's debatable, we have literally tens of thousands of games which will never be ported to 64bit. We have thousands of 32bit software titles as well and they provide life critical support.
            There are thousands of 32bit windows titles wine + hangover does not need 32 bit host platform support to run them. Those are a short term problem.

            Originally posted by birn1107164
            NVIDIA (that's how they are spelled) has not ended support for 32bit - they ended support for 32bit kernel drivers. They are still supplying 32bit libraries and will keep on doing that for the foreseeable future.
            This is less required than you would think. emugl from android and virtgl work both don't care if you only have 64 bit opengl hardware support. Virtgl inside a VM to it rendering engine outside allows 32 bit inside VM and 64 bit in the host works. emugl by pipe allowed 32 bit in container and 64 bit as host. So for opengl programs we don't in fact need host provided 32bit opengl support once we have these solutions completed off.

            With these advancements do we really need multilib any more. Or should we simple put old 32 bit Linux application in container and use virtgl/emugl to host particularly thinking they are most likely not getting security patched any more we might want to restrict file system access and other things. Wine with hangover means that 32 bit windows applications will not be needing 32 bit graphics driver libraries from Nvidia either.

            Comment


            • #66
              Originally posted by skeevy420 View Post
              Also, also, I'm gonna seriously ROFL when/if Steam decides to switch to Suse due to this.
              SteamOS and Ubuntu are both based on Debian. Why would they need to change anything?

              Comment


              • #67
                Originally posted by skeevy420 View Post

                Mint is a fork of Ubuntu which is not 32bit anymore...you didn't think that one through. Shit, as is Mint considered closing up shop recently...they're not going to pick up the 32bit torch when Ubuntu drops it.

                Both Cent and Suse both have official AMDGPU Pro drivers making them prime Steam candidates. RHEL is the only other choice and don't nobody wanting that for their gaming OS.
                Security, compatibility, performance, and maintenance should not be an issue at all. It's all this reliance of existing compatibility that is causing the containerized approach. IMO this is the best approach for now.

                Every distro out there is dated and has issues in some form or another. Someone needs to rethink how distributions are approached as a whole. Ubuntu tried to do a bit of that (and is failing) with snap. Packaging systems need to be improved, the concept of root and the root filesystem should go away (at least from user space), and kernel space should be off limits. That is the direction Windows is headed (future versions of Windows allow you to run apps in a sandbox VM). Security these days is paramount and we have the hardware to do it. Games can even be containerized if the the driver HAL is properly virtualized. I believe that Wayland will eventually cause a push in this direction. A containerized version of Wayland with it's own virtual hardware accelerated screen would not add much overhead, and as an added bonus, you'd get security to boot. No more invasive DRM or cheat detection (or cheats). It's all containerized with the game itself.

                Unfortunately, all that I've mentioned takes a lot of work and a lot of change, and there aren't enough developers willing to commit to an effort, much less even having a consensus on what needs to be done. The UNIX mentality is dated, but Linux, the BSDs, etc. are so ingrained in it, things will likely never change.

                Comment


                • #68
                  Originally posted by oiaohm View Post

                  There are thousands of 32bit windows titles wine + hangover does not need 32 bit host platform support to run them. Those are a short term problem.

                  With these advancements do we really need multilib any more. Or should we simple put old 32 bit Linux application in container and use virtgl/emugl to host particularly thinking they are most likely not getting security patched any more we might want to restrict file system access and other things. Wine with hangover means that 32 bit windows applications will not be needing 32 bit graphics driver libraries from Nvidia either.
                  I wonder how long it'll be until we end up using LIMES with Tequila Shots. You know, the LInux Multi-architectural Environment System.

                  Comment


                  • #69
                    Originally posted by leiptrstormr View Post

                    SteamOS and Ubuntu are both based on Debian. Why would they need to change anything?
                    Well, Ubuntu felt the need to change something hence the topic at hand...and because I'm a little retarded and forgot SteamOS was Debian based...

                    Comment


                    • #70
                      Originally posted by oiaohm View Post

                      That 99% does not line up for Linux native games.



                      There are thousands of 32bit windows titles wine + hangover does not need 32 bit host platform support to run them. Those are a short term problem.



                      This is less required than you would think. emugl from android and virtgl work both don't care if you only have 64 bit opengl hardware support. Virtgl inside a VM to it rendering engine outside allows 32 bit inside VM and 64 bit in the host works. emugl by pipe allowed 32 bit in container and 64 bit as host. So for opengl programs we don't in fact need host provided 32bit opengl support once we have these solutions completed off.

                      With these advancements do we really need multilib any more. Or should we simple put old 32 bit Linux application in container and use virtgl/emugl to host particularly thinking they are most likely not getting security patched any more we might want to restrict file system access and other things. Wine with hangover means that 32 bit windows applications will not be needing 32 bit graphics driver libraries from Nvidia either.
                      99% of games are 32 bit only? News to me. The vast majority of games I play are 64 bit. Maybe the older stuff is 32 bit. Anything developed in Unity3d or UE4 likely is 64 bit. Also, don't confuse Ubuntu dropping 32 bit support with Wine dropping 32 bit support. Wine builds Ubuntu packages (https://wiki.winehq.org/Ubuntu), not Ubuntu. Finally, if you read the actual mailing lists posts, they are not dropping 32-bit without recourse. They are investigating how to best handle the removal of 32 bit packages. I assume, from reading the mailing list post, that no "new" 32 bit packages will be accepted. Then i386 is mentioned a lot, which leads me to believe there is some confusion of 32 bit support vs i386 support (vs i586 or i686). Time will tell and I'm willing to bet that the final solution will work out of the box with all existing software, but with a slight nudge for 32 bit applications.

                      Also, this myth about 32 bit applications running faster is just that, a myth. It was true early on that AMD64 could run 32 bit applications faster due to the way the architecture was implemented, but times, and architectures, have changed. These days, any decent hardware will run 64 bit applications just as fast, if not faster, than 32 bit equivalents.

                      Comment

                      Working...
                      X