[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: About i386 support



On Mon, 20 May 2024 00:30:13 +0200, Thomas Goirand <zigo@debian.org> wrote:
> For example, *I* don't care at all about 32 bits arch, and would prefer if these were to be sent to ports.debian.org. I really mean *all* 32 bits arch, including armhf for example.

I agree with you.

No one really needs armel(armv5te) now. Linux kernel has just dropped Marvell's armv5te device support. RPI0/1 users want armv6hf instead of armel(armv5te). armhf in Debian is armv7hf, and does not support RPI0/1. It supports RPI2.

For armhf, Fedora has dropped it in 37 due to lack of community interest, and worse and worse upstream support. armhf is 3GB user process address space, 1GB shared kernel address space, and users will find armhf is a bad platform for any heavier jobs, such as compiling or emulating things or running heavy server or computing programs. Chrome and Chromium-based apps and some other things do not support armhf now as well.

armel, armv6hf and armv7hf can be done by embedded distros like Armbian. Debian can just move them into Debian ports, not release them as official arches.

For i386, I only use wine32, and do not have any pure 32-bit x86 devices. Pure 32-bit x86 devices are aging and less energy-saving, and 64-bit first-handed or second-handed devices are cheap enough to buy one rather than wasting time to maintain i386 support. Old native i386 Linux apps can be supported by an old Debian release chroot or container, not by a new release (native boot or multiarch or chroot or container or whatever).

I would like to suggest Debian to drop all i386 things excluding wine32, and recompile wine32 to 64-bit time_t. And if WineHQ announced 'new wow64' becomes default, Debian could drop i386 completely, only leaving multilib and cross compiling things in amd64 is enough.

Reply to: