Announcement

Collapse
No announcement yet.

Ubuntu To Provide Select 32-Bit Packages For Ubuntu 19.10 & 20.04 LTS

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

  • #91
    Originally posted by oiaohm View Post
    Windows 10 was release 22 July 2009 so we are basically 10 years from that and we still have 64 bit binaries with 32 bit installers.
    I hope you mean Windows 7, because Win-

    Originally posted by MamiyaOtaru View Post
    WAT. That was the Windows 7 release date. Win10 was 2015
    -noooooooooo!!!

    Comment


    • #92
      Originally posted by jpg44 View Post
      Having to figure out which binaries are a dependancy for some 32 bit only software is more effort than just continuing to build everything for 32 bit, which requires no effort since its an automated process. Again, messing with the status quo on 32 bit libraries makes absolutely no sense. I am also of the view getting rid of 32 bit images was a mistake and we see getting rid of images was part of their scheme to basically throw gamers, printer driver users, steam users and desktop users in general under the bus. Ubuntu doesnt give a damn about what its desktop users think.
      Makes sense with printers that business normally keep laser printers in usage for 20 years+. So yes laser printer drivers have cross the 2038 threshold. We really do need laser printer makers to be providing 64 bit printer drivers because 32 bit are really no longer suitable for how long printer will be in service for. Gamers and Steam users are not buying Ubuntu product so they are not Ubuntu customers so stiff briskets.

      Ubuntu cases for enterprise desktop users who buy their support contracts more than the non paying freeloaders.

      Problem for the 2038 means 10 years before for ubuntu this is 2028 not far off. The current system for using 32 only software cannot be used. Ubuntu cannot be shipping with something that will not work properly for 10 years. This idea that automated process can just keep on building libraries like they have been built and installed how they have been installed is not possible.

      We need to change over to installing 32 bit libraries and programs in containers were we can when 2038 comes up change the EPOCH value and keep those 32 bit programs working. If at 2028 we have this solution Ubuntu and other enterprise distributions will be able to keep on shipping and maintaining 32 bit libraries because they will know they can keep them working for 10+ years from that point.

      Yes Ubuntu post was clear snap/containers have to be used going forwards as for 32 bit libraries well.

      Comment


      • #93
        Oh, it feels so good to be right.
        People here make a lot of nonsense statements here:
        - LXD containers are intended for use by normal (non-technical) users.
        - Flatpak and Snap are good solutions for everything.
        - VM with Virgl is a good solution for gamers.
        - QEMU provides enough performance for gaming.
        - It is easy to bundle everything on your own, up from glibc, including GPU drivers.
        - Canonical have no time, nor resources to support i386.
        - It costs them a lot of money to support it, so it is completely unprofitable.
        - They don't care about Steam or WINE, because this software is not widely used by their customers.
        - The average Ubuntu user don't play games or use WINE at all.
        - We should force game developers to rewrite old games.
        - If Canonical abandon support for i386, it will have a huge impact on Windows programmers. They will stop producing 32-bit installers.
        - Win32 applications are legacy software.
        - They perfectly know what they are doing and this is the right decision to drop support for multiarch.
        I knew from the very begging that they were wrong.

        Comment


        • #94
          Originally posted by the_scx View Post
          - It is easy to bundle everything on your own, up from glibc, including GPU drivers.
          What drivers. That is the problem.

          Mesa3d is not segregated linked. Was not design that way. Its a interface library.

          Nvidia user libraries read the license. "provided that the binary files thereof are not modified." Nvidia classes modified as altering how they are bundled.
          Nvidia is not using segregated linking fully either. So there is no such thing on Linux in user space libraries as a item you could call a GPU driver. Everything is GPU interface libraries.

          Libcapsule was great work we need more of it.


          [QUOTE=the_scx;n1109462]-VM with Virgl is a good solution for gamers.
          We don't know how well that will perform over time. Virgl is improving in performance. There Vulkan support has way lower overhead than the Opengl.

          Originally posted by the_scx View Post
          The average Ubuntu user don't play games or use WINE at all.

          Sorry the average Ubuntu user who takes part in surveys less than 10 percent of them have Wine or Steam installed. So the average Ubuntu user don't use stream or wine. That does not mean they don't play native games. Debian users have higher Wine and steam count. Its been kind of a scratch head when you look at the statistics of debian and ubuntu why in hell has Ubuntu had the gaming company support. Maybe because by dumb luck supporting Ubuntu their stuff mostly works under Debian?

          Comment


          • #95
            Originally posted by oiaohm View Post

            Sorry the average Ubuntu user who takes part in surveys less than 10 percent of them have Wine or Steam installed. So the average Ubuntu user don't use stream or wine. That does not mean they don't play native games. Debian users have higher Wine and steam count.
            I looked at that link and I'm not sure I see what you see. Where is the statistics for Steam and Wine? Where did you find a statistics for Debian?
            Last edited by BOYSSSSS; 27 June 2019, 06:32 AM.

            Comment


            • #96
              Originally posted by Jumbotron View Post

              It's OLD cruft that has to be maintained and packaged properly when Canonical does not have the internal resources to hang on to that stuff like a Microsoft or Apple or even IBM/RedHat. But even Microsoft and Apple are shoving 32 bit aside more and more.

              If for nothing else....there is NO need to maintain TWO code bases when only ONE can properly handle and address the coming ( and now in the present ) memory model where EVERYTHING is or can be addressable memory with persistence.

              Just like with lazy web developers hanging on to Adobe Flash code and NOT recoding for HTML5....it's HIGH TIME to give a rude, kick the ass reminder to lazy 32 bit code monkeys to get off their asses and port to 64 bits. Or abandoned their shit and let somebody else MORE capable do it for them and take over that area.
              First off, just to be clear, there are not two code bases. The same code is compiled one for x86 and one for x86_64 (and s390x, powerpc, 32-bit and 64-bit ARM, etc. etc.) It's unlikely for x86-specific bug fixes to be a significant drain on resources (since it'd probably also make it not build on some other platforms.) A lot of the packages are maintained by Debian, who support even more platforms, and keep things patched up to support all of these platforms (they also pass these patches upstream), so it would take little effort on Canonicals part to maintain the code.

              What WOULD be a drain on resources is building all those packages -- my copy of Synaptic shows 63521 available pacakages! That is probably for x86 and x86_64, and there's metapackages, and non-platform-specific pacakges, but... it's got to take a while to build like 30,000 packages. BUT, I would not be surprised if all wine's depencies like glibc, x libs, qt, glib, sdl, sane, samba, opengl stuff, avcodec/ffmpeg, etc. altogether might take less time to compile than chromium (the built-from-source google chrome) alone. (firefox and libreoffice are also quite portly builds.) 30,000 packages are a pretty big drain, some maybe 100 base libraries (that compile relatively quickly) are not. Having them as first-class packages rather than bundled in a flatpak also ensures you would get security updates simultaneously with your main libs (although I must admit exploiting a linux-side bug in an out-of-date 32-bit lib, via a windows executable under wine, does sound like a difficult attack vector.)
              Last edited by hwertz; 27 June 2019, 10:42 PM.

              Comment


              • #97
                Originally posted by Floturcocantsee View Post
                Seems like a good outcome. People get their legacy 32-bit application support and Ubuntu drops useless 32 bit packages like GCC/LLVM.
                Your comment is funny since these are primary packages that can't be discontinued. You need GCC to actually build the libraries and you need LLVM for Mesa. Not having LLVM is same as dropping 32bit entirely when it comes to Steam.

                Comment


                • #98
                  While it is nice to be able to run old programs, what I don't like is architectural dependence. It is an unnecessary obstacle for ARM, POWER and such to proliferate. Containerization can't help with that either.

                  Sorry game devs, but the moment you delete the source code, or go out of business with the source code into the grave, that is when the software is lost.

                  Burn, 32-bit, burn…
                  Last edited by andreano; 17 September 2019, 11:52 AM.

                  Comment

                  Working...
                  X