No announcement yet.

Ubuntu 19.10 To Drop 32-bit x86 Packages

  • Filter
  • Time
  • Show
Clear All
new posts

  • #81
    Originally posted by Weasel View Post
    Retarded analogy. Software (and games) doesn't have a "lifespan", just as old movies don't have a "lifespan". This is as retarded dropping support for reading mp3 files because it's an "old" format. Get over it.
    I didn't say it was an analogy, that was the bit about gangrene in the last post. What I said was that it reminded me of the people who live and own apartments in the same complex. It's also funny how you tell me to "Get over it" when you're the one complaining about a decision by Canonical.

    Also, dropping support for MP3 files really doesn't work at all as analogy as it doesn't cause any duplication of effort, wasted disc space or performance loss. Complaining about dropping i386 is more like the people who complained about VHS cassette players going away, vinyl records and tapes being replaced CDs or when CDs went away in favor of digital music without optical media.

    Originally posted by brent View Post
    Well, yeah. The alternative to dropping i386 is of course to not drop it completely. What did you expect? Canonical says i386 is a maintenance burden. My suggestion addresses this. It might even be possible to agree on a really small set of core libraries. Could be less than 100 packages. I can't imagine that would be a serious burden, particularly because Ubuntu is standing on the shoulders of giants, namely Debian.
    Your suggestion doesn't really address as much as slightly mitigate it. Dropping some, but not all, is inevitably going to lead to developers making incorrect assumptions of what's available which in turn is going to cause headaches for end users. That still leaves a huge amount of stuff that needs to be looked after and this is about being able to re-focus resources away from supporting a legacy architecture that hasn't really been relevant in almost a decade.

    I don't agree. This would prepare developers for the end of i386. If you just ship a small set of libraries, it will force developers to ship non-core libraries themselves, which is a good preparation step for a full drop possibly some years later. It also signals clearly to developers that the end of support is coming.
    I highly doubt that devs will do anything of the sort without a shock to the system like this when we've known for the better part of a decade that i386 is eventually going to go away and we've already seen Clear Linux demonstrate the advantages of doing so. We're talking about something that's been about as clearly foreshadowed as Y2K was, except even longer in certain regards.

    Ubuntu's current plan is simply throwing out the baby with the bathwater. Lots of people might migrate to something else, especially commercial, possibly paying customers.
    Paying customers that aren't using the ARM flavors are generally going to be using LTS versions anyway so this argument doesn't really apply. They're intentionally introducing this in a non-LTS version to give developers at least 6 months to get their applications to switch over to the AMD64/x86_64 versions of the libraries before it really starts to matter to their bottom line.

    Originally posted by skeevy420 View Post
    That analogy only works if they're buying or owning a place to live, leasing property w/o a warranty, and other similar situations.
    First of all that wasn't an analogy and second of all I thought it was apparent that I was talking about people who actually own their apartments and thus have an actual say in how the shared infrastructure of the building is maintained. On top of that, most old people who don't live in service living facilities own their own apartments/houses.
    Last edited by L_A_G; 19 June 2019, 10:27 AM.


    • #82
      Originally posted by Weasel View Post
      Retarded analogy. Software (and games) doesn't have a "lifespan", just as old movies don't have a "lifespan".
      Actually, archival of documents, movies, etc. is a very hard problem. Not only you need the hardware around that can read the media, but also the software that can decode the formats. This is why long-term archival always relies on vendor neutral open standards.

      For software, the programs that are going to work potentially indefinitely are FOSS. Proprietary software will stop working at some point, sooner or later.

      Originally posted by xfcemint View Post
      If there are security problems, patch them.
      Some security problems cannot simply be patched. When the Spectre flaw was disclosed, 32-bit x86 remained vulnerable for a long time until something was worked out.

      Originally posted by brent View Post
      Ubuntu can drop application packages and the like and only ship a set of essential i386 libraries.
      That would fix a problem, but not the problem. Even for the "essential" i386 libraries, they need to keep the infrastructure around etc. I guess that the amount of extra work going from 0 to 1 i386 libraries is much more than for going from 1 to 100.


      • #83
        Originally posted by xfcemint View Post
        In my view, there should not be any need to ever drop i386. There are no issues. Just ship the libraries, not the apps. If there are security problems, patch them. Maybe ship a few simple apps, just to test out the libraries.

        i386 is a feature of x86 lineage, there is noo need to dump it. It enables you to run all the old apps made a decade or two ago.

        So, it takes just a little effort to maintain i386 libraries. They could have just imported them from Debian, and called it a day. i386 causes no harm to other components. There are no conflicts.

        Ubuntu project is led by a bunch of idiots. First Unity, now this. Unfortunately, I didn't realize it before, but now I get it.
        unity was the best thing out there, fast and stable.

        I will wait and see what it will happen with ubuntu 19.10, maybe they have a simple solution for steam, using a snap or something, I use wine 64 bit for many years without problems, the drivers well I will wait and see


        • #84
          Originally posted by Raka555 View Post
          It is also ironic that games, that are by far the most demanding software, run very well on 32bit.

          It is probably because game developers have a much better understanding of the hardware and how to write proper programs.
          Not all games, though. Even on the best high-end computers, OMSI2 runs like sh*t because it's 32-bit. Not only users say that, but the devs have also acknowledged that (and given the fact they created such a gigantic game (as in: size/code/etc.) I trust that they know what they're talking about).


          • #85
            Originally posted by shmerl View Post
            Rather, those who need it will just migrate to other distros.
            If ever. I mean: 18.04 still supports 32-bit and is supported until 2028. Chances are, those who currently need 32-bit, will have moved on by 2028.


            • #86
              Originally posted by Weasel View Post
              Retarded analogy. Software (and games) doesn't have a "lifespan", just as old movies don't have a "lifespan".
              Enlighten me, how can I play a movie from 1922 using the original tape it was recorded on on my laptop? Do I just open up the casing of my laptop and jam the movie in it or...?


              • #87
                It is the stupidest idea they have ever made.
                This will prevent users from using of 32-bit software, including:
                - WINE
                - Steam
                - 32-bit games from GOG, Humble Bundle, Game Jolt,, IndieGala, Groupees, etc.
                - a lot of the closed-source software
                - some of the open source software, i.e. PCSX2, quickbms, etc.

                WINE without support for PE32 executables is completely useless.
                Originally posted by WINE
                64-bit Wine built without 32-bit support will not be able to run ANY 32-bit applications, which most Windows binaries are. Even many 64-bit programs still include 32-bit components!
                And don't even mention about Flatpak. It has the worst multilib solution ever created. It is impossible to build 32-bit deps in 64-bit packages. The best you can do in such a situation is to provide pre-compiled binaries. But to do this you need a system with support for 32-bit binaries, so you can forget about flatpaking mixed 32-/64-bit software (such as Steam, WINE, PlayOnLinux/Phoenicis, Lutris, etc.) on Ubuntu 19.10+.

                What's worse, Flatpak is simply not suitable for a lot of programs, and never will be.


                • #88
                  Originally posted by ThoreauHD View Post
                  I think it's time. Netbooks/shitboxes are cancer anyway.
                  It is not about supporting ancient hardware. It is about supporting software like Steam, WINE, Proton, PlayOnLinux/Phoenicis, Lutris, etc. - mainly a lot of games and Windows software.


                  • #89
                    Originally posted by FireBurn View Post
                    Hopefully if Steam are on the ball they'll provide a 64bit client, and just enough libraries (and probably drivers too) to keep 32bit games working
                    It won't help, because you still need a 32-bit version of at least glibc and OpenGL/Vulkan libs. The Steam Runtime doesn't provide it and never will be, because it is out of the scope of this solution.


                    • #90
                      Originally posted by xpris View Post
                      Half or even more steam games need 32bit libs but steam-runtime can save it. Most on GOG need it too. Steam itself is 32bit for now. I hope they release soon 64-bit Steam.
                      Dont know what with some old games or wine32 games?
                      It is easy. Just forget about them! Ubuntu developers know better what you need or not.
                      Alternatively, you can wait a quarter of a century until someone creates a free/open-source clone...