4 ms·
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
by 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.