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

[tildearrow]

Not to be outdone, openSUSE Tumbleweed dropped support for both 32-bit and 64-bit x86, due to continued "security related concerns". They too were forced to reconsider, and will be shipping SystemD + Emacs, which "provides 90% of a typical Linux install". The btrfs maintainer was not available for comment.

I wonder what happened to Leap and SLES.

[Dukenukemx]

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.

What happens to all the old 32-bit proprietary code? I get it costs money to maintain it, but that's part of their job. Whatever, if this becomes a problem I'm switching distros. Debian, Majaro, and PoP_OS seem likely candidates.

[BaronKrause]

What happens to all the old 32-bit proprietary code? I get it costs money to maintain it, but that's part of their job. Whatever, if this becomes a problem I'm switching distros. Debian, Majaro, and PoP_OS seem likely candidates.

Really hope Pop actually follows through with their claim of maintaining the 32 bit dependencies themselves if needed.

[oiaohm]

Once again (may phoronix may mention that?), even newest 64 Bit software on Windows in general comes with 32 Bit setup. It‘s not about old legacy software. Pure 64 Bit wine doesn‘t make sence.

This is the same arguement made against dropping win16 from windows that a lot of 32 bit application were coming with 16 installers.

There are a few different answers to this problem.
1) Microsoft win16 answer. Detect installer extract install script and run install script with win32 version in past case in this case would be run with 64 bit version.
2) Go the https://github.com/AndreRH/hangover route. So run the install in virtual this means you don't need host 32 bit. After 64 bit program is install then you are able to run that directly so no more overhead.

Both of these options you are not needing 32 bit host libraries or 32 bit syscall support.

Pure 64 bit wine does not make sense at the moment because installer detect and replace does not exist for wine and hangover is not ready and windows developers have not go the memo that they should be using 64 bit installers with 64 bit applications.

Of course this does not help you with pure 32 bit applications.

There is a serous note in the Statement no is really talking.

You’ve heard about Spectre and Meltdown – many of the mitigations for those attacks are unavailable to 32-bit systems.

Please note apple is not dropping 32 bit for no reason. Neither is ubuntu wish. 32 bit program running on 64 bit system cannot be properly mitigated against different security flaws that have come up. I would call the current move a temporary stay of execution. 32 bit has to be containerised one way or the other for 2038 also has to be containerised because they are no longer secure. Installers like going on the internet and checking if there is a newer version this is not wise. Games like going in the internet as well.

[oiaohm]

Yep, also containers almost always have more compatibility issues than native libs, and now the developer needs to provide an updated lib in a container instead of Ubuntu doing it for everyone. You're doing more work for the same or worse outcome. Doing a sandbox right for an app might be easy, but doing a sandbox right for any app is still a hard thing to do.

Yes and no. It depends how the containers are done. Flatpak has runtimes so application developers don't have to take care of every library. 32 bit Linux applications and large number of Windows applications will have to be in a container in time because they will been needing the date and time faked due to the 2038 problem. We really don't want to leave this process to the last min like get to 2037 and then attempt to sandbox because we know this is not always going to be easy.

Remember with sandboxing we are still have those making the application designing without sandbox in mind. This mind set for 32 bit programs need to change. Between the fact we cannot do mitigation properly on 32 bit applications for the security issues that have come up and the 2038 problem 32 bit being containerised and sandboxed needs to come normal.

Some ways I agree with what the Ubuntu developers have done as bending everyone nose out of joint on this problem to get people talking about the problem is most likely the only way this problem will start being addressed.

If they were actually serious about a transition, Ubuntu could provide a transitional script to switch between 64-bit only and multilib/multiarch, and print out some sort of a message in syslog or somewhere about binaries linking to and using 32-bit libs.

Microsoft did this when they were ending 16 bit and it did not change a thing. Developers only really responded to fixing up 16 bit installers on 32bit applications when they would not work.

What Ubuntu has done is about the only option if you are serous and you want it fixed. Start demoing and making it clear that you are going to only provide 64 bit get the threat out there front and centre to developers that their applications are not going to work any more and they need to start developing around that problem.

[ThoreauHD]

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.

[muncrief]

Wow. Well then, that solidifies it.

Ubuntu just gained me back after years of working with Arch and its derivatives, but now they've lost me for good.

I'll go to any lengths to find another Linux distro that works as well and consistently as possible, and supports a non-kindergarten interface like XFCE. Manjaro seemed perfect for quite awhile, but then within six months simply broke down so badly it wasn't functional anymore.

But like I said, this crazy crap with Canonical has to end. And for me it's going to end now. I can't afford to invest my time in a dead-end desktop distro. But for whatever the reason it seems clear Canonical wants to wind down their desktop operations.

That's certainly their right, and I think they simply believed this would be the easiest way to let everyone know.

[board]

Snaps? Good luck with that. So many bugs it's beyond belief. My favorite part is probably System Monitor. Fresh new install, and it just won't start. Bug reported, "solution"? Uninstall snap, install native package.

There's a million similar examples. Ridiculous.

I agree, it's limited. Personally I'm running Ubuntu 16.04 (because Unity utilizes screen real estate better than Gnome Shell), just to be completely honest here. I have no way of using Snap'd VLC with multimedia on my other internal drive, there is no Snap "interface" that will allow that. Such limitations are real showstoppers. Even if some smart people out there know how to create/modify interfaces or repackage VLC, that simply isn't something you can demand from the average user!

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.

[oiaohm]

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.

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.

[BOYSSSSS]

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!