On Sun, May 19, 2024 at 07:26:28AM +0000, 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

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmZJuMYtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh /YoP/1PiHJXTsizPaGoJ6t/DwwEejr7nca3Wa6+BlyTQLJSOBc564yYiA27/T3y5 MhAMKR4CTaiGB7bj1+3wNJXhc/7WjyH7ACL0O5qmO0qAK6YxIfHTaehsQm3wqFAP dFMwBFnSajeWN5sXkUsy2+ubviKgVG+e/X8h2cym1LFmrzp8wWmiBCz2nNKH9u5/ hDuh0NB2YRKJLvBKAnESiIsxUqCUpC8M7CWP3bzsYXHnQp9zgFOmlNCz8idwmQph EO/KIe9SnpmJcO8c/65QEzwaudVQXnhxO6MLjG7j9qal1up/DnKfxsPiwXtN1Pjg 55BFhw63xNrjK9GHvNLqAiGXQBCMty7cs3QuGRzL4dspzIF4T+C1XTS5lUVy9rzo T6On8AEX32mUa/E40U8UqSVhWp4hdacCDHy3W9237vxZtJ9bKhwl8UuPzVYX2ea1 flWHqreqkoul7ofCKjQb5O75KtKFd1rhWN7QEjHPLZ2/Aw6sgzw2pjHrtqkaFhHZ FwDAWKJZZc0NDOcGSjA5T5vtauClZmbApFKoEBhvY4CIVJcdD5awcHPyfCb8R1FH avPcithrHys9lIzI/WVz7sadpl6m3ofYwPvnWTjo3oGdgqTlvkG8NrqruxAi7mnc SXyOlwiguVjt93a6g2G8cLtXJ387pMIWcjbkz20qOWOVZrc+
=Vkgi
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, May 19, 2024 at 09:09:10AM +0000, 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

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmZJznctFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh 7l0P/1qvNiN5L2OMEX1kGXFe1AyLhzrurv7FOVgF0bSxhXOqy+Tc2Yevy1AkBev6 ZszLdYvNfRTJtnbPrLSfkDx+sV6ODub0GJb/ed/3IL52DZz41M5rxpe/x5uETV5G nyfv5bjlCjDe9kTTatkdFcLAY2kKKy21grvPL1a9VP/xaO6jWnZGrfnFsUNyHG68 3GPmvu5Y49cR2I2AqjAXGE6l37s0SwwLthl/u3VoryQ+rZb6q32rM6GIkVxb1jwX Rdog2hVf2wjwpzhT0JYQkUdxz9+hpRSvyLQiFjBEYES/PXopLTf27nNu4y6pOdJu jDWUg0g+m7r86+f8N12cUixM5k1rzovVR0LbRIuN/6LranZOp36nijfVFKtk237X PROzzQDgx9fSQbrhMGWR5PsNvISseEt1JTIienbgkHOCvjMdcv5F1rGPXBMrMfHY RpHlmOIDT4RkljRMO3FKS/cc4HoQD4I8AZEIziGeTwkDNplzWeJCiPS6mB8Co6Zp 9FfOF+uWL+mKjSk0n3xKdUYg0AhzwzHh4dTLx3JbtAadFo3bZeN60hcrbofZR7Y+ OCmTsNaRltKOTf86g4oBHbHdAaZ/mcfoyF9fd7TWn+4xM5SJvkPEa/XuRDlLEtZM KFQnpwsziNIBqVofZ5Ex7D3XNKjrkxIDkIqkWjzs/iewYokx
=/mLu
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 19 May 2024 20:19:12 +0200, Ben Hutchings
<ben@decadent.org.uk> 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On Sun, 2024-06-09 at 08:58 -0500, rhys@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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Jun 09, 2024 at 08:39:27PM -0500, rhys@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

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmZmoM0tFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh x4cP/RCT2hLNkwbdegAqMxTH+X1G6kuTJYR6Za4tEft99hB5HZRp3CPlz9jwVELr ZD4auMMV3xG3baTFKeLC236NiPYBHRSubUhu34HADUfRkzTF3ktGR5kS32jalwIa hYSkLU7rcgzEL6w5/qIEehR1/AYmXUF7VIx3JNlrBTM7nYcdRXR4nZEOrmavYURT ueZdtYdvXKQTIn2RwC3KhHPU9k945eNRLuYpTrvg/bvwpWKYbFf/IkwPTmZ3DMuP uS+mEj+p3dZGIHHoLJmKAzf/+xyC4W0xuWxwtTede57amDWHn8ijgz/URjB2IVtV DfgEeTc8b0Oshkqnvsa9NW6GNu2BxCH4nE7QIqF8mfDjsdjrJtmLuMRTpQ0KA43G MGvrZ5X1NUFr3XzQxLFQieoAHUmQCC4GzXqz6V7FevNTpK+zzBfFi6aeWBg521Mb XKfhpCKInLFs2yYjHXMOp0JCOfJFx6/hrZ0fi/aOSCxY0sXaztVxFtHSs2hfzKKv zxSYvXBOweIOBeZdMqDYT4NUrqmR5SKKpLRIR0iJEChKuCNY9akjjsEt3WNcFeAW LVEu7E2ul56XRD6B2uwydEc/yHysXGdYeoMWg2NwV/fJegauwzb/eCeY851uWRev CSYC9gZei4EP1aKSuJm9WNTPcCIu/edxYplLi8n2Lzo0wRBW
=eulS
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Jun 10, 2024, at 01:44, Andrey Rakhmatullin <wrar@debian.org> wrote:

On Sun, Jun 09, 2024 at 08:39:27PM -0500, rhys@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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi The (2024.06.10_12:22:14_+0000)

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/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
On 2024-06-10 at 08:09, rhys wrote:

On Jun 10, 2024, at 01:44, Andrey Rakhmatullin <wrar@debian.org>
wrote:

On Sun, Jun 09, 2024 at 08:39:27PM -0500, rhys@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


-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEJCOqsZEc2qVC44pUBKk1jTQoMmsFAmZm7/YACgkQBKk1jTQo Mmu9FxAAogS9mQ9Il062SFB6hUdIP+ohRJJIc10N9jK7f+a1eufE7cIP4s76Akl/ 9iz1LpK4EwUbwfuGkDxCqiq24v4fkzTXli5h6pQpp5w5bKY3cYxCHzdQg53dwaws zkCTeZq3r/AelDwN9rcv0MlwPBjR37GiL62fx2qMOHRHYm+XlSL7w8bh5KlilweL FZS1H2pPBVqXwiN3FZrzMq/pGinQ3nOP5MzP6KgmErop96/2TEFqaWzfRL7F/ECA D+Fy8PZnpp0n0i+6OcCyAE2DWUsiBhX8LynVPYHToa5e1PN6AaLnUtzXD/+geLy2 ltL+7nuY+K68dct+YQtwN1tCxslDwT6dlh+fpt7nGu8xURtJF8VWQ0orL1dYKIlq brxNMt/R769fIouZb7LD1D1A1aHs+V3oZSB0WGiKHfRFDryIUjCh7iXI15AHDqBL d7tIJCDjdtjTwkdS+3MbnEMf/So/jIFaCRrY1l9F7ExgzcU2q7DQXSMnABx6y6Or aD6GlzztaGkVw/Jv3OUR7aGgcAXklvPrs88E0bey5/Cb3FmbBZB/xdxP/F1zuRh8 wj4NY208g4fGFMiWO0zOncNjW4dJC9BkGGV/4hQuHhy2bIxJZWBrFb3dhnZRcjmJ +cQq+n1Dg7YD3fUa3R4QPVL1e4aT

On Mon, 10 Jun 2024 at 12:43:27 +0000, 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Jun 10, 2024 at 04:02:54PM +0100, Simon McVittie wrote:

On Mon, 10 Jun 2024 at 12:43:27 +0000, 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

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmZnGQctFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh On8P/AyS4QvtsZ0h9J8GArT33SaA8GaS/fudyU+eneeDk58J6PtJedHla28nE9ZI Y0A2yq0tBZ90iJc9bLQC6CQspxt6xm91ahwU3Kg9/zBnlhoiy9Su1QTPXfRebkOt iaZduQIqt2JL9QvBCCIf1B/Pnk1oDXcPGfu0eO4yvD5Y3ue8M1RhNaMIEAXj+kgN XFKrV75+ak01ZIqHysfCW4Ac63r+nJ3p0JTGeQLNX4MW31kj28+WBq4RCd0GPpYN PO9DOVrCKffKKn5YzwIkZ59EYBd6iBtseNjDvypYCOsEplpi/GhKRlUXwHVENzBP H/gvLgBY4B75nl4t3mXrP4x8LK9wsercZjPF9SsAqkeVSMwtFuFm5GjiBDKJEJdv RJTbrTkCjNdX1pQA0+T1O3qgH67mAX/DiY4WI1lsPV/TMzh2rhHWUyBoU1Fp3Q0K NoJ9+q1YnDthq7guBk0Dx0mokQSVeypdrDVmtnrc3gQqlixtjK3gfviBIjR/n00P rQMVa5dkUcHfJw2WekpcXnBUHq1WncakS7Qp1hDI/6/WvHzwaPOVSRkZDSnYC9OM IcJVG5hnYWQoo3NpzKD3tw4bANZWtBvgP18O5nF9Kjc/30Bb1fA1vctA1G1kfeBk z9f1psD+Z9CqokHIt8hZxji8oY2c9rM57cs2uhb4GTxM6W0r
=Dg4a
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

On 09.06.24 16:21, Ansgar 🙀 wrote:

Hi,

On Sun, 2024-06-09 at 08:58 -0500, rhys@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.

There can be other reasons aswell, for example, it's quite hard
to get a T61 with 4:3 screens and later models only have widescreens,
which I find cumbersome to use.

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.

Newer hardware is still often sought after and as such often quite
costly, whilst you can sometimes snatch a machine from e-waste,
you have to still be lucky.

About electricity: I know that, and that is part of the reason why I
would never use a Pentium 4 as a server nowerdays. However,
with laptops, which often run in standby or are at idle and have
good power-saving features, the advantage, at least with my T60
lies in 4-10W, which can be mostly attributed to the CCFL, if the
powertop output is correct. (If I were to switch out the CCFL for
an LED, I might be able to get single digit discharge-rates.)

Also the repairability of newer laptops is often times garbage,
something I find invaluable on a transportable device, not to mention
that you can replace such machines quite cheaply, in the worst case.

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.

CPU mitigations exist in the PAE kernel that is at least supported on an
Intel Pentium PRO (and on Pentium M's with forcepae, to my knowledge).
Instead of removing i386 entirely, I'd suggest to bump the requirements to include PAE, if that would otherwise be an argument to stop supporting i386.
If someone would really like to run debian on a non-PAE-system, they'd still
be able with a custom kernel.

2. Address builds reaching address limit. There were ideas to use foreign-arch (amd64) compilers to do so.

Wouldn't that be important for all 32-bit archs? I'll have a look at
trying to setup
a crosscompile environment.

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.)

My mail server has some problems which is the reason why I use my old mail address. My new address is mail@zeldakatze.de , however, currently postfix sends mail on the wrong ip address breaking rDNS lookups, which I'll
have to fix.

Ansgar

regards,
Maite Gamper (zeldakatze)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 14 Jun 2024 21:04:23 +0200, Ben Hutchings
<ben@decadent.org.uk> wrote:

But we definitely should
discourage users from using i386 kernel packages on 64-bit-capable
hardware, if we don't drop them entirely. I keep meaning to implement
a boot-time warning about that...

We could build that into the update-grub kernel snippet, with the
advantage that it would be easier to get rid of the warning locally.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)