Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Having non-x86 machines makes your life harder

utcc.utoronto.ca

Post reply on HN
Print view View original

51–60 of 100 posts

Re: Having non-x86 machines makes your life harder

#51

Post by dezgeg »

yodsanklai wrote: post #28
blueflow wrote: post #4

Implied in this: The expectation to copy binaries between machines and having them work. Less of an issue if you compile from source.

I've never put much thought into this but given a "linux x86" binary package, on what range of machines is it supposed to work? for instance, what's x86 mean exactly? I suppose all x86 processors have slightly different sets of instruction. Also, different linux kernels may have different sets of syscalls?

At least for 32-bit x86 I've run into such problems. The Intel Quark platform has such an old CPU core in it that normal Ubuntu binaries wouldn't work on it (even at the the platform was relevant), as it lacks conditional move instructions unlike any other non-museum piece x86.

Also Glibc drops support for old kernel versions time to time, so even statically linked stuff isn't safe when compiling modern stuff against really old kernels.

Re: Having non-x86 machines makes your life harder

#52

Post by PlutoIsAPlanet »

dikei wrote: post #48
yodsanklai wrote: post #28

Earlier quoted context omitted.

I've never put much thought into this but given a "linux x86" binary package, on what range of machines is it supposed to work? for instance, what's x86 mean exactly? I suppose all x86 processors have slightly different sets of instruction. Also, different linux kernels may have different sets of syscalls?

Linux Kernel userland ABI/API is very stable, and backward compatible: you can take a binary compile for Linux 1.0 and run it today. The same applies for CPU instruction, backward compatibility means stuff targeting i686 instruction sets will run on today CPU. However, if you need more modern stuffs, then obviously you need a higher minimum version. For example, some software require SSE; or docker will only run on a…

The interface between the Kernel and Userland is stable.

The interface between Userland-Userland is not, very much not, a binary compiled a decade ago, unless its statically compiled or has no dependencies, will very likely not run, and is why things such as Flatpak and Docker partially exist in the first place.

Re: Having non-x86 machines makes your life harder

#53

Post by PlutoIsAPlanet »

mnd999 wrote: post #17
webmobdev wrote: post #7

It'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…

Epyc is also a SOC and that is both x86 and doesn’t seem to cause any issues.

I think they meant SBCs, which if they did they would have a point, work there to standardise outside the server space is very slow.

Re: Having non-x86 machines makes your life harder

#55

Post by dikei »

PlutoIsAPlanet wrote: post #52
dikei wrote: post #48

Earlier quoted context omitted.

Linux Kernel userland ABI/API is very stable, and backward compatible: you can take a binary compile for Linux 1.0 and run it today. The same applies for CPU instruction, backward compatibility means stuff targeting i686 instruction sets will run on today CPU. However, if you need more modern stuffs, then obviously you need a higher minimum version. For example, some software require SSE; or docker will only run on a…

The interface between the Kernel and Userland is stable. The interface between Userland-Userland is not, very much not, a binary compiled a decade ago, unless its statically compiled or has no dependencies, will very likely not run, and is why things such as Flatpak and Docker partially exist in the first place.

True, I was only talking about Kernel-Userland.

It's also why closed-source software often include every dependencies in their installation package. And even that is sometimes not enough, like when the host's glibc is too old.

Re: Having non-x86 machines makes your life harder

#56

Post by dezgeg »

dikei wrote: post #48
yodsanklai wrote: post #28

Earlier quoted context omitted.

I've never put much thought into this but given a "linux x86" binary package, on what range of machines is it supposed to work? for instance, what's x86 mean exactly? I suppose all x86 processors have slightly different sets of instruction. Also, different linux kernels may have different sets of syscalls?

Linux Kernel userland ABI/API is very stable, and backward compatible: you can take a binary compile for Linux 1.0 and run it today. The same applies for CPU instruction, backward compatibility means stuff targeting i686 instruction sets will run on today CPU. However, if you need more modern stuffs, then obviously you need a higher minimum version. For example, some software require SSE; or docker will only run on a…

Well, it's worth noting that Linux backward compatibility is not absolute guarantee, but rather "if feature is removed in a forest and nobody is around to hear it, then it's not a backward compatibility break".

Eg. for instance the removal of a.out support: https://lwn.net/Articles/888741/ - the a.out support was almost removed, until a single user happened to notice and object. But then someone came up with a workaround and that single (known) remaining a.out user changed his code, and the a.out support was deleted.

Re: Having non-x86 machines makes your life harder

#57

Post by jeroenhd »

tinus_hn wrote: post #26

The difference is not mainly about CPU architecture, it’s about the standardized PC architecture vs ARM computers where you need to build a new distribution for every model. You can easily build a kernel that will run on any PC built in the last decade and any PC that will be built in the next decade. But if you are using an ARM computer you have to run the patched kernel provided by the manufacturer.

That depends on the ARM machine you picked. There's an ARM UEFI standard, for example.

With postmarketOS a ton of Android devices can now also boot the mainline Linux kernel. Samsung certainly isn't helping anyone run modern Linux kernels on their devices, but my old tablet released with Linux 3.1 now runs Linux 6.2.

Getting the necessary kernels and software together isn't even all that difficult most of the time, the problem is that you need someone to set up an appropriate distribution. I could've gone completely compile-free if someone had sacrificed their cloud storage space to offer compiled installer ZIPs for me, because the software on the tablet now just comes from the Alpine repositories.

Re: Having non-x86 machines makes your life harder

#58

Post by andrewstuart »

I tried using Amazon ARM server instances running Postgres and they periodically locked up for reasons I could not determine.

So I waited a couple of years and tried again figuring they’d have got it worked out.

No dice.

Ever since then I’ve stuck with AMD64 for everything.

Re: Having non-x86 machines makes your life harder

#59

Post by jeroenhd »

andrewstuart wrote: post #58

I tried using Amazon ARM server instances running Postgres and they periodically locked up for reasons I could not determine. So I waited a couple of years and tried again figuring they’d have got it worked out. No dice. Ever since then I’ve stuck with AMD64 for everything.

My ARM server experience is similarly disappointing. Sometimes there's software that's just not available and setting up cross compilers sucks.

Running Docker containers on ARM feels like the Gentoo version of Docker. Sometimes you'll find an official image that will work, but most of the time you end up compiling images. In some cases, the base images need compiling too, so you end up with custom Docker bases that you now also need to keep track of in case they need to be updated.

There's no technical reason why it has to be this hard, but if you're mostly running other people's software, everything is just so very suboptimal.

Luckily, Apple's macbooks are now bringing consumer ARM to developers in a way that makes sense. I think there's a direct link between the M1 coming out and the sudden increase in aarch64 Docker images.

There are still major pain points with ARM but the experience is getting better.

Post reply on HN