Announcement

Collapse
No announcement yet.

Ubuntu 19.10 To Drop 32-bit x86 Packages

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

  • Originally posted by the_scx View Post
    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.
    The steam runtime does provide glibc afaik and that's one of the cause of issues (you usually need to nuke it manually along with other crap they drop in there). I don't see why they could not drop a full OpenGL or whatever else in there if they feel like it.

    The main point here is that Steam's way of delivering software is completely unsustainable and break-prone bullshit and I'm all for sending a strong message about not accepting it anymore (as Ubuntu was the only "officially supported" distro for Steam, apart from SteamOS)

    Also I hate Canonical so I always automatically approve any decision that causes them to be flamed.

    Comment


    • Originally posted by Raka555 View Post
      What is going to happen is these 32bit apps will be bundling their own "mini distro" with all required 32bit libraries as snap/flatpak/etc with EVERY app ...
      As I said, Flatpak 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+.
      https://github.com/flatpak/freedeskt...ges/issues/101

      Today, to do this, you can simply use an another distribution. Even Ubuntu 18.04 LTS will be fine. But how will it look like in 5-10 years? Many people think that 32-bit software is just outdated. It's not. WINE and related software (VK9, DXVK, VKD3D) is constantly developed. It will require more recent compilers, OpenGL/Vulkan libraries, Mono, Gecko (maybe Chromium at same point?), etc. Within time, it will be increasingly difficult to build this on the old distribution, just like it is already hard to provide new packages for Ubuntu 14.04 LTS or CentOS 6.

      So, in next 10 years, Microsoft will support 32-bit software flawless, while in Ubuntu it will be a pain in the ass. Another chance for the year of Linux (on the desktop) wasted.

      Comment


      • Originally posted by the_scx View Post
        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.
        They just need to ship their own 32bit libraries too. As long as the kernel does indeed still have the 32bit application support (there is a config about that I think, to allow the use of 32bit application with a 64bit kernel) it's going to be fine.

        It's just a slight nudge towards modern packaging systems like snap and flatpak that allow you to deal with it

        Comment


        • This is a very stupid decision. The big problem is some commercial programs may need the 32 bit toolchain to run, some drivers still do. It can be a big issue for binaries and driver sort of things that need a supporting toolchain to run still.

          Dropping images was a bad thing to considering linux really shines on old hardware that has been dumped by Microsoft so this is a prime market for Linux to allow older hardware to be re-used and rehabilitated.

          Netbooks are perfectly fine and many of them just a few years ago with 32 bit. Not everyone has a bunch of cash in their pocket to just run out and buy new hardware whenever these idiots decide at a whim to just drop support for old hardware. Its a very stupid thing because I dont know how many times these people have been told that people using old hardware often want to use Linux. You have some old hardware that works, why not use it?

          So its all very stupid and very hostile and arrogant towards the users.

          Comment


          • Originally posted by L_A_G View Post
            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.
            Duplication of effort? Sure, because the mp3 decoding isn't even duplicated, it's literally extra effort.

            Wasted disc space: again, the mp3 decoding is code which requires disk space.

            Performance loss: this doesn't apply in either case.

            Originally posted by L_A_G View Post
            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.
            Actually no, this is the dumbest analogy I keep reading online. Software is data, just like movies. The medium it is stored in is irrelevant. I want to watch a movie from 1990s, say Terminator 2. I can do that, on a standard install. Easy. It doesn't have to be on a DVD, I can archive it on a USB stick, hard drive, or whatever is "modern". I don't give a shit about the original CD installers for old games. Those yes, are like VHS or whatever, since they're medium. I talk about the software itself, the data that you archive.

            Software is the same thing.

            Comment


            • Originally posted by chithanh View Post
              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.
              I don't think there's a movie format that used to be widespread that ffmpeg can't read, so you're wrong. Either way, patents expire. mp3 is free already. And guess what? It's still "readable".

              Comment


              • Originally posted by chithanh View Post
                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.
                That was for 32-bit kernels. Facepalm.

                Comment


                • Originally posted by Vistaus View Post
                  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...?
                  Nobody cares about the hardware storage medium. Convert it to digital and archive the data. Software is data not a storage medium.

                  Comment


                  • Originally posted by the_scx View Post
                    You want to sacrifice most of the Linux games just because you would like to use a 64-bit version of the Steam client?! Why do you even need this?! Does it consume more than 2 GB of RAM? Does it extensively use 64-bit integers? Just tell me why?!
                    Valve could provide a 64-bit client a long time ago. They didn't do it because they couldn't, but because they knew how it would end - dropping support for 32-bit software in a various Linux distributions. Unfortunately, even Steam and WINE didn't stop Ubuntu developers from making an extremely idiotic decision.
                    You are one of the few sane people in this thread (and xfcemint).

                    Other morons who keep mixing up hardware with software make me cringe.

                    Comment


                    • Originally posted by Weasel View Post
                      Other morons who keep mixing up hardware with software make me cringe.
                      I would suppose most people in the FOSS OS community assume software is code you compile for your architecture. But yes, in cases where you want to run binaries compiled for another architecture, you'll need to find ways to accommodate that legacy object code.

                      "While this means we will not provide 32-bit builds of new upstream versions of libraries, there are a number of ways that 32-bit applications can continue to be made available to users of later Ubuntu releases ... We will be working to polish the 32-bit support story over the course of the 19.10 development cycle."
                      I think people should probably take a wait-and-see approach given this suggestion 32-bit support may still exist in a form suitable for certain niche cases.

                      Comment

                      Working...
                      X