Having non-x86 machines makes your life harder
utcc.utoronto.ca
Having non-x86 machines makes your life harder
1–10 of 100 posts
Re: Having non-x86 machines makes your life harder
#2I ran sparc32/64 suns and vaxen under BSD derived os just fine. Symbolic expansion of $arch in nfs mounted filestores to maintain a local/bin path.. no biggie
Sorry I'm not sure I buy this line of reasoning.
Re: Having non-x86 machines makes your life harder
#3This doesn't say anything meaningful. It just states some obvious things with some sort of implied value judgement with no information about how it's supposed to be bad, aside from the author's lack of experience. "you'll almost certainly wind up with a mixed setup". So what? It's not bad just because you say it is if you don't say why it's supposedly bad.
It's also factually incorrect:
"If you try to share things across architectures, you'll get to find all of the ways that modern systems aren't really set up for that, partly because it's been decades since most environments really tried to do this."
What? Did the author give even ONE example? No.
It has never been the case that environments haven't tried to do this. Ever hear of the Internet? It has every architecture you can imagine. If you support 32 bit and 64 bit x86, you're already "sharing things across architectures" because of how different they are.
Re: Having non-x86 machines makes your life harder
#4Implied in this: The expectation to copy binaries between machines and having them work.
Less of an issue if you compile from source.
Re: Having non-x86 machines makes your life harder
#5Implied in this: The expectation to copy binaries between machines and having them work. Less of an issue if you compile from source.
Compiling from source is easier said than done for many big open source projects. In practice, they compile only with specific versions of GCC, CMake and libc.
Re: Having non-x86 machines makes your life harder
#6Lots of people it's using OpenBSD on macppc with light usage. Even playing some games such as OpenTTD.
Also, software like Luakit has been working fine, and on videoconferencing... once you have USB 2.0 UVC webcams, FFMPEG and drivers working, FLOSS conferencing software (lots of them) will work the same.
Re: Having non-x86 machines makes your life harder
#7It's a simple statement of fact, but it does need to be pointed out when ARM or RISC is often hyped. Many forget that that most non-x86's are system-on-chips, with very different components on them to make each a unique hardware platform on its own for system developers (and thus a huge pain in the butt) compared to the more "standardised" x86-64 hardware available from Intel and AMD.
I fear that unless some kind of standardisation is introduced for SoCs, we are looking at a very fragmented future for non-x86-64 platforms.
Re: Having non-x86 machines makes your life harder
#8The author is confused. The points they make are not about x86 vs. non-x86, they're instead about mixing different architectures. Yes, if you write a program and deploy it on three machines, and they all have different pointer sizes, endianness, and executable formats (PE, ELF, etc.) then, yes that can suck.
If this article was written 10 years ago, more people would probably agree. But nowadays, its perfectly possible to have a setup where all your machines, from large servers, to laptops, to small embedded devices, are x86, or aarch64, or something like that, and no mixed architecture is present. There are other, possibly more glaring, issues with sharing software across very different setups: Memory requirements, assumptions about filesystem layout, assumptions about syscalls/capabilities, assumptions about security. The architecture is usually at most a cli switch in your build pipeline, all this other stuff isn't.
That said, if you use Rust, Zig, Java, C++ (with Zig C++, for example), C (with Zig CC), building N different binaries for different targets is a bash script with exactly N lines of code. Not sure that's all that hard.
> where [...] people haven't tried their software, software has architecture specific bugs
I have to agree with this, just from the projects I've been part of, reviewed and used in the past. This is not an ARM issue, its an issue of laziness. People are inherently lazy, and they will only build and test on what is convenient. x86 machine at home, x86 ci/cd server, ... guess what isn't being tested on? Non-x86. That said, there are not that many things that can go wrong on non-x86 in my experience. They're usually little endian, they usually have 32 or 64 bit pointers, sizes, etc., and if they don't, they're likely not magical either.
People who still write C code, but also don't know that they can't just use `char`, `int` and `long` to mean 8, 32, and 64 bit, are the only population that will have issues here. Sadly, that's a lot of people in my experience.
The real issue is everything else, like I said above (fs layout, security, assumptions about OS specific behavior, ...)
Re: Having non-x86 machines makes your life harder
#9I ran sparc32/64 suns and vaxen under BSD derived os just fine. Symbolic expansion of $arch in nfs mounted filestores to maintain a local/bin path.. no biggie Sorry I'm not sure I buy this line of reasoning.
There's something to be said about why those architectures, plus many others, died in favor of an x86 monoculture.
Re: Having non-x86 machines makes your life harder
#10Implied in this: The expectation to copy binaries between machines and having them work. Less of an issue if you compile from source.
Compiling from source is easier said than done for many big open source projects. In practice, they compile only with specific versions of GCC, CMake and libc.
Robustness of the build process should be part of the quality assessment.