Hacker News Reader

Comment by johnklos | Hacker News Reader

Yeah! Let's not fix the software and the bad assumptions some programmers make - let's all just do what's simplest for the bad programmers. What could go wrong? ;)

Seriously, there's zero reason why endianness should matter in code. All good code compiles and runs on whatever endian system you want. If it doesn't, then it's buggy and broken and should be fixed, and whoever wrote it should be ashamed.

View on HN

I agree with this in principle, that good code should be endian neutral, but if the goal of the project is to produce something that's broadly useful as a "real laptop" then this is a serious concern, as a lot of software is either bugged or straight up broken on big endian.

Fixing all the broken software and making all of GNU/Linux bug-free is a noble cause, and one FOSS contributors all want I'm sure, but people who are interested should know just how much software is broken on BE. It's not a tiny handful of packages. It's not a ton either, FWIW, but the broken packages tend to be the larger, more complex application software that IMO your average end user will want, especially if you're marketing this laptop for general users and not specifically to programmers or others willing to compromise on software.

It's not an insurmountable challenge, especially 64-bit PPC which works okay in BE, as there are enough diehard PPC64 users keeping the patches flowing to keep it working. But some things will never work without incredible porting efforts, and some of the things that work have issues.

> if the goal of the project is to produce something that's broadly useful as a "real laptop" then this is a serious concern, as a lot of software is either bugged or straight up broken on big endian.

This is really my only concern. From a practical perspective, big endian would not work for a general purpose usable laptop. Perhaps if Apple had kept with the PPC architecture, software developers would have paid more attention.

There is zero reason why developers should even concern themself with BE these days. LE officially won, just as two's complement, UTF-8 and IEEE-754 won. Sure, most software could easily be agnostic and probably most software is. But unless tested you don't know for sure. And why would you? It has zero application.

>Seriously, there's zero reason why endianness should matter in code

How about wanting to share binary blobs between architectures without spending the effort to marshal things.

How would binary blobs work on a different architecture regardless of endian-ness?

htonl and ntohl would like a word.

You mean https://linux.die.net/man/3/htonl ? What does that have to do with executing binaries on another architecture?

Binary doesn't imply executable. A NumPy array is a binary blob.

Your binary blobs are structures with fixed-size primitives and a known layout, on ABIs with manageable structure packing rules:

    struct my_data {
        uint32_t x;
        uint16_t y;
    };

You can transmit data structures like this over the network with write(), if you want. You can say, “sizeof(my_data) == 8” and just refuse to support systems where this is not true. On the other end, you can

    obj.x = swap32(obj.x);
    obj.y = swap16(obj.y);

where necessary, or avoid the swap if both peers have the same endian. Keep in mind that this is illustrative. Not trying to describe the details of how you would design a system from a higher level.

Note that you’re not making any attempt to support all architectures, here. You can restrict yourself to byte-oriented architectures with the normal 8, 16, 32, and 64 bit integer types that have no stricter than natural alignment. That covers a useful, broad range of architectures. Depending on whether you care about architectures like M68k where uint32_t does not have natural alignment, you can manually pad out structures.

Big endian is backwards. Little endian is logical and should've been the only choice from the beginning.

https://news.ycombinator.com/item?id=9451284

The only real BE holdouts are networking hardware and mainframes.

(In LE, increasing offsets are increasing weight, just like the commonly accepted bit numbering. In BE, they're decreasing and length-dependent.)

Reply on news.ycombinator.com