4 ms·

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?

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.

jayd16 5y ago
>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.
- yjftsjthsd-h 5y ago
  How would binary blobs work on a different architecture regardless of endian-ness?
  - zdw 5y ago
    htonl and ntohl would like a word.
    - yjftsjthsd-h 5y ago
      You mean https://linux.die.net/man/3/htonl https://linux.die.net/man/3/htonl ? What does that have to do with executing binaries on another architecture?
      - nonesuchluck 5y ago
        Binary doesn't imply executable. A NumPy array is a binary blob.
  - klodolph 5y ago
    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.
spijdar 5y ago
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.
- ronsor 5y ago
  > 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.
userbinator 5y ago
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 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.)
stkdump 5y ago
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.

jayd16 5y ago

>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.

yjftsjthsd-h 5y ago
How would binary blobs work on a different architecture regardless of endian-ness?
- zdw 5y ago
  htonl and ntohl would like a word.
  - yjftsjthsd-h 5y ago
    You mean https://linux.die.net/man/3/htonl https://linux.die.net/man/3/htonl ? What does that have to do with executing binaries on another architecture?
    - nonesuchluck 5y ago
      Binary doesn't imply executable. A NumPy array is a binary blob.
- klodolph 5y ago
  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.

spijdar 5y ago

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.

ronsor 5y ago
> 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.

userbinator 5y ago

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 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.)

stkdump 5y ago

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.