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 least 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. What can we do about this? Thanks for your consideration.
73 Answers
I tested and still use x86/i386/32-bit hardware.
post-18.04 and i386
Releases occurred for Lubuntu 18.10 & Xubuntu 18.10 and they were supported the full life of the cosmic cycle.
ISOs were released into the disco cycle too (Lubuntu, Xubuntu), so any installs made with those were provided updated packages the entire life of the product, however both teams (Lubuntu & Xubuntu did not provide support for disco once the ISOs stopped being produced).
It was possible to upgrade from disco (x86/i386) to eoan in the alpha stage, and I did so with a pentium 4 testing box as the different hardware was still useful for detecting issues in the amd64 that still received full support (I didn't have a amd64 box capable of using the video card in the pentium 4 box). However the build architecture for i386 was progressively stopped in the beta stage of eoan so any box, like my pentium 4, that was running 19.10 development was stuck using un-patched software which should be avoided in a production environment, and I soon ignored the box (until it was needed for 18.04.3, 18.04.4, 18.04.5 QA-testing anyway).
I've watched the x86/i386 discussions (with an active interest), and have seen NO NEWS that reports any interest in the x86/i386 architecture being built, released or supported again. I'm also on the Ubuntu News team, so would like to think I've seen all announcements, releases, blogs etc, and have seen nothing. I'm on IRC most of each day (in many rooms) and have seen nothing along those lines either. My involvement with a flavor likewise has resulted in no news either.
18.04 and i386
Ubuntu provided support for x86 in 18.04 producing a few install ISOs though, but flavors treated it as a normal release (the last i386 for most flavors), and i386 will be supported the entire life of 18.04's cycle. Whether that will continue into ESM I've seen no definitive news, but flavors do drop support for 18.04 this month anyway (3 years from release of 18.04 on 26-April-2018).
2[W]e'll need a 32-bit version. What can we do about this?
Debian
Debian still produces a complete 32-bit distro. It's not Ubuntu, but it's the closest that you will get.
According to the best way to post suggestions for Ubuntu:
*Successful community suggestions tend to have the following characteristics: They are made in the correct forum (currently or the appropriate developer mailing list) They are well-researched already. You care more about this feature than anybody else, so look up the feature on Launchpad (or upstream). Use the changelogs and mailing list archives to determine why it was originally dropped, who was involved, and the specific code changes. It's a real research project - keep notes and bookmark links. You will need to refer back to them.
They occur during the right time in the six-month Ubuntu development cycle. Most changes are planned in early November and early May - the weeks right after an Ubuntu release, as teams start planning their next six months' work. Many changes are roadmapped a year or two in advance. Don't approach a team in January expecting to see a new feature in April. The suggester has enough technical skills to start work. The worst thing you can say to a developer is "Well I'm not a programmer". Neither were they when they started. Developers will happily mentor: They will show you how to fish. They won't do all the work for you. They have their own projects (that they care about more).
The suggester has a clear vision and is willing to lead volunteers. You don't need to do all the work yourself - other interested volunteers pop out of nowhere all the time. Basic leadership and management skills are helpful to spread the load and make the work light and fun for everybody.
The written suggestion itself is persuasive to the audience. You're not trying to convince yourself. You're not begging developers. You are not arguing with anybody. You are trying to convince developers that this new feature is a great addition to their codebase, that it will be easy to maintain, that it meets open source standards, that it will be easy to support, that it will be used. You are trying to convince volunteers who could join a dozen other project that yours is the most fulfilling and fun/interesting/challenging. Wishlist bugs usually meet few of those criteria, so few are picked up by the (volunteer) developers.
Suggestion: Get to know the Ubuntu community contributors before pitching an idea. Join a team (testing, documentation, support, bug triage, upstream, whatever) that you find interesting and find a few ways to contribute. Observe how others make suggestions, and how the contributors and community responds, the communication channels they use, the resources they refer to. Time well spent.*
5
