You’re just ignoring the arguments on one side. Saying that the argument is “not worthºy” doesn’t really represent correctly the arguments that were made, and saying it’s not possible to run it on Ubuntu is simply to ignore the path that was presented to actually enable users to continue to use them. It’s not fair to put things that way and doesn’t represent the reality.
By the way other distros have been walking the same path, and some have also done the same (minor distros in popularity like OpenMandriva), but the fact that the others haven’t looked more into doing something like this says more about the other distros disregard for security and stability risks, than says whatever about Ubuntu. When you lag maintenance at the upstream projects and QA is almost null because nobody does it, then those risks increase a lot.
Would you mind elaborating? I.e., in what way does it not work well? Your upstream in this case is Debian, they still maintain i386 (dpkg arch, not “would run on an actual i386”) as a first class arch, and you don’t hear “Debian” and “not maintained correctly” in the same sentence very often. As long as the i386 packages are built from the same source as the amd64 ones, they stay current, most fixes trickle down to them as well. The exposure is limited to issues that only manifest in the i386 version of a package. That’s much better odds than amd64 universe and PPA packages, that may not receive any updates at all and be of questionable quality to begin with.
The fact is, current amd64 systems can run 32-bit code natively, removing support on the OS level is a regression in hardware support. I’d be against it in principle even if there weren’t any major use-cases – and there are plenty. (One could even make the case for re-introducing i386 as an installable architecture, if not for 32-bit/hybrid Atom boards and netbooks then for lighter [= more] VMs, but I digress.) The point is, 32-bit code is not legacy, hardware that cannot run 64-bit code is – that’s a big difference. Even if it were legacy, it looks like many people still want or even need to run 32-bit software, and why shouldn’t they? When choosing an OS, they ask “Does it run my stuff, and does it run it well?”, not “Is it pure 64-bit?” – and for once, they got it right.
IMHO, running both 32-bit and 64-bit code on amd64 at the same time should be fully supported and as seamlessly as possible – Windows does that very well – for the foreseeable future, and multiarch is, as of now, the best way to do that. Compiling the 32-bit packages to target amd64 CPUs is an option, as is selectively dropping non-essential packages that won’t compile and would be too much effort to fix.
Bundles (Flatpack/Snap/Appimage) currently negate all advantages of centralised package management, containers/VMs aren’t there yet, either. Too much overhead, too much complexity to manage, too fragile for the desktop, not at all well integrated, let alone seamless.
It’s highly likely that a better solution than multiarch will emerge, maybe in conjunction with a paradigm shift to containerise everything transparently (cf. Qubes), who knows, but it isn’t even on the horizon yet, so why the rush?
I for 1 am glad to see support for running 32bit on amd64.
While I do like the thought of moving towards a pure 64bit environment, I don’t think the time is right.
I wish 32 programs could just use the 64bit library, but I guess that just isn’t going to happen.
Frankly I’m annoyed by all this “it’s not ubuntus problem if a given application doesn’t work/run”. This is not kosher in my view to the community guidelines. Regardless of a person’s view toward a particular program , these comments are not helpful. Some users need these programs, your personal bias against Windows and games is just detrimental to the conversation.
As was pointed out in the legitimate concerns category there are some 64bit apps that have 32bit dependency issues. Wine being just 1 example. Luckily the apt system can enumerate such dependencies and a solution can be found that covers most use cases.
If it’s so little maintenance to take Debian’s i386 packages and run them in Ubuntu, perhaps you could make a respin of Ubuntu 19.10 which has full i386 support? Or is it not as easy as you’re making it out to be and it is actually time-consuming to do?
This was already explained on the thread about dropping 32 bit packages, I’ll not repeat it. The upstream of Ubuntu is not only Debian, and the upstream I was referring was the software developers.
That was never what was at play here. Ubuntu was never removing the ability to run 32bit software on Ubuntu.
You don’t say which thread exactly but I’ve read the predecessor to this one, and it doesn’t go into any detail, doesn’t give reasons, just asserts.
Yes, you were, and are still going to. Without a comprehensive set of 32-bit drivers, libraries, frameworks … 32-bit applications cannot run. Providing these is what an OS does. No 32-bit libs = no OS-level 32-bit software support. By that logic, you might just as well remove the 64-bit libs, because 64-bit code would still run on the hardware & kernel.
No, containers, VMs, emulators and such don’t count, at that point you’re running an OS inside an OS (and both of them might just as well not be Ubuntu). By that logic, Ubuntu also has the ability to run Windows software, SNES ROMs, …
But never mind. As I’ve said before, it’s your decision. It’s just that I prefer sound reasoning to underpin decisions – and so far all I’ve seen is “We’re desperately low on manpower & other resources” [worrying, as that tends to lead to cut corners and bad decisions]; “64 bits are more than 32, that must be better” & “removing compatibility equals progress” [are there’s only 20-year-olds left at the helm?]; “just upgrade, the hardware, the software, whatever, it’s cheap & easy!.” [total disconnection from reality, also ironic] & “use-cases that aren’t mine are irrelevant”.
Also, communication was abysmal. No, discussions on internal mailing lists do not constitute advance warning, much less demonstrate a consensus among users.
In short, the whole thing has tarnished my image of Ubuntu as professional and dependable, trustworthy.
Don’t say you, because, neither I was involved on the decision (I knew there were discussions regarding it), nor do I represent Ubuntu, or work for Canonical, I’m just an individual involved with the Ubuntu community expressing my personal opinions.
Removing libraries doesn’t prevent those distributing software to add them back, or users from doing also, and Ubuntu provided several options on ways to use those libraries even from the Ubuntu archive itself.
If Ubuntu was to drop support to i386 in a way to prevent applications to run it would do it at Kernel level (switching kernel configurations to achieve that goal.
Yes containers, VMs, chroots, and even and snaps do count, because they offer a way to do it, which is what really matters to users.
Containers even run on the host system kernel, they just have their own isolated run time (which is what windows does to run 32bits). And the sugestion was to use an older version of Ubuntu, or a container, or a runtime, not another different Operating System.
Could you please link it, so we’re on the same page?
I said removing the libs removes the OS-level support for 32-bit software (by definition, really), nothing about preventing it from running. Just because a feature can be added that doesn’t make it a supported feature.
Agree to disagree?
I don’t know much about Windows internals, but I do know that 64- and 32-bit software is not isolated in any user-visible way.
How is another version of an OS not another OS? How is keeping an older and sooner or later unmaintained version of an OS around not a maintenance and security nightmare? Why use Ubuntu when another distro can do it all via multiarch?
Even when isolation is desired: Why use an old 32-bit version of Ubuntu over a current 32-bit version of another distro as a base? Why not use the same distro for both, then, for simplicity?
Well, because of this I have to do a long complicated process to trick one of my 32-bit laptops into downgrading from Ubuntu 18.10 to 18.04, because I am stuck in limbo where all of the repositories don’t exist and I can’t do any updates, making this way more complicated than it has to be.
Also, sorry for necroposting, I’m just pissed about this.
I just gave an old Dell XPS system that wouldn’t even recognize the sound card at all, nor the video card except as “standard vga” with windows 7 (since XP is essentially unusable now). Pentium dual-core 3.4GHz, 3G ram, to a needy friend. Had to put older Linux on it since it won’t support a 64bit OS.
Linux found not utilizes the sound card fine, but also the older nVidia card, yay!
Sure would be nice to continue to use current Ubuntu on these older, yet perfectly serviceable systems.
I’m not a programmer, but would/is it really that hard to implement 32 bit versions as well?
Thanks for the announcement. It is our understanding that 20.04 only exists in a 64-bit version. However, I just heard that, after some discussion within the Ubuntu community, a 32-bit version was being considered. I have at leat 1,000 legacy devices floating around that we would like to promote to 20.04, but the implemented Intel micoprocessor will only allow us to run a 32-bit OS. We are currently running 16.04 on these devices, and our customer has asked us to manually update all their devices with our latest mobile software stack this summer. We love Ubuntu and would like to stick with it, but, like others, we’ll need a 32-bit version. Do you have any timeframe for a possible 32-bit version> Thanks for your consideration.
jeff@ameritrak.biz
This sounds promising. Are you suggesting that 20.04 may have a 32-bit avaiable for ‘compatibility’? If so, how may we get hold of a 32-bit compatable 20.04 version? And, if so, will a possible 32-bit compatable 20.04 version be supported?
Is a foreboding statement. It would be nice if we could quickly get an official position. We have very little time to resolve these issues.
you can run some select 32bit packages on top of a 64bit system with that …
There is no and will not be a 32bit installation media anymore and the larger part of the 32bit archive packages is gone as well.
This “compatibility” layer is for running 32bit binary packages of i.e. proprietary software for which there are no 64bit versions, printer drivers, wine applications and the like on top of a 64bit system.
Got it. Fully understand. I still have 1,000+ 64-bit incompatable mobile computers floating around, in need of a facelift. So, with a heavy heart, we say “Bye-bye Ubuntu”. Debian Version 10 here we come. Thanks for all the exceptional discussions: Great forum.
