Home Store Blog

Dropping 32bit ISO images from 18.10 onwards


We have had a successful release of Ubuntu Budgie 18.04 LTS and we now are in full planning mode for 18.10.

Similar to the decision made by Ubuntu themselves at 17.10, we have decided to concentrate all our efforts on producing a really good image based on the hardware almost all of you actually use now.

Eh - does this impact me?

Highly unlikely - from the various reports and statistics we have observed from 16.04 budgie-remix all the way to you enthusiastic 18.04 trail-blazers, almost all of you are now using the 64bit ISO.

We have also seen various reports that those that are using the 32bit ISO are again doing so on a 64bit hardware architecture - i.e. you could just use the 64bit ISO but have not chosen to.

Ubuntu will still offer 32-bit packages (i386 intel/amd) packages in the various package repositories.

… but I need 32bit images

We do know that this decision will upset some of you.

Rest assured for the entire 18.04 cycle - the next 3 years will continue with updated 32bit ISO’s of Ubuntu Budgie.

I’m sure you are already aware software providers and various hardware manufacturers no longer produce 32bit software or are about to drop support for 32bit versions of their software. Chrome, Nvidia, Vivaldi are recent examples. Even the provider of Firefox (mozilla) support 64bit only - its kind of a happy coincidence that 32bit still works and that is thanks to the maintainers working with the opensource community at large.

None of the Ubuntu Budgie test team have access to 32bit hardware - so our development is only via Virtualbox. That isnt really satisfactory.

I hope you understand the decision. The next three years we will endeavour providing good support moving forward with 18.04 through to 18.10 and beyond.


There’s a good reason for which people use 32-bit software on 64-bit machines - low RAM. And there’s no need to hunt down ancient hardware to test how the 32-bit perform on the 64-bit-capable software, because there’s plenty of new hardware artificially limited to a small quantity of RAM by the manufacturer.

32-bit makes a lot of sense on PCs with 4GB or less RAM, because people who need to run multiple programs at the same time, one of those being a browser, will run out of RAM quite easily. And torturing the storage device with swap is never a good idea. It slows down a HDD, and it shortens the life of and SSD needlessly when the same software could be run as 32-bit.

So it’s rather sad the PC manufacturers come up with weird hardware, but they do make multi-core 64-bit CPUs out there that don’t benefit from enough RAM. And hopefully some distro makers will acknowledge this fact and rethink the abandonment of the 32-bit builds. Because apart from the people who know why 32-bit makes sense for their hardware, there are also people who have no idea and they use 64-bit on PCs that end up being abused with frequent swap usage, due to low RAM (for their needs).

I wish I could hope that by the time 18.04 runs out of support we will no longer have RAM-castrated hardware out there. But they are being sold today, so they will be only 5 years old by then, or merely 3 years old in the case of the officially recognized Ubuntu spins. And this is if all the manufacturers decide to stop pushing out such hardware on the shelves today.

Would it kill anyone to give this another thought? I wonder if the telemetry reports include swap usage (with quantity and frequency), but probably they don’t. But at least try to make a correlation between the 10% using 32-bit software on their 64-bit machines, compared to their installed RAM.


One of the side effects of using 32bit Linux on 64bit hardware is that you are not safe from the latest cpu exploits. So simply browsing could expose you to attacks. There are no plans by the Linux community to patch 32bit operating systems running on 64bit hardware.

The other issue is simply manpower. Throughout the entire cycle nobody using 32bit stepped up to help test. This unfortunately had a big impact on the team diverting them to testing when really development and fixing issues raised by testers was key.