Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Lisandro Damián Nicanor Pérez Meyer]

Hi, late on the thread, but...

On Tue, 30 May 2023 at 19:51, Diederik de Haas  wrote:
>
> [Please CC me in replies as I'm not subscribed to this list]
>
> I hope I'm not too late for this discussion ...
>
> Steve McIntyre  wrote:
> > Luca Boccassi wrote:
> > >On Fri, 19 May 2023 at 12:42, Steve McIntyre  wrote:
> > >> I'm planning on stopping publishing installer images for i386
> > >> soon. Why? We should be strongly encouraging users to move away from
> > >> If they're still running i386 *hardware*, then they should be replacing
> > >> that hardware with more modern, more capable, more *efficient* stuff.
> > >>
> > >+1 for stopping publishing installers for i386, it has been mentioned
> > >many times but it's always worth repeating: electricity costs to keep
> > >running i386 hardware are already way higher than what it costs to buy
> > >a cheap, low-power replacement like a raspberry pi, that also provides
> > >better performance.
> >
> > Exactly.
> > ...
> > If people have strong opinions about that plan, let us know please.
>
> I have *strong* opinions about this.
>
> https://lists.debian.org/debian-kernel/2023/01/msg00372.html was a message/
> plea to not forget about supporting OLD systems.
>
> While it may be a no-brainer for a person with a $/€ 1000 a month residual
> income to just buy new hardware whenever they feel like it, that is not the
> case for everyone.
>
> To quote (a part) of that email:
> > I happen to know of a few derivative projects that have been using
> > Debian technology that have brought new life to some really aging equipment
> > and some people in either Third World countries or in communities with low
> > incomes and either limited or non-existent access to modern equipment. One
> > such effort, the antiX distribution, has been effective in reaching poor
> > communities in Brazil recently, and has long been able to reach people with
> > scaled down Debian technology all over the world.
> >
> > I'm wondering if there is some way to provide a "hook" or a way for some of
> > these ten to twenty year old systems to remain functional for those who may
> > not otherwise have a way, other than to run insecure, out of date systems.
> > If there is a way, even a "side project", I hope that the Debian community
> > can help a few of these derivative distributions assist people worldwide to
> > have access to modern technology,
> > even from systems that are barely "modern" any more.
>
> Besides people in 'third world countries' (I actually don't like such
> qualifications at all), there are also people in the '1st world' who work 
> their
> asses off just to put food on the table, and thus also don't have the money to
> buy new equipment. But if you want to interact with your own government, you
> highly likely will need to have some PC (type) equipment.
> It could also provide a way to learn/develop new skills.
>
> It's absolutely true that modern machines are more energy efficient. What is
> also true is that the production of new devices has a big environmental
> impact.

Well, I do consider myself someone living in a third world country,
possibly already a four world by now. Some years ago I would have
certainly totally concurred with your observation. Nowadays? No. amd64
systems are old enough that you can find them in old machines too. My
PoV is that we reached the point at which we can safely say there are
replacements. Ecologically it is better to refurbish old amd64 systems
rather than trying to keep the i386 alive.

My personal PoV, but...



-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Diederik de Haas]

On Friday, 2 June 2023 20:59:27 CEST Wouter Verhelst wrote:
> "complain on -devel" is not part of the job

That wasn't my intend, but I obviously horribly failed at that.
Won't happen again o/

signature.asc
Description: This is a digitally signed message part.

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Wouter Verhelst]

On Wed, May 31, 2023 at 11:24:15PM +0200, Diederik de Haas wrote:
> On Wed May 31, 2023 at 12:44 PM CEST, Wouter Verhelst wrote:
[...]
> > 20+ year old machines are typically more power hungry, more expensive,
> > less performant, and less reliable than an up-to-date raspberry pi. If
> > you want to support people who can't afford shiny new hardware, I think
> > pointing them to raspberry pi-class hardware is a better idea than
[...]
> In the responses here, I've mostly seen the *assumption* that those old
> devices must be power hungry. While I'm quite sure modern hardware is
> more power *efficient*, that doesn't mean old hardware is thus power
> hungry. 
> But most of all, I'm flabbergasted/annoyed that someone who made explicit and 
> clear what they need, namely keeping support for i386, a bunch of people feel 
> the need to respond like "Well, actually, you need this (other thing)".
> I find that extremely condescending.

That's actually a bit of a misrepresentation of what I said.

I do believe there are still people using i386 hardware. I know for a
fact that there are still people using m68k hardware, too.

My argument is that "it is still used" is an argument that, due to the
very fact that retrocomputing exists, will never be a wrong statement.
To name an extreme example, there exist a handful of apple I devices
that are in working order today, but nobody would reasonably suggest
that it is a platform that still matters today.

Since it is always possible to come up with an example of someone still
using some old piece of hardware, I therefore think that it is not a
very compelling argument, in and of itself.

I also specifically said that older systems *typically* require more
power for less performance (etc). Of course there are exceptions, but
those are much more rare than the more common case of 20 year old
desktop-class hardware.

As an ex contributor to the m68k port who was active on the port when
our buildd hosts were still running on actual m68k hardware, I can tell
you that 20 year old hardware is not reliable *at all*. I have forgotten
how many times we've had to scrounge for older hard drives to replace
ones that died, wiggle RAM modules around, or do various types of
insane hardware maintenance that on modern hardware just isn't
necessary (I .. remember the one time where the one host
had to be moved because it was in a hot attic and the cooling system
had Opinions on having been run 24/7 for over a decade). As such, if
your choice is between a 20 year old piece of hardware or a brand new
one that has similar performance, your better choice is almost always
going to be the latter.

Note again how I said "almost always" here. Exceptions exist.

In my opinion, the question we should be asking ourselves is therefore
not "can we still find valid use cases for the port", because the answer
to that is always "yes" and therefore not interesting, but rather, "how
much effort will it cost us to keep the old port running".

Note that the answer to that very valid question will be influenced by
"who is interested in keeping the port available". If there is a strong
feeling that the i386 port needs to go, and there is a bunch of people
with the skills required and the interest in changing that, then there
is a fairly straightforward thing they can do to avoid the port being
binned. It requires you do lot of work, but "complain on -devel" is not
part of the job.

I was part of the team that kept doing the necessary work for years, and
we saved the port from being removed from Debian several times. If you
want to do the same for i386, the path is clear...

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[nick black]

Adam Borowski left as an exercise for the reader:
> Instead of RasPis as suggested by many in this thread, I'd instead suggest
> whatever is the current model of Odroid-H2+:

I was intrigued, but https://ameridroid.com/products/odroid-h2
suggests it's been out of stock since 2021?

-- 
nick black -=- https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.


signature.asc
Description: PGP signature

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Adam Borowski]

On Wed, May 31, 2023 at 10:10:56PM +, Andrew M.A. Cater wrote:
> As someone who owned and happily used an Asus eePC several years ago: very
> nice, silent - it also had a flash disk from the earliest days of flash disks.

Instead of RasPis as suggested by many in this thread, I'd instead suggest
whatever is the current model of Odroid-H2+:
* x86
* no moving parts
* either my meter is broken or it's 4.6W under full load (specs say 14W?!?)
* fat i/o
* 2×2.5Gbe

> The same arguments that I would now apply to the i386 port I'd also 
> apply to early AMD64 hardware - whoever had my first machine with it,
> it should now be long gone as power inefficient beyond words and 
> 15 years old.

At that time the concept of a daily driver capable machine taking low power
was in its infancy, they just can't come close to newer designs.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ An imaginary friend squared is a real enemy.
⠈⠳⣄

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Theodore Ts'o]

On Wed, May 31, 2023 at 12:51:06AM +0200, Diederik de Haas wrote:
> 
> I would be VERY disappointed if Debian would abandon people who do NOT have 
> the means to just buy new equipment whenever they feel like it.

Debian is a Do-ocracy.  Which is to say, it's a volunteer project.
People work on what they feel like working on.  Trying to guilt-trip
people into working on something because they *should* often doesn't
work well.

If you'd like to make sure that i386 isn't abandoned, why don't you
roll up your sleeves, step forward, and volunteer to help?

Cheers,

- Ted

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Paul Wise]

On Wed, 2023-05-31 at 00:51 +0200, Diederik de Haas wrote:

> I would be VERY disappointed if Debian would abandon people who do NOT have 
> the means to just buy new equipment whenever they feel like it.

There are Debian contributors who are in this position (although
perhaps not with i386 hardware) and would likely appreciate hardware
donations to upgrade to more modern hardware. At the same time we have
contributors who regularly buy, stop using and discard old hardware.

It would be great if our more fortunate contributors would be willing
to donate hardware to less fortunate contributors and could register
their available hardware on the wiki page for this. Perhaps this could
be extended to users of i386 hardware too.

https://wiki.debian.org/Hardware/Wanted#Donations

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Andrew M.A. Cater]

On Wed, May 31, 2023 at 11:24:15PM +0200, Diederik de Haas wrote:
> On Wed May 31, 2023 at 12:44 PM CEST, Wouter Verhelst wrote:
> > On Wed, May 31, 2023 at 12:51:06AM +0200, Diederik de Haas wrote:
> My point is: what about people who don't have the option to *buy*
> anything (new or used), for financial, logistical or other reasons?
> 
> I've been keeping an eye on developments in the upstream linux kernel
> and saw there was a 'spring cleaning' (i.e. removal of old HW support).
> Reading through the commit messages, I noticed 2 criteria for removal:
> - Code has (effectively) been unmaintained for MANY years
> - The maintainers have not seen any indication for several years that
>   ANYONE is actually using that hardware.
> 
> I think those are very reasonable criteria.
> In my initial reply I quoted someone who EXPLICITLY said there were
> people who actually used those i386 devices.
> 
> On the kernel team I've an actual valid argument why supporting i386
> hardware is *difficult* as they don't have the HW (themselves) to
> reproduce an i386-specific issue or to test a potential fix for that.
> 
> In the responses here, I've mostly seen the *assumption* that those old
> devices must be power hungry. While I'm quite sure modern hardware is
> more power *efficient*, that doesn't mean old hardware is thus power
> hungry. 
> But most of all, I'm flabbergasted/annoyed that someone who made explicit and 
> clear what they need, namely keeping support for i386, a bunch of people feel 
> the need to respond like "Well, actually, you need this (other thing)".
> I find that extremely condescending.
> 
> Maybe it's an option to answer the ACTUAL question?
> (and that answer could be 'no')
> 
> > I don't think "but old hardware is still used" is a very good argument
> > for keeping i386 around.
> 
> I think that's actually an excellent reason.
> 
> I've likely missed prior discussions around this subject, but I haven't
> seen and can't think of the reasons why so many people seem so adament
> to get rid of i386 ASAP.

I think I raised this some months ago and was told that it was too late to
make a decision to stop for bookworm but that this was something that 
should be decided early in a release cycle and not at the end when deciding
which architectures wouldn't actually make the cut for release.

It is already hard to test i386 on i686 hardware: as others have said,
most of the tests would be on >> 10 year old hardware.

It does become a law of diminishing returns: if i386 programs had to 
be pulled for security or unmaintainability reasons in the course of bookworm, 
nobody would be surprised.

> 
> Assuming there are indeed valid reasons to get rid of i386, I think it
> would be a far better plan to announce that **Trixie** will be the last
> release that will support i386.

No: announce it at the start of bookworm release and have the Trixie release
team immediately drop it for Trixie
- that way you have five years of support to transition off it.
Otherwise, you've just added _another_ five years of lessening support to
an architecture that won't have been produced for >15 years.


> That way people who care about i386 have a full development cycle to
> make i386 the best it can be for as long as they can still use that HW.
> Maybe they can also make arrangements with CIP to designate the Trixie
> kernel as a Super Long Term Support kernel release.
> 
> But tackling on the release notes at the very last moment that Bookworm

> will be the last supported release, seems not so 'nice' IMO.
> 

As someone who owned and happily used an Asus eePC several years ago: very
nice, silent - it also had a flash disk from the earliest days of flash disks.
If the person who has them still has them all running in another five years,
he will have got an excpetional lifespan out of them. There comes a time
when ports and architectures have to die through lack of hardware or 
maintenance: we've seen that for alpha, varieties of mips and sparc, 
effectively, and the maintainers behind the Debian bsd ports have just
suggested that it should end.

The same arguments that I would now apply to the i386 port I'd also 
apply to early AMD64 hardware - whoever had my first machine with it,
it should now be long gone as power inefficient beyond words and 
15 years old.
> Cheers,
>   Diederik

With best wishes, as ever,

Andy Cater

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Diederik de Haas]

On Wed May 31, 2023 at 12:44 PM CEST, Wouter Verhelst wrote:
> On Wed, May 31, 2023 at 12:51:06AM +0200, Diederik de Haas wrote:
> > While it may be a no-brainer for a person with a $/€ 1000 a month residual 
> > income to just buy new hardware whenever they feel like it, that is not 
the 
> > case for everyone.
> [...]
> > It's absolutely true that modern machines are more energy efficient. What 
> > is 
> > also true is that the production of new devices has a big environmental 
> > impact. 
>
> 20+ year old machines are typically more power hungry, more expensive,
> less performant, and less reliable than an up-to-date raspberry pi. If
> you want to support people who can't afford shiny new hardware, I think
> pointing them to raspberry pi-class hardware is a better idea than

I have worked to improve support for Pine64 devices (too), so that
people who can afford it, can buy power-efficient SBCs (instead of
horrible RPi's where the non-free firmware is the least of their sins).

My point is: what about people who don't have the option to *buy*
anything (new or used), for financial, logistical or other reasons?

I've been keeping an eye on developments in the upstream linux kernel
and saw there was a 'spring cleaning' (i.e. removal of old HW support).
Reading through the commit messages, I noticed 2 criteria for removal:
- Code has (effectively) been unmaintained for MANY years
- The maintainers have not seen any indication for several years that
  ANYONE is actually using that hardware.

I think those are very reasonable criteria.
In my initial reply I quoted someone who EXPLICITLY said there were
people who actually used those i386 devices.

On the kernel team I've an actual valid argument why supporting i386
hardware is *difficult* as they don't have the HW (themselves) to
reproduce an i386-specific issue or to test a potential fix for that.

In the responses here, I've mostly seen the *assumption* that those old
devices must be power hungry. While I'm quite sure modern hardware is
more power *efficient*, that doesn't mean old hardware is thus power
hungry. 
But most of all, I'm flabbergasted/annoyed that someone who made explicit and 
clear what they need, namely keeping support for i386, a bunch of people feel 
the need to respond like "Well, actually, you need this (other thing)".
I find that extremely condescending.

Maybe it's an option to answer the ACTUAL question?
(and that answer could be 'no')

> I don't think "but old hardware is still used" is a very good argument
> for keeping i386 around.

I think that's actually an excellent reason.

I've likely missed prior discussions around this subject, but I haven't
seen and can't think of the reasons why so many people seem so adament
to get rid of i386 ASAP.

Assuming there are indeed valid reasons to get rid of i386, I think it
would be a far better plan to announce that **Trixie** will be the last
release that will support i386.
That way people who care about i386 have a full development cycle to
make i386 the best it can be for as long as they can still use that HW.
Maybe they can also make arrangements with CIP to designate the Trixie
kernel as a Super Long Term Support kernel release.

But tackling on the release notes at the very last moment that Bookworm
will be the last supported release, seems not so 'nice' IMO.

Cheers,
  Diederik


signature.asc
Description: This is a digitally signed message part.

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Ansgar]

On Wed, 2023-05-31 at 19:48 +0100, Wookey wrote:
> On 2023-05-31 07:29 -0500, John Goerzen wrote:
> 
> > > Hanging on to systems using power-hungry chips from 20 years ago instead 
> > > of
> > > intercepting a system such as this is not reducing the number of computers
> > > that end up in the waste stream, it just keeps you stuck with a more
> > > power-hungry system.
> 
> a) That's not necessarily a problem if the machine is running from a
> renewable supply. The issue is emissions, not power consumption per
> se.

Thankfully I have a spiritual power filter[1] based on anthroposophic
principles that makes my computers consume only renewable energy ;-)

> and b) as both John and I have pointed out there are low-power i386
> systems still in use.
> 
> c) it's not our choice to make. If people insist on using more
> electricity than they need to for their computing, that's on them.
> (we
> enable enormous amounts of this already - old i386 systems probably
> barely register at this point)
> 
> Debian should be supporting people using whatever suits them where
> that effort is reasonably proportionate. We are not driven by the
> 'sell new stuff' goals of hardware manufactuers so we should IMHO be
> erring on the side of keeping stuff going as long as there is
> sufficient community support.

I doubt we have that, see some of the issues listed for i386 on
https://release.debian.org/testing/arch_qualify.html

I would not be surprised if we consider dropping leaf software where
builds start to hit the address space limit (I expect browsers & such).

Plus the broken FPU implementation as we don't require SSE.

And it *is* our choice to make to not spend time on dead architectures.

Ansgar

  [1]: It also works for other carbon emissions!

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Wookey]

On 2023-05-31 07:29 -0500, John Goerzen wrote:

> > Hanging on to systems using power-hungry chips from 20 years ago instead of
> > intercepting a system such as this is not reducing the number of computers
> > that end up in the waste stream, it just keeps you stuck with a more
> > power-hungry system.

a) That's not necessarily a problem if the machine is running from a renewable 
supply.
The issue is emissions, not power consumption per se.

and b) as both John and I have pointed out there are low-power i386 systems 
still in use.

c) it's not our choice to make. If people insist on using more
electricity than they need to for their computing, that's on them. (we
enable enormous amounts of this already - old i386 systems probably
barely register at this point)

Debian should be supporting people using whatever suits them where
that effort is reasonably proportionate. We are not driven by the
'sell new stuff' goals of hardware manufactuers so we should IMHO be
erring on the side of keeping stuff going as long as there is
sufficient community support.

However, to get back to the topic at hand, old atoms being used by
radio nerds and cavers, effectively as convenient form-factor
'embedded' devices, do not actually care whether the time ABI changes
or not. They are not (SFAIK) running proprietary windows binaries or
games, so the debate about how long support is maintained, at least
for this type of usage, is independent of the 'should the i386 ABI
switch along with other 32-bit ABIs'.

Switching or not (so long as the fairly small subset of the distro we
use keeps working) would not affect our usage of the device, for example.

So if we could try and consider these questions separately, that would be 
helpful.

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Gunnar Wolf]

John Goerzen dijo [Wed, May 31, 2023 at 07:29:38AM -0500]:
> (...)
> I guess the question is: is this use case too niche for Debian to
> continue supporting?  I would suggest that as long as we have 32-bit
> ARM, are the challenges for 32-bit x86 really worse?

Do note, however, the ARM64 started appearing in consumer devices
maybe around 2015, ten years later than AMD64. And nowadays there are
still (although few) ARM32 systems being produced --- I know it's even
funny to refer to them giving the stock shortage that's been biting
them for already too long, but i.e. the lowest Raspberry Pi models
(Zero, 1A, 1B -- the ones that need armel) have "obsolescence
statements" committing to have them produced at least until January
2026¹.


¹ https://www.raspberrypi.com/products/raspberry-pi-zero-w/
  https://www.raspberrypi.com/products/raspberry-pi-1-model-a-plus/
  https://www.raspberrypi.com/products/raspberry-pi-1-model-b-plus/
  (end of page)

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Gunnar Wolf]

Alexandre Detiste dijo [Wed, May 31, 2023 at 01:00:42PM +0200]:
> Le mer. 31 mai 2023 à 12:44, Wouter Verhelst  a écrit :
> > 20+ year old machines are typically more power hungry, more expensive,
> > less performant, and less reliable than an up-to-date raspberry pi.
> 
> Embedded systems and medical one can be crazily expensive to maintain
> and even more to replace but some will run on i386 for a long time more
> (had to manage some still running on DOS recently ...),
> there's also much of amd64 HW running on i386 because of lazyness/cost
> for hybrid fleets; energy efficiency is there the least of concerns.

You point out a valid and important use case. However... how should I
name this for the sake of the argument... "Large embedded" systems
(i.e. systems that act as embedded because they are the
general-purpose computer that lives inside a very purpose-specific bit
of equipement) are very unlikely to be a compelling use case to keep
producing i386 install media.

Medical equipment is usually tied to a very old computer because it
sports an ancient installation and set of binaries. Those systems are
(thankfully!) most often not internet-connected, so as long as you can
deal with DOS or Win9x quirks, and the gaping security holes won't be
of great importance.

Oh, did your medical imaging system ship with Debian 3.1 Sarge? Sweet!
Beautiful! However, it's quite unlikely you will want to upgrade it to
current-day Debian. Not only you will have to get enough memory for
the very hungry 6.x Linux kernel (I once built a boot floppy disk to
use a given system as an X terminal, and it all fit in 2MB
RAM... Nowadays that would be plainly impossible), but quite likely,
the specialized drivers for the vey one-of-a-kind imaging device would
not work.

And if you manage to replace the old install for said i386 system with
a recent one, I'm sure you would be able to replace the i386 system
with an ARM-based or AMD64-based system as well -- After all, the old
computer is not only needlessly power-hungry, but much more likely to
break.

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Sven Hoexter]

On Wed, May 31, 2023 at 07:29:38AM -0500, John Goerzen wrote:

Hi,

> I guess the question is: is this use case too niche for Debian to
> continue supporting?  I would suggest that as long as we have 32-bit
> ARM, are the challenges for 32-bit x86 really worse?

If I assume for a moment that the Debian LTS guys (I'm not affiliated
and did not speak to anyone) continue to support at least bookworm
including i386, that would give you roughly another five years of
support for those i386 devices. So can we add that timeframe
as well to our consideration, and ask ourselfs if there is a need
for fresh Debian installations on i386 five years from now?
Assuming the device from 2008 that would correspond to a lifetime
of around 20 years by then.

As much as I love the idea of some small device still humming along
five years from now, it sounds more likely that either the device
will die, or you replace it anyway with some other spare device.
Yeah I know stories of forgotten systems somewhere in a corner of
a room, but maybe we can stick to more common cases.

If the i386 support without an installer is kept for another release,
maybe that extends the support for existing installations even further.
That would only add some burden for fresh installations to install
bookworm first, and upgrade later on. At that point I guess we could
start to talk about retro computing if it's still running on i386. :)

Sven

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Sven Hoexter]

On Wed, May 31, 2023 at 01:00:42PM +0200, Alexandre Detiste wrote:

Hi,

> Embedded systems and medical one can be crazily expensive to maintain
> and even more to replace but some will run on i386 for a long time more

The question is: Is that a target for a future Debian installation and/or
a target for a recent Debian release?
It sounds more like cases which require a certification of some kind, and are
more likely to stay on very old releases for a long a time anyway (which
sometimes is problematic in different ways). It's likely the owner of such
long running device must now think about the plans for Y2038 anyway.

Sven

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[John Goerzen]

On Tue, May 30 2023, Steve Langasek wrote:

> For businesses, the transition from 32-bit to 64-bit was several
> depreciation cycles ago.
>
> In my city, there is a non-profit that accepts donations of old computers,
> refurbishes them, installs Linux, and both sells them and provides them free
> to people in need.
>
> They receive x86-64 systems that they determine are *too old to be worth
> refurbishing* and they e-cycle them.
>
> Hanging on to systems using power-hungry chips from 20 years ago instead of
> intercepting a system such as this is not reducing the number of computers
> that end up in the waste stream, it just keeps you stuck with a more
> power-hungry system.

I still have several Asus EeePCs (Atom N270 which had a TDP of 2.5W)
from around 2008ish.  One of them is in active use as an amateur radio
digipeater, while the others see occasional use.  These don't support a
64-bit instruction set but are perfectly servicable for certain use
cases.

I understand that a 9" screen and an Atom isn't going to be suitable for
the segment of the population that wants to use it for modern web
browsing and video calling, so I understand why your nonprofit is doing
that.

I wouldn't buy a used EeePC today.  Still, I see no reason to contribute
to the waste and carbon stream by replacing these perfectly usable
machines with something newer.  Capability-wise, they are roughly
similar to a Raspberry Pi, but they have the added benefit of a screen,
keyboard, and battery all integrated in a small device.

Not everything from that age was power-hungry.

I guess the question is: is this use case too niche for Debian to
continue supporting?  I would suggest that as long as we have 32-bit
ARM, are the challenges for 32-bit x86 really worse?

- John

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Alexandre Detiste]

Le mer. 31 mai 2023 à 12:44, Wouter Verhelst  a écrit :
> 20+ year old machines are typically more power hungry, more expensive,
> less performant, and less reliable than an up-to-date raspberry pi.

Embedded systems and medical one can be crazily expensive to maintain
and even more to replace but some will run on i386 for a long time more
(had to manage some still running on DOS recently ...),
there's also much of amd64 HW running on i386 because of lazyness/cost
for hybrid fleets; energy efficiency is there the least of concerns.

Some things _do_ start to fall apart: some nasty memory corruption bug in nginx
that only shows up on i386 code path ... :-(

Greetings

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Wouter Verhelst]

On Wed, May 31, 2023 at 12:51:06AM +0200, Diederik de Haas wrote:
> While it may be a no-brainer for a person with a $/€ 1000 a month residual 
> income to just buy new hardware whenever they feel like it, that is not the 
> case for everyone.
[...]
> It's absolutely true that modern machines are more energy efficient. What is 
> also true is that the production of new devices has a big environmental 
> impact. 

20+ year old machines are typically more power hungry, more expensive,
less performant, and less reliable than an up-to-date raspberry pi. If
you want to support people who can't afford shiny new hardware, I think
pointing them to raspberry pi-class hardware is a better idea than
trying to recycle old hardware. As such, I don't think "but old hardware
is still used" is a very good argument for keeping i386 around.

If they can afford 10 year old hardware, the situation is different; but
no 10 year old hardware that is worth recycling does not support x86-64.

I'm not saying we shouldn't support old hardware at all -- I fought for
a long time to keep m68k hardware a supported architecture in Debian --
but this is not the best argument for it, IMO.

Thanks,

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Re: Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[James Addison]

If there's a well-supported social or technical reason to remove the
i386 Debian installer, I think that it would still be disappointing,
but acceptable.

I don't know what those reasons are yet (I've imagined that they could
be maintainer burden -- but as mentioned, I don't think there's much
compiled-binary or i386-specific support required within d-i itself;
key packages etc yes, but the installer itself, I'm less sure), and I
still think that the strongest indicator of usage would probably be
download statistics for i386 ISO images (in other words: are many
people still requesting them?).

Looking ahead, I think it would be good to try to figure out ways to
avoid some of the frustrations caused by technological platform
shifts.  Yes, we probably learned some things collectively during each
of those transitions, but also, the 40-year-or-so old computer that I
have on a side table could be used for word processing, creating
shopping lists, and probably saving and searching fairly large lists
of food recipes (some of the tasks that I now use a much more powerful
laptop for).

The economic impact can either be phrased as an opportunity (hardware,
software sales) and/or as a burden (finding new equipment, discovering
incompatibilities, re-learning how to perform similar tasks using
different systems.  how much the vendor cares can also make a
difference with each of these).  Some amount of diversity in systems
allows for comparison and improvement (maybe one design team -- or
even one designer -- found a technique that applies to their system
that makes it much more efficient at some workloads; that discovery
can then be shared and adapted by others).

The argument that people can still install manually using debootstrap
or other methods is kinda fine - although in the same way that I like
to refactor code so that there are fewer 'if' conditions and
workarounds for particular situations (and to work towards removing
those if conditions by fixing adjacent/surrounding components and then
gradually updating when possible), we should be aware that there are
communication (users, documentation) and comprehension (keeping
per-architecture limitations in mind) overheads when creating
additional tiers/partitions of support and functionality.

So in summary: probably fine, some i386 ISO download stats would be
nice, and is there a particular key package or packages that are
causing problems here?

On Wed, 31 May 2023 at 05:55, Johannes Schauer Marin Rodrigues
 wrote:
>
> Hi,
>
> Quoting Diederik de Haas (2023-05-31 00:51:06)
> > > If people have strong opinions about that plan, let us know please.
> >
> > I have *strong* opinions about this.
> >
> > https://lists.debian.org/debian-kernel/2023/01/msg00372.html was a message/
> > plea to not forget about supporting OLD systems.
> >
> > While it may be a no-brainer for a person with a $/€ 1000 a month residual
> > income to just buy new hardware whenever they feel like it, that is not the
> > case for everyone.
>
> I think that depends on where you live. As Steve has said, if you live in a
> place with tons of rich people around, so many "old" computers are discarded 
> by
> them that it's not a problem for anybody to get hold of one of those for near
> to nothing. People with too much money just go through way too many computers
> per year, thereby creating a vast amount of old but still usable computers. At
> my university I recently saw a whole container filled with "old" desktop
> machines to be discarded (systems from 10 years ago, so definitely 64bit
> machines). This is just disturbing in my opinion but hey, those old systems
> don't run the most recent MS Windows anymore...
>
> This situation is probably very different around the world and I guess there
> are many places where it is very hard to get hold of a machine younger than a
> decade? Are you talking about those places?
>
> > Besides people in 'third world countries' (I actually don't like such
> > qualifications at all), there are also people in the '1st world' who work
> > their asses off just to put food on the table, and thus also don't have the
> > money to buy new equipment. But if you want to interact with your own
> > government, you highly likely will need to have some PC (type) equipment.  
> > It
> > could also provide a way to learn/develop new skills.
>
> In my own "1st world" country I know a number of people in that situation and
> at least over here, a "computer" doesn't help them to do the daily life 
> things.
> They need a smartphone to stay connected with their employer via Whatsapp or
> download the apps to participate in the things everybody else participates in.
> In Germany they just rolled out a monthly ticket for trains and buses for the
> whole country which will be smartphone-only starting next year -- will a 
> person
> with less income invest in a new/old desktop machine or in a smartphone new
> enough to run such an app? Yes, this is another discussion but I also do not
> 

Re: Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Diederik de Haas (2023-05-31 00:51:06)
> > If people have strong opinions about that plan, let us know please.
> 
> I have *strong* opinions about this.
> 
> https://lists.debian.org/debian-kernel/2023/01/msg00372.html was a message/
> plea to not forget about supporting OLD systems.
> 
> While it may be a no-brainer for a person with a $/€ 1000 a month residual 
> income to just buy new hardware whenever they feel like it, that is not the 
> case for everyone.

I think that depends on where you live. As Steve has said, if you live in a
place with tons of rich people around, so many "old" computers are discarded by
them that it's not a problem for anybody to get hold of one of those for near
to nothing. People with too much money just go through way too many computers
per year, thereby creating a vast amount of old but still usable computers. At
my university I recently saw a whole container filled with "old" desktop
machines to be discarded (systems from 10 years ago, so definitely 64bit
machines). This is just disturbing in my opinion but hey, those old systems
don't run the most recent MS Windows anymore...

This situation is probably very different around the world and I guess there
are many places where it is very hard to get hold of a machine younger than a
decade? Are you talking about those places?

> Besides people in 'third world countries' (I actually don't like such
> qualifications at all), there are also people in the '1st world' who work
> their asses off just to put food on the table, and thus also don't have the
> money to buy new equipment. But if you want to interact with your own
> government, you highly likely will need to have some PC (type) equipment.  It
> could also provide a way to learn/develop new skills.

In my own "1st world" country I know a number of people in that situation and
at least over here, a "computer" doesn't help them to do the daily life things.
They need a smartphone to stay connected with their employer via Whatsapp or
download the apps to participate in the things everybody else participates in.
In Germany they just rolled out a monthly ticket for trains and buses for the
whole country which will be smartphone-only starting next year -- will a person
with less income invest in a new/old desktop machine or in a smartphone new
enough to run such an app? Yes, this is another discussion but I also do not
think your argument applies well to "1st world" countries because of this
reason and the reasons I gave above.

> It's absolutely true that modern machines are more energy efficient. What is
> also true is that the production of new devices has a big environmental
> impact.
> 
> https://mastodon.green/@gerrymcgovern/110329331475328263 said:
> > The European Environmental Bureau has stated that extending the lifespan of
> > smartphones and other electronics by just one year would save the EU as
> > much carbon emissions as taking two million cars off the roads annually.
> 
> I would be VERY disappointed if Debian would abandon people who do NOT have
> the means to just buy new equipment whenever they feel like it.

That argument goes both ways. You could also say that for people with less
income, the electricity costs make using a more modern system cheaper for them.

This of course does not negate the environmental argument but the environmental
argument is a tricky one. A 20 year old machine bought 20 years ago will have
racked up a lot of electricity usage which pales against the energy required to
build and run small single-board machines that are similarly powerful built
today. There is a cut-off point where using an energy-hungry old system *does*
have a higher environmental impact than building a small new system.

> Especially when I see various proposals to make the 'life'/work of companies
> who make BILLIONS a YEAR, easier.  (I'll leave my moral objections to several
> of those aside this time)
> 
> Cheers,
>   Diederik
> 
> PS: Nothing in here should be taken as a personal attack, but as I said I 
> feel 
> rather strongly about this subject. (And communication isn't my strong suit)

There are probably many places in the world where your argument applies well.
Remember though, that this is also a person-power problem. If we can find many
more people interested to keep 20 year old systems alive by working on that in
their free-time, I do not think we would have this discussion. A lot of work is
required to keep an architecture and its installer alive. I suspect kibi would
*love* more hands helping maintain d-i. There will always be someone with real
reasons for using 20 year old systems and wanting to do a fresh installation on
one. The question is, is this worth our free-time or should we do other things
instead? Who is having fun doing that?  We can argue a lot about the social and
environmental reasons for supporting 20 year old systems but the sad fact of
the matter is: if there is nobody there doing the work then that discussion is

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Steve Langasek]

On Wed, May 31, 2023 at 12:51:06AM +0200, Diederik de Haas wrote:
> > >+1 for stopping publishing installers for i386, it has been mentioned
> > >many times but it's always worth repeating: electricity costs to keep
> > >running i386 hardware are already way higher than what it costs to buy
> > >a cheap, low-power replacement like a raspberry pi, that also provides
> > >better performance.

> > Exactly.
> > ...
> > If people have strong opinions about that plan, let us know please.

> I have *strong* opinions about this.

> https://lists.debian.org/debian-kernel/2023/01/msg00372.html was a message/
> plea to not forget about supporting OLD systems.

> While it may be a no-brainer for a person with a $/€ 1000 a month residual 
> income to just buy new hardware whenever they feel like it, that is not the 
> case for everyone.

> To quote (a part) of that email:
> > I happen to know of a few derivative projects that have been using
> > Debian technology that have brought new life to some really aging equipment
> > and some people in either Third World countries or in communities with low
> > incomes and either limited or non-existent access to modern equipment. One
> > such effort, the antiX distribution, has been effective in reaching poor
> > communities in Brazil recently, and has long been able to reach people with
> > scaled down Debian technology all over the world.
> >
> > I'm wondering if there is some way to provide a "hook" or a way for some of
> > these ten to twenty year old systems to remain functional for those who may
> > not otherwise have a way, other than to run insecure, out of date systems. 
> > If there is a way, even a "side project", I hope that the Debian community
> > can help a few of these derivative distributions assist people worldwide to
> > have access to modern technology,
> > even from systems that are barely "modern" any more.

> Besides people in 'third world countries' (I actually don't like such
> qualifications at all), there are also people in the '1st world' who work
> their asses off just to put food on the table, and thus also don't have
> the money to buy new equipment.  But if you want to interact with your own
> government, you highly likely will need to have some PC (type) equipment. 
> It could also provide a way to learn/develop new skills.

> It's absolutely true that modern machines are more energy efficient. What is 
> also true is that the production of new devices has a big environmental 
> impact. 

> https://mastodon.green/@gerrymcgovern/110329331475328263 said:
> > The European Environmental Bureau has stated that extending the lifespan of
> > smartphones and other electronics by just one year would save the EU as
> > much carbon emissions as taking two million cars off the roads annually.

> I would be VERY disappointed if Debian would abandon people who do NOT have 
> the means to just buy new equipment whenever they feel like it.

> Especially when I see various proposals to make the 'life'/work of companies 
> who make BILLIONS a YEAR, easier.
> (I'll leave my moral objections to several of those aside this time)

For businesses, the transition from 32-bit to 64-bit was several
depreciation cycles ago.

In my city, there is a non-profit that accepts donations of old computers,
refurbishes them, installs Linux, and both sells them and provides them free
to people in need.

They receive x86-64 systems that they determine are *too old to be worth
refurbishing* and they e-cycle them.

Hanging on to systems using power-hungry chips from 20 years ago instead of
intercepting a system such as this is not reducing the number of computers
that end up in the waste stream, it just keeps you stuck with a more
power-hungry system.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Diederik de Haas]

[Please CC me in replies as I'm not subscribed to this list]

I hope I'm not too late for this discussion ...

Steve McIntyre  wrote:
> Luca Boccassi wrote:
> >On Fri, 19 May 2023 at 12:42, Steve McIntyre  wrote:
> >> I'm planning on stopping publishing installer images for i386
> >> soon. Why? We should be strongly encouraging users to move away from
> >> If they're still running i386 *hardware*, then they should be replacing
> >> that hardware with more modern, more capable, more *efficient* stuff.
> >> 
> >+1 for stopping publishing installers for i386, it has been mentioned
> >many times but it's always worth repeating: electricity costs to keep
> >running i386 hardware are already way higher than what it costs to buy
> >a cheap, low-power replacement like a raspberry pi, that also provides
> >better performance.
> 
> Exactly.
> ...
> If people have strong opinions about that plan, let us know please.

I have *strong* opinions about this.

https://lists.debian.org/debian-kernel/2023/01/msg00372.html was a message/
plea to not forget about supporting OLD systems.

While it may be a no-brainer for a person with a $/€ 1000 a month residual 
income to just buy new hardware whenever they feel like it, that is not the 
case for everyone.

To quote (a part) of that email:
> I happen to know of a few derivative projects that have been using
> Debian technology that have brought new life to some really aging equipment
> and some people in either Third World countries or in communities with low
> incomes and either limited or non-existent access to modern equipment. One
> such effort, the antiX distribution, has been effective in reaching poor
> communities in Brazil recently, and has long been able to reach people with
> scaled down Debian technology all over the world.
>
> I'm wondering if there is some way to provide a "hook" or a way for some of
> these ten to twenty year old systems to remain functional for those who may
> not otherwise have a way, other than to run insecure, out of date systems. 
> If there is a way, even a "side project", I hope that the Debian community
> can help a few of these derivative distributions assist people worldwide to
> have access to modern technology,
> even from systems that are barely "modern" any more.

Besides people in 'third world countries' (I actually don't like such 
qualifications at all), there are also people in the '1st world' who work their 
asses off just to put food on the table, and thus also don't have the money to 
buy new equipment. But if you want to interact with your own government, you 
highly likely will need to have some PC (type) equipment.
It could also provide a way to learn/develop new skills.

It's absolutely true that modern machines are more energy efficient. What is 
also true is that the production of new devices has a big environmental 
impact. 

https://mastodon.green/@gerrymcgovern/110329331475328263 said:
> The European Environmental Bureau has stated that extending the lifespan of
> smartphones and other electronics by just one year would save the EU as
> much carbon emissions as taking two million cars off the roads annually.


I would be VERY disappointed if Debian would abandon people who do NOT have 
the means to just buy new equipment whenever they feel like it.

Especially when I see various proposals to make the 'life'/work of companies 
who make BILLIONS a YEAR, easier.
(I'll leave my moral objections to several of those aside this time)

Cheers,
  Diederik

PS: Nothing in here should be taken as a personal attack, but as I said I feel 
rather strongly about this subject. (And communication isn't my strong suit)

signature.asc
Description: This is a digitally signed message part.

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[James Addison]

On Fri, 26 May 2023 at 00:27, Roger Lynn  wrote:
>
> On 21/05/2023 07:00, James Addison wrote:
> > On Fri, 19 May 2023 at 22:58, Ansgar  wrote:
> >> One of the problems with popcon is that it draws too much attention to
> >> old releases which isn't really interesting when talking about future
> >> developments.  If one looks at arch usage per release (as reported to
> >> popcon) one gets this table:
> >>
> >> | Architecture   | jessie | stretch | buster | bullseye | bookworm/sid |
> >> |++-++--+--|
> >> | alpha  |  1 | ||  |4 |
> >> | amd64  |   9090 |   17156 |  41137 |   108145 |14800 |
> >> | arm64  ||   1 | 93 |  937 |  203 |
> >> | armel  | 21 |  47 | 67 |   68 |   10 |
> >> | armhf  |  7 |  18 |216 |  429 |   49 |
> >> | hppa   || ||  |8 |
> >> | hurd-i386  || ||4 |6 |
> >> | i386   |   1318 |1231 |   1495 | 3042 |  168 |
> >> | ia64   || ||  |3 |
> >> | kfreebsd-amd64 |  2 | ||  |  |
> >> | m68k   ||   1 ||  |4 |
> >> | mips   |  2 | |  6 |  |  |
> >> | mips64el   || |  6 |4 |  |
> >> | mipsel |  2 |   1 |  7 |  |  |
> >> | powerpc| 13 |   1 |  1 |1 |   18 |
> >> | ppc64  || ||1 |   28 |
> >> | ppc64el||   5 | 16 |  |   12 |
> >> | riscv64|| ||  |   15 |
> >> | s390x  || ||8 |3 |
> >> | sh4|| ||  |1 |
> >> | sparc64|| ||  |   11 |
> >> | x32|| ||  |2 |
> >> |++-++--+--|
> >> | ∑  |  10456 |   18461 |  43044 |   112639 |15345 |
> >> #+TBLFM: @>$2..@>$>=vsum(@I..II)
> >>
> >> where i386 has dropped from 13% to 7% to 3% to 3% and finally to 1%.
> >> Also interesting is that arm64 has taken over i386 on bookwork/sid.
> >>
> >> We don't know how many people downloaded i386 instead of amd64 as they
> >> have an Intel CPU.
> >>
> >> What is also not clear is the bias of systems having popcon enabled at
> >> all (it seems to be mostly desktop systems) and how it looks on the
> >> total population.
> >
> > Thanks, those are better statistics (and good notes about their 
> > limitations).
> >
> > I may be playing devil's advocate, but I do also read from those that
> > the i386 install-base, even dwindled as it has to ~1%, remains more
> > popular than many other architectures (within whatever dimension of
> > users enable popcon) where we do provide install images, and then that
> > those users tend to upgrade to the latest i386 release of Debian that
> > they can -- and/or that despite the percentage-of-total trend
> > reducing, the absolute population of those i386 users is growing (I
> > guess the former is the larger contributing factor, but it's hard to
> > determine from the numbers only).
>
> The popcon graphs clearly show that the absolute number (not proportion) of
> i386 reports flattened off in 2008 at about 65000, when AMD64 became
> popular. The number of i386 reports has been falling since 2014, and is now
> about 1, most of which are from old releases (oldstable or older). It
> seems likely that the number of i386 reports from stable will be overtaken
> by ARM64 during the period of Bookworm.

Thanks Roger.  I concede that the absolute number of i386 popcon
reports has been falling; this graph makes that clear[1]:
https://web.archive.org/web/20221223090933/https://popcon.debian.org/stat/sub-i386.png

Also, yep, it does seem possible that i386's position in terms of
total popcon reports could fall into third place behind AMD64 and
ARM64 over the next two years or so.

Is an architecture's ranking position within popcon reports a
significant factor in whether it should be installer-supported?  Or is
it perhaps only a secondary indicator and there are other
considerations that are more important?  (for example, whether we have
volunteers keen to support it..)


An aside: the trend for ARM64 reports appears to include a few steep
increments followed by pauses.  I'm left wondering whether those
correspond to additional hardware support, arrival of popular packages
in the ARM64 archive, or other factors[2]:

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Roger Lynn]

On 21/05/2023 07:00, James Addison wrote:
> On Fri, 19 May 2023 at 22:58, Ansgar  wrote:
>> One of the problems with popcon is that it draws too much attention to
>> old releases which isn't really interesting when talking about future
>> developments.  If one looks at arch usage per release (as reported to
>> popcon) one gets this table:
>>
>> | Architecture   | jessie | stretch | buster | bullseye | bookworm/sid |
>> |++-++--+--|
>> | alpha  |  1 | ||  |4 |
>> | amd64  |   9090 |   17156 |  41137 |   108145 |14800 |
>> | arm64  ||   1 | 93 |  937 |  203 |
>> | armel  | 21 |  47 | 67 |   68 |   10 |
>> | armhf  |  7 |  18 |216 |  429 |   49 |
>> | hppa   || ||  |8 |
>> | hurd-i386  || ||4 |6 |
>> | i386   |   1318 |1231 |   1495 | 3042 |  168 |
>> | ia64   || ||  |3 |
>> | kfreebsd-amd64 |  2 | ||  |  |
>> | m68k   ||   1 ||  |4 |
>> | mips   |  2 | |  6 |  |  |
>> | mips64el   || |  6 |4 |  |
>> | mipsel |  2 |   1 |  7 |  |  |
>> | powerpc| 13 |   1 |  1 |1 |   18 |
>> | ppc64  || ||1 |   28 |
>> | ppc64el||   5 | 16 |  |   12 |
>> | riscv64|| ||  |   15 |
>> | s390x  || ||8 |3 |
>> | sh4|| ||  |1 |
>> | sparc64|| ||  |   11 |
>> | x32|| ||  |2 |
>> |++-++--+--|
>> | ∑  |  10456 |   18461 |  43044 |   112639 |15345 |
>> #+TBLFM: @>$2..@>$>=vsum(@I..II)
>>
>> where i386 has dropped from 13% to 7% to 3% to 3% and finally to 1%.
>> Also interesting is that arm64 has taken over i386 on bookwork/sid.
>>
>> We don't know how many people downloaded i386 instead of amd64 as they
>> have an Intel CPU.
>>
>> What is also not clear is the bias of systems having popcon enabled at
>> all (it seems to be mostly desktop systems) and how it looks on the
>> total population.
> 
> Thanks, those are better statistics (and good notes about their limitations).
> 
> I may be playing devil's advocate, but I do also read from those that
> the i386 install-base, even dwindled as it has to ~1%, remains more
> popular than many other architectures (within whatever dimension of
> users enable popcon) where we do provide install images, and then that
> those users tend to upgrade to the latest i386 release of Debian that
> they can -- and/or that despite the percentage-of-total trend
> reducing, the absolute population of those i386 users is growing (I
> guess the former is the larger contributing factor, but it's hard to
> determine from the numbers only).

The popcon graphs clearly show that the absolute number (not proportion) of
i386 reports flattened off in 2008 at about 65000, when AMD64 became
popular. The number of i386 reports has been falling since 2014, and is now
about 1, most of which are from old releases (oldstable or older). It
seems likely that the number of i386 reports from stable will be overtaken
by ARM64 during the period of Bookworm.

Roger

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Jonathan Carter]

Hi Simon

On 2023/05/19 17:30, Simon McVittie wrote:

1. same as in recent Ubuntu: just enough packages (mostly libraries) to
configure it as a multiarch foreign architecture on an amd64 system,
and run legacy Linux i386 binaries directly or legacy Windows i386
binaries via Wine

2. same as (1), plus basic utilities (coreutils, etc.) and optionally an
init system, to be able to make a pure i386 container or chroot
that can run on an externally-provided amd64 kernel

3. same as (2), plus kernel, bootloader and init system to be able to:
(a) construct a complete bootable installation using debootstrap or
similar;
(b) upgrade existing i386 installations


All of the above sounds reasonable, all those options acknowledge that 
we need some method to support a subset of packages for an architecture. 
It would be nice to see this extend to more than just 32bit x86. A while 
back someone from release team mentioned to me that they toyed with the 
idea of adding a new 32bit x86 architecture for Debian that's called 
i686 instead (and enable things that might not actually work on actual 
32bit binary), so it would really just be for 
compatibility/containers/etc, and then dropping the entire i386 
architecture completely. Not sure how viable that is in practice, but it 
sounds like a good idea.



4. user-facing media like debian-installer and Debian Live


I think we already have broad enough consensus that we don't need this. 
If there's enough Debian binaries to make that happen, and a user who 
has a niche enough use case for that, then they should have no problem 
just performing a local debootstrap install themselves.


-Jonathan

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[James Addison]

On Fri, 19 May 2023 at 22:58, Ansgar  wrote:
>
> On Fri, 2023-05-19 at 19:40 +0100, James Addison wrote:
> > Do we know how often the i386 installer is downloaded compared to
> > amd64, and could/should we start with updated messaging where those
> > are provided before removing users' ability to install on their
> > systems?
> >
> > (i386 remains the second-most-popular architecture behind amd64 today
> > going by popcon[1] stats - perhaps a lot of that is people using i386
> > as a compatibility architecture only, but it'd be nice to be
> > reasonably confident about that)
>
> One of the problems with popcon is that it draws too much attention to
> old releases which isn't really interesting when talking about future
> developments.  If one looks at arch usage per release (as reported to
> popcon) one gets this table:
>
> | Architecture   | jessie | stretch | buster | bullseye | bookworm/sid |
> |++-++--+--|
> | alpha  |  1 | ||  |4 |
> | amd64  |   9090 |   17156 |  41137 |   108145 |14800 |
> | arm64  ||   1 | 93 |  937 |  203 |
> | armel  | 21 |  47 | 67 |   68 |   10 |
> | armhf  |  7 |  18 |216 |  429 |   49 |
> | hppa   || ||  |8 |
> | hurd-i386  || ||4 |6 |
> | i386   |   1318 |1231 |   1495 | 3042 |  168 |
> | ia64   || ||  |3 |
> | kfreebsd-amd64 |  2 | ||  |  |
> | m68k   ||   1 ||  |4 |
> | mips   |  2 | |  6 |  |  |
> | mips64el   || |  6 |4 |  |
> | mipsel |  2 |   1 |  7 |  |  |
> | powerpc| 13 |   1 |  1 |1 |   18 |
> | ppc64  || ||1 |   28 |
> | ppc64el||   5 | 16 |  |   12 |
> | riscv64|| ||  |   15 |
> | s390x  || ||8 |3 |
> | sh4|| ||  |1 |
> | sparc64|| ||  |   11 |
> | x32|| ||  |2 |
> |++-++--+--|
> | ∑  |  10456 |   18461 |  43044 |   112639 |15345 |
> #+TBLFM: @>$2..@>$>=vsum(@I..II)
>
> where i386 has dropped from 13% to 7% to 3% to 3% and finally to 1%.
> Also interesting is that arm64 has taken over i386 on bookwork/sid.
>
> We don't know how many people downloaded i386 instead of amd64 as they
> have an Intel CPU.
>
> What is also not clear is the bias of systems having popcon enabled at
> all (it seems to be mostly desktop systems) and how it looks on the
> total population.

Thanks, those are better statistics (and good notes about their limitations).

I may be playing devil's advocate, but I do also read from those that
the i386 install-base, even dwindled as it has to ~1%, remains more
popular than many other architectures (within whatever dimension of
users enable popcon) where we do provide install images, and then that
those users tend to upgrade to the latest i386 release of Debian that
they can -- and/or that despite the percentage-of-total trend
reducing, the absolute population of those i386 users is growing (I
guess the former is the larger contributing factor, but it's hard to
determine from the numbers only).

Meanwhile my understanding is that most of the i386 installer package
-- although I referred to it as a binary package in another thread,
using the source/binary package naming terminology -- is mostly shell
scripting and architecture-independent logic.

So I guess I will ask: is there a technical reason we want to drop d-i
images on i386, or is it primarily about trying to reduce our
anticipated support burden for one architecture?

(and if people clamoured for an i386 installer to download, would we
reverse the decision?)

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[James Addison]

On Sat, 20 May 2023 at 09:39, Cyril Brulebois  wrote:>
> James Addison  (2023-05-20):
> > Replying individually, but may bring this back on-list depending on
> > what I learn:
> >
> > On Sat, 20 May 2023 at 06:00, Cyril Brulebois  wrote:
> > >
> > > If you're concerned about the impact of no longer producing installation
> > > images for this use case, you shouldn't. Building netinst, CD, DVD, BD,
> > > etc. images happens via debian-cd
>
> Stopping that is the plan.
>
> > > using artifacts produced by a src:debian-installer build, which are stored
> > > under installer-/ directories in the archive. Those wouldn't go away
> > > in this scenario.
> > >   http://ftp.debian.org/debian/dists/bookworm/main/installer-i386/
> >
> > I'm confused: I thought Steve's suggestion was exactly that these i386
> > installer builds would no longer occur after the bookworm release.
> >
> > Did I misunderstand the plan?
>
> I suppose so?

Ok, thanks.  I was uncertain what you were referring to with "Those
wouldn't go away" - and that potentially raised conflicts with my
reading of Steve's suggestion.

Updated understanding:

  * planned to go away: Debian-distributed images as built using
debian-cd for i386 (where the images include: debian-installer + a
subset of packages from a Debian mirror + supporting stuff to provide
a complete installation environment).
  * _not_ planned to go away: standalone binary package builds of the
i386 debian-installer package itself in the archives.

And so the result should be: it'd still be possible for people to
build-their-own i386 ISO images by using the debian-cd tooling; there
won't be officially-distributed images provided by Debian, though.

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Cyril Brulebois]

(2-in-1 reply.)

Ansgar  (2023-05-19):
> On Fri, 2023-05-19 at 20:57 +0200, Bjørn Mork wrote:
> > Hmm.  I find the netboot installer archives very useful for rescue
> > purposes.  This sometimes involves PC hardware too old for amd64. I
> > PXE booted a 20+ year old laptop with no DVD/CD drive (Compaq Evo
> > N410c - CD drive was part of the optional docking station) using a
> > bullseye netboot.tar not long ago.

If you're concerned about the impact of no longer producing installation
images for this use case, you shouldn't. Building netinst, CD, DVD, BD,
etc. images happens via debian-cd, using artifacts produced by a
src:debian-installer build, which are stored under installer-/
directories in the archive. Those wouldn't go away in this scenario.
  http://ftp.debian.org/debian/dists/bookworm/main/installer-i386/

If you're thinking about debian-installer--netboot-i386 binaries,
that would be the exact same story, since those are built by packing the
contents of those directories.

> You can keep using the bullseye netboot.tar for the next 20+ years to
> rescue boot an ancient system, copy the data off of it, and then
> responsibly dispose the system.

If the system to be rescued is older than the netboot being considered,
that should be possible. If it's newer, that might not be possible. See
what happened when we moved from LUKS to LUKS2: an older d-i couldn't
rescue a newer system because it just didn't know about the new format.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Ansgar]

On Fri, 2023-05-19 at 19:40 +0100, James Addison wrote:
> Do we know how often the i386 installer is downloaded compared to
> amd64, and could/should we start with updated messaging where those
> are provided before removing users' ability to install on their
> systems?
> 
> (i386 remains the second-most-popular architecture behind amd64 today
> going by popcon[1] stats - perhaps a lot of that is people using i386
> as a compatibility architecture only, but it'd be nice to be
> reasonably confident about that)

One of the problems with popcon is that it draws too much attention to
old releases which isn't really interesting when talking about future
developments.  If one looks at arch usage per release (as reported to
popcon) one gets this table:

| Architecture   | jessie | stretch | buster | bullseye | bookworm/sid |
|++-++--+--|
| alpha  |  1 | ||  |4 |
| amd64  |   9090 |   17156 |  41137 |   108145 |14800 |
| arm64  ||   1 | 93 |  937 |  203 |
| armel  | 21 |  47 | 67 |   68 |   10 |
| armhf  |  7 |  18 |216 |  429 |   49 |
| hppa   || ||  |8 |
| hurd-i386  || ||4 |6 |
| i386   |   1318 |1231 |   1495 | 3042 |  168 |
| ia64   || ||  |3 |
| kfreebsd-amd64 |  2 | ||  |  |
| m68k   ||   1 ||  |4 |
| mips   |  2 | |  6 |  |  |
| mips64el   || |  6 |4 |  |
| mipsel |  2 |   1 |  7 |  |  |
| powerpc| 13 |   1 |  1 |1 |   18 |
| ppc64  || ||1 |   28 |
| ppc64el||   5 | 16 |  |   12 |
| riscv64|| ||  |   15 |
| s390x  || ||8 |3 |
| sh4|| ||  |1 |
| sparc64|| ||  |   11 |
| x32|| ||  |2 |
|++-++--+--|
| ∑  |  10456 |   18461 |  43044 |   112639 |15345 |
#+TBLFM: @>$2..@>$>=vsum(@I..II)

where i386 has dropped from 13% to 7% to 3% to 3% and finally to 1%.
Also interesting is that arm64 has taken over i386 on bookwork/sid.

We don't know how many people downloaded i386 instead of amd64 as they
have an Intel CPU.

What is also not clear is the bias of systems having popcon enabled at
all (it seems to be mostly desktop systems) and how it looks on the
total population.

Ansgar

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Bjørn Mork]

Ansgar  writes:

> On Fri, 2023-05-19 at 20:57 +0200, Bjørn Mork wrote:
>> Hmm.  I find the netboot installer archives very useful for rescue
>> purposes.  This sometimes involves PC hardware too old for amd64. I PXE
>> booted a 20+ year old laptop with no DVD/CD drive (Compaq Evo N410c - CD
>> drive was part of the optional docking station) using a bullseye
>> netboot.tar not long ago.
>
> You can keep using the bullseye netboot.tar for the next 20+ years to
> rescue boot an ancient system, copy the data off of it, and then
> responsibly dispose the system.

That won't work, will it?  netboot must match the kernel version in the
archive to be useful.  Or am I missing something?


> I don't think this is a good argument to keep generating i386 install
> media.

Maybe not.  Just wanted to mention the use case so it can be
considered. I understand that it might not justify the resources
required.



Bjørn

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Ansgar]

On Fri, 2023-05-19 at 20:57 +0200, Bjørn Mork wrote:
> Hmm.  I find the netboot installer archives very useful for rescue
> purposes.  This sometimes involves PC hardware too old for amd64. I PXE
> booted a 20+ year old laptop with no DVD/CD drive (Compaq Evo N410c - CD
> drive was part of the optional docking station) using a bullseye
> netboot.tar not long ago.

You can keep using the bullseye netboot.tar for the next 20+ years to
rescue boot an ancient system, copy the data off of it, and then
responsibly dispose the system.

I don't think this is a good argument to keep generating i386 install
media.

> Not a major thing, but if you're going to keep most of i386 anyway...

I would hope we could eventually drop some expensive, useless packages
from i386 like src:linux.

Ansgar

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Bjørn Mork]

Steve McIntyre  writes:

> I had been thinking about doing similar for installer images too, but
> with other work going on too I think it got too late in the cycle to
> make that change. My plan is therefore to ship i386 installer images
> for bookworm as normal (including bookworm point releases going
> forwards), but to disable those builds for testing/trixie ~immediately
> after the release.

Hmm.  I find the netboot installer archives very useful for rescue
purposes.  This sometimes involves PC hardware too old for amd64. I PXE
booted a 20+ year old laptop with no DVD/CD drive (Compaq Evo N410c - CD
drive was part of the optional docking station) using a bullseye
netboot.tar not long ago.

Not a major thing, but if you're going to keep most of i386 anyway...


Bjørn

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[James Addison]

On Fri, 19 May 2023 at 12:42, Steve McIntyre  wrote:
>
> I'm planning on stopping publishing installer images for i386
> soon. Why? We should be strongly encouraging users to move away from
> it as a main architecture. If they're still installing i386 on 64-bit
> hardware, then that's a horrible mistake. If they're still running
> i386 *hardware*, then they should be replacing that hardware with more
> modern, more capable, more *efficient* stuff.

Do we know how often the i386 installer is downloaded compared to
amd64, and could/should we start with updated messaging where those
are provided before removing users' ability to install on their
systems?

(i386 remains the second-most-popular architecture behind amd64 today
going by popcon[1] stats - perhaps a lot of that is people using i386
as a compatibility architecture only, but it'd be nice to be
reasonably confident about that)

[1] - https://popcon.debian.org/

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Michael Biebl]

Am 19.05.23 um 19:23 schrieb Cyril Brulebois:

Hi,

Andrew M.A. Cater  (2023-05-19):

I'd honestly suggest *just* publishing DVD1 for i386.

Netinst requires internet access: DVD1 can be used to install a basic
system without this. Scrap *everything else* for i386 installation media.


I'm not sure how dropping one netinst ISO is going to change anything in
debian-cd: that's a very fast build, that's a small, single ISO, and not
having to download several GBs seems quite appealing to me. Having DVD1
only would really not seem acceptable to me.

I'm also very much *not* in favour of dropping images just *days* before
the release, without any kind of heads-up.



+1

That said, I also support the idea of dropping (at least) the installer 
media for i386 in trixie, so I like Ansgar's proposal of using the 
bookworm release notes to prepare our users for that.




OpenPGP_signature
Description: OpenPGP digital signature

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Guillem Jover]

Hi!

On Fri, 2023-05-19 at 12:42:32 +0100, Steve McIntyre wrote:
> Guillem Jover wrote:
> >On Thu, 2023-05-18 at 12:01:40 -0700, Steve Langasek wrote:
> >> > […], I'm also dubious about this, and introduces a special case
> >> > and complexity that does not seem warranted TBH. If this was the case it
> >> > would seem to me it would disallow SOVERSION bumps for example, which we
> >> > have never been concerned with.

Err, sorry the SOVERSION example does not make sense here, precisely
because in those cases the dependency system works for the user and
(in general) should let the old versions of those shared libraries
even if now obsolete packages be co-installed along the new versions.

> >The problem with obsolete packages is also shared by all other arches,
> >and for those and for local packages the dependency system works for
> >the user and should let them know whether they can upgrade or they
> >would need to remove such packages. For other local FOSS packages
> >they might just be able to rebuild them.
> >
> >Excluding i386 from this transition seems to me will pretty much
> >sentence it, and would also make it rather hard to perform that
> >transition cleanly going forward if people want to keep it alive. And
> >while Debian might eventually remove it from its official ports, we
> >have multiple old ports that are still maintained and used.
> >
> >If the main reason is to support non-free binaries, at least to me
> >that does not seem like a very compelling reason. And people can
> >always use old chroots or similar I guess?
> 
> i386 is in a really awkward situation here, I think. Nobody is working
> on it explicitly any more (AFAICS?),

I assume because it seems to "work" and people might have not seen the
need to jump in, compared to say if it was in ports.d.o, but I might be
wrong.

> but its history as by far the
> most common architecture means that:
> 
>  * we still have a (very!) long tail of installations using it
>  * there are *massively* more old binaries available for it, free,
>proprietary *and* locally-built
> 
> Moving forwards, we need to make a call on what we want i386 for. I
> was hoping to wait until after bookworm is released to have the meat
> of that discussion, but...

> […]

> As and when we switch i386 to a secondary status like this (however we
> label it!), then I think we should *only* consider it as a
> compatibility layer for older software. People *could* just use old
> chroots or similar, but the need is likely to be around for a
> while.

> There's a tension here: I think it's important to keep the old ABI
> around for those old binaries, and I genuinely don't see a use case
> for a new incompatible ABI on a mostly-dead architecture that won't
> support those binaries. *But* I think we'll also need to keep the port
> going with security fixes - it's still likely to be quite common and
> we need to keep users safe.

> People are even likely to want to keep old software running beyond
> 2038, in which case I envisage clock hacks coming to keep things
> limping on. :-/

So I guess my concern is three fold:

  a) There's the part that I mentioned where excluding it means it is
 destined to die in exchange for that backwards binary compat,
 although it's not clear for how long this all will be supported
 by Debian (and where I consider I've registered my concern here,
 but if people in general think the backwards compat trumps other
 stuff I'm fine with that).
  b) I still keep at least one 32-bit Athlon system around mostly to
 be able to support 3Dfx hardware, which I'll have to stop
 supporting either when the machine, the port or time dies. OTOH
 I've been pondering stopping the support in the future anyway so
 it's not such a great concern for me.
  c) And then there's the port support long term in dpkg, where my
 expectation is that when and if Debian does not officially support
 it, people that might still want to use that port on vintage
 hardware will most probably request to flip the switch, and then
 me and/or the ports.d.o maintainers might need to decide between
 users that have expected such backwards compat and porters that
 might want to be able to continue using the port. :/

(I also keep that Athlon around as I need to recover data from a bunch
of 3.5" floppy disks! But that should stop being relevant once I sit down
through the drudge of changing the piles of disks every few minutes. :)

Thanks,
Guillem

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Steve McIntyre]

Steve Langasek wrote:
>
>On Fri, May 19, 2023 at 12:42:32PM +0100, Steve McIntyre wrote:
>> >If the main reason is to support non-free binaries, at least to me
>> >that does not seem like a very compelling reason. And people can
>> >always use old chroots or similar I guess?
>
>> i386 is in a really awkward situation here, I think. Nobody is working
>> on it explicitly any more (AFAICS?), but its history as by far the
>> most common architecture means that:
>
>>  * we still have a (very!) long tail of installations using it
>>  * there are *massively* more old binaries available for it, free,
>>proprietary *and* locally-built
>
>FTR this includes wine, and 30 years of 32-bit Windows executables that
>people want to be able to run, including games.  (for which inaccurate times
>are not going to be hugely important, in general.) And some of those games
>are going to require e.g. library packages for 3d acceleration that are in
>sync with kernel drivers (nvidia).  This was ultimately what made "just use
>an older version in a chroot/container" untenable for Ubuntu and led to
>keeping i386 as a partial port.

ACK!

>So one may not think that support for legacy, proprietary programs is a
>compelling reason to keep binary-compatibility on i386.  But I counter that
>unless you care about this, there's no reason to keep i386 as an
>architecture *at all*.

That's exactly my reasoning, yup!

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< sladen> I actually stayed in a hotel and arrived to find a post-it
  note stuck to the mini-bar saying "Paul: This fridge and
  fittings are the correct way around and do not need altering"

partial support for i386 (Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal))

[Michael Biebl]

Am 19.05.23 um 17:30 schrieb Simon McVittie:

On Fri, 19 May 2023 at 09:19:35 -0500, G. Branden Robinson wrote:

I have to ask how someone would conduct an install to a 32-bit x86 machine
running under emulation, assuming no OS on the simulated machine.


I see four levels of support that we could reasonably have for i386:

1. same as in recent Ubuntu: just enough packages (mostly libraries) to
configure it as a multiarch foreign architecture on an amd64 system,
and run legacy Linux i386 binaries directly or legacy Windows i386
binaries via Wine



While I wouldn't mind dropping support for i386 to something like 1, I 
do wish we don't end up doing it exactly the same as in Ubuntu, where we 
now have to apply i386 specific code to e.g. debian/rules, i386 specific 
build-deps etc.


The prospect of something 
https://salsa.debian.org/systemd-team/systemd/-/merge_requests/158 
doesn't make me too happy.


Removing (partial) support for an architecture shouldn't lead to 
additional work and maintenance burden.



Michael



OpenPGP_signature
Description: OpenPGP digital signature

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Steve McIntyre]

Andrew Cater wrote:
>On Fri, May 19, 2023 at 03:03:40PM +0100, Steve McIntyre wrote:
>> 
>> I had been thinking about doing similar for installer images too, but
>> with other work going on too I think it got too late in the cycle to
>> make that change. My plan is therefore to ship i386 installer images
>> for bookworm as normal (including bookworm point releases going
>> forwards), but to disable those builds for testing/trixie ~immediately
>> after the release.
>
>I'd honestly suggest *just* publishing DVD1 for i386.
>
>Netinst requires internet access: DVD1 can be used to install a basic
>system without this. Scrap *everything else* for i386 installation media.

We've had this discussion before. I don't see the point in removing
choice here at *really* short notice before bookworm, but still
keeping a non-zero number of installer images for the architecture. It
saves us very little effort and doesn't really gain us anything.

This is why I'm talking *now* about dropping things for trixie.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< sladen> I actually stayed in a hotel and arrived to find a post-it
  note stuck to the mini-bar saying "Paul: This fridge and
  fittings are the correct way around and do not need altering"

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Steve McIntyre]

Colin Watson wrote:
>On Fri, May 19, 2023 at 09:19:35AM -0500, G. Branden Robinson wrote:
>> Well, maybe not a strong view, but a sense of vague unease--possibly an
>> ill-informed one.  As someone who has used SIMH for "real" work[1], I
>> have to ask how someone would conduct an install to a 32-bit x86 machine
>> running under emulation, assuming no OS on the simulated machine.
>
>I occasionally use 32-bit x86 even today (mostly for not very good
>historical reasons, but nevertheless), and I do it by using a 32-bit
>container on a 64-bit x86 machine instead.  It's much faster to run, and
>it doesn't depend on installer support.  There are doubtless edge cases
>where you need a completely separate kernel, but they aren't really ones
>I run into.

ACK. For people needing/testing i386 stuff, even just a simple
debootstrap and {s,}chroot will cover the vast majority of
needs. That's how we've been building i386 software already for ages
in Debian already.

More complex things can be done if needed: loopback mount an image,
debootstrap, install a kernel, etc. I don't see this as something we
should be spending much effort on in the future.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< sladen> I actually stayed in a hotel and arrived to find a post-it
  note stuck to the mini-bar saying "Paul: This fridge and
  fittings are the correct way around and do not need altering"

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Cyril Brulebois]

Hi,

Andrew M.A. Cater  (2023-05-19):
> I'd honestly suggest *just* publishing DVD1 for i386.
> 
> Netinst requires internet access: DVD1 can be used to install a basic
> system without this. Scrap *everything else* for i386 installation media.

I'm not sure how dropping one netinst ISO is going to change anything in
debian-cd: that's a very fast build, that's a small, single ISO, and not
having to download several GBs seems quite appealing to me. Having DVD1
only would really not seem acceptable to me.

I'm also very much *not* in favour of dropping images just *days* before
the release, without any kind of heads-up.

If the point is to limit the amount of testing done before publishing,
it would seem acceptable to me to limit i386 testing, and to only be
“reacting” to user reports about things that might not be working for
them (instead of proactively checking various combinations).

Cc-ing debian-boot@ and debian-cd@ for information, seeing such an idea
mentioned only on debian-devel@ feels weird.

> Update media for i386 - no, really, don't bother. One DVD per point
> release and have done with it. The utility for i386 was questioned by
> me (amongst others) late in Bookworm planning and it was suggested
> that it should be decided for Trixie immediately bookworm is released.

No opinion on that.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Andrew M.A. Cater]

On Fri, May 19, 2023 at 03:03:40PM +0100, Steve McIntyre wrote:
> Luca Boccassi wrote:
> >On Fri, 19 May 2023 at 12:42, Steve McIntyre  wrote:
> >>
> >> I'm planning on stopping publishing installer images for i386
> >> soon. Why? We should be strongly encouraging users to move away from
> >> it as a main architecture. If they're still installing i386 on 64-bit
> >> hardware, then that's a horrible mistake. If they're still running
> >> i386 *hardware*, then they should be replacing that hardware with more
> >> modern, more capable, more *efficient* stuff.
> >>
> >
> >+1 for stopping publishing installers for i386, it has been mentioned
> >many times but it's always worth repeating: electricity costs to keep
> >running i386 hardware are already way higher than what it costs to buy
> >a cheap, low-power replacement like a raspberry pi, that also provides
> >better performance.
> 
> Exactly.
> 
> >Just to clarify, by 'soon' here, do you mean for Bookworm too, or 
> >post-Bookworm?
> 
> I had been thinking about doing similar for installer images too, but
> with other work going on too I think it got too late in the cycle to
> make that change. My plan is therefore to ship i386 installer images
> for bookworm as normal (including bookworm point releases going
> forwards), but to disable those builds for testing/trixie ~immediately
> after the release.
> 

I'd honestly suggest *just* publishing DVD1 for i386.

Netinst requires internet access: DVD1 can be used to install a basic
system without this. Scrap *everything else* for i386 installation media.

Update media for i386 - no, really, don't bother. One DVD per point release
and have done with it. The utility for i386 was questioned by me (amongst
others) late in Bookworm planning and it was suggested that it should
be decided for Trixie immediately bookworm is released.

We could make that decision here and now - *definitely* not for Trixie
and minimal effort on i386 installers for Bookworm.

> If people have strong opinions about that plan, let us know please.
> 
> -- 
> Steve McIntyre, Cambridge, UK.st...@einval.com
> < sladen> I actually stayed in a hotel and arrived to find a post-it
>   note stuck to the mini-bar saying "Paul: This fridge and
>   fittings are the correct way around and do not need altering"
> 

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Steve Langasek]

On Fri, May 19, 2023 at 04:30:56PM +0100, Simon McVittie wrote:
> On Fri, 19 May 2023 at 09:19:35 -0500, G. Branden Robinson wrote:
> > I have to ask how someone would conduct an install to a 32-bit x86 machine
> > running under emulation, assuming no OS on the simulated machine.

> I see four levels of support that we could reasonably have for i386:

> 1. same as in recent Ubuntu: just enough packages (mostly libraries) to
>configure it as a multiarch foreign architecture on an amd64 system,
>and run legacy Linux i386 binaries directly or legacy Windows i386
>binaries via Wine

> 2. same as (1), plus basic utilities (coreutils, etc.) and optionally an
>init system, to be able to make a pure i386 container or chroot
>that can run on an externally-provided amd64 kernel

2. is actually closer to what we have in Ubuntu, because builds are still
self-hosted on i386 userspace (with an amd64 kernel).  However, this is
*strictly* limited to the base install + build-dep enclosure for the
packages we want to support; autopkgtests for instance are run in a
cross-environment (and if it can't cross-install, then there's no reason to
care about test results for it because it has no end-user application!)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Steve Langasek]

On Fri, May 19, 2023 at 09:19:35AM -0500, G. Branden Robinson wrote:
> I think simulation of 32-bit x86 will get _more_ important as year 2038
> approaches, not less, because in about 2037, people will suddenly notice
> they need to test things before deployment.

Ah but if Debian doesn't support i386 as an architecture then the test for
deployment is very simple: you can't deploy, game over ;)

> [1] Running nroff and troff on an emulated PDP-11/45 running Version 7
> Unix, to resolve compatibility defects in groff and settle arguments
> about "authentic" Unix *roff behavior.

Dustin Kirkland once did a demo where he booted every 6-monthly Ubuntu
release since the dawn of time in a VM (15+ at the time, I think).  That's
much more useful for software archaeology of this sort than providing i386
host support in *future* Debian releases.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Steve Langasek]

On Fri, May 19, 2023 at 12:42:32PM +0100, Steve McIntyre wrote:
> >If the main reason is to support non-free binaries, at least to me
> >that does not seem like a very compelling reason. And people can
> >always use old chroots or similar I guess?

> i386 is in a really awkward situation here, I think. Nobody is working
> on it explicitly any more (AFAICS?), but its history as by far the
> most common architecture means that:

>  * we still have a (very!) long tail of installations using it
>  * there are *massively* more old binaries available for it, free,
>proprietary *and* locally-built

FTR this includes wine, and 30 years of 32-bit Windows executables that
people want to be able to run, including games.  (for which inaccurate times
are not going to be hugely important, in general.) And some of those games
are going to require e.g. library packages for 3d acceleration that are in
sync with kernel drivers (nvidia).  This was ultimately what made "just use
an older version in a chroot/container" untenable for Ubuntu and led to
keeping i386 as a partial port.

So one may not think that support for legacy, proprietary programs is a
compelling reason to keep binary-compatibility on i386.  But I counter that
unless you care about this, there's no reason to keep i386 as an
architecture *at all*.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting G. Branden Robinson (2023-05-19 16:19:35)
> > If people have strong opinions about that plan, let us know please.
> 
> Well, maybe not a strong view, but a sense of vague unease--possibly an
> ill-informed one.  As someone who has used SIMH for "real" work[1], I
> have to ask how someone would conduct an install to a 32-bit x86 machine
> running under emulation, assuming no OS on the simulated machine.
> Ordinarily, I'd turn to this:
> 
> https://wiki.debian.org/DebianInstaller/Qemu
> 
> What happens to that with trixie?

would you be happy with a Debian system bootable in Qemu that was not created
by d-i? Creating a i386 chroot with the right packages (essential + kernel +
init) and writing that to a ext2/3/4 disk image can be done without d-i. For
example, try running:

debvm-create --size=4G -- --architecture=i386

Or are there things that only d-i does that you need?

Thanks!

cheers, josch

signature.asc
Description: signature

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Simon McVittie]

On Fri, 19 May 2023 at 09:19:35 -0500, G. Branden Robinson wrote:
> I have to ask how someone would conduct an install to a 32-bit x86 machine
> running under emulation, assuming no OS on the simulated machine.

I see four levels of support that we could reasonably have for i386:

1. same as in recent Ubuntu: just enough packages (mostly libraries) to
   configure it as a multiarch foreign architecture on an amd64 system,
   and run legacy Linux i386 binaries directly or legacy Windows i386
   binaries via Wine

2. same as (1), plus basic utilities (coreutils, etc.) and optionally an
   init system, to be able to make a pure i386 container or chroot
   that can run on an externally-provided amd64 kernel

3. same as (2), plus kernel, bootloader and init system to be able to:
   (a) construct a complete bootable installation using debootstrap or
   similar;
   (b) upgrade existing i386 installations

4. user-facing media like debian-installer and Debian Live

Debian 12 is (4). Steve is talking about dropping down to (3), or possibly
lower, for Debian 13 (and I think that's a good idea).

For compatibility testing for what will happen to legacy 32-bit binaries,
I'd personally install multiarch foreign architecture packages on a
64-bit system (possibly emulated), which matches how we would expect
our users to run those legacy binaries "in production": after all,
there isn't a great deal of point in testing situations that we don't
expect to support. That matches how typical users of things like Steam
and 32-bit Wine are expected to run them today, and requires at least (1)
(I assume Ubuntu continues to keep (1) *because* those use-cases exist).

If we have at least (2), then it's also possible to make a 32-bit-only
container or chroot, using mmdebstrap or debootstrap or similar. For a
chroot, or a "chroot done properly"-style container with no init system
(conventional for Docker), an init system isn't needed. For a container
that boots like a lightweight alternative to a VM (conventional for lxc),
an init system like systemd will also be necessary. Some container
frameworks like Podman and systemd-nspawn can work either way.

If we have at least (3), then it's also possible to make a bootable
system, but without (4) you would have to either install Debian 12 and
upgrade, or use something like vmdb2 or debos, instead of installing
interactively with debian-installer. For a reproducible test system,
you might well want to do that anyway.

smcv

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[G. Branden Robinson]

At 2023-05-19T15:32:40+0100, Colin Watson wrote:
> I occasionally use 32-bit x86 even today (mostly for not very good
> historical reasons, but nevertheless), and I do it by using a 32-bit
> container on a 64-bit x86 machine instead.  It's much faster to run,
> and it doesn't depend on installer support.  There are doubtless edge
> cases where you need a completely separate kernel, but they aren't
> really ones I run into.

Yeah, I knew the containerization rejoinder would arise but failed to
pre-empt it.  And since time_t is a userland problem, it's probably good
enough for the subject of the parent thread.  But I still feel a twinge
of worry for the _unanticipated_ problems...

I am probably also utterly failing to manage my secret desire that by
2037 we'll all[1] be running RISC-V 64 and that no major fab in the
world will still be etching dies of x86-{32,64} cores.

You can laugh at my optimism now.

Regards,
Branden

[1] Not all.  I hope there will still be m68k machines humming away.


signature.asc
Description: PGP signature

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Colin Watson]

On Fri, May 19, 2023 at 09:19:35AM -0500, G. Branden Robinson wrote:
> Well, maybe not a strong view, but a sense of vague unease--possibly an
> ill-informed one.  As someone who has used SIMH for "real" work[1], I
> have to ask how someone would conduct an install to a 32-bit x86 machine
> running under emulation, assuming no OS on the simulated machine.

I occasionally use 32-bit x86 even today (mostly for not very good
historical reasons, but nevertheless), and I do it by using a 32-bit
container on a 64-bit x86 machine instead.  It's much faster to run, and
it doesn't depend on installer support.  There are doubtless edge cases
where you need a completely separate kernel, but they aren't really ones
I run into.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[G. Branden Robinson]

At 2023-05-19T15:03:40+0100, Steve McIntyre wrote:
> Luca Boccassi wrote:
> >+1 for stopping publishing installers for i386, it has been mentioned
> >many times but it's always worth repeating: electricity costs to keep
> >running i386 hardware are already way higher than what it costs to
> >buy a cheap, low-power replacement like a raspberry pi, that also
> >provides better performance.
> 
> Exactly.
[...]
> My plan is therefore [...]  to disable those builds for testing/trixie
> ~immediately after the release.
> 
> If people have strong opinions about that plan, let us know please.

Well, maybe not a strong view, but a sense of vague unease--possibly an
ill-informed one.  As someone who has used SIMH for "real" work[1], I
have to ask how someone would conduct an install to a 32-bit x86 machine
running under emulation, assuming no OS on the simulated machine.
Ordinarily, I'd turn to this:

https://wiki.debian.org/DebianInstaller/Qemu

What happens to that with trixie?

I think simulation of 32-bit x86 will get _more_ important as year 2038
approaches, not less, because in about 2037, people will suddenly notice
they need to test things before deployment.

And there are reasons we might not anticipate today.[2]

Regards,
Branden

[1] Running nroff and troff on an emulated PDP-11/45 running Version 7
Unix, to resolve compatibility defects in groff and settle arguments
about "authentic" Unix *roff behavior.

[2] https://ieeexplore.ieee.org/stamp/stamp.jsp?tp==7974703


signature.asc
Description: PGP signature

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Steve McIntyre]

Luca Boccassi wrote:
>On Fri, 19 May 2023 at 12:42, Steve McIntyre  wrote:
>>
>> I'm planning on stopping publishing installer images for i386
>> soon. Why? We should be strongly encouraging users to move away from
>> it as a main architecture. If they're still installing i386 on 64-bit
>> hardware, then that's a horrible mistake. If they're still running
>> i386 *hardware*, then they should be replacing that hardware with more
>> modern, more capable, more *efficient* stuff.
>>
>> As and when we switch i386 to a secondary status like this (however we
>> label it!), then I think we should *only* consider it as a
>> compatibility layer for older software. People *could* just use old
>> chroots or similar, but the need is likely to be around for a
>> while.
>
>+1 for stopping publishing installers for i386, it has been mentioned
>many times but it's always worth repeating: electricity costs to keep
>running i386 hardware are already way higher than what it costs to buy
>a cheap, low-power replacement like a raspberry pi, that also provides
>better performance.

Exactly.

>Just to clarify, by 'soon' here, do you mean for Bookworm too, or 
>post-Bookworm?

We've already switched off i386 *live* images for Bookworm. Honestly,
we should probably have done that a while ago; IMHO they've not been
useful in some time.

I had been thinking about doing similar for installer images too, but
with other work going on too I think it got too late in the cycle to
make that change. My plan is therefore to ship i386 installer images
for bookworm as normal (including bookworm point releases going
forwards), but to disable those builds for testing/trixie ~immediately
after the release.

If people have strong opinions about that plan, let us know please.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< sladen> I actually stayed in a hotel and arrived to find a post-it
  note stuck to the mini-bar saying "Paul: This fridge and
  fittings are the correct way around and do not need altering"

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Luca Boccassi]

On Fri, 19 May 2023 at 12:42, Steve McIntyre  wrote:
>
> Guillem Jover wrote:
> >On Thu, 2023-05-18 at 12:01:40 -0700, Steve Langasek wrote:
>
> ...
>
> >> > > * … but NOT on i386.  Because i386 as an architecture is primarily of
> >> > >   interest for running legacy binaries which cannot be rebuilt against 
> >> > > a new
> >> > >   ABI, changing the ABI on i386 would be counterproductive, as 
> >> > > mentioned in
> >> > >   https://wiki.debian.org/ReleaseGoals/64bit-time.
> >>
> >> > Like Russ, I'm also dubious about this, and introduces a special case
> >> > and complexity that does not seem warranted TBH. If this was the case it
> >> > would seem to me it would disallow SOVERSION bumps for example, which we
> >> > have never been concerned with.
> >>
> >> I didn't see anything in Russ's email in this thread that implied he was
> >> dubious of this approach?  He simply has a library he maintains for which 
> >> he
> >> believes binary compatibility is uninteresting.
> >
> >Ah, indeed, just reread the specific paragraph now, sorry Russ! :)
> >
> >> FWIW in Ubuntu where we maintain i386 strictly as an architecture for
> >> compatibility with third-party binaries, we have 1034 source packages that
> >> build Arch: i386 debs.  Not all of those source packages are shared
> >> libraries, but enough of them are that manually updating them to maintain
> >> ABI compatibility on i386 would be a substantial amount of work.  In terms
> >> of overall complexity, I think the scales tip in favor of the toolchain not
> >> defaulting to _TIME_BITS=64 on i386.
> >
> >The problem with obsolete packages is also shared by all other arches,
> >and for those and for local packages the dependency system works for
> >the user and should let them know whether they can upgrade or they
> >would need to remove such packages. For other local FOSS packages
> >they might just be able to rebuild them.
> >
> >Excluding i386 from this transition seems to me will pretty much
> >sentence it, and would also make it rather hard to perform that
> >transition cleanly going forward if people want to keep it alive. And
> >while Debian might eventually remove it from its official ports, we
> >have multiple old ports that are still maintained and used.
> >
> >If the main reason is to support non-free binaries, at least to me
> >that does not seem like a very compelling reason. And people can
> >always use old chroots or similar I guess?
>
> i386 is in a really awkward situation here, I think. Nobody is working
> on it explicitly any more (AFAICS?), but its history as by far the
> most common architecture means that:
>
>  * we still have a (very!) long tail of installations using it
>  * there are *massively* more old binaries available for it, free,
>proprietary *and* locally-built
>
> Moving forwards, we need to make a call on what we want i386 for. I
> was hoping to wait until after bookworm is released to have the meat
> of that discussion, but...
>
> I'm planning on stopping publishing installer images for i386
> soon. Why? We should be strongly encouraging users to move away from
> it as a main architecture. If they're still installing i386 on 64-bit
> hardware, then that's a horrible mistake. If they're still running
> i386 *hardware*, then they should be replacing that hardware with more
> modern, more capable, more *efficient* stuff.
>
> As and when we switch i386 to a secondary status like this (however we
> label it!), then I think we should *only* consider it as a
> compatibility layer for older software. People *could* just use old
> chroots or similar, but the need is likely to be around for a
> while.

+1 for stopping publishing installers for i386, it has been mentioned
many times but it's always worth repeating: electricity costs to keep
running i386 hardware are already way higher than what it costs to buy
a cheap, low-power replacement like a raspberry pi, that also provides
better performance.

Just to clarify, by 'soon' here, do you mean for Bookworm too, or post-Bookworm?

Kind regards,
Luca Boccassi

i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Steve McIntyre]

Guillem Jover wrote:
>On Thu, 2023-05-18 at 12:01:40 -0700, Steve Langasek wrote:

...

>> > > * … but NOT on i386.  Because i386 as an architecture is primarily of
>> > >   interest for running legacy binaries which cannot be rebuilt against a 
>> > > new
>> > >   ABI, changing the ABI on i386 would be counterproductive, as mentioned 
>> > > in
>> > >   https://wiki.debian.org/ReleaseGoals/64bit-time.
>> 
>> > Like Russ, I'm also dubious about this, and introduces a special case
>> > and complexity that does not seem warranted TBH. If this was the case it
>> > would seem to me it would disallow SOVERSION bumps for example, which we
>> > have never been concerned with.
>> 
>> I didn't see anything in Russ's email in this thread that implied he was
>> dubious of this approach?  He simply has a library he maintains for which he
>> believes binary compatibility is uninteresting.
>
>Ah, indeed, just reread the specific paragraph now, sorry Russ! :)
>
>> FWIW in Ubuntu where we maintain i386 strictly as an architecture for
>> compatibility with third-party binaries, we have 1034 source packages that
>> build Arch: i386 debs.  Not all of those source packages are shared
>> libraries, but enough of them are that manually updating them to maintain
>> ABI compatibility on i386 would be a substantial amount of work.  In terms
>> of overall complexity, I think the scales tip in favor of the toolchain not
>> defaulting to _TIME_BITS=64 on i386.
>
>The problem with obsolete packages is also shared by all other arches,
>and for those and for local packages the dependency system works for
>the user and should let them know whether they can upgrade or they
>would need to remove such packages. For other local FOSS packages
>they might just be able to rebuild them.
>
>Excluding i386 from this transition seems to me will pretty much
>sentence it, and would also make it rather hard to perform that
>transition cleanly going forward if people want to keep it alive. And
>while Debian might eventually remove it from its official ports, we
>have multiple old ports that are still maintained and used.
>
>If the main reason is to support non-free binaries, at least to me
>that does not seem like a very compelling reason. And people can
>always use old chroots or similar I guess?

i386 is in a really awkward situation here, I think. Nobody is working
on it explicitly any more (AFAICS?), but its history as by far the
most common architecture means that:

 * we still have a (very!) long tail of installations using it
 * there are *massively* more old binaries available for it, free,
   proprietary *and* locally-built

Moving forwards, we need to make a call on what we want i386 for. I
was hoping to wait until after bookworm is released to have the meat
of that discussion, but...

I'm planning on stopping publishing installer images for i386
soon. Why? We should be strongly encouraging users to move away from
it as a main architecture. If they're still installing i386 on 64-bit
hardware, then that's a horrible mistake. If they're still running
i386 *hardware*, then they should be replacing that hardware with more
modern, more capable, more *efficient* stuff.

As and when we switch i386 to a secondary status like this (however we
label it!), then I think we should *only* consider it as a
compatibility layer for older software. People *could* just use old
chroots or similar, but the need is likely to be around for a
while.

There's a tension here: I think it's important to keep the old ABI
around for those old binaries, and I genuinely don't see a use case
for a new incompatible ABI on a mostly-dead architecture that won't
support those binaries. *But* I think we'll also need to keep the port
going with security fixes - it's still likely to be quite common and
we need to keep users safe.

People are even likely to want to keep old software running beyond
2038, in which case I envisage clock hacks coming to keep things
limping on. :-/

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< sladen> I actually stayed in a hotel and arrived to find a post-it
  note stuck to the mini-bar saying "Paul: This fridge and
  fittings are the correct way around and do not need altering"