4 ms·

In addition to this, even if this eventually leads to actual hardware, it will be based on a dead architecture. The PowerPC e6500 supports big endian ppc64, whi

by DCKing 6y ago

In addition to this, even if this eventually leads to actual hardware, it will be based on a dead architecture. The PowerPC e6500 supports big endian ppc64, which is unfortunately a dead end. Since 2014 and the launch of POWER8, all Power development has gone towards little endian ppc64le. There will not be any ppc64 big endian only hardware. Running ppc64 Linux in 2020 (on e.g. a G5 Mac) can be buggy affair due to lack of attention towards Power or even big endian systems in general. The QoriQ series is still the best choice for any Power-based laptop hardware mind you, it's just the state of affairs in Power that a 2013 chip aimed at network equipment is the best you can do.

gnufx 6y ago
What sort of problems are there specifically with current GNU/Linux distributions on big-endian systems? Fedora/RHEL, SUSE, and Debian are all supported on s390x, though doubtless many packages aren't very relevant on it. It was long ago that I ran SPARC Debian without issue that I remember, but it does seem still to be active. I'm sure there is some badly-written stuff with issues, but I have the impression they're not widespread.
- spijdar 6y ago
  The most prominent problem you'll run into on BE systems is the lack of support of graphics cards post 2008-ish, and even cards that are supported tend to be very buggy. You can essentially say goodbye to 3D acceleration and hw video decoding, while ppc64le has good support up to the newest Radeon cards, and Nouveau works ... as good as it does on x86, anyway. Package wise, you're also in a pretty miserable state. It's "usable", but even getting Firefox to compile on BE is a pain, and it's still a buggy experience. Firefox and Chromium build on LE systems, and with IBM's V8 port and patches to use Altivec and GPU acceleration, Chromium is very nice on LE. Beyond those, more packages are broken on BE. As a practical example, there's the PPC void linux fork at https://repo.voidlinux-ppc.org/stats.html https://repo.voidlinux-ppc.org/stats.html . Many applications do built, but there are a few blockers like the lack of Go support and lack of Haskell support, which trickles down into other packages (e.g. pandoc doesn't build on BE because lack of haskell). Neither docker nor podman work on BE. Packages that do build are sometimes broken on BE as well. The more complex a program, the more likely it's subtly broken. Basically, it's usable, but it's an extreme downgrade from LE, and requires being a lot more forgiving of your system. Enthusiasts using G5s are fine with it, but building a new system that's only BE capable would sting for eager customers receiving their inevitably pricey laptop only to discover a large number of prominent linux applications aren't available and the system is riddled with endianness bugs. Depending on what you use your computer for, you might not run into any problems, but you've got pretty serious problems across the "gaming, web browsing, productivity, devops" spectrum.
  - gnufx 6y ago
    I actually meant the bit about "even big endian systems in general." I know of things missing on BE ppc64 from EPEL6 packaging. (There's a significant number of things of interest to me missing on ppc64le, but desktop stuff isn't the interest there.)
    - DCKing 6y ago
      What I've seen most is issues with drivers. Even AMD, whose open GPU drivers make/made the planned included supplier of GPUs for this notebook have said that you're on your own on big endian systems. If you use the PCI Express slots on your 2005 Power Mac G5 to add a modern-ish (<12 years) AMD GPU to your big endian ppc64 system, it will give you a picture alright but 3D effects sometimes get corrupted and the hardware video decoder flat out does not work. The AMD driver simply implicitly assumes their platform is little endian in many places. And that's not really a surprise. The only big endian system available to mere mortals that can fit an AMD GPU is a noisy, heavy, oversized metal box from 2005 you need to get off of Craigslist. Even the Raptor desktops default option is ppc64le. Most hardware developers never need to worry or care about big endian hardware, as none of their users use POWER, SPARC, S390X or something even more obscure. This driver case is where AMD has made an explicit statement (though you'll have to forgive me from backing that up, can't find it anymore). In other cases it can be hard to differentiate between regular software bugs and endianness specific bugs.

by DCKing 6y ago

gnufx 6y ago

What sort of problems are there specifically with current GNU/Linux distributions on big-endian systems? Fedora/RHEL, SUSE, and Debian are all supported on s390x, though doubtless many packages aren't very relevant on it. It was long ago that I ran SPARC Debian without issue that I remember, but it does seem still to be active. I'm sure there is some badly-written stuff with issues, but I have the impression they're not widespread.

spijdar 6y ago
The most prominent problem you'll run into on BE systems is the lack of support of graphics cards post 2008-ish, and even cards that are supported tend to be very buggy. You can essentially say goodbye to 3D acceleration and hw video decoding, while ppc64le has good support up to the newest Radeon cards, and Nouveau works ... as good as it does on x86, anyway. Package wise, you're also in a pretty miserable state. It's "usable", but even getting Firefox to compile on BE is a pain, and it's still a buggy experience. Firefox and Chromium build on LE systems, and with IBM's V8 port and patches to use Altivec and GPU acceleration, Chromium is very nice on LE. Beyond those, more packages are broken on BE. As a practical example, there's the PPC void linux fork at https://repo.voidlinux-ppc.org/stats.html https://repo.voidlinux-ppc.org/stats.html . Many applications do built, but there are a few blockers like the lack of Go support and lack of Haskell support, which trickles down into other packages (e.g. pandoc doesn't build on BE because lack of haskell). Neither docker nor podman work on BE. Packages that do build are sometimes broken on BE as well. The more complex a program, the more likely it's subtly broken. Basically, it's usable, but it's an extreme downgrade from LE, and requires being a lot more forgiving of your system. Enthusiasts using G5s are fine with it, but building a new system that's only BE capable would sting for eager customers receiving their inevitably pricey laptop only to discover a large number of prominent linux applications aren't available and the system is riddled with endianness bugs. Depending on what you use your computer for, you might not run into any problems, but you've got pretty serious problems across the "gaming, web browsing, productivity, devops" spectrum.
- gnufx 6y ago
  I actually meant the bit about "even big endian systems in general." I know of things missing on BE ppc64 from EPEL6 packaging. (There's a significant number of things of interest to me missing on ppc64le, but desktop stuff isn't the interest there.)
  - DCKing 6y ago
    What I've seen most is issues with drivers. Even AMD, whose open GPU drivers make/made the planned included supplier of GPUs for this notebook have said that you're on your own on big endian systems. If you use the PCI Express slots on your 2005 Power Mac G5 to add a modern-ish (<12 years) AMD GPU to your big endian ppc64 system, it will give you a picture alright but 3D effects sometimes get corrupted and the hardware video decoder flat out does not work. The AMD driver simply implicitly assumes their platform is little endian in many places. And that's not really a surprise. The only big endian system available to mere mortals that can fit an AMD GPU is a noisy, heavy, oversized metal box from 2005 you need to get off of Craigslist. Even the Raptor desktops default option is ppc64le. Most hardware developers never need to worry or care about big endian hardware, as none of their users use POWER, SPARC, S390X or something even more obscure. This driver case is where AMD has made an explicit statement (though you'll have to forgive me from backing that up, can't find it anymore). In other cases it can be hard to differentiate between regular software bugs and endianness specific bugs.