The fading out of multi-'architecture' Unix environments
When I started in the Unix world, it was relatively common to have overall Unix environments where you had multiple binary architectures and user home directories that were shared between machines with different architectures. Sometimes you had multiple architectures because you were in the process of an architecture transition from one Unix vendor (for example, from Motorola 68K based Sun 3s to SPARC based Sun 4s, with perhaps a SunOS version jump in the process). Sometimes you had multiple architectures because you'd bought systems from different vendors; perhaps you still had some old Vaxes that you were nursing along for one reason or another but all your new machines were from Sun.
All of this pushed both Unix systems and user home directories in a
certain direction, one where it was sensible to have both /usr/share
and /usr/lib
, or /csri/share
and /csri/lib
, the latter of which
was magically arranged to be a symlink to the right architecture for
your current machine. For user home directories, you needed to somehow
separate out personal binaries for architecture A from the same binaries
for architecture B; usually this was different directories and having
your .profile
adjust your $PATH
to reflect the current machine's
architecture.
Those days have been fading out for some time. People's Unix environments have become increasingly single-architecture over the years, especially as far as user home directories are concerned. Partly this is just that there is much less diversity of Unixes and Unix vendors, and partly this is because cross machine shared home directories have gone out of style in general (along with NFS). The last gasp of a multi-architecture environment here was when we were still running both 32-bit and 64-bit Linux machines with NFS-mounted user home directories, but we got rid of our last 32-bit Linux machines more than half a decade ago.
(We had Solaris and then OmniOS machines, and we still have OpenBSD ones, but neither are used by users or have shared home directories.)
A certain amount of modern software and systems still sort of believe
in a multi-architecture Unix environment, and so will do things
like automatically install compiled libraries with an architecture
dependent name (I was recently pleased to discover that Python's
pip
package installer does this). However, an increasing amount
doesn't unless you go out of your way. For example, both Rust's
cargo
and Go's go
command install their compiled binaries into
a fixed directory by default, which only works if your home directory
isn't shared between architectures. In practice, this is fine, or
at least fine enough that both projects have been doing this for
some time. And it's certainly more convenient to just have a
$HOME/go/bin
and a $HOME/.cargo/bin
than to have ones with
longer and more obscure names involving snippets like linux-x86_64
.
(By 'architecture' here I mean the overall ABI, which depends on both the machine architecture itself and the Unix you're running on it. In the old days there tended to be one Unix per architecture in practice, but these days there's only a few machine architectures left in common use, so a major point of ABI difference is which Unix you're using.)
|
|