Re: Let's start a survey on our userbase
On Sun, 2025-09-21 at 19:30 +0200, Linux User #330250 wrote:
> On 2025-09-21 at 17:40 John Paul Adrian Glaubitz wrote:
> > On Sun, 2025-09-21 at 17:11 +0200, Linux User #330250 wrote:
> > > IMHO the biggest issue for POWER4 and PowerPC 970 (G5) is it's
> > > Endinanness. Most modern software no longer gets tested or Big Endian,
> > > and Power/PowerPC transisioned to Little Endian as well, so those old
> > > PPC machines were additionally left behind on this front.
> >
> > IBM's own Unix, AIX, still defaults to big-endian on POWER as far as I know and
> > on Linux, they're still default to big-endian on z-Series mainframes (s390x).
>
> That's great to hear! My personal experience is very limited, but I
> tried to setup Gentoo Linux on my G5 a couple of years back and had
> nothing but issues, mostly due to those machines being no longer well
> tested and used by the developers themselves. I don't blame them, this
> makes perfect sense.
Linux is still actively being tested on PowerPC 970 CPUs, even by the kernel
developers last time this came up. It's still a supported baseline and the
ppc64 port even with the POWER4 baseline successfully builds 95% of the
Debian distribution without any issues:
https://buildd.debian.org/stats/graph-ports-big.png
> Partly this was due to them not testing their code on Big Endian. And I
> do remember reading that at least Gentoo Linux recommended Little Endian
> on POWER machines that support it. (Newer POWER CPUs do.)
I don't think this has got anything to do with big-endian. As I said, the
toolchain is still officially supported on big-endian systems by IBM and
it's not going anywhere anytime soon.
> > So, despite what some people may think, support for big-endian targets is still
> > going to stay relevant. At least as long as IBM exists. I don't think they're
> > going to switch their high-end systems over to little-endian anytime soon.
>
> I'm guessing that there are adequately tested distributions, such as
> Debian. Thank you for keeping it alive so well!
Well, for one, Debian actually builds every package it ships and runs the
testsuites which already helps uncovering a lot of bugs. There are certainly
some packages like Firefox that have issues. But claiming the port is broken
would be really a stretch.
> > > Additionally, e.g. the PowerPC 74xx (G4) is left behind as it's 32-Bit only.
> >
> > I'm not sure what that's supposed to mean. Are we arguing that a 20-year-old
> > CPU can't compete with modern designs? Does anyone really question that?
>
> No, this is just what I also see on x86: 32-Bit dies out. Most modern
> distributions have discontinued support for IA-32. My assumption is that
> this will become more and more of a problem for PPC32 as well, when it
> comes to bumping versions or introducing new projects into the
> installation base.
Just because some developers think that 32-bit Linux has to die it doesn't
mean that this going to happen anytime soon. There is still a large userbase
for 32-bit embedded applications which are optimized for low power and there
is no gain for these to switch them to a 64-bit CPU and software stack.
If 32-bit was on the verge of dying, Debian and Canonical wouldn't have invested
the time and effort to support Linux on 32-bit targets beyond 2038 with the
time64_t transition.
> > > Could be that some software won't work because it expects SIMD
> > > extensions as well, but AFAIK at least for the G4/G5 AltiVec/VMX was
> > > never as well established as was SSE on x86.
> >
> > At least ffmpeg and VLC support AltiVec and I'm sure that compilers can optimize
> > certain code to use AltiVec extensions when even when the developers of a certain
> > software package did not explicitly add support for it.
>
> I also read somewhere -- don't remember where, don't remember when --
> that some of those AltiVec optimizations and (in my own words:)
> "accelerators" are often assembler based, and often get left behind
> until they no longer work for the progress of the rest of the code. So,
> very often those legacy "accelerators" become discontinued themselves,
> leaving no real optimization for those older CPUs, other than generic
> GCC compiler options for AltiVec.
Modern compilers are already extremely good at optimizing code such that they
use specific CPU extensions such that you often don't need handwritten assembly
for optimal performance.
I'm not saying that you won't gain any additional performance with hand-written
assembly. But to claim that code generated by modern C compilers isn't optimized
is as equally wrong.
> > Adrian
>
> Again, thank you for your great work! My Power Mac G5 is currently
> (still) collecting dust, and I still haven't gotten around to installing
> Debian on it. If the time comes, I will and I will try to use it for
> stuff, but I'm not sure how this will turn out. Gentoo has always been
> my favorite choice, as well as individual configuration has been. I'm
> looking for XFS, not ext4 as a file system for example, encrypted
> LUKS-LVM as the partitioning scheme, and for other modern stuff like
> e.g. zram and so forth. Not sure how this is supported/tested on G5s.
Why should this work on the G5 and why do you think that Debian doesn't
allow you to use these features? You don't have to build your whole system
from source just to switch the default filesystem or use an encrypted
partition ;-).
> When it's becoming more and more legacy software for the system, this is
> something I tend to get unhappy with... (as opposed to how Linux was
> handled in the past on the majority of systems I used, where I'd get
> modern software on old hardware no matter what...)
I don't actually understand what you're trying to say in this paragraph.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Reply to: