Hacker News Reader

Comment by rwmj | Hacker News Reader

I wonder if anyone using Linux regularly ran it on a PPC 601?

Because as a former owner of an Itanium[1] I can say that even when a processor is "officially supported" upstream, unless a critical mass of people actually use it there are lots of weird regressions. Debian/ia64 at the time (2015) only partially worked - lots of common utilities would randomly segfault or fail in peculiar ways.

[1] https://rwmj.wordpress.com/2014/09/08/raise-the-itanic/ https://rwmj.wordpress.com/2015/05/03/raise-the-itanic-part-...

View on HN

> unless a critical mass of people actually use it there are lots of weird regressions.

Even 32-bit x86 has been having some of those weird regressions these past few years.

Can you provide links to any of those weird regressions?

I don't have anything specific, but until Fedora stopped compiling a i686 kernel altogether a few years ago we had to disable our tests of "does the current kernel boot on qemu" for years on i686 because those kernels simply didn't work. And no one really cared. And no one cared again when Fedora dropped i686 (except for multilib on x86-64) entirely.

The kernel people can say one thing, userland people can say another.

"It compiles, it runs! No smoke tests. libc is busted? oh well, patches welcome!"

I made the same comment above about the kernel. How covered by automated tests is glibc?

> Debian/ia64 at the time (2015) only partially worked - lots of common utilities would randomly segfault or fail in peculiar ways.

It works reasonably well these days, albeit not perfect.

There are issues with kernels >= 4.15 on larger NUMA systems, but otherwise it runs mostly fine.

Images can be found here:

> https://cdimage.debian.org/cdimage/ports/

Yeah...I tried to run 68k Linux for a while (quite some time ago, to be fair) and got to "Nope" pretty quick. Your 'critical mass' observation is absolutely spot on: Open Source is about the 'number of eyes on the code', and it turns out you clearly need a certain number of eyes for it to work in the long run.

How covered by automated tests is the kernel? Some tests would require hardware emulators to some degree, but a lot wouldn't.

Last time I submitted a kernel patch which added some new user-visible API:

  $ grep Umask /proc/self/status
  Umask: 0002

I had to also submit a test to go along with it. I understand that these are run by CI on the main architectures, although it didn't appear to be a condition of accepting the patch that the test was correct on all arches. Also I wonder if their CI really runs on PPC601 and IA64, I guess probably not. (Obviously this minor feature doesn't depend on the arch and it's hard to see how it could go wrong even on IA64).

Reply on news.ycombinator.com