Re: Architecture baseline for Forky
I note that I've mostly noped out of this discussion because https://mstdn.jp/@landley/115504860540842713 and https://mastodon.sdf.org/@washbear/115646255465589454 but as long as I'm catching up on back email anyway... On 11/12/25 12:27, Adrian Bunk wrote: We are already providing a non-PIE version of the Python interpreter for users who need it for performance reasons, and it is for example possible that the benefits of providing packages without hardening (for situations where hardening is not necessary) might bring larger benefits than architecture-optimized versions. Long ago when I was doing https://landley.net/aboriginal/about.html (work which eventually allowed Alpine to be based on busybox), I benched that statically linking busybox let the autoconf stage of package builds complete about 20% faster under qemu. (My theory was lazy binding patched out the PLT indirection on the first call which dirtied the executable page and forced QEMU to discard the native code cache and retranslate it, often multiple times as multiple indirections were dynamically patched. I later found it hilarious that the dynamic linking people went on to do snap and flatpak and so on, using FAR more space for no obvious gain...) Does that mean static linking is faster everywhere? Dunno, I haven't tried "everywhere". You can't "optimize" without saying what you're optimizing FOR, and the ground changes out from under you. Loop unrolling was an optimization, then became a pessimization when cpu caches showed up, then an optimization again when L2 caches showed up, and the pendulum went back and forth multiple times before I stopped trying to even track it sometime around when branch prediction turned into a security hole and people started doing TLB invalidation mitigations for it. My takeaway lesson was outside of tight inner loops, do the simple thing and let the hardware and optimizers take care of themselves. I do know I left the Red Hat world for the Debian world when the new Fedora CD wouldn't install on the Pentium Pro I had at the time (because they'd "moved on" to an architecture newer than the hardware I was still using). I had to learn what x86-64-v1 vs v2 were when an android NDK update made all binaries it produced segfault on my netbook. I cared because I was maintaining their command line utilities, and it was nice to be able to actually test that environment. But I didn't discard my hardware to humor the change, I just ran my test binaries under qemu until that netbook died... There was talk back then (what, 2018?) about teaching repositories to know about various architecture flags so it could pull optimized packages for your machine, but the discussion petered out because the gains were small and the overhead was huge. > Would x32 optimized for v3 be the best option for many use cases? It would prevent the x86-64-v2 laptop I'm typing this on from running those binaries, but I've already talked to the netbsd guys and to them running on systems people want to use their stuff on is a point of pride. Like it used to be on Linux, before everybody got old and tired and needed to lighten the load. Decisions have costs. It's your call to cull your herd and chastise the outliers, but it usually means some subset will move on to things that are still fun. It's an interesting move giving ultimatums to people who never got forced onto windows and never moved to GPLv3. Not "I am stepping down from this and going this way instead", but "xfree86 is now under this new license, you will all comply hey where are you going"... *shrug* You do you. Rob
Re: Architecture baseline for Forky
On 12/11/25 at 20:27 +0200, Adrian Bunk wrote: > On Wed, Nov 05, 2025 at 08:42:08PM +0100, Lucas Nussbaum wrote: > > Hi, > > Hi Lucas, > > > On 26/10/25 at 13:21 +0100, Bastian Blank wrote: > > > 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 > > > want to > > > actually support. But given that we are a general purpose distribution, > > > we > > > have to find a balance. > > > > This thread only discusses bumping baselines, but I wonder if we should > > consider other ways to provide architecture-optimized versions of some > > packages? > >... > > I did already discuss in [1] two additional topics, that should be > prerequisites for any productive discussion: > > 1. Lack of data > > I have not seen any data discussed here on the benefits that could be a > basis for an actual discussion. > > Like what are the actual performance differences between v1/v2/v3/v4 > on amd64? > > Which steps (if any) bring large performance improvements? > Are these performance improvements for everything and/or are there > large benefits that are limited to few packages? > > I do remember how 20 years ago when Gentoo was new, people spent days > watching their computer compiling everything perfectly optimized for > their system - only to discover that it didn't make a noticeable > difference. > > 2. Don't restrict the discussion/data to architecture baselines > > How much performance does security hardening cost? > What are the performance and size effects of building packages > optimized for size instead of speed? > What performance benefits would making x32 a (partial?) release > architecture bring? > ... > > We are already providing a non-PIE version of the Python interpreter for > users who need it for performance reasons, and it is for example > possible that the benefits of providing packages without hardening (for > situations where hardening is not necessary) might bring larger benefits > than architecture-optimized versions. > > Would x32 optimized for v3 be the best option for many use cases? > > Any discussion of possible solutions has to start with data showing what > changes might actually bring sufficient benefits for being worth the > effort. Right. There are some benchmarks results at https://www.phoronix.com/review/ubuntu-x86-64-v3-benchmark Also, there are at least 4 criterias to evaluate solutions: - performance gain - loss of HW support - per-package work needed (hwcaps is bad for this) - archive/mirror impact (architecture variant is bad for this) A tentative summary: | Solution | Performance | HW support | Pkg maint work | Archive size | | | --- | -- | -- | | | baseline bump| +++ | ---| little impact | no impact | | architecture variant | +++ | no impact | little impact | --- | | per-pkg solutions| + | no impact | ---| no impact | Lucas
Re: Architecture baseline for Forky
On Wed, Nov 05, 2025 at 08:42:08PM +0100, Lucas Nussbaum wrote: > Hi, Hi Lucas, > On 26/10/25 at 13:21 +0100, Bastian Blank wrote: > > 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 > > want to > > actually support. But given that we are a general purpose distribution, we > > have to find a balance. > > This thread only discusses bumping baselines, but I wonder if we should > consider other ways to provide architecture-optimized versions of some > packages? >... I did already discuss in [1] two additional topics, that should be prerequisites for any productive discussion: 1. Lack of data I have not seen any data discussed here on the benefits that could be a basis for an actual discussion. Like what are the actual performance differences between v1/v2/v3/v4 on amd64? Which steps (if any) bring large performance improvements? Are these performance improvements for everything and/or are there large benefits that are limited to few packages? I do remember how 20 years ago when Gentoo was new, people spent days watching their computer compiling everything perfectly optimized for their system - only to discover that it didn't make a noticeable difference. 2. Don't restrict the discussion/data to architecture baselines How much performance does security hardening cost? What are the performance and size effects of building packages optimized for size instead of speed? What performance benefits would making x32 a (partial?) release architecture bring? ... We are already providing a non-PIE version of the Python interpreter for users who need it for performance reasons, and it is for example possible that the benefits of providing packages without hardening (for situations where hardening is not necessary) might bring larger benefits than architecture-optimized versions. Would x32 optimized for v3 be the best option for many use cases? Any discussion of possible solutions has to start with data showing what changes might actually bring sufficient benefits for being worth the effort. > Lucas cu Adrian [1] https://lists.debian.org/debian-release/2025/10/msg00487.html
Re: Architecture baseline for Forky
On Wed, Nov 05, 2025 at 08:42:08PM +0100, Lucas Nussbaum wrote: > This thread only discusses bumping baselines, but I wonder if we should > consider other ways to provide architecture-optimized versions of some > packages? indeed, me too thinks this would be good. > https://wiki.debian.org/InstructionSelection lists some, including > glibc's hwcaps. > > Also Canonical/Ubuntu decided to enable architecture variants in dpkg > and APT since Ubuntu 2025.10. See: /me likes both of these suggestions, thanks! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ "We'll just terraform Mars," they insist, unable to terraform Earth, a planet that is already perfect except it's like 2° too warm. signature.asc Description: PGP signature
Re: Architecture baseline for Forky
Hi, On 26/10/25 at 13:21 +0100, Bastian Blank wrote: > 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 want > to > actually support. But given that we are a general purpose distribution, we > have to find a balance. This thread only discusses bumping baselines, but I wonder if we should consider other ways to provide architecture-optimized versions of some packages? https://wiki.debian.org/InstructionSelection lists some, including glibc's hwcaps. Also Canonical/Ubuntu decided to enable architecture variants in dpkg and APT since Ubuntu 2025.10. See: https://discourse.ubuntu.com/t/introducing-architecture-variants-amd64v3-now-available-in-ubuntu-25-10/71312 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1118567 https://wiki.debian.org/ArchitectureVariants https://lwn.net/Articles/1044383/ Lucas
Re: Architecture baseline for Forky
On 28/10/2025 08:39, [email protected] wrote: Hi, On Tue, Oct 28, 2025 at 09:18:38AM +0200, Sicelo wrote: On Mon, Oct 27, 2025 at 11:52:00PM +, 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.
Re: Re: Architecture baseline for Forky
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
Re: Planned obsolescence ? (was: Re: Architecture baseline for Forky)
On Tue Oct 28, 2025 at 3:03 PM CET, Marc Haber wrote: > On Tue, Oct 28, 2025 at 03:00:24PM +0100, Diederik de Haas wrote: >>On Tue Oct 28, 2025 at 10:07 AM CET, Marc Haber wrote: >>> On Tue, Oct 28, 2025 at 09:59:11AM +0100, Romain Dolbeau wrote: Planned obsolescence is bad, not good. >>> >>> Still, Debian has to rely on stable support in kernel and toolchain. >>> Once kernel and toolchain stop supporting¹ an architecture there is >>> nothing that Debian could do about that with its limited personpower and >>> resources. >> >>The kernel and/or toolchain dropping support is a valid argument IMO. >>Dropping support because 7/8/10/15 years have passed is not. >>Some 'random' other distro dropping support is (IMO) not a valid >>argument in itself. Maybe their reasons behind dropping it, is. > > The problem is that Bastian has a point here in wanting to announce that > YEARS in advance, but toolchain/kernel usually having a much shorter > horzion. So, when we want to guess what they're going to do we have to > be really careful and err to the conservative side. I think announcing at the beginning of a new release cycle that release X (in this case Forky) will be the last that architecture X will be supported, is great. Then people who are interested/invested in it have ~2 years to prepare for it. When it comes to kernel support, I'm quite sure Arnd Bergmann announces dropping support for (device) X *years* in advance, so that does NOT happen overnight. (With their spring/autumn announcement/summary IIRC) As said before, I think those are substantive arguments. My problem is that I have mostly seen imaginary or theoretical arguments. I would be fine with an argument where I think "that makes sense" (even though I may not be happy about it). Just arbitrary amount of years have passed or "people should not be using that anymore". To which my response is: "Why not? If it still works?" Cheers, Diederik signature.asc Description: PGP signature
Re: Planned obsolescence ? (was: Re: Architecture baseline for Forky)
On Tue Oct 28, 2025 at 10:07 AM CET, Marc Haber wrote: > On Tue, Oct 28, 2025 at 09:59:11AM +0100, Romain Dolbeau wrote: >> Planned obsolescence is bad, not good. > > Still, Debian has to rely on stable support in kernel and toolchain. > Once kernel and toolchain stop supporting¹ an architecture there is > nothing that Debian could do about that with its limited personpower and > resources. The kernel and/or toolchain dropping support is a valid argument IMO. Dropping support because 7/8/10/15 years have passed is not. Some 'random' other distro dropping support is (IMO) not a valid argument in itself. Maybe their reasons behind dropping it, is. I've also seen the argument that special casing is an effort. While ofc true, a lot if not all of that has already been done. When there's practical, not just some theoretical, evidence that it still involves an undue burden/effort, that's a valid argument. As an example, I have an Asus TF-101 with Tegra2 chip, thus no NEON support, which still works great. AFAIK the (armhf) software has already been adapted/special-cased to deal with HW which does and HW which does not support NEON. Removing that special casing is an extra effort ... for what? To deliberately drop support for HW which does not? Why? If changing the baseline to require NEON (f.e.) would speed up all the software by X%, then I would consider that a valid argument. But I have not seen that. My 0.02 signature.asc Description: PGP signature
Re: Planned obsolescence ? (was: Re: Architecture baseline for Forky)
On Tue, Oct 28, 2025 at 03:00:24PM +0100, Diederik de Haas wrote: On Tue Oct 28, 2025 at 10:07 AM CET, Marc Haber wrote: On Tue, Oct 28, 2025 at 09:59:11AM +0100, Romain Dolbeau wrote: Planned obsolescence is bad, not good. Still, Debian has to rely on stable support in kernel and toolchain. Once kernel and toolchain stop supporting¹ an architecture there is nothing that Debian could do about that with its limited personpower and resources. The kernel and/or toolchain dropping support is a valid argument IMO. Dropping support because 7/8/10/15 years have passed is not. Some 'random' other distro dropping support is (IMO) not a valid argument in itself. Maybe their reasons behind dropping it, is. The problem is that Bastian has a point here in wanting to announce that YEARS in advance, but toolchain/kernel usually having a much shorter horzion. So, when we want to guess what they're going to do we have to be really careful and err to the conservative side. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
AW: Re: Planned obsolescence ? (was: Re: Architecture baseline for Forky)
It's a really good point though about x86-64-v1. There are still thousands of Core2Duo systems out there. Anything pre-Nehalem just isn't x86-64-v2 compliant. These systems basically flooded the used marked and are an entry point to low-cost computing for many. It's hard to justify locking out these users before support is dropped in the mainline Kernel. It's only RHEL that's really pushing for it AFAIK. From their perspective it's reasonable, because of the the marginal performance gains that would benefit their customers. For anyone else it just isn't. Cheers, JD Am Di., Okt. 28, 2025 at 10:32 schrieb John Paul Adrian Glaubitz: On Tue, 2025-10-28 at 09:59 +0100, Romain Dolbeau wrote: > Le lun. 27 oct. 2025 à 22:58, Milan Kupcevic a écrit : > > It would be more reasonable to count 7 years since mass sales or wide > > availability ends as hardware typically lasts 5 to 7 years in production > > environment. > > Hardware lasts a lot longer. People are forced to update because > vendors have given up on support and are forcing users to upgrade. > It's called planned obsolescence, as I'm sure you all already know. There is no such thing is planned obsolescence. Code has to be maintained and that costs money. You cannot force any vendor to support old hardware forever. You can still pay them to get support for ancient hardware in most cases though. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Planned obsolescence ? (was: Re: Architecture baseline for Forky)
On Tue, Oct 28, 2025 at 09:35:00AM +, Jan-Daniel Kaplanski wrote: It's a really good point though about x86-64-v1. There are still thousands of Core2Duo systems out there. Anything pre-Nehalem just isn't x86-64-v2 compliant. These systems basically flooded the used marked and are an entry point to low-cost computing for many. It's hard to justify locking out these users before support is dropped in the mainline Kernel. Or before support noticeably declines. I agree with that. But I also see that Bastian might have deliberately worded his message in a way that would prompt some discussion. No bill leaves parliament as it entered parliament. It's only RHEL that's really pushing for it AFAIK. From their perspective it's reasonable, because of the the marginal performance gains that would benefit their customers. For anyone else it just isn't. I agree that Debian should not orient itself along Enterprise Linuxes' commercial decisions. We should orient ourselves along what toolchain and kernels reasonably support, acknowledging that this is hard to determine years in advance. I would be fine with a statement "these and these architectures might lose their support with Debian's 2029 release" IF we can optionally decide to postpone that date for certain architectures if we find, preparing for the 2029 release, that there still is reasonable support. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: Planned obsolescence ? (was: Re: Architecture baseline for Forky)
On Tue, 2025-10-28 at 09:59 +0100, Romain Dolbeau wrote: > Le lun. 27 oct. 2025 à 22:58, Milan Kupcevic a écrit : > > It would be more reasonable to count 7 years since mass sales or wide > > availability ends as hardware typically lasts 5 to 7 years in production > > environment. > > Hardware lasts a lot longer. People are forced to update because > vendors have given up on support and are forcing users to upgrade. > It's called planned obsolescence, as I'm sure you all already know. There is no such thing is planned obsolescence. Code has to be maintained and that costs money. You cannot force any vendor to support old hardware forever. You can still pay them to get support for ancient hardware in most cases though. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Planned obsolescence ? (was: Re: Architecture baseline for Forky)
On Tue, 2025-10-28 at 10:07 +0100, Marc Haber wrote: > On Tue, Oct 28, 2025 at 09:59:11AM +0100, Romain Dolbeau wrote: > > Debian isn't Microsoft. Debian isn't Apple. Debian isn't Google. > > Please don't learn the wrong lessons from them. Planned obsolescence > > is bad, not good. > > Still, Debian has to rely on stable support in kernel and toolchain. > Once kernel and toolchain stop supporting¹ an architecture there is > nothing that Debian could do about that with its limited personpower and > resources. POWER8 is still years away from being removed from the kernel and toolchain. I don't think that anyone at IBM is seriously considering dropping POWER8 support in the kernel or even the toolchain at the moment. I mean, POWER5 was first announced in 2003 and is still supported by the Linux kernel and toolchain, so I'm very sure that POWER8 is not going to go anywhere soon. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Architecture baseline for Forky
On Mon, Oct 27, 2025 at 03:13:45PM -0500, Rob Landley wrote: It's funny how the push to make architectures go away corresponds with the patent expiration on those architectures, I.E. the point at which clones (compatible reimplementations) can start being sold very cheaply. Considering that kernel and toolchain support is commonly paid for by the hardware vendors, it does not come as a surprise that this support declines with the deprecation of the architecture. Also, people volunteering for kernel and toolchain support for a certain architecture are usually more interested in working on the current version of that arch and not for something obsolete. I do understand that users expect toolchain and kernel support to "just appear" out of thin air, but in practice it is a considerable effort to keep bit rot away from the parts of code that are needed to keep older architectures running. You need motivation and money to facilitate that. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: Planned obsolescence ? (was: Re: Architecture baseline for Forky)
On Tue, Oct 28, 2025 at 09:59:11AM +0100, Romain Dolbeau wrote: Debian isn't Microsoft. Debian isn't Apple. Debian isn't Google. Please don't learn the wrong lessons from them. Planned obsolescence is bad, not good. Still, Debian has to rely on stable support in kernel and toolchain. Once kernel and toolchain stop supporting¹ an architecture there is nothing that Debian could do about that with its limited personpower and resources. Greetings Marc ¹ there is more than one way to do that, either pull support officially, letting people know about that, or just let the respective code rot away slowly because noone tests any more -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: Re: Architecture baseline for Forky
Hi, On Tue, Oct 28, 2025 at 09:18:38AM +0200, Sicelo wrote: > On Mon, Oct 27, 2025 at 11:52:00PM +, 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. > > 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] yes, but your mileage may vary: You often have a special case where general performance measuerement didb't catch the use case. > > 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? yes - that are all people involde in debian or generally in Open Source. > > Is it a desire for cleanliness, and removing older targets makes things more > > clean? yes, throwing out old clumsy code with special workaround for old hardware flaws is a great cleanup. > > 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? See above. Measurement I don't know. > * is there something that the rest of us can do to help? Eg. do measurements and evaluations on that. > I am particularly interested in keeping armhf (Cortex-A8 specifically) > supported, Me too as this architecture is still sold as SoC boards with an excellent feature to price ratio. Especially for low power environments. Of course this platforms have licens/errata etc. issues, but OpenHardware like RISCV is not common enough yet. > 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. See above. Thanks alot to everbody keeping the debian ecosystem running! Greetings Hermann
Planned obsolescence ? (was: Re: Architecture baseline for Forky)
Le lun. 27 oct. 2025 à 22:58, Milan Kupcevic a écrit : > It would be more reasonable to count 7 years since mass sales or wide > availability ends as hardware typically lasts 5 to 7 years in production > environment. Hardware lasts a lot longer. People are forced to update because vendors have given up on support and are forcing users to upgrade. It's called planned obsolescence, as I'm sure you all already know. Debian is (at least up to now) the Linux distribution one could rely on to support hardware as long as its actual life without forcing users to upgrade. I have ~2007 (Penryn) systems still in use that were deployed with Debian when new, and I'm sure I'm not the only one. If it ain't broke, don't fix it, just upgrade Debian :-) Debian isn't Microsoft. Debian isn't Apple. Debian isn't Google. Please don't learn the wrong lessons from them. Planned obsolescence is bad, not good. Cordially, -- Romain Dolbeau
Re: Architecture baseline for Forky
On October 27, 2025 10:38:57 PM GMT+01:00, Milan Kupcevic wrote: >On 10/26/25 8:21 AM, Bastian Blank wrote: >> Hi > >Hi Bastian, > >> >> 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 want >> 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 range >> at release time. > > >It would be more reasonable to count 7 years since mass sales or wide >availability ends as hardware typically lasts 5 to 7 years in production >environment. We still have PCs running that were shipped 15 to 20 years ago that we and their IT department wish would be replaced with something more recent. It really only gets replaced when it stops working. Kurt
Re: Architecture baseline for Forky
Hi On Mon, Oct 27, 2025 at 11:52:00PM +, 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
Re: Architecture baseline for Forky
Hello, # Proposal for architecture baseline I propose to use the x86-64-v2 baseline in Forky. It gives us more then the 15 ... I propose to use the POWER9 baseline in Forky. The Debian infrastructure seems ... I propose to use the z15 baseline in Forky. Yes, this is less then ten years, 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 [1] https://discourse.ubuntu.com/t/trying-out-ubuntu-23-04-on-x86-64-v3-rebuild-for-yourself/40963/10
Re: Architecture baseline for Forky
On 10/26/25 8:21 AM, Bastian Blank wrote: Hi Hi Bastian, 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 want 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 range at release time. It would be more reasonable to count 7 years since mass sales or wide availability ends as hardware typically lasts 5 to 7 years in production environment. Milan
Re: Architecture baseline for Forky
On 10/26/25 19:29, Tony Rodriguez wrote: > Yet x86-64 v2 will still be supported, based on the initial email, I hope so, that's the laptop I'm still using. (When they got cheap I bought a couple spares.) Kinda weird that Linux's response to Windows 11 going "we will forcibly drop support for a huge amount of hardware" seems to be "yeah, us too!" Rob
Re: Architecture baseline for Forky
On 10/27/25 05:20, Marcin Juszkiewicz wrote: W dniu 27.10.2025 o 01:15, Jan-Daniel Kaplanski pisze: > Besides, the armhf baseline of armv7-a+fp aligns with the Cortex-A8 > from 2005[2]. I highly doubt that archaic architecture has a lot of > users besides SBCs up to the generation of RPi 2 and legacy embedded > systems that are likely EOL too. Especially since aarch64 came in > 2012 with armv8-a on the Cortex-A53/A57[3][4]. Many people would love to see arm32 go away. Market is still against us and arm32 is still sold and used. It's funny how the push to make architectures go away corresponds with the patent expiration on those architectures, I.E. the point at which clones (compatible reimplementations) can start being sold very cheaply. Proprietary commercial vendors want to kill their competition. "Many people" work for hardware vendors who not only stop selling things when their patents expire, but actively want support for stuff they were just recently selling to go away. Rob
Re: Architecture baseline for Forky
Power8 EOS is 2024 Oct and it is far away from the retrocomputing system.
Kindly reconsider Power8 as a baseline and I believe there are
infrastructures running on P8.
Thanks,
Kiruthika NV
On Mon, Oct 27, 2025 at 2:16 PM Geert Uytterhoeven
wrote:
> On Mon, 27 Oct 2025 at 01:16, Jan-Daniel Kaplanski
> wrote:
> > Besides, the armhf baseline of armv7-a+fp aligns with the Cortex-A8 from
> > 2005[2]. I highly doubt that archaic architecture has a lot of users
> > besides SBCs up to the generation of RPi 2 and legacy embedded systems
> > that are likely EOL too. Especially since aarch64 came in 2012 with
> > armv8-a on the Cortex-A53/A57[3][4].
>
> BeagleBone Black/Industrial/Green/... and variants are still being sold.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> [email protected]
>
> In personal conversations with technical people, I call myself a hacker.
> But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
>
>
Re: Architecture baseline for Forky
W dniu 27.10.2025 o 01:15, Jan-Daniel Kaplanski pisze: > Besides, the armhf baseline of armv7-a+fp aligns with the Cortex-A8 > from 2005[2]. I highly doubt that archaic architecture has a lot of > users besides SBCs up to the generation of RPi 2 and legacy embedded > systems that are likely EOL too. Especially since aarch64 came in > 2012 with armv8-a on the Cortex-A53/A57[3][4]. Many people would love to see arm32 go away. Market is still against us and arm32 is still sold and used. There could be one change done to armhf: enabling NEON by default as Tegra2 is long time gone. On the other side: why adding new work for port which has decreasing amount of users each year? AArch64 could gain with move to ARM v8.2 so we get Atomics. But the amount of v8.0 devices is holding everyone from making such move.
Re: Architecture baseline for Forky
On 2025-10-26 20:12, Marco d'Itri wrote: > Next year probably we should also talk about RISC-V, when hopefully it will > be more clear what hardware will be available. Hardware and *upstream kernel support*, which might take a few more years if things continue like now... Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B [email protected] http://aurel32.net signature.asc Description: PGP signature
Re: Architecture baseline for Forky
On Mon, 2025-10-27 at 09:55 +0100, Gerardo Ballabio wrote: > If I understand correctly, the rationale for not supporting power8 is this: > > Bastian Blank wrote: > > ## 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) > > ``` > > I read that as meaning that power9 is supported by the current > toolchain, while power8 is not. Please correct me if I am wrong. POWER8 is still supported. The snippet above just documents what additional targets are supported through the hwcaps mechanism in glibc [1] which are POWER9 and POWER10. > So this isn't about "dropping" support for power8, it's about > "restoring" it. As usual, Debian is a doocracy: we can do that if > somebody commits to do that. Nope, it's about dropping. POWER8 is still supported by the toolchain, kernel and glibc. In fact, even much older POWER systems down to POWER5 and PowerPC 970 and even 32-bit PowerPC are still supported. PS: I still think it's a bad idea to use the alias debian-ports@. Adrian > [1] > https://sourceware.org/glibc/manual/latest/html_node/Hardware-Capability-Tunables.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Architecture baseline for Forky
If I understand correctly, the rationale for not supporting power8 is this: Bastian Blank wrote: > ## 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) > ``` I read that as meaning that power9 is supported by the current toolchain, while power8 is not. Please correct me if I am wrong. So this isn't about "dropping" support for power8, it's about "restoring" it. As usual, Debian is a doocracy: we can do that if somebody commits to do that. Gerardo
Re: Architecture baseline for Forky
On Mon, 27 Oct 2025 at 01:16, Jan-Daniel Kaplanski wrote:
> Besides, the armhf baseline of armv7-a+fp aligns with the Cortex-A8 from
> 2005[2]. I highly doubt that archaic architecture has a lot of users
> besides SBCs up to the generation of RPi 2 and legacy embedded systems
> that are likely EOL too. Especially since aarch64 came in 2012 with
> armv8-a on the Cortex-A53/A57[3][4].
BeagleBone Black/Industrial/Green/... and variants are still being sold.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: Architecture baseline for Forky
Well said, 100% agree with Jan-Daniel! Killing off an arch like Power8 that is 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 wrote: > > >> >> Because that's 15 years and Debian's purpose is not to enable retrocomputing >> projects. > Huh? What is Debian's purpose then? It even boasts about its broad hw support > on the "Reasons to use Debian" page.[1] > > Besides, the armhf baseline of armv7-a+fp aligns with the Cortex-A8 from > 2005[2]. I highly doubt that archaic architecture has a lot of users besides > SBCs up to the generation of RPi 2 and legacy embedded systems that are > likely 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 > away from being a "retrocomputing" platform btw), plus POWER9 systems will > reach 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 > reasonable to ask for POWER8 to be supported beyond 2028, or in a more > radical manner, move the baseline to POWER10 instead. > > --- > >> As a general guidance I would like to aim for a ten to 15 years support range >> at release time. > I take issue with that, as this approach does neither reflect on the actual > user base nor the shelf life of a given architecture. There is the risk you > kill off a platform too early when it still has an active user base. It only > works in regards to POWER8/POWER9 because those have a 10 year span from > release to EOL. Rather than "release + 15 years" I feel like it should be > "EOL + 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 active > development but likes to keep tabs on what's happening. From the perspective > 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-discontinuance-service-select-power-systems-products-replacements-available >
Re: Architecture baseline for Forky
Hi, On 10/27/25 9:15 AM, Jan-Daniel Kaplanski wrote: Besides, the armhf baseline of armv7-a+fp aligns with the Cortex-A8 from 2005[2]. I highly doubt that archaic architecture has a lot of users besides SBCs up to the generation of RPi 2 and legacy embedded systems that are likely EOL too. Especially since aarch64 came in 2012 with armv8-a on the Cortex-A53/A57[3][4]. It makes sense to base the support on whether dropping older platforms actually gains something tangible. This was true for i386 .. i686, as we gained enough extra registers that -fPIC no longer incurred a 5% performance penalty, but the differences between iterations of other architectures are a lot smaller. Newer machines might have a better vector unit, but this does not make a lot of difference outside of a bunch of mostly scientific applications that already select an appropriate computation kernel at runtime, and differences in instruction scheduling are better handled by assuming a way newer-than-baseline model for -mtune=. That said, it would be nice to have a way to crossgrade architectures when the ABI is compatible, that would allow us to just create ports for older architectures, and shunt people over. Simon
Re: Architecture baseline for Forky
Yet x86-64 v2 will still be supported, based on the initial email, even when power8 was released during the same time-frame? So power8 is considered retro computing, but not Intel v2? That power8 machine is also more powerful compared to Intel cpus for that time period. Power7 and older I totally understand, but Power8 is still a decent machine. > On Oct 26, 2025, at 4:59 PM, Marco d'Itri wrote: > > On Oct 26, Tony Rodriguez wrote: > >> Why not support power 8 beyond 2028? It is still a good system and supports >> newer little endian. > Because that's 15 years and Debian's purpose is not to enable retrocomputing > projects. > > I think that waldi's proposal is quite reasonable. > > Next year probably we should also talk about RISC-V, when hopefully it will > be more clear what hardware will be available. > > -- > ciao, > Marco >
Re: Architecture baseline for Forky
Because that's 15 years and Debian's purpose is not to enable retrocomputing projects. Huh? What is Debian's purpose then? It even boasts about its broad hw support on the "Reasons to use Debian" page.[1] Besides, the armhf baseline of armv7-a+fp aligns with the Cortex-A8 from 2005[2]. I highly doubt that archaic architecture has a lot of users besides SBCs up to the generation of RPi 2 and legacy embedded systems that are likely 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 away from being a "retrocomputing" platform btw), plus POWER9 systems will reach 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 reasonable to ask for POWER8 to be supported beyond 2028, or in a more radical manner, move the baseline to POWER10 instead. --- As a general guidance I would like to aim for a ten to 15 years support range at release time. I take issue with that, as this approach does neither reflect on the actual user base nor the shelf life of a given architecture. There is the risk you kill off a platform too early when it still has an active user base. It only works in regards to POWER8/POWER9 because those have a 10 year span from release to EOL. Rather than "release + 15 years" I feel like it should be "EOL + 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 active development but likes to keep tabs on what's happening. From the perspective 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-discontinuance-service-select-power-systems-products-replacements-available smime.p7s Description: Kryptografische S/MIME-Signatur
Re: Architecture baseline for Forky
On Oct 26, Tony Rodriguez wrote: Why not support power 8 beyond 2028? It is still a good system and supports newer little endian. Because that's 15 years and Debian's purpose is not to enable retrocomputing projects. I think that waldi's proposal is quite reasonable. Next year probably we should also talk about RISC-V, when hopefully it will be more clear what hardware will be available. -- ciao, Marco signature.asc Description: PGP signature
Re: Architecture baseline for Forky
Why not support power 8 beyond 2028? It is still a good system and supports newer little endian. Hopefully, you can reconsider and keep power 8 for as long as power 9/10 regarding baseline support. > On Oct 26, 2025, at 5:40 AM, Bastian Blank wrote: > > 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 want > 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 range > 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) and > 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[^redhat9x86]. > * 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 stop > 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 supported > 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 years, > but s390 is such a niche architecture and all we do is best (often not even > this) effort support. The Debian infrastructure is documented to be at least > z15, all accesible system are actually z16. This means that z14 and older > will > stop being support in 2028. > > # How to see supported baseline > > The dynamic linker of glibc can show what microarchiture level it considers > 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 > glibc-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_linux/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. >
