Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #89777 > unrolled thread

Architecture baseline for Forky

Back to article view | Back to linux.debian.kernel

Contents

  Architecture baseline for Forky Bastian Blank <waldi@debian.org> - 2025-10-26 13:40 +0100
    Re: Architecture baseline for Forky John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> - 2025-10-26 14:20 +0100
      Re: Architecture baseline for Forky Bastian Blank <waldi@debian.org> - 2025-10-27 08:40 +0100
    Re: Architecture baseline for Forky Tony Rodriguez <unixpro1970@gmail.com> - 2025-10-26 19:40 +0100
      Re: Architecture baseline for Forky John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> - 2025-10-26 20:30 +0100
      Re: Architecture baseline for Forky Adrian Bunk <bunk@debian.org> - 2025-10-27 12:50 +0100
        Re: Architecture baseline for Forky Martin <debacle@debian.org> - 2025-10-27 18:10 +0100
        Re: Architecture baseline for Forky "Arnd Bergmann" <arnd@arndb.de> - 2025-10-27 22:40 +0100
          Re: Architecture baseline for Forky Adrian Bunk <bunk@debian.org> - 2025-10-29 09:00 +0100
            Re: Architecture baseline for Forky Peter Green <plugwash@debian.org> - 2025-10-30 07:00 +0100
              Re: Architecture baseline for Forky Peter Green <plugwash@debian.org> - 2025-10-30 10:10 +0100
                Re: Architecture baseline for Forky "Arnd Bergmann" <arnd@arndb.de> - 2025-10-30 10:10 +0100
            Re: Architecture baseline for Forky Adrian Bunk <bunk@debian.org> - 2025-10-30 15:30 +0100
      Re: Architecture baseline for Forky Rob Landley <rob@landley.net> - 2025-10-27 21:40 +0100
    Re: Architecture baseline for Forky Adrian Bunk <bunk@debian.org> - 2025-10-27 11:20 +0100
    Re: Architecture baseline for Forky Colin Watson <cjwatson@debian.org> - 2025-10-27 19:30 +0100
      Re: Architecture baseline for Forky "Nikos Tsipinakis" <nikos@tsipinakis.com> - 2025-10-30 14:40 +0100
    Re: Architecture baseline for Forky Milan Kupcevic <milan@debian.org> - 2025-10-27 22:40 +0100
      Re: Architecture baseline for Forky Bastian Blank <waldi@debian.org> - 2025-10-27 23:40 +0100
        Re: Architecture baseline for Forky Marc Haber <mh+debian-release@zugschlus.de> - 2025-10-28 10:10 +0100
      Planned obsolescence ? (was: Re: Architecture baseline for Forky) Romain Dolbeau <romain@dolbeau.org> - 2025-10-28 10:00 +0100
        Re: Planned obsolescence ? (OpenBSD) Paul Tagliamonte <paultag@debian.org> - 2025-11-02 23:30 +0100
        Re: Planned obsolescence ? (*BSD, Rust) David Starner <prosfilaes@gmail.com> - 2025-11-04 00:20 +0100
    Re: Architecture baseline for Forky Rob Landley <rob@landley.net> - 2025-12-05 00:20 +0100
    R: Re: Architecture baseline for Forky Federico Vaga <federico.vaga@vaga.pv.it> - 2026-09-07 09:20 +0200

Page 2 of 2 — ← Prev page 1 [2]

#89807 — Planned obsolescence ? (was: Re: Architecture baseline for Forky)

Le lun. 27 oct. 2025 à 22:58, Milan Kupcevic <milan@debian.org> 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

[toc] | [prev] | [next] | [standalone]

#89904 — Re: Planned obsolescence ? (OpenBSD)

[Multipart message — attachments visible in raw view] — view raw

On Sun, Nov 02, 2025 at 09:35:49PM +0000, jbranso@dismail.de wrote:
>OpenBSD has the express goal of supporting ancient hardware.

OpenBSD and Debian share many ideals. We both believe in a secure, open
baseline for humanity to stop making the same mistakes. There are some 
differences; Debian places a huge emphasis on end-user freedom in a way 
OpenBSD hasn't historically, which, fine. We also share many upstreams 
(at least within ports). We even have some shared developers.

Debian has no corperate entity -- it's only people, working together. We 
have a few nonprofits that sponsor Debian resources in a few countries, 
but none are "Debian". OpenBSD is in similar shape. I respect that.

I have a few OpenBSD boxes at home. I ensure my software I write ports 
cleanly to OpenBSD (not any of the others, FWIW). I enjoy OpenBSD a 
great deal. I find it nice to work with.

I'm very envious of OpenBSD's ability to break ABI between releases as 
part of the explicit contract. I like the security features (pledge and 
unveil are very nice things to have), and I really like the hard work 
that goes into the OS. I've sent a few (fairly minor and not very 
important) patches to misc@.

The idea that OpenBSD would continue to support an old CPU at the 
expense of a meaningful security change is an interesting take. I would 
expect the reaction there to be "fix the broken arch" not "refuse the 
security change", which, isn't far off from where my perspective here 
is. I find the view that OepnBSD supports old CPUs at great expense hard 
to square with things like[1]. There are no doubt active porters within 
OpenBSD, as there are within Debian.

There is disagreement between OpenBSD's view on Rust's cost/benefit with 
a stable, reviewed and maintained C codebase and most of the rest of the 
industry, (and within apt) -- but again, that's not important here.

I see no reason that this fairly obvious trolling has any weight here. 
If folks are interested in OpenBSD for what it does (very) well, they 
should use it, not because of an implementation language (what a hot 
take).

   paultag


[1]: https://www.openbsd.org/i386.html

     Due to the increased usage of OpenBSD/amd64, as well as the age and 
     practicality of most i386 hardware, only easy and critical security 
     fixes are backported to i386. The project has more important things to 
     focus on.

-- 
   ⢀⣴⠾⠻⢶⣦⠀               Paul Tagliamonte <paultag>
   ⣾⠁⢠⠒⠀⣿⡁  https://people.debian.org/~paultag | https://pault.ag/
   ⢿⡄⠘⠷⠚⠋        Debian, the universal operating system.
   ⠈⠳⣄⠀⠀  4096R / FEF2 EB20 16E6 A856 B98C  E820 2DCD 6B5D E858 ADF3

[toc] | [prev] | [next] | [standalone]

#89915 — Re: Planned obsolescence ? (*BSD, Rust)

On Mon, Nov 3, 2025 at 4:20 PM Jan-Daniel Kaplanski <jd.kaplanski@aol.de> wrote:
>
> > Yes, 20 year old hardware is looking ancient and retro.
> To specify, I was refering to x86-64-v1 hw when I said "reasonably large
> amount of users".

Which works just fine with Rust. It's strictly unhelpful to confound
the two issues.

> > There is no practical reason to use Linux on any of those [...]
> Except for homelabers, in enterprise environments (legacy software!) or
> lab environments (specialised hardware peripherals), etc.

In what cases would you use Linux on any of the four systems I
mentioned for legacy software or specialized hardware peripherals? As
for homelabers, yes, it's fun to make an old Mac run Linux/m68k, but
that doesn't mean it's practical.

> > a Pi 5 soundly beats any of those systems ever made
> And a Threadripper PRO 9995WX based system soundly beats any Pi 5. So
> going by your logic there isn't a practical reason to run Linux on a Pi
> 5, because there is a more capable system out there. That logic isn't
> very sound, yk?

No, a Threadripper PRO 9995WX is way more expensive than a Pi 5, it
draws way more power, it's way louder and takes way more space. You
will save the cost of the Raspberry Pi in a year on electrical costs
alone. There is no practical reason to run Linux on HPPA or Alpha or
SH4 or m68k.

> That only means that in the future you'd have to have a highly
> specialised Rust-dev team in any major OS-related project. And for what
> purpose? Just because everyone does it.

Is this just a grousing session?

-- 
The standard is written in English . If you have trouble understanding
a particular section, read it again and again and again . . . Sit up
straight. Eat your vegetables. Do not mumble. -- _Pascal_, ISO 7185
(1991)

[toc] | [prev] | [next] | [standalone]

#90363

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

[toc] | [prev] | [next] | [standalone]

#94026 — R: Re: Architecture baseline for Forky

Hello everyone,

Thank you, Adrian, for mentioning it. I'm the CERN engineer responsible for that migration. 

As of today, we should be covered by Trixie (LTS + ELTS). However, we would like to have the possibility of upgrading to Forky.

Having Forky support x86_64-v1 would give us a more modern system and a larger margin to both replace our x86_64-v1 hardware and cover the accelerator RUN (when beams will actually run).


Federico Vaga (CERN)

lunedì 7 settembre 2026 08:35, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> ha scritto:

> Hi,
> 
> On Sun, 2025-10-26 at 13:21 +0100, Bastian Blank wrote:
> > 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.
> 
> I'm very sorry to bring up this old thread again, but there is now a very
> good argument for keeping the baseline of the amd64 port at x86_64-v1, namely
> CERN.
> 
> They just started migrating their laboratory PCs away from RHEL to Debian
> because of the baseline switch in RHEL 9 and 10. They cannot just simply
> replace the hardware without making larger investments.
> 
> See: https://www.ictjournal.ch/articles/2026-09-04/pourquoi-le-cern-choisit-debian-plutot-quun-renouvellement-materiel-a-54
> 
> Adrian
> 
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer
> `. `'   Physicist
>   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
> 
> 

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.kernel

csiph-web