Re: Suggestions about i386 support
On Mon, 10 Jun 2024 at 20:17:27 +0500, Andrey Rakhmatullin wrote: > On Mon, Jun 10, 2024 at 04:02:54PM +0100, Simon McVittie wrote: > > several important upstreams no longer consider i386 to be useful (and > > especially i386-without-SSE2), so so the burden of supporting 32-bit > > CPUs in modern software will fall on the downstream developers who have > > chosen that their aim is to support 32-bit CPUs. > > I assume such software already has this status on Debian i386 (and so is > either not built there or supported only by the maintainer, or maybe built > with a raised baseline) so there should be no regression here Some concrete examples: * Packages built with -fcf-protection (Intel CET) require CPU support for "long NOP" opcodes which are, or used to be, non-baseline. This is a security hardening measure, so if we disable it in order to respect the documented baseline, the result is that our binaries are less secure than they could be (fewer mitigations for exploits) on CPUs where those opcodes actually *are* supported. (That's what started this thread: sudo enables this hardening.) * nodeJS, Qt5WebEngine and others have a known baseline violation by using and requiring SSE2 internally, which they document by depending on sse2-support. I thought Chromium did this too, but maybe it either doesn't do that any more, or still has the baseline violation but doesn't document it. * Packages built with rustc (notably Firefox and librsvg) had a known baseline violation in the past (they would crash with an illegal instruction on i586) which was made officially not-a-bug by raising the baseline to i686. * In packages with test suites that compare the results of floating-point calculations at a high precision (such as librsvg), the fact that we target the legacy i387 FPU (which has 80-bit excess precision) rather than SSE2 (which has 64-bit IEEE precision) has caused a lot of extra work for maintainers in the past, due to tests getting a result on i386 that differs from the result on every other platform we support. * Some third-party software like Steam does not follow our baselines, and unconditionally requires newer CPU features. (Not a concern for Steam on i386 any more, because Steam now requires a 64-bit CPU, so bookworm's steam-installer is intentionally not installable on purely 32-bit systems - but Steam will not actually work on a baseline *64-bit* CPU any more.) smcv
Re: Suggestions about i386 support
On Mon, Jun 10, 2024 at 04:02:54PM +0100, Simon McVittie wrote: > On Mon, 10 Jun 2024 at 12:43:27 +, Stefano Rivera wrote: > > The point here is that the Debian project is not intending to support > > new hardware on the i386 architecture. The architecture is being kept > > around primarily to support running old i386 binaries. > > ... and the most appropriate answers to some technical questions are not > going to be the same for "i386 to run legacy 32-bit binaries on 64-bit > CPUs" and "i386 to run on 32-bit CPUs", so we cannot simply support > both equally. Yeah, it should be made clear that if some people want to bring back proper support for i386 hardware, they will need to make a new port. Which is of course more complicated than fixing an existing one (but at least bootstrapping it should be easier than bootstrapping some non-x86 port). > If people want a distribution to run on 32-bit x86 CPUs badly enough, > one possible route would be to start a new port (perhaps called ia32, > i386t64 or something similar) for that use-case; it would have a baseline > that is as low as its maintainers want it to be (i586?), and a 64-bit > time_t for post-2038 future-proofing. > > As far as I'm aware, nobody is yet putting effort into doing this. Also, > several important upstreams no longer consider i386 to be useful (and > especially i386-without-SSE2), so so the burden of supporting 32-bit > CPUs in modern software will fall on the downstream developers who have > chosen that their aim is to support 32-bit CPUs. I assume such software already has this status on Debian i386 (and so is either not built there or supported only by the maintainer, or maybe built with a raised baseline) so there should be no regression here, though additional packages will get the same status in the future. Similarly, we already don't build a noticeable number of packages on armel (and some of them also on armhf) when we build them on arm64. -- WBR, wRAR signature.asc Description: PGP signature
Re: Suggestions about i386 support
On Mon, 10 Jun 2024 at 12:43:27 +, Stefano Rivera wrote: > The point here is that the Debian project is not intending to support > new hardware on the i386 architecture. The architecture is being kept > around primarily to support running old i386 binaries. ... and the most appropriate answers to some technical questions are not going to be the same for "i386 to run legacy 32-bit binaries on 64-bit CPUs" and "i386 to run on 32-bit CPUs", so we cannot simply support both equally. > We didn't bring 64bit time_t to the architecture, because of this goal. This is a good example of a decision that goes differently for those two purposes. If we want to run legacy i386 binaries, 64-bit time_t would be counterproductive, because it will break some of those binaries *now* (not just in 2038). Raising the baseline (to i686 or beyond) is another decision that would go differently for those two purposes. For legacy i386 binaries on an x86_64 CPU, the baseline could raise as far as i686 + SSE + SSE2 without losing any 64-bit CPU support, because SSE and SSE2 are part of the x86_64 baseline; but for genuinely 32-bit CPUs, as discussed in this thread and elsewhere, even i686 is sometimes too high. > There isn't a team working on a modern 32 bit x86 port. We're just > trying to keep the old one going for as long as we can. You're welcome > to try to form such a team, of course :) The "i386" name is widely hard-coded in third-party software (e.g. Steam) as being the appropriate architecture to use to run legacy 32-bit binaries on a 64-bit CPU, so if we were to fork i386 into two separate ports (one for legacy binaries on 64-bit CPUs, and one for 32-bit CPUs), the route that would avoid breaking backwards-compatibility would be for the i386 name to stay with the port that is intended for legacy binaries, introducing a new name for the port that is intended for 32-bit CPUs. (This is because by definition legacy binaries are legacy, and are not going to change to accommodate new decisions, whereas a new port can produce new binaries with code changes if enough effort is put into doing so.) If people want a distribution to run on 32-bit x86 CPUs badly enough, one possible route would be to start a new port (perhaps called ia32, i386t64 or something similar) for that use-case; it would have a baseline that is as low as its maintainers want it to be (i586?), and a 64-bit time_t for post-2038 future-proofing. As far as I'm aware, nobody is yet putting effort into doing this. Also, several important upstreams no longer consider i386 to be useful (and especially i386-without-SSE2), so so the burden of supporting 32-bit CPUs in modern software will fall on the downstream developers who have chosen that their aim is to support 32-bit CPUs. And, for several larger packages it is becoming a serious problem to compile and link the software natively on any 32-bit architecture, because the working set for the compiler or linker is larger than 4 GiB, but a 32-bit architecture can't possibly address more than 4 GiB of virtual memory at a time. Those are problems that any would-be port maintainer for a "modern" 32-bit x86 port would have to deal with somehow, and telling the wider Debian project "this is important to me, therefore it should be important to you" is unlikely to result in those problems going away. Alternatively... > The cost of supporting a port of Debian is far more than the cost of the > machines needed to build it. Never mind the cost of 1 user's machine. As a point of comparison, a used 64-bit laptop of a well-respected design from 12-13 years ago (Lenovo X220) seems to be readily available for around £60 on eBay UK, and that price is enough to pay a software consultant in the UK for somewhere around 1 hour. Of course, volunteer effort is not directly interchangeable with consultant effort and not every country is the UK, but the time-cost of maintaining a 32-bit port of Debian is going to be lots of hours. I suspect that many of the used 64-bit laptops of that age on eBay go unsold and will instead be discarded, entering the e-waste stream, in which case buying one as a replacement for a 32-bit machine is not a net increase in e-waste. (No endorsement of eBay intended, other sources of refurbished computers are available.) smcv
Re: Suggestions about i386 support
Hi The (2024.06.10_12:22:14_+) > How to get access to the right parts of the waste stream to be able to > pull out some working 64-bit hardware is another question, and one where > I don't have an answer that wouldn't involve spending money (which would > presumably make the proposed alternative insufficiently comparable, > since presumably you wouldn't have to spend money to keep the existing > 32-bit machine in service). If Andrey does, I'd be interested to learn > it. The point here is that the Debian project is not intending to support new hardware on the i386 architecture. The architecture is being kept around primarily to support running old i386 binaries. We didn't bring 64bit time_t to the architecture, because of this goal. There isn't a team working on a modern 32 bit x86 port. We're just trying to keep the old one going for as long as we can. You're welcome to try to form such a team, of course :) The cost of supporting a port of Debian is far more than the cost of the machines needed to build it. Never mind the cost of 1 user's machine. Stefano -- Stefano Rivera http://tumbleweed.org.za/
Re: Suggestions about i386 support
On 2024-06-10 at 08:09, rhys wrote: > On Jun 10, 2024, at 01:44, Andrey Rakhmatullin > wrote: > >> On Sun, Jun 09, 2024 at 08:39:27PM -0500, r...@neoquasar.org >> wrote: >>> Reuse is better than recycle for complex things like electronics. >>> >> You were suggested to resuse an old amd64 machine. > > Again, that assumes that I have such a thing. I don't. Unless you > want to provide one? > > Also, that still doesn't explain how that means the existing 32-bit > machine stays out of the waste stream. In your solution, it doesn't. > In my solution, it does. I think the suggestion was to take an old amd64 machine out of the waste stream, and put the existing 32-bit machine into the waste stream, so that the total amount in the waste stream remains the same but you no longer need software support for the 32-bit machine. How to get access to the right parts of the waste stream to be able to pull out some working 64-bit hardware is another question, and one where I don't have an answer that wouldn't involve spending money (which would presumably make the proposed alternative insufficiently comparable, since presumably you wouldn't have to spend money to keep the existing 32-bit machine in service). If Andrey does, I'd be interested to learn it. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Suggestions about i386 support
> On Jun 10, 2024, at 01:44, Andrey Rakhmatullin wrote: > > On Sun, Jun 09, 2024 at 08:39:27PM -0500, r...@neoquasar.org wrote: It's not just a matter of "buy something better." That's easy. >> >>> Indeed, that is easier and cheaper. >> >> Of course, continuing to use a system I already have is cheaper still. >> >>> What's not easy is that a) that adds another machine to the waste >>> stream, instead of continuing to get use from it, and b) someone has >>> to take the time to set up the new machine, test things, migrate >>> services, etc. to functionally replace the old one. That takes time >>> and effort, too, multiplied by the number of such systems out there. >> >>> (a) is false as newer hardware can already be taken from electronic waste, >>> so it does not add new waste. >> >> That is a gross overstatement. Electronics are NOT 100% recyclable. A fair >> amount of material still goes to waste, and there are all kinds of costs >> associated with those processes. >> >> Reuse is better than recycle for complex things like electronics. > You were suggested to resuse an old amd64 machine. Again, that assumes that I have such a thing. I don't. Unless you want to provide one? Also, that still doesn't explain how that means the existing 32-bit machine stays out of the waste stream. In your solution, it doesn't. In my solution, it does. --J
Re: Suggestions about i386 support
On Sun, Jun 09, 2024 at 08:39:27PM -0500, r...@neoquasar.org wrote: > >> It's not just a matter of "buy something better." That's easy. > > >Indeed, that is easier and cheaper. > > Of course, continuing to use a system I already have is cheaper still. > > > What's not easy is that a) that adds another machine to the waste > > stream, instead of continuing to get use from it, and b) someone has > > to take the time to set up the new machine, test things, migrate > > services, etc. to functionally replace the old one. That takes time > > and effort, too, multiplied by the number of such systems out there. > > > (a) is false as newer hardware can already be taken from electronic waste, > > so it does not add new waste. > > That is a gross overstatement. Electronics are NOT 100% recyclable. A fair > amount of material still goes to waste, and there are all kinds of costs > associated with those processes. > > Reuse is better than recycle for complex things like electronics. You were suggested to resuse an old amd64 machine. -- WBR, wRAR signature.asc Description: PGP signature
Re: Suggestions about i386 support
>> It's not just a matter of "buy something better." That's easy. >Indeed, that is easier and cheaper. Of course, continuing to use a system I already have is cheaper still. > What's not easy is that a) that adds another machine to the waste > stream, instead of continuing to get use from it, and b) someone has > to take the time to set up the new machine, test things, migrate > services, etc. to functionally replace the old one. That takes time > and effort, too, multiplied by the number of such systems out there. > (a) is false as newer hardware can already be taken from electronic waste, so > it does not add new waste. That is a gross overstatement. Electronics are NOT 100% recyclable. A fair amount of material still goes to waste, and there are all kinds of costs associated with those processes. Reuse is better than recycle for complex things like electronics. >(Also electricity isn't free everywhere.) Of course. > Maintaining support for ancient hardware costs too. And is more expensive per > device as the number of systems is lower. This will always be true if more than one architecture is supported. One will be more expensive (in labor) than the other. > [support assistance suggestions] I will keep this (and a couple others) that have listed specific suggestions and work on them as I have time. The idea of fundraising is an interesting one. > Which leads to the problem: most people who want this, seem to want to > continue to use old hardware (T60, N270). However, continuing to support i386 > has likely costs much higher than the replacement cost of said hardware... Which is probably why nobody really seems sufficiently motivated to actually invest resources. (Or do you?) Except that the "replacement cost" is not tied in any way to the "development cost" in a practical sense. There is no way to move resources from anywhere that I can use for "replacement cost." I'm on my own. That's true for development, too, of course. But you make it sound like there is money somewhere for replacement and there isn't. Also, HARDWARE replacement is the simplest and cheapest part. That doesn't address any of the time or expense in setting up and implementing a new system. That is far more expensive and time consuming than just buying a new motherboard. It's disingenuous to ignore this. > (Sadly you previously refused incoming mail as I got a bounce.) As you can imagine, I don't personally approve or deny each incoming email. It's possible my mail server denied your message based on anti-spam criteria. I do get incoming mail in general and I get mail sent to this list. If you want to troubleshoot this further, I can send you another account (off list) that we might use as a side channel.
Re: Suggestions about i386 support
Hi, On Sun, 2024-06-09 at 08:58 -0500, r...@neoquasar.org wrote: > What it is is functional, and paid for. And likely, already installed > and in use somewhere (like all of my 32-bit systems). > > It's not just a matter of "buy something better." That's easy. Indeed, that is easier and cheaper. > What's not easy is that a) that adds another machine to the waste > stream, instead of continuing to get use from it, and b) someone has > to take the time to set up the new machine, test things, migrate > services, etc. to functionally replace the old one. That takes time > and effort, too, multiplied by the number of such systems out there. (a) is false as newer hardware can already be taken from electronic waste, so it does not add new waste. (Also electricity isn't free everywhere.) Maintaining support for ancient hardware costs too. And is more expensive per device as the number of systems is lower. > I've asked before and I'll ask again - and perhaps it's time for > someone to contact me off list to discuss details - how can I help > with support for i386? I have just enough software training to be > dangerous and may be able to help carry some of the actual load here, > instead of just asking for more free support. As I said before (https://lists.debian.org/debian-devel/2024/05/msg00302.html): If you look at https://release.debian.org/testing/arch_qualify.html there is at least several things that can be done: 1. Add CPU security mitigations to Linux kernel. 2. Address builds reaching address limit. There were ideas to use foreign-arch (amd64) compilers to do so. 3. Look at other arch-specific issues (porter); this can also include baseline violations and other issues for real i386 hardware. It is also possible to work on finding funding and asking someone else to do this. I've no idea how much that would cost, but let's say a few 10k USD. Which leads to the problem: most people who want this, seem to want to continue to use old hardware (T60, N270). However, continuing to support i386 has likely costs much higher than the replacement cost of said hardware... Which is probably why nobody really seems sufficiently motivated to actually invest resources. (Or do you?) (Sadly you previously refused incoming mail as I got a bounce.) Ansgar
Re: Suggestions about i386 support
Characterizing it as "ancient" intentionally misses the point. What it is is functional, and paid for. And likely, already installed and in use somewhere (like all of my 32-bit systems). It's not just a matter of "buy something better." That's easy. What's not easy is that a) that adds another machine to the waste stream, instead of continuing to get use from it, and b) someone has to take the time to set up the new machine, test things, migrate services, etc. to functionally replace the old one. That takes time and effort, too, multiplied by the number of such systems out there. People are saying "you can't trust the popcorn data," but that kind of sounds to me like people looking to support the answer they've already chosen and discounting evidence to the contrary. I understand that continuing to support things isn't free. I've offered to contribute, but my offers have all been met with descriptions of how hard someone else is working, rather than any description of how I might help. Lastly, there was a description of a problem that "needed to be fixed," but also "can't be reproduced." Well, if it can't be reproduced, then by definition, it can't be fixed. That's basic troubleshooting. If it can't be reproduced and doesn't seem to affect most systems, then it's barely more than a rumor and deserves no attention until it's substantiated further. So it doesn't make sense to throw that on the pile of "look how hard it is to support old hardware." Yes, there are challenges. Lots of them. But that's not one of them. I've asked before and I'll ask again - and perhaps it's time for someone to contact me off list to discuss details - how can I help with support for i386? I have just enough software training to be dangerous and may be able to help carry some of the actual load here, instead of just asking for more free support. Sent from my mobile device. From: Marc Haber Sent: Monday, May 20, 2024 02:35 To: debian-devel@lists.debian.org Subject: Re: Suggestions about i386 support On Sun, 19 May 2024 20:19:12 +0200, Ben Hutchings wrote: >The plan is to keep i386 as a partial architecture that can be used as >a "foreign architecture" on systems where amd64 is the main >architecture. Many people using ancient hardware such as a T60 thinkpad say that's not enough for them. I can partly understand both sides though. Greetings Marc -- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Re: Suggestions about i386 support
On Sun, 19 May 2024 20:19:12 +0200, Ben Hutchings wrote: >The plan is to keep i386 as a partial architecture that can be used as >a "foreign architecture" on systems where amd64 is the main >architecture. Many people using ancient hardware such as a T60 thinkpad say that's not enough for them. I can partly understand both sides though. Greetings Marc -- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Re: Suggestions about i386 support
On Sun, 2024-05-19 at 07:26 +, defrag mentation wrote: > I think some of the i386 support policies needs to be reconsidered. > > Here are some suggestions: > > 1. Move Wine-32 to amd64, and Wine-32 may be compiled to 64-bit time_t. > > Wine-32 is now in currently dropped i386 DVDs/BDs, not in amd64 DVDs/BDs as > it is multiarch-only now, so at least I think moving it to amd64 is needed. I think you are confusing the removal of i386 installation media, with the removal of i386 as a whole. The plan is to keep i386 as a partial architecture that can be used as a "foreign architecture" on systems where amd64 is the main architecture. [...] > 2. For device support: > > There are no pure 32-bit x86 non-embedded devices since 2010 (as Atom N450 > deprecated the pure 32-bit Atom N270) widely manufactured. > > i386 UEFI support is mandatory for Bay Trail and some Cherry Trail devices > widely manufactured in 2012-2015, as they are 32-bit Windows 8/8.1 > preinstalled and do not support legacy BIOS boot mode. > > It's good to keep i386 UEFI support (signed is better) for Bay Trail and some > Cherry Trail devices in Debian amd64. Bookworm has added it (moved it from > multi-arch iso to amd64 isos), but trixie seems to be dropping it. If Debian > thinks 2015 is ancient enough in 2025, this suggestions can be ommited. [...] You should ask about that on the debian-cd or debian-boot list. Ben. -- Ben Hutchings For every complex problem there is a solution that is simple, neat, and wrong. signature.asc Description: This is a digitally signed message part
Re: Re: Suggestions about i386 support
On Sun, May 19, 2024 at 09:09:10AM +, defrag mentation wrote: > > What will this solve? > > > I don't think this is "needed"? Unless you think all i386 packages will be > > removed from Debian, which is not the plan? > > Case 1: Debian removed i386 DVDs/BDs, and someone jigdo backed the full amd64 > DVDs/BDs set will be surprised that it do not contain wine32. This isn't specific to wine. > > Debian wine is not the only thing we want i386 libraries for. > > What are they? Non-Debian Wine (e.g. Proton), legacy native apps, probably other non-Wine wrappers. -- WBR, wRAR signature.asc Description: PGP signature
Re: Re: Suggestions about i386 support
> What will this solve? > I don't think this is "needed"? Unless you think all i386 packages will be removed from Debian, which is not the plan? Case 1: Debian removed i386 DVDs/BDs, and someone jigdo backed the full amd64 DVDs/BDs set will be surprised that it do not contain wine32. Case 2: Wine will work through Y2038 if its Unix-layer is 64-bit time_t by Debian, and its Win32-layer is 64-bit time_t by Wine maintainers. And it will be convenient to separate it from i386 repo since it will stick to 32-bit time_t. Visual C++ 2005 compiled things are 64-bit time_t already, so a lot of 32-bit Win32 apps already have no Y2038 problem. Case 3: If forky or later versions will drop i386 totally, trixie may be good to firstly separate wine32 from i386 repo. > Debian wine is not the only thing we want i386 libraries for. What are they? > And nobody proposed it. If nobody proposed it, this can be ignored. Sorry for the confusion.
Re: Re: Suggestions about i386 support
On Sun, May 19, 2024 at 07:26:28AM +, defrag mentation wrote: > What will this solve? > I don't think this is "needed"? Unless you think all i386 packages will be removed from Debian, which is not the plan? Case 1: Debian removed i386 DVDs/BDs, and someone jigdo backed the full amd64 DVDs/BDs set will be surprised that it do not contain wine32. Case 2: Wine will work through Y2038 if its Unix-layer is 64-bit time_t by Debian, and its Win32-layer is 64-bit time_t by Wine maintainers. And it will be convenient to separate it from i386 repo since it will stick to 32-bit time_t. Visual C++ 2005 compiled things are 64-bit time_t already, so a lot of 32-bit Win32 apps already have no Y2038 problem. Case 3: If forky or later versions will drop i386 totally, trixie may be good to firstly separate wine32 from i386 repo. > Debian wine is not the only thing we want i386 libraries for. What are they? > And nobody proposed it. If nobody proposed it, this can be ignored.
Re: Suggestions about i386 support
On Sun, May 19, 2024 at 07:26:28AM +, defrag mentation wrote: > I think some of the i386 support policies needs to be reconsidered. > > Here are some suggestions: > > 1. Move Wine-32 to amd64, and Wine-32 may be compiled to 64-bit time_t. What will this solve? > Wine-32 is now in currently dropped i386 DVDs/BDs, not in amd64 DVDs/BDs as > it is multiarch-only now, so at least I think moving it to amd64 is needed. I don't think this is "needed"? Unless you think all i386 packages will be removed from Debian, which is not the plan? > 3. For future i386 support: > > If there are not enough human resources, i386 can be dropped completely as > Wine-32 is moved to amd64 Debian wine is not the only thing we want i386 libraries for. > If someone wants to continue maintaining pure 32-bit device bootable i386, I > think recompiling it to be Y2038-safe is still meaningless And nobody proposed it. -- WBR, wRAR signature.asc Description: PGP signature
Suggestions about i386 support
I think some of the i386 support policies needs to be reconsidered. Here are some suggestions: 1. Move Wine-32 to amd64, and Wine-32 may be compiled to 64-bit time_t. Wine-32 is now in currently dropped i386 DVDs/BDs, not in amd64 DVDs/BDs as it is multiarch-only now, so at least I think moving it to amd64 is needed. Wine-32 may be compiled to 64-bit time_t, not affecting its Win32 binary compatibility. For its Win32-layer, 64-bit time_t can be enabled with -D__MINGW_USE_VC2005_COMPAT or by linking to UCRT, but it's up to Wine maintainers. For its Unix-layer, 64-bit time_t can be enabled with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64, and since Wine is to run Win32 executables, this do not affect its Win32 binary compatibility. This can be done by Debian. For compatibility with the multiarch support to i386, I think renaming the dependencies' package name and soname may be needed. There is an experimental 32-bit Unix library-free 'WoW64 thunking' or 'new WoW64' mode introduced in Wine 8.0 enabled by './configure --enable-arches=x86_64,i686', and becomes almost stable in Wine 9.0. But there are some restrictions in it, such as OpenGL performance problem and Win16 support, so it's not sure whether Wine 10.0 will announce this mode becomes default. If Wine 10.0 announces 'WoW64 thunking' or 'new WoW64' mode becomes default, Wine-32 can be dropped directly. As Freexian's ELTS is selective support, and almost no one using Debian as server needs Wine, Freexian probably will not support i386 any more, and thus I think Debian releasing important 32-bit time_t i386 stuffs like Wine-32 is acceptable until 2032. But Ubuntu may have a different opinion as they will support total Ubuntu for 12 years. Moving Wine-32 from i386 to amd64 and recompiling it to 64-bit time_t (or dropping it because 'new WoW64' mode becomes default) may be needed for Ubuntu to keep it from Y2038 problem. 2. For device support: There are no pure 32-bit x86 non-embedded devices since 2010 (as Atom N450 deprecated the pure 32-bit Atom N270) widely manufactured. i386 UEFI support is mandatory for Bay Trail and some Cherry Trail devices widely manufactured in 2012-2015, as they are 32-bit Windows 8/8.1 preinstalled and do not support legacy BIOS boot mode. It's good to keep i386 UEFI support (signed is better) for Bay Trail and some Cherry Trail devices in Debian amd64. Bookworm has added it (moved it from multi-arch iso to amd64 isos), but trixie seems to be dropping it. If Debian thinks 2015 is ancient enough in 2025, this suggestions can be ommited. 3. For future i386 support: If there are not enough human resources, i386 can be dropped completely as Wine-32 is moved to amd64 (or is dropped because 'new WoW64' mode becomes default), pure 32-bit device boot support is dropped, and it's all about support for ancient Linux apps/games which can be done by old Debian releases. If someone wants to continue maintaining pure 32-bit device bootable i386, I think recompiling it to be Y2038-safe is still meaningless as the devices will be very aging and probably broken in 2038, and probably no one need a non-binary-compatible i386 build. Just keep it 32-bit time_t is enough as I think.
