4 ms·

This 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 t

This 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 ago
You 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 ago
    You 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).
- aragilar 3y ago
  I doubt this is related to the OS, more likely user home directories (e.g. people installing conda for x86 would run into issues running on arm), or shared software outside the standard OS setup.
- johnklos 3y ago
  As someone who runs many architectures, I do know what it means. I wasn't aware of the author's experience because Chris didn't offer any details, but that link does offer some clues. The reality is that there have always been ways to have multiple architectures supported simultaneously, and they're neither all that complicated nor kludgy, unless one has to support poorly written software. Even back in the m68k -> SPARC transition, people had clean ways to keep things separate and clean, and to support the same homes and binaries across both architectures simultaneously. We had the PowerPC to x86 transition show us how it can be done so cleanly that many people had no idea what architecture they were running. The same can be said about the x86 to ARM transition with Apple now. (Open)VMS explicitly supports multiple simultaneous architectures. We have ways of making fat binaries for other OSes, too - we had them back then, and we have them right now. We also have examples of doing it wrong: Microsoft Windows. The idea that people had to know and choose whether they want a 32 bit or 64 bit OS is still incredibly stupid, as is needing to choose 32 bit or 64 bit software. If people are writing binary files in endian specific ways, or with data sizes that depend on the specific processor, that's shitty programming. Any software doing that never had any sort of portability in mind, so that's not a good example at all. That kind of software is chided in public in the open source world, or at very least people know to isolate it and run it where it's safe. Sharing a user's home across multiple systems, perhaps with different architectures, isn't to save disk space, by the way. Expecting users to manage data and configurations across multiple machines isn't reasonable. Shared homes is still both normal and common in larger environments. If the author disagrees, it'd be nice to hear some actual examples of why it's a problem. After all, ARM isn't going away and RISC-V is only going to become more common.

phrenicfraud 3y ago

[flagged]

JdeBP 3y ago

You 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 ago
  You 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).
aragilar 3y ago
I doubt this is related to the OS, more likely user home directories (e.g. people installing conda for x86 would run into issues running on arm), or shared software outside the standard OS setup.
johnklos 3y ago
As someone who runs many architectures, I do know what it means. I wasn't aware of the author's experience because Chris didn't offer any details, but that link does offer some clues. The reality is that there have always been ways to have multiple architectures supported simultaneously, and they're neither all that complicated nor kludgy, unless one has to support poorly written software. Even back in the m68k -> SPARC transition, people had clean ways to keep things separate and clean, and to support the same homes and binaries across both architectures simultaneously. We had the PowerPC to x86 transition show us how it can be done so cleanly that many people had no idea what architecture they were running. The same can be said about the x86 to ARM transition with Apple now. (Open)VMS explicitly supports multiple simultaneous architectures. We have ways of making fat binaries for other OSes, too - we had them back then, and we have them right now. We also have examples of doing it wrong: Microsoft Windows. The idea that people had to know and choose whether they want a 32 bit or 64 bit OS is still incredibly stupid, as is needing to choose 32 bit or 64 bit software. If people are writing binary files in endian specific ways, or with data sizes that depend on the specific processor, that's shitty programming. Any software doing that never had any sort of portability in mind, so that's not a good example at all. That kind of software is chided in public in the open source world, or at very least people know to isolate it and run it where it's safe. Sharing a user's home across multiple systems, perhaps with different architectures, isn't to save disk space, by the way. Expecting users to manage data and configurations across multiple machines isn't reasonable. Shared homes is still both normal and common in larger environments. If the author disagrees, it'd be nice to hear some actual examples of why it's a problem. After all, ARM isn't going away and RISC-V is only going to become more common.