Endian wars and anti-portability: this again?
dalmatian.life
Endian wars and anti-portability: this again?
1–10 of 73 posts
Re: Endian wars and anti-portability: this again?
#2> In closing, let me reiterate this point so it is crystal clear. If you are a maintainer of a libre software project and you refuse a community port to another architecture, you are doing a huge disservice to your community and to your software’s overall quality. As the Linux kernel has demonstrated, you can accept new ports, and deprecate old ports, as community demands and interest waxes and wanes.
Every feature has a cost and port to a different architecture has a huge cost in ongoing maintenance and testing.
This is open source. The maintainer isn’t refusing a port. The maintainer is refusing to accept being a maintainer for that port.
A person is always free to fork the open source project and maintain the port themselves as a fork.
Re: Endian wars and anti-portability: this again?
#3> If the community is offering you a port to an architecture, whether it is 4 days old or 40 years old, that means the community actively wants to use your software on it – otherwise, nobody would put in the effort. Ports like this are hard, and authors like me already know we are fighting an uphill battle just trying to make upstream projects care.
I've had plenty of opensource contributions over the years for some feature or other I don't care about. I used to accept these pull requests. But all too often, the person who wrote the patch disappears. Then for years I receive bug reports about a feature I didn't write and I don't care about. What do I do with those reports? Ignore them? Fix the bugs myself? Bleh.
I don't publish opensource projects so I can be a volunteer maintainer, in perpetuity, for someone else's feature ideas.
If its a small change, or something I would have done myself eventually, then fine. But there is a very real maintenance burden that comes from maintaining support for weird features and rare computer architectures. As this article points out, you need to actively test on real hardware to make sure code doesn't rust. Unfortunately I don't have a pile of exotic computers around that I can use to test my software. And you need to test software constantly or there's a good chance you'll break something and not notice.
That said, is there an easy way to run software in "big endian" mode on any modern computer? I'd happily run my test suite in big endian mode if I could do so easily.
Re: Endian wars and anti-portability: this again?
#4> In closing, let me reiterate this point so it is crystal clear. If you are a maintainer of a libre software project and you refuse a community port to another architecture, you are doing a huge disservice to your community and to your software’s overall quality. As the Linux kernel has demonstrated, you can accept new ports, and deprecate old ports, as community demands and interest waxes and wanes. Every feature h…
Hmm, if the author of the port cares, why won't the author of the port become a maintainer of that port? This should be a two-way street.
Re: Endian wars and anti-portability: this again?
#5> If the community is offering you a port to an architecture, whether it is 4 days old or 40 years old, that means the community actively wants to use your software on it – otherwise, nobody would put in the effort. Ports like this are hard, and authors like me already know we are fighting an uphill battle just trying to make upstream projects care. I've had plenty of opensource contributions over the years for some…
> That said, is there an easy way to run software in "big endian" mode on any modern computer?
QEMU userspace emulation is usually the easiest for most "normal" programs IMO. Once you set it up you just run the other architecture binaries like normal binaries on your test system (with no need to emulate a full system). Very much the same concept as Prism/Rosetta on Windows/macOS for running x86 apps on ARM systems except it can be any target QEMU supports.
Re: Endian wars and anti-portability: this again?
#6> In closing, let me reiterate this point so it is crystal clear. If you are a maintainer of a libre software project and you refuse a community port to another architecture, you are doing a huge disservice to your community and to your software’s overall quality.
Linus Torvalds disagrees. Vehemently.
https://www.phoronix.com/news/Torvalds-No-RISC-V-BE
> For those who don’t know, endianness is simply how the computer stores numbers. Big endian systems store numbers the way us humans do: the largest number is written first.
Really, what's first? You're so keen on having the big end first, but when it comes to looking at memory, you look... starting at the little end of memory first??? What's up with that?
> I happen to prefer big endian systems in my own development life because they are easier for me to work with, especially reading crash dumps.
It always comes back to this. But that's not a good rationale for either the inconsistency of mixed-endianness where the least significant bit is zero but the most significant byte is zero, or true big endianness, where the least significant bit of a number might be a bit numbered 7 or numbered 15, or even 31 or 63, depending on what size integer it is.
> (Porting to different endianness can help catch obscure bugs.)
Yeah, I'm sure using 9 bit bytes would catch bugs, too, but nobody does that either.
Re: Endian wars and anti-portability: this again?
#7I don’t have an opinion either way on this authors belief around the port being accepted upstream or not.
I did however learn a lot googling some of the terms they dropped and finding out things like PowerPC architecture getting and update as recently as 2025.
Several of their references I knew from my first tech leads mentioning their own early career. I am surprised at how much still has active development.
Re: Endian wars and anti-portability: this again?
#8> In closing, let me reiterate this point so it is crystal clear. If you are a maintainer of a libre software project and you refuse a community port to another architecture, you are doing a huge disservice to your community and to your software’s overall quality. As the Linux kernel has demonstrated, you can accept new ports, and deprecate old ports, as community demands and interest waxes and wanes. Every feature h…
Hmm, if the author of the port cares, why won't the author of the port become a maintainer of that port? This should be a two-way street.
In my experience, as someone who has gone through this as maintainer of two decent sized projects, that simply doesn't work.
The author of the 'port' probably doesn't know your whole codebase like you, so they are going to need help to get their code polished and merged.
For endian issues, the bugs are often subtle and can occur in strange places (it's hard to grep for 'someone somewhere made an endian assumption'), so you often get dragged into debugging.
Now let's imagine we get everything working, CI set up, I make a PR which breaks the big-endian build. My options are:
1) Start fixing endian bugs myself -- I have other stuff to do!
2) Wait for my 'endian maintainer' to find and fix the bug -- might take weeks, they have other stuff to do!
3) Just disable the endian tests in CI, eventually someone will come complain, maybe a debian packager.
At the end of the day I have finite hours on this earth, and there are just so few big endian users -- I often think there are more packagers who want to make software work on their machine in a kind of 'pokemon-style gotta catch em all', than actual users.
Re: Endian wars and anti-portability: this again?
#9If you want to keep software working on systems with a 9-bit byte or other weirdness, that's entirely on you. No one else needs or wants the extra complexity. Little endian is logical and won, big endian is backwards and lost for good reason. (Look at how arbitrary precision arithmetic is implemented on a BE system; chances are it's effectively LE anyway.)
Re: Endian wars and anti-portability: this again?
#10> I happen to prefer big endian systems in my own development life because they are easier for me to work with, especially reading crash dumps.
If hex editors were mirrored both left to right and right to left, would it be easier to read little endian dumps?