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)