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

  • #71
    Originally posted by ThoreauHD View Post
    As long as they get this done within the next 13 years(18-5 support cycle), it will be fine. But it will need to be 64bit within that time frame, no matter how many games or print drivers we lose.
    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.

    Ubuntu does not have 13 years. Long term LTS distributions by what Ubuntu is doing 10 years of support. The 32 bit time failure year is 2038. You subtract support time frame that comes 2028. The last year a distribution should release with non containerised 32 bit 2027. Ubuntu LTS are only done on a even year that make the wall for a Ubuntu LTS 2026. This is not 13 years to solve the problem its 6-7 years.

    Please note containerising all the 32 bit applications is only the first step. The step is agreeing in things like EPOCH offsets to time.

    Originally posted by board View Post
    Snap is not mature, its sandboxing is too rough or too restrictive. We need something that covers most real world scenarios and that is customizable enough to satisfy the security needs of most users.
    Remember we only have 6-7 years todo this. Ubuntu developers are right on wanting drop 32 bit out the main distribution. This has to happen due to the fact we will have to use time domains on 32 bit applications. Distributions agreeing to support software for 10 years means they cannot agree to-do that if they know they have include something that will be broken inside 10 years.

    6-7 years to make snap/flatpak mature with time offset support or something else equal with the option if we fail lose all 32 bit support out any distribution that will sell companies/end users 10 year support contracts after 2027 like it or not.

    Comment


    • #72
      I'm not a programmer, but I see people saying to put all 32bit libraries into flatpak or snap, including the drivers? That seems crazy to me. Let's say that driver developers continue to support 32bit even if the OS doesn't. Some people now are even saying that compilers should stop supporting 32bit... That's insane! How are mesa developers going to compile the 32bit driver libraries then?! If you don't want 32bit libraries, delete everything i386 and disable the architecture, you have a choice. If you remove 32libs permanently you're taking everyone else's choice. That's tyrannical!

      Comment


      • #73
        Originally posted by BOYSSSSS View Post
        I'm not a programmer, but I see people saying to put all 32bit libraries into flatpak or snap, including the drivers? That seems crazy to me. Let's say that driver developers continue to support 32bit even if the OS doesn't. Some people now are even saying that compilers should stop supporting 32bit... That's insane! How are mesa developers going to compile the 32bit driver libraries then?! If you don't want 32bit libraries, delete everything i386 and disable the architecture, you have a choice. If you remove 32libs permanently you're taking everyone else's choice. That's tyrannical!
        Oh, don't listen to those jumped up arseholes... most of the people talking like that don't actually know much beyond installing their distribution's packages and acting smug.

        They aren't going to do away with multiarch compilers.

        Comment


        • #74
          About 32bit and the whole 2038 thing:

          You can have int64_t on 32bit.
          Just make time_t a int64_t everywhere and stop whining about it. (There is 20 years to do it)

          And ofc the existing 32bit software, that can't be recompiled, are all going to launch nuclear missiles ones their timers wrap ...

          So we should all immediately stop using 32bit or else your PC is going to explode in 20 years
          Last edited by Raka555; 06-25-2019, 04:00 AM.

          Comment


          • #75
            Originally posted by Jumbotron View Post
            Happy yet 32 bit retards? Happy that you're holding back the ONE Linux distro and really the ONLY distro that has and can bring Windows and Mac refugees into the Linux fold? You Geeks and Phreaks are Linux's BEST and WORST enemy!
            What a pathetic take. Windows is the dominant desktop OS and it has backwards compatibility going back to Windows 95. Linux desktop needs to offer what Windows 10 offers, if not more, to gain users.

            EVERYONE has gone 64 bit. IDE'S AND COMPILERS are dropping 32 bit support left and right. BUT OMG WINE AND MY 32 BIT VERSION OF QUAKE 2 IN UBUNTU?? TO ARMS...TO ARMS!! HUZZAH !!
            And yet you can still do this: gcc -m32 -o hello hello.c.

            Get OFF YOUR ASS....and learn how to package a Snap or Flatpak and/or learn LXD containers. Or pleaee SHOVE OFF as quickly as possible to your favorite "hobbyist" distro choice like Linux Mint or whatever Arch flavor of the month that hadn't been abandoned yet and let the adults continue to pave the way to a cleaner, more manageable Linux world with Ubuntu without us hearing you bitch dead tech.
            ArchLinux is 2 years older than Ubuntu, still has multilib, still not abandoned. Debian, 11 years older, still has multilib, Ubuntu just has to leverage on the work done by Debian developers. Also get out of here with that Snap/Flatpak garbage.

            Comment


            • #76
              Originally posted by BOYSSSSS View Post
              I'm not a programmer, but I see people saying to put all 32bit libraries into flatpak or snap, including the drivers? That seems crazy to me. Let's say that driver developers continue to support 32bit even if the OS doesn't. Some people now are even saying that compilers should stop supporting 32bit... That's insane! How are mesa developers going to compile the 32bit driver libraries then?! If you don't want 32bit libraries, delete everything i386 and disable the architecture, you have a choice. If you remove 32libs permanently you're taking everyone else's choice. That's tyrannical!
              Lets break this down.
              Originally posted by BOYSSSSS View Post
              Some people now are even saying that compilers should stop supporting 32bit...
              This is the first mistake. Has multiarch install been able to build multiarch system from source without using chroot/container? The answer in most cases no.

              Only the next release of debian will at long last be able to Multiarch build wine. Of course this still leaves a lot programs where you cannot this in fact includes mesa3d. Hang on wine project has been release 64 bit and 32 bit versions of wine. Lets go read the instructions.
              https://wiki.winehq.org/Building_Wine#Containers
              So the wine programs most people have been using the 32 part has been built in a container or chroot with only 32 bit parts.

              Lot of ways remove the 32 bit complier make sense on the host multi-arch system because mostly it does not work dependable. Have developer wanting to build 32 bit parts use containers/chroots that do in fact work.

              Originally posted by BOYSSSSS View Post
              How are mesa developers going to compile the 32bit Interface libraries then?!
              Pardon the correct will explain latter. Basically the same way they have been built now in a container/chroot with only 32 bit parts.

              Originally posted by BOYSSSSS View Post
              I'm not a programmer, but I see people saying to put all 32bit libraries into flatpak or snap, including the drivers?
              First horrible point is technically there are no drivers libraries in the flatpak runtime. There is a critical problem here what you will be calling driver libraries are not in fact driver libraries.

              Mesa libraries are interface libraries there is a fatal difference between a proper driver library and a interface library.

              When you program load a interface library what ever libraries and part using the interface library uses playing in your application memory. This is why if your application uses 1 version of C++ and mesa libraries uses a different one your program can completely bust up and fail. While mesa has this behaviour it has to built as part of your application run-time or else trouble.

              Now if mesa libraries were in fact using segregated loading of dynamic libraries covered in in the following video:
              https://www.youtube.com/watch?v=Rb1wdDdOizc
              They then could be called driver libraries as they are not going to mess your application up if what they are built use in libraries does not match what your application is using. This would be a totally different debate if mesa was in fact driver libraries.

              Originally posted by BOYSSSSS View Post
              If you don't want 32bit libraries, delete everything i386 and disable the architecture, you have a choice. If you remove 32libs permanently you're taking everyone else's choice. That's tyrannical!!
              I am not wanting to be rid of 32 bit programs at all I am wanting that they still work. Why I want them in containers where we can use namespace to set the time EPOCH value. This still brings us back to the 2038 problem.

              The way you work around the 2038 problem is change the Unix EPOCH value to something else the history standard has this as 00:00 1 of January 1970 this gives you rough 68 years before 32 bit time second counter causes errors in the year 2038.

              What 32 bit micro-controllers in you car has done is kind of horrible EPOCH in them starts on the date the car was first run and counts from then forwards. Car should not be in use in 68 years right(this is a little bit of finger crossing). The CLOCK_MONOTONIC in the Linux kernel has it EPOCH starting when you boot your computer.

              If you have not worked out yet both of these solutions have a problem. Lets say you want to play a game with someone who is on a different computer with a different EPOCH and program send 32 bit time across network. You now have horrible event of time travel where items have dates on one end in the future for them. So you need to be able to negotiate your EPOCH offset so that you can run the 32 bit programs on both ends with the same EPOCH offset. Remember with games a lot of the programs source code is lost for good today so we cannot rebuild them to fix. Same applies to some enterprise applications so we are deep in a hole.

              Even those making fully 32 bit distributions by 2027 have to decide how they are dealing with the 2038 problem if they are providing 10 years of support. Be the distribution 32bit or 64 bit running 32 bit applications will equal placing them in containers/namespaces and having to use different time domains.

              Reality is we are going into a world where we will have multi time domains and have to manage multi time domains to keep 32 bit programs working.

              Comment


              • #77
                Originally posted by Raka555 View Post
                About 32bit and the whole 2038 thing:

                You can have int64_t on 32bit.
                Just make time_t a int64_t everywhere and stop whining about it. (There is 20 years to do it)

                And ofc the existing 32bit software, that can't be recompiled, are all going to launch nuclear missiles ones their timers wrap ...

                So we should all immediately stop using 32bit or else your PC is going to explode in 20 years
                Its not 20 years in the future under 19 years now. Distributions doing 10 years of support in future straight up lose 10 years off that. That bring 8 and a bit years max. Ubuntu with there release cycles this comes down to 6-7 years.

                The time we have to solve this problem before enterprise class distributions will have to start making hard choices is not that long. Make everything use time_t int64_t the simple way for Linux distributions to achieve this is remove 32 bit support completely. Most of us don't want this solution. Containerisation and use the 2038 work around of moving EPOCH is about the only way we can avoid that.

                Comment


                • #78
                  Originally posted by oiaohm View Post

                  Its not 20 years in the future under 19 years now. Distributions doing 10 years of support in future straight up lose 10 years off that. That bring 8 and a bit years max. Ubuntu with there release cycles this comes down to 6-7 years.

                  The time we have to solve this problem before enterprise class distributions will have to start making hard choices is not that long. Make everything use time_t int64_t the simple way for Linux distributions to achieve this is remove 32 bit support completely. Most of us don't want this solution. Containerisation and use the 2038 work around of moving EPOCH is about the only way we can avoid that.
                  OMG I am so sorry.
                  We have no chance to make the deadline now.

                  I remember something about babies and bath water ...
                  Last edited by Raka555; 06-25-2019, 04:31 AM.

                  Comment


                  • #79
                    Originally posted by Raka555 View Post
                    OMG I am so sorry.
                    We have no chance to make the deadline now.
                    Exactly we need to think the deadline is basically now in development so we start trying different solutions. So that we have time to get the solution working before enterprise distributions have to make their final choices. If enterprise distributions have made their final choice to be 64 bit only why would they do any support to keep like 32 bit mesa functional? So by 2038 if we are not ready in 6-7 years 32 bit programs might not work any more because the 32 bit libraries have not been funded for 10 years by that point.

                    The 2038 problem can hit us two ways.

                    Comment


                    • #80
                      Originally posted by oiaohm View Post

                      Exactly we need to think the deadline is basically now in development so we start trying different solutions. So that we have time to get the solution working before enterprise distributions have to make their final choices. If enterprise distributions have made their final choice to be 64 bit only why would they do any support to keep like 32 bit mesa functional? So by 2038 if we are not ready in 6-7 years 32 bit programs might not work any more because the 32 bit libraries have not been funded for 10 years by that point.

                      The 2038 problem can hit us two ways.
                      Many of us wont even make it to 2038 and we are getting told to stop doing things we enjoy now because of an event we will never see...

                      Comment

                      Working...
                      X