“I’m sorry we’ve given the impression that we're dropping support for i386 apps” | Hacker News Reader

“I’m sorry we’ve given the impression that we're dropping support for i386 apps”

discourse.ubuntu.com

73 pointscameronbrown41 comments

It sounds like they expect everyone to use Snap for 32-bit binaries. This might make sense for very popular apps like Steam, but is bound to break for legacy binaries that won't have any Snaps available.

What's been missing here is the rationale for removing these libraries, though. Glibc, and most other base libraries still support 32-bit intel without any problems. The cost of Ubuntu providing them seems very low here. Since they even use APT still, I suspect they could even reuse the Debian repos for i386!

The cost of Ubuntu providing them seems very low here.

If that's so, then they'll get tons of volunteers willing to put in the "very low" effort, no? More seriously, I don't think that it's going to happen, and I think you'll agree that it's unlikely. This suggests that the cost is not so low after all.

They already have all the volunteers they need in the form of Debian developers and packagers. Ubuntu is 99% Debian with just some minor changes on top. The only real costs to them are for building and distributing.

On a gentoo system being able to easily see the backbones of multi-lib support i can say that it's mostly a straight forward process, sometimes exotic makefiles might need a little push, nothing much more beyond that. Also there are volunteers only for non profit organizations like debian, arch, gentoo etc. For everyone else we are just customers and we have no obligation to help and every right to criticize.

Stupid question: if they don't ship an i386 version, how would the snaps be created? Since there would no longer be a root disk it could be based on…

I'm probably missing something obvious?

I haven't actually used that function myself, but snapcraft supposedly supports docker as a building tool... So I'd imagine you could just use Alpine as base

Snaps can be built from an OS version, e.g. from 18.04 which still has 32-bit and will for 5 years (from April 2018). And the snap includes all the system libraries etc.

Fwiw, 18.04 is promised security updates until 2028 instead of the normal 2023.

Only if you're paying for the extra support through Ubuntu Advantage program.

They will still be shipping 18.04lts, with security updates, for years to come. This will be increasingly outdated. I'd like to hear specific examples of where that would be a problem though, besides Wine. More specifically, I don't understand what Valve is so upset about since Valve already supplies their own run time that games are recommended to use, and I hope that would apply to their photon system.

It is possible for Canonical, Valve, $random_person or even Microsoft to distribute all the 32-bit libraries and support as a snap, which can be used by both snapped or traditional applications. The libraries would just live in a different directory, and the update lifecycle would be decoupled.

The big issue here is graphics drivers -- the host OS needs to provide libGL.so, and that requires a large 32-bit userland that needs to be updated.

The message and comments actually raise more questions. While they might not completely remove the i386 libraries, they will be marked as "legacy" and will not see any updates (frozen 18.04 versions). But what about security fixes? The thread is an interesting read, but also feels like this was made as a uninformed decision; were the consequences realized? And if they were, why is this not properly communicated? Their userbase and 'partners' need to know and understand what this means to them. Reading the response from Valve, this clearly isn't the case.

I haven't had the time to dig into this drama over the past few days. I personally don't care about support for a physical 32-bit processor machine, I just want to be able to run old games, EEPROM writer software, and handful of software for patching old instruments, on my 10 year old 64-bit machine. Will that still be doable?

Can you send me the EEPROM writer software? I'll be able to tell you what's needed to run it.

Most likely, things will keep working as is.

The implication is that if the 32bit libraries are frozen in time forever, emulators, wine[0] and some game platforms will soon become incompatible with Ubuntu.

If that's the case, it's dishonest to say "oh we're not killing 32bit" when in fact they're boiling the frog.

This has pissed off Valve enough to make vaguely threatening statements about stepping away from Ubuntu.

[0] https://discourse.ubuntu.com/t/i386-architecture-will-be-dro...

No longer vague. They're ending support for Ubuntu. https://www.engadget.com/2019/06/22/steam-will-stop-supporti...

And Debian is not stepping away from 32-bit? So we can all just move to Debian or a derivative if we liked Ubuntu?

For a while at least... the drama is exactly the use case you're describing: supporting old software/peripherals (esp. 32-bit apps for Wine/Steam.) If Ubuntu freezes 32-bit libraries at the current versions, it's likely that they will start to bit-rot as the 64-bit side of things move forward. This would likely manifest in things starting to break over time since Wine/Steam/whatever aren't likely to maintain/backport fixes to work around issues going forward for out of date packages.

> But there is every intention to ensure that there is a clear story for how i386 applications (including games) can be run on versions of Ubuntu later than 19.10.

‘a clear story’ doesn’t sound to me like actual support, it sounds more like words chosen to obfuscate the fact that they won’t be providing support, and will instead offload support to some third party, with no actual guarantees.

What would actual guarantees mean for consumers, who aren't paying for or receiving commercial support?

If someone is paying for commercial support and this drop affects them, they should probably be calling their rep about now.

A little bit confused... Debian will still fully support x86, right? Why can't the community get any updates they need from Debian repos?

Because Ubuntu is very hacked-up, and you will likely break your aystem

Looks like the Wine x32 emulation is based on the x32 Ubuntu distribution existing.

So now even if Canonical agrees to support just a subset of the x32 libraries then they'll be testing it not like a distribution but like a base for Wine (because it won't be used as a whole dist).

I understand that the Wine project doesn't want to take on that work. They aren't comfortable with the fact that x32 will become like one of those old gaming consoles we need emulators for, and everything will eventually go into Wine.

Either way the testing will be reduced.

It's not quite clear from this: are they dropping i386 or something more like i686? I recently got modern Debian to start up on my first computer, a PII 350. It only worked because that was the first modern x86 architecture that distros support easily. Pretty much everything older's been dropped.

It's i686.

I think a few distros still support all the way back to i486. Debian and Ubuntu only support i686 though. Too bad too because i586 CPUs were on the market as recently as 2015 (Intel Quark).

https://www.phoronix.com/scan.php?page=news_item&px=Debian-6...

I can't immediately find a definitive listing, but I think Vortex86 [1] chips (inheritor of the Rise/SiS x86 core) are still sold that have 586-level ISA compatibility.

[1] http://www.vortex86.com/

Intel Quark has some catastrophic errata which make it unable to run any stock Linux distribution. In particular, there's an issue with its implementation of the LOCK instruction prefix which can cause unpredictable crashes -- and the CPU has no microcode update facility, so there's no way to patch it.

They label the x86 architecture i386 - even though it's not actually compatible with 386 processors anymore.

So when they're talking about dropping i386 - they're talking about dropping 32bit, not your 25yo sx16.

Wouldn't it make sense to drop 32-bit on intermediate releases but keep it on LTS releases? It sounds like the perfect compromise to me, but I'm not sure what exactly it takes to support 32-bit. Is it a matter of human or computing resources that's driving this?

It's still supported on 18.04 LTS etc, they just don't want to support it in 20.04 LTS, so this is a preparation move.

https://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-D...

I mean why not support it only on 20.04, 22.04 and so on.

Because that code will then be untested for the releases between LTS and hence more fragile and expensive to support within it.

The code will be tested in its 64-bit form. Is 6 months not enough to check for 32-bit specific bugs? How often are there 32-bit bugs anyway?

Maybe. That'd still put the distribution in the strange position of shipping old 32-bit versions of libraries alongside newer 64-bit ones. I'd be concerned that using two different versions "side by side" could cause problems.

I don't understand, why ship different library versions for 32-bit and 64-bit? I'm proposing they reduce their maintenance burden by dropping 32-bit completely on non-LTS releases and keep supporting it properly on LTS releases for the use-cases that require it

It seems impractical to drop support then re-add it. Probably less work to keep building and testing it all along then to have to fix 2 years of 32 bit specific bugs all at once.

How much of the maintenance burden consists of 32-bit specific bugs? I would guess almost nothing, but I have no idea really.

They shouldn't be sorry. Canonical is not Microsoft, it can't afford to support legacy software forever. Let Valve support i386 apps for Linux, they definitely have money and resources for it.

Then they can't pretend to care about desktop users anymore - I just think it'll damage them and their brand in the long term.

Reply on news.ycombinator.com