Multi-Unix environments are less and less common now

October 21, 2017

For a long time, the Unix environments that I existed in had a lot of diversity. There was a diversity of versions of Unix and with them a diversity of architectures (and sometimes a single vendor had multiple architectures). This was most pronounced in a number of places here that used NFS heavily, where your $HOME could be shared between several different Unixes and architectures, but even with an unshared $HOME I did things like try to keep common dotfiles. And that era left its mark on Unix itself, for example in what is now the more or less standard split between /usr/share and /usr/lib and friends. Distinguishing between 'shared between architectures' and 'specific to a single architecture' only makes sense when you might have more than one in the same large-scale environment, and this is what /usr/share is about.

As you may have noticed, such Unix environments are increasingly uncommon now, for a number of reasons. For a start, the number of interesting computer architectures for Unix has shrunk dramatically; almost no one cares about anything other than 64-bit x86 now (although ARM is still waiting in the wings). This spills through to Unix versions, since generally all 64-bit x86 hardware will run your choice of Unix. The days when you might have bought a fire-breathing MIPS SMP server for compute work and got SGI Irix with it are long over.

(Buying either the cheapest Unix servers or the fastest affordable ones was one of the ways that multiple Unixes tended to show up around here, at least, because which Unix vendor was on top in either category tended to keep changing over the years.)

With no hardware to force you to pick some specific Unix, there's a strong motivation to standardize on one Unix that runs on all of your general-usage hardware, whatever that is. Even if you have a NFS-mounted $HOME, this means you only deal with one set of personal binaries and so on in a homogenous environment. Different versions of the same Unix count as a 'big difference' these days.

Beyond that, the fact is that Unixes are pretty similar from a user perspective these days. There once was a day when Unixes were very different, which meant that you might need to do a lot of work to deal with those differences. These days most Unixes feels more or less the same once you have your $PATH set up, partly because in many cases they're using the same shells and other programs (Bash, for example, as a user shell). The exceptions tend to make people grumpy and often to cause heartburn (and people avoid heartburn). The result may technically be a multi-Unix environment, but it doesn't feel like it and you might not really notice it.

(With all of this said, I'm sure that there are still multi-Unix environments out there, and some of them are probably still big. There's also the somewhat tricky issue of people who work with Macs as their developer machines and deploy to non-MacOS Unix servers. My impression as a distant bystander is that MacOS takes a fair amount of work to get set up with a productive and modern set of Unix tools, and you have to resort to some third party setup to do it; the result is inevitably a different feel than you get on a non-MacOS server.)

Written on 21 October 2017.
« Ext4, SSDs, and RAID stripe parameters
Understanding what our wireless password protects »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Oct 21 01:20:40 2017
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.