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.

Ensuring a code base indefinitely supports arbitrary architectures carries a substantial code architecture cost. Furthermore, it is difficult to guarantee testing going forward or that the toolchains available for those architectures will continue to evolve with your code base. I'm old enough to have lived this reality back when it was common. It sucked hard. I've also written a lot of code that was portable to some very weird silicon so I know what that entails. It goes far beyond endian-ness, that is just one aspect of silicon portability.

The expectation that people should volunteer their time for low ROI unpleasantness that has a high risk of being unmaintainable in the near future is unreasonable. There are many other facets of the code base where that time may be better invested. That's not "anti-portable", it is recognition of the potential cost to a large base of existing users when you take it on. The Pareto Principle applies here.

Today, I explicitly only support two architectures: 64-bit x86 and ARM (little-endian). It is wonderful that we have arrived at the point where this is a completely viable proposition. In most cases the cost of supporting marginal users on rare architectures in the year 2026 is not worth it. The computing world is far, far less fragmented than it used to be.

> It is usually easy to write code that is endian-safe. Any code that is not endian-safe is poorly written and harder to maintain at best, and possibly obscuring security bugs at worst. Any project maintainer should be jumping for joy when they receive a patch adding a big-endian port of their project, especially if it includes reports that tests pass and the software works. That is the sign of a codebase that has a level of sanity that should not be noteworthy, yet is.

And every single sentence is false.

The tower collapses once you remove any of the bases, let alone all of them.

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.

Someone who has a computer that my software can't run on isn't in my community. If they really want to use the software, they have the option of: 1) get a different computer, or 2) maintain their own custom-special port of my software forever.

In other words, they have to JOIN the community if the want the BENEFITS of the community. It's not my job to extend my community to encompass every possible use case and hardware platform.

If hex editors were mirrored both left to right and right to left, would it be easier to read little endian dumps?

This is just so fundamentally wrong that it makes the whole rest of TFA highly suspect (and yes, most of the rest of it is also pretty wrong).

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.

The author betrays their own point with the anecdote about 586 support: they had tests, the tests passed, but the emulator was buggy, masking the issue. Frankly, if you're the Linux kernel and nobody has the hardware to run the tests on an actual device, it says a lot. But it also shows that qemu is struggling to make it work if the emulation isn't working as it should. How is someone who runs a small project supposed to debug a BE issue when you might have to debug the emulator when a user report comes in?

For me, I'll always welcome folks engaging with my work. But I'll be hesitant to take on maintenance of anything that takes my attention away from delivering value to the overwhelming majority of my users, especially if the value of the effort disappears over time (e.g., because nobody is making those CPUs anymore).

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.

The article touches on the 32/64 bit split. A lot of the code I write nowadays doesn't run on 32 bit systems, not because it uses a lot of RAM, but because having an actually usable 64-bit address range enables you to write programs that you couldn't on 32 bit.

If you want to write code that works on big endian systems, systems where pointers aren't integers or bytes aren't 8 bits, all the power to you. I'm happy to pretend big endian is not a thing and focus my limited manpower on the hardware that my program will run on.

Obviously the author was trying to just give a quick example to aid visualization, but here's some nitpicking: I can probably come up with at least IV writing systems used by humans that don't use "big endian" for numbers. Or either, really.

Examples: Tally marks, Ancient Egyptian numerals, Hebrew and Attic numerals, and obviously Roman numerals.

Also lots languages in written form order words somewhat... randomly (French, Danish, old English, ...).

https://commandcenter.blogspot.com/2012/04/byte-order-fallac...