The future of 32-bit Linux [LWN.net]

The future of 32-bit Linux

Posted Dec 5, 2020 12:50 UTC (Sat) by amacater (subscriber, #790)
In reply to: The future of 32-bit Linux by cpitrat
Parent article: The future of 32-bit Linux

That's part of the problem - it's the fact that hardware is heading for 12 years old and becomes a law of diminishing returns to keep the infrastructure to produce a whole distribution for it.

to post comments

The future of 32-bit Linux

Posted Dec 6, 2020 11:25 UTC (Sun) by glaubitz (subscriber, #96452) [Link] (10 responses)

It's not really a problem. We're building Debian for the m68k which is mostly hardware from the 80s and 90s.

It's maintained, so I don't see the problem. On the contrary, it helps to find portability issues and hidden bugs because many issues are only immediately visible on architectures such as m68k and SPARC with their peculiar alignment requirements.

The future of 32-bit Linux

Posted Dec 6, 2020 14:27 UTC (Sun) by amacater (subscriber, #790) [Link] (7 responses)

In my comment above, I was thinking specifically of the AMD/Intel 32 bit only architecture. Over the years in Debian, we've had to effectively change the minimum spec of the processor it runs on - it's now, effectively, i686 and some of the Via and Cyrix processors are excluded - and a lot of the hardware that is 32 bit only out in the world is increasingly unreliable with the years. I spent yesterday working with the Debian images team producing boot images. Every AMD/Intel 64 bit machine (apart from the Itanium) can boot 32 bit code but can also run 64 bit code. One comment made then: running the oldest 32 bit laptop is probably less effective than running a slightly newer second hand Thinkpad and moving to newer models every few years: maybe the oldest machines do need to go to recycling

The long term future of AMD/Intel 32 bit only is rapidly downhill, I think, though I'm fairly sure that we've committed to supporting it for the lifetime of Debian 11 (Bullseye) - the discussions on architectures are going on at the moment as Bullseye will be released next year and porters and maintainers for the various architectures have to step up and be counted at the moment.

In the ARM world, there's a large number of small boards / embedded systems as noted - but it's hard to build 32 bit code for some large packages on the 32 bit boards themselves because they have small memory. Some packages have to be built on an ARM 64 bit platform in a 32 bit environment - not all ARM 64 bit processors will now run 32 bit code. Various build farms of small boards are also increasingly flaky to support. [Speaking for myself and not on behalf of the Debian project].

The future of 32-bit Linux

Posted Dec 6, 2020 16:28 UTC (Sun) by luto (subscriber, #39314) [Link] (4 responses)

Is the problem with i486/i586 the lack of atomics and CMOV? I try to keep the kernel working all the way back to 486 and whatever Cyrix and VIA chips people are willing to test. The kernel probably works better now on a 486 than it has for a long time.

The future of 32-bit Linux

Posted Dec 6, 2020 17:18 UTC (Sun) by amacater (subscriber, #790) [Link] (1 responses)

2016: https://lists.debian.org/debian-devel-announce/2016/05/ms... refers - from Ben Hutchings. I think it was the fact that gcc was moving to target newer processors. I know it caused anguish amongst some of the folks with firewalls running the lowest powered processors at the time.

The future of 32-bit Linux

Posted Jan 1, 2021 10:44 UTC (Fri) by wtarreau (subscriber, #51152) [Link]

On the other hand, home firewalls are often drop-in boxes that don't really need to follow upgrades when there is zero exposed service running on them. Mine runs on a 2002-era VIA-Eden i586-like CPU with a 2.4 kernel last built in 2010... it will eventually be replaced but migrating rules is a pain when everything works fine out of the box. I'll probably wait for the hardware to die.

The future of 32-bit Linux

Posted Dec 6, 2020 17:33 UTC (Sun) by smcv (subscriber, #53363) [Link]

Increasingly, the problem with i386 is that upstream user-space developers want to rely on having SSE so they don't have to deal with the i387 FPU's strange quirks, but that isn't actually allowed in Debian's current baseline (although some packages unconditionally use SSE anyway).

The future of 32-bit Linux

Posted Dec 10, 2020 20:19 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]

We dropped 486 support by accident. It was broken in the kernel by sync_core() using CPUID unconditionally (Debian bug #515982), and then by stack-protector initialisation using RDTSC unconditionally (Debian bug #766105). The latter was reported 5 years after the regression and after it had been included in 2 stable releases, which indicated to me that it wasn't worth fixing.

We dropped 586 support more deliberately, after discussion on debian-devel.

The future of 32-bit Linux

Posted Dec 7, 2020 3:57 UTC (Mon) by pabs (subscriber, #43278) [Link] (1 responses)

This happened with mips too, to the point where I can't run Debian on my router any more since it is MIPS r1 and Debian bumped to MIPS r2 (and then dropped big-endian mips entirely).

The future of 32-bit Linux

Posted Dec 7, 2020 8:00 UTC (Mon) by geert (subscriber, #98403) [Link]

Same here: I keep Linux running on rbtx4927, but nfsroot userspace is stuck at Debian Jessie.

The future of 32-bit Linux

Posted Dec 11, 2020 11:50 UTC (Fri) by winden (subscriber, #60389) [Link] (1 responses)

Are you aware of anyone running / fixing m68k Debian for vampire boards? They are getting fairly high performance (at least 4x of a 060/50 for cpu intensive work) and it seems to me that they are being well-enough engineered.

Ps. Thankyou for latest information about m68k and how to get a fully-working Debian chroot / nspwand ... it works great! :)

The future of 32-bit Linux

Posted Dec 11, 2020 11:57 UTC (Fri) by glaubitz (subscriber, #96452) [Link]

> Are you aware of anyone running / fixing m68k Debian for vampire boards? They are
> getting fairly high performance (at least 4x of a 060/50 for cpu intensive work) and it
> seems to me that they are being well-enough engineered.

I know about the Vampire boards and I talked to one of the developers at the Amiga32
conference in Neuss, Germany.

The problem is that Vampire currently does not emulate an MMU that is compatible with
the Linux/m68k kernel. However, the FPGA they are using has its own MMU and the
Vampire developers speculated whether it could be used by the Linux kernel instead.

> Ps. Thankyou for latest information about m68k and how to get a fully-working Debian
> chroot / nspwand ... it works great! :)

You're welcome. Please also have a look at http://m68k.info which brings news about new
development in the m68k community. You will find a talk about the upcoming M68k backend
for LLVM as well as a new qemu virtual machine type for m68k with 3.2 GB RAM and 128
virtual devices.