Oh, that's excellent news! The more little endian, the better.

you must be the guy who thought of middle endian

I hear that middle endian is ideal endainness when implementing middle-out compression.

I think the kernel remains big endian. Only userspace has a brand new little-endian ABI.

Also, Net and Open BSDs support big endian PowerPC (NetBSD supports big endian arm even)

> NetBSD supports big endian arm even

AFAIK, this is probably the easiest way to test BE on hardware (if you need that for some reason) - NetBSD on a Raspberry Pi running in BE mode is easy to use. (EDIT: Actually the more important thing is that it's cheap and easy to acquire)

What's the reason someone would willingly choose to run a big endian ARM OS?

To use big endian on real-world systems. And one of the reasons to use big endian is because diversity helps to find bugs in code. A bug that might result in a hidden off-by-one on little endian might crash on big endian.

Wouldn't that only matter if the bug has no affect on little endian?

Otherwise you don't need the other endian to confirm it?

Or are you saying to test their software before it goes out to big endian devices, which doesn't answer the question as to why someone would want to use it on those end devices?

> Wouldn't that only matter if the bug has no affect on little endian?

I don't know whether this logic applies to this specific sort of bug, but there is a long history of bugs that "don't matter" combining with other bugs to become something that matters. Therac-25 was a bug that didn't matter on the hardware it was developed for, but then the software that "worked fine" got repurposed for another hardware platform and people died. If there's an easy way to identify an entire class of bugs it seems like a good idea to do it.