Well said, 100% agree with Jan-Daniel! Killing off an arch like Power8 that i
s still very useable is not ideal. Power8 should remain in Debian and is not
a ?retro computing? platform.

On Oct 26, 2025, at 8:54?PM, Jan-Daniel Kaplanski <jd.kaplanski@ao

l.de> wrote:

?

Because that's 15 years and Debian's purpose is not to enable retrocomput ing projects.

Huh? What is Debian's purpose then? It even boasts about its broad hw supp

ort on the "Reasons to use Debian" page.[1]

Besides, the armhf baseline of armv7-a+fp aligns with the Cortex-A8 from 2

005[2]. I highly doubt that archaic architecture has a lot of users besides S BCs up to the generation of RPi 2 and legacy embedded systems that are likel
y EOL too. Especially since aarch64 came in 2012 with armv8-a on the Cortex- A53/A57[3][4].

POWER8 went EOSL in 10/2024[5] (only a year ago, which in my books is far a

way from being a "retrocomputing" platform btw), plus POWER9 systems will re ach the end of standard service on 31st Jan 2026[6], so by the time Forky is
around in 2027 POWER9 will be obsolete too. Considering that, it's reasonab
le to ask for POWER8 to be supported beyond 2028, or in a more radical manne
r, move the baseline to POWER10 instead.

---

As a general guidance I would like to aim for a ten to 15 years support r ange
at release time.

I take issue with that, as this approach does neither reflect on the actua

l user base nor the shelf life of a given architecture. There is the risk yo
u kill off a platform too early when it still has an active user base. It on
ly works in regards to POWER8/POWER9 because those have a 10 year span from r elease to EOL. Rather than "release + 15 years" I feel like it should be "EO
L + X years", though there should be debate on what that "X years" may be.

---

That's just my personal take on this as someone who is not involved in act

ive development but likes to keep tabs on what's happening. From the persp ective of a systems administrator, I'm not really fond of the idea of having
to switch to a different OS because the platform is killed off on the basis
of an arbitrary time frame.

Cheers, JD

[1]: https://www.debian.org/intro/why_debian.en.html
[2]: https://en.wikipedia.org/wiki/ARM_Cortex-A8
[3]: https://en.wikipedia.org/wiki/ARM_Cortex-A53
[4]: https://en.wikipedia.org/wiki/ARM_Cortex-A57
[5]: https://www.ibm.com/new/announcements/ibm-power8-end-of-service
[6]: https://www.ibm.com/docs/en/announcements/services-withdrawal-discont

inuance-service-select-power-systems-products-replacements-available


--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Hi

On Mon, Oct 27, 2025 at 11:52:00PM +0000, John Klos wrote:

What is the purpose of this? Is it to, perhaps, reduce work? If so, what
work would that be, specifically?

Is it to give better performance because of greater compiler optimization potential? If so, has anyone done tests that show the advantages of such optimizations? If I recall correctly, at least for amd64, optimizing for newer "v" levels didn't offer measurably meaningful advantages. [1]

Is it to reduce the load on some people or some group or groups of people who'd otherwise need to maintain code supporting older architecture
variants? If so, who are these people / groups, and what work would be
saved?

Is it a desire for cleanliness, and removing older targets makes things more clean?

In other words, what're the real world advantages to these changes, and have they been measured and shown to outweigh the real world disadvantages? If
so, where can we find those evaluations?

Thanks very much,
John Klos

I totally agree with John and would add:

* is there something that the rest of us can do to help?

I am particularly interested in keeping armhf (Cortex-A8 specifically) supported, and while it is not much, I have been contributing to the
linux kernel in connection with these machines, and I am looking for
ways to contribute more in Debian too.

Regards
Sicelo A. Mhlongo

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

yes - maintaining all special cases is an effort.

yes, but your mileage may vary: You often have a special case where general performance measuerement didb't catch the use case.

yes - that are all people involde in debian or generally in Open Source.

yes, throwing out old clumsy code with special workaround for old hardware flaws
is a great cleanup.

It seems you're talking about something different than what the discussion
is about: this discussion is about the baselines for generated binaries.
This isn't a discussion about dropping support for certain architectures
and removing code.

I carefully asked what I asked because I'd like to see real data about
what advantages there are to defaulting compiler flags to an x86-64 level other than default, for instance.

Answering "yes" without providing any information or links to information
or measurements isn't really all that helpful.

Thanks,
John Klos

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 28/10/2025 08:39, Hermann.Lauer@uni-heidelberg.de wrote:

Hi,

On Tue, Oct 28, 2025 at 09:18:38AM +0200, Sicelo wrote:

On Mon, Oct 27, 2025 at 11:52:00PM +0000, John Klos wrote:

What is the purpose of this? Is it to, perhaps, reduce work? If so, what >>> work would that be, specifically?

yes - maintaining all special cases is an effort.

I feel architecture improvements fall into a few categories.

Some improvements eliminate a significant source of bullshit. Examples of
this would be the move from x87 to sse2 (making floating point far more deterministic) or support for hardware atomics (eliminating the need to simulate atomics using some kind of locking)

Some improvements provide more options for the optmiser, but don't
really eliminate any bullshit or change the basic codegen.

Some improvements are really only useful in special-purpose code
written with intrinsics or inline assembler. Most sane projects
also maintain a hll fallback for such code to support new
architectures and to use as a reference.

So lets look at what is actually in "x86-64-v2". (a designation
invented by an enterprise linux vendor)

CMPXCHG16B - expands the size of "native" atomics to 128 bit
LAHF-SAHF - allows loading flags directly into register
POPCNT - counts number of bits set to 1
SSE3 - more vector stuff
SSE4 - even more vector stuff
SSE4_1 - yet more vector stuff
SSE4_2 - yet more vector stuff
SSSE3 - yet more vector stuff

CMPXGNC16B seems the closes to "eliminating a source of BS"
but even that seems pretty marginal.

--- PyGate Linux v1.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Apologies if something similar already exists or has been discussed
before. If so, I'd appreciate being pointed to the relevant
documentation or discussion.
I'd like to propose an alternative that may complement raising
architecture baselines. Instead of increasing the default baseline for
official binary packages, Debian could make it easier for users to
locally rebuild the distribution with CPU-specific optimization flags
(mostly march, -flto , -fstack-protector-strong etc ). The idea is to
extend APT/dpkg so it can automatically rebuild installed packages and
their dependency graph from source. While the required pieces already
exist, coordinating recursive builds currently requires managing
custom build scripts and manual intervention. Integrating this
workflow into APT would make optimized local builds accessible to
ordinary users without requiring packaging bootstrapping expertise.

A possible workflow could be:
1. Install a minimal Debian system.
2. Enable an optional "source-based package management" mode that:
* configures source repositories,
* installs the compiler toolchain and build dependencies,
* allows user-defined or Debian-recommended compiler flags.
3. Rebuild installed packages (e.g. `apt reinstall '~i'`), with APT automatically resolving build dependencies, rebuilding packages from
source, and reinstalling them.
4. Continue using the same mechanism for future
`upgrade`/`full-upgrade` operations.

Potential benefits:
* No need for managing multiple micro-architectures
* No major space requirements
* Server all variety of users (scientific computing, security focused e
tc)
* Will this reduce efforts in bootstrapping ?

A few anticipated concerns:
* Why not implement this as an external script?
Most of the required functionality already exists. However,
integrating the workflow into APT would provide a more consistent user experience, reduce duplicated tooling, and make the feature accessible
to a broader audience instead of only advanced users.

* Why not simply use a source-based distribution?
Source-based distributions certainly provide this capability, but
Debian's strengths are different: long-term stability, well-maintained packaging, conservative updates, and extensive security support. I
value those and still want the option to optimize packages for my own
hardware.

* Would this increase unsupported bug reports due to custom compiler fl ags?
That is a legitimate concern. One possible approach would be to
provide a small number of supported optimization profiles (or simply
default to the distribution's standard flags), while clearly
documenting that bug reports resulting from unsupported compiler flags
should first be reproduced using the supported configuration before
being reported.

I realize this would represent a significant enhancement to APT and
would require careful design. Nevertheless, it seems like a possible
way to satisfy users who want hardware-specific optimization without
requiring Debian to change the default architecture baseline for
everyone.

Regards,
Vipul

On Oct 26, 2025, at 5:40?AM, Bastian Blank <waldi@debian.org> wro

te:

?Hi

We never did a real discussion about architecture baselines before, but I

think

we should do that. We also don't have any guidelines what we as Debian w

ant to

actually support. But given that we are a general purpose distribution,

we

have to find a balance.

As a general guidance I would like to aim for a ten to 15 years support r

ange

at release time. The cutoff in respect to the expected 2027 release date

of

Forky would therefor be 2012 to 2017. More time is given for widely used architectures, less for more specialized ones.

Bastian

# Current architecture baseline

Only three architectures set an explicit baseline in gcc-12 (Bookworm) an

d

gcc-15 (Forky):
* armhf: armv7-a+fp
* i386: i686
* s390: z196

All other architectures use the default values.

# Proposal for architecture baseline

## amd64 (and i386)

* x86-64-v2: Supported since around 2008[^x86]. Used in RedHat 9[^redhat9

x86].

* x86-64-v3: Supported since around 2013-2015[^x86]. Used in RedHat
10[^redhat10].

I propose to use the x86-64-v2 baseline in Forky. It gives us more then

the 15

years and everyone else already switched to it or even a newer variant. Factoring in a possible LTS for Trixie, this means that x86-64-v1 will st

op

being supported by Debian in 2030.

## ppc64el

* POWER8: Launched in 2014[^power8].
* POWER9: Launched in 2017[^power9]. Used in RedHat 9[^redhat9] and
10[^redhat10].

I propose to use the POWER9 baseline in Forky. The Debian infrastructure

seems

to be comprised of all POWER9s. This means POWER8 will stop being suppor

ted in

2028.

## s390x

* z14: Launched in 2017[^z14]. Used by RedHat 10[^redhat10].
* z15: Launched in 2019[^z15]. Used by next Ubuntu.

I propose to use the z15 baseline in Forky. Yes, this is less then ten y

ears,

but s390 is such a niche architecture and all we do is best (often not ev

en

this) effort support. The Debian infrastructure is documented to be at l

east

z15, all accesible system are actually z16. This means that z14 and olde

r will

stop being support in 2028.

# How to see supported baseline

The dynamic linker of glibc can show what microarchiture level it conside

rs

supported on the current CPU. The "supported" marker is relevant in this

case.

## amd64
```
% /usr/lib64/ld-linux-x86-64.so.2 --help | sed -n '/^Subdirectories of gl

ibc-hwcaps/,$p'

Subdirectories of glibc-hwcaps directories, in priority order:
x86-64-v4
x86-64-v3 (supported, searched)
x86-64-v2 (supported, searched)
```

## ppc64el
```
% /usr/lib64/ld64.so.2 --help | sed -n '/^Subdirectories of glibc-hwcaps/

,$p'

Subdirectories of glibc-hwcaps directories, in priority order:
power10
power9 (supported, searched)
```

## s390x
```
% /usr/lib/ld64.so.1 --help | sed -n '/^Subdirectories of glibc-hwcaps/,/

^ z15/p'

Subdirectories of glibc-hwcaps directories, in priority order:
z16 (supported, searched)
z15 (supported, searched)
```

[^power8]: https://en.wikipedia.org/wiki/POWER8
[^power9]: https://en.wikipedia.org/wiki/POWER9
[^x86]: https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels
[^z14]: https://en.wikipedia.org/wiki/IBM_z14_(microprocessor)
[^z15]: https://en.wikipedia.org/wiki/IBM_z15_(microprocessor)
[^redhat9]: https://docs.redhat.com/en/documentation/red_hat_enterprise_l

inux/9/html/9.0_release_notes/architectures

[^redhat9x86]: https://developers.redhat.com/blog/2021/01/05/building-red

-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level

[^redhat10]: https://docs.redhat.com/en/documentation/red_hat_enterprise_

linux/10/html/considerations_in_adopting_rhel_10/architectures

--
Spock: The odds of surviving another attack are 13562190123 to 1, Captain

.


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)