Hacker News Reader

Comment by meruru | Hacker News Reader

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?

View on HN

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.

Reply on news.ycombinator.com