10 ms·
Having non-x86 machines makes your life harder
- ggm 3y agoI 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.
- CrLf 3y agoThere's something to be said about why those architectures, plus many others, died in favor of an x86 monoculture.
- neilalexander 3y agoMany of those reasons nothing to do with technical merit, I might add.
- krger 3y ago> There's something to be said about why those architectures, plus many others, died in favor of an x86 monoculture. I think that has a lot more to do with the economics around Linux, Windows, and macOS on commodity amd64 hardware becoming “good enough” to replace servers and workstations running on other, more expensive, architectures. Not having to deal with architecture porting issues is just gravy at that point.
- johnklos 3y agoThis 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.
- phrenicfraud 3y ago[flagged]
- JdeBP 3y agoYou appear not to know what is meant by sharing across architectures here. Chris Siebenmann dates from the times when system administrators would do things like have most of the operating system executables and read-only data files remote-mounted from fileservers. We'd worry about such things as instruction set architectures and bitnessess and endinannesses of non-text file formats. We'd have "architecture-dependent" and "architecture-independent" exports. We'd take care when replacing executable scripts with compiled binaries. And yes, it has been decades since this was a norm. DASDs have long since become big and cheap enough that just having copies of all of the files locally has long overtaken the idea of having the operating system partly on a remote fileserver that had the limited money spent on it for the really big DASDs. Microsoft originally had DOS+Windows with a shareable "system" directory and a per-machine "windows" directory. Modern Windows doesn't even incorporate such an idea, not least because many things came along that put per-machine stuff in the "system" directory. Modern Unices and Linux-based operating systems similarly don't normalize the idea of remote-mounted /usr/share and whatnot as Unices did decades ago. * https://utcc.utoronto.ca/~cks/space/blog/unix/FadingMultiArchUnixSetups https://utcc.utoronto.ca/~cks/space/blog/unix/FadingMultiArc...
- danaris 3y ago> And yes, it has been decades since this was a norm. ...So why is it relevant? Sharing files between systems with different architectures Just Works these days, unless you start getting into the really esoteric. "Having non-x86 machines is Bad, now, today, because of problems I had with managing multiple-architecture deployments 30 years ago" is not a useful statement in any way.
- aragilar 3y agoYou can use QEMU to do automatic emulation, but I suspect that's not common. Likely, the binaries are not from the OS, but from users/for users which run on different machines (and more likely than not NFS mounted across the systems to ensure consistency).
- blueflow 3y agoImplied in this: The expectation to copy binaries between machines and having them work. Less of an issue if you compile from source.
- K0balt 3y agoWhich assumes all software you are using is open source, which would be great….
- ptspts 3y agoCompiling 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.
- blueflow 3y agoRobustness of the build process should be part of the quality assessment.
- arp242 3y agoYou don't always have 6 different projects to choose from because there just aren't that many projects that solve $problem according to your specific $requirements. And it's also just a hassle even with good build systems, and I say this as someone who has a bunch of custom build scripts to compile stuff from source.
- gjvc 3y agoquite often, this is a major indicator of how quality is valued in an organisation. Whether we are talking about open-source or not, there has to be a commitment to excellence at all levels of the product, as would be expected in any other real-world manufacturing.
- redeeman 3y agocan you provide a few examples? this is something I dont see at all
- 3y ago
- anthk 3y agoLots 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.
- arp242 3y agoIt's not that it doesn't work at all, but it is more effort. Even though I spent more time tinkering with lots of stuff than most (and probably still do), at least having the "Just Works™" option is nice.
- webmobdev 3y agoIt'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.
- mnd999 3y agoEpyc is also a SOC and that is both x86 and doesn’t seem to cause any issues.
- PlutoIsAPlanet 3y agoI think they meant SBCs, which if they did they would have a point, work there to standardise outside the server space is very slow.
- webmobdev 3y agoA good example of what I am saying can be seen with Apple Silicon SoCs todays - since details of some of the components in it are unavailable, system developers are being forced to reverse-engineer it to port other OSes on it. Imagine the effort to do that for 100's or 1000's of SoCs, each of which can have their own unique, custom component (with closed documentation) in it?
- webmobdev 3y agoWhat I meant was that Intel and AMD take the pain to be more open about their SoCs than other ARM manufacturers, and ensure there aren't 100's of them. Both are more developer friendly than others who often deliberately choose the ARM SoC's mainly to ensure they can exert control over system developers - by ensuring that details of the component hardware are only available on closed licenses or sometimes not even made available to the public at all.
- lionkor 3y agoThe 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, ...)
- secretsatan 3y agoNo developing anything for mobile then
- user6723 3y ago[flagged]
- tux2bsd 3y ago[dead]
- tinus_hn 3y agoEven though the blog appears to be by someone who doesn’t have much of a clue, this is gatekeeping. Just like in the Unix world of old before the rise of open source, many system administrators never compile any binary. And that is fine.
- notmypenguin 3y agoIt’s not gatekeeping in any sense. Technical skills are required to do technical jobs, and this person asked for any criticism or feedback given by posting a public blog that has, for some bizarre reason, gotten to the front page of hacker news. Wtf. Technical incompetence must be addressed head first, or we risk real world problems
- DaiPlusPlus 3y ago> Technical incompetence must be addressed head first, or we risk real world problems Given there's always been a chronic shortage of qualified and experienced technical staff, isn't the the "real" real-world problem here the raising of the barriers-to-entry for sysadmins jobs? I think most companies would rather employ someone who can at-least try to get something done rather than having no-one at all. One of the reasons why "the cloud" is so popular among businesses today is because it frees them up from having to run their own systems and infrastructure (who needs a *nix sysadmin when the AWS and Azure portals let you do everything through a GUI?) - whereas I'm sure many (most?) of those same businesses would honestly prefer retaining possession and sovereignty over their data and applications (especiallly latency-sensitive stuff) - and we all lament how the cloud giveth and the cloud taketh-away - but here we are.
- tinus_hn 3y ago
- deleted 3y ago[deleted]
- tinus_hn 3y agoThe 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.
- jeroenhd 3y agoThat 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.
- tinus_hn 3y agoIt’s much better than PC, there’s many more standards to chose from! /s > 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 Guess what? On PC there’s a ton of people who have set up a distribution and they are all appropriate for all PCs. That makes it a whole lot easier to find such a person for your PC.
- moondev 3y agoThis works the same way for arm64 "system ready" uefi hardware https://cdimage.ubuntu.com/daily-live/current/mantic-desktop-arm64.iso https://cdimage.ubuntu.com/daily-live/current/mantic-desktop...
- 3y ago
- wazoox 3y ago"Picking the right binary for the right architecture", isn't your OS package manager supposed to take care of that? Cross-compiling is often pretty easy if you have custom binaries. There is a big advantage to using different OSes/architectures with the same programs (compiled to target the right combination of hardware and OS) : it often helps detect subtle bugs, that may not manifest on one platform but be obvious on the next.
- drpixie 3y agoI run a handful of little servers, some x86, some ARM. I've had none of the issues that the author raises. Sounds a little like the old Linux v Windows or the PC v Mac debate - lots of fuss and really comes down to personal preferences.
- irusensei 3y agoFor a while I was running a mixed k3s server for fun and curiosity. Most popular images are manifests pointing to -$arch containers that gets selected automatically. It's also fairly trivial to build them yourself either with 2 machines or qemu. I've stopped using it but multi arch is definitely not the reason. Biggest problem is that 60% of my punny machines resources were being used to keep Longhorn synced - and the constant high usage resource kicking the fans up started to irritate me. But the cluster worked really well regardless of what node the software was running.
- avidphantasm 3y agoThere’s an argument to be made that if you want a more robust computing environment, you want more diversity of architecture and OS, not less. Does this take more effort? Possibly. Is that worth it? It depends.
- miga 3y agoVoice against innovation!!! Without architecture diversity, he wants to limit innovation, and promote a monopoly. x86 is anything but an open source standard, due to patents, and thus cannot be easily standardized. So he also voices against open standards.
- yjftsjthsd-h 3y agoWell, it's a duopoly; both Intel and AMD make modern x86 processors.
- rabite 3y agoHaving non-x86 machines has actually made my life a lot easier -- most common exploits don't have the proper offsets and simply don't work. Before you call me lazy for not patching, there are a lot of vendors that have very long patch times. If you have an environment that is mission critical, you would be well advised to not use x86 at all in the server environment. My entire income is based on cryptocurrency, so if I get owned it would result in large uninsurable losses.
- ketzu 3y agoI find it hard to disagree with this post, because the points are so broad, and the claim ("makes your life harder") is so low stakes. Most comments I read on here seem to interpret it as a form of "impossible." Sure you might not have some of those problems if you compile from source for all machines, but that is definitely harder than having pre-compiled options. Especially if you have to maintain many machines (which is mostly implied in the post, but also explicitly mentioned here and there). Hosting and maintaining a custom package repository for your self-compiled binaries so you don't have to do it on every single machine manually (maybe compiling everything from scratch might take days or the machine couldn't do it on its own anyways) is also obviously making your life harder. My personal small scale experience, developing a small service on my laptop and running it on my local pi for testing, already ran into many of the problems. Some packages I wanted to use didn't exist, some containers I used locally weren't available for ARM. Are those unsolvable, or even hard, problems? No. But! They are time sinks that make a very simple thing more complex, more brittle and more annoying, than if I just used a homogeneous x86 setup, even if I were a skilled sysadmin (which I am not) or enjoyed fixing those differences and maintaining the fixes (which I do not).
- andrewstuart 3y agoI 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.
- jeroenhd 3y agoMy 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.
- markus_zhang 3y ago[flagged]
- xiphias2 3y agoSwitching to M1 MacBook Pro (ARM) from an intel machine with Windows 10 made my life so much easier. I miss the games, but everything else just works. My tablet and phone is ARM as well, and I'm not considering switching them to intel either.
- Woeps 3y agoBut is that a intel/ARM thing? or a Windows/MAC thing? Would Windows on ARM also have a "everything else just works" benefit?
- misterio7 3y agoI have a mix of x86_64 and aarch64 machines and, damn, NixOS makes it so freaking easy. Most of nixpkgs works on both architectures. You can even use your machines as remote builders and/or use binfmt to transparently run/build stuff through qemu. When I was helping out a friend with his free oracle aarch64 server, I got baffled on how ARM feels like a second class citizen on most distros.