/u, one of our long-standing Unix customizations
One of Unix's small problems is that it has no simple and universal way
to refer to people's home directories, especially other people's home
directories. Some people are about to pipe up about
~user, but that's
not a universal way; support for it has to be added to every program
that will use it (and in every context where they resolve file names),
and inevitably there are programs where it is not supported at all or is
not supported everywhere. Beyond that, it's the wrong solution for the
same reason that handling globbing in each program instead of in shells
is the wrong solution.
(You can see how non-universal
~user is these days by trying it in
various graphical file open dialogs. And in fact there are places where
~user support simply cannot be added, such as
#! lines in shell
scripts; no Unix kernel is ever going to support '
If you want a universal solution to a problem related to filenames and paths in Unix, there is only one way you can do it: you have to put something in the filesystem, because that's the only common thing used by absolutely every program that uses files. And you want to put it in the filesystem because this instantly makes it accessible to everything that uses files, which on a Unix system is a lot of things.
(This is the same core idea behind
/proc and so on, and behind Plan 9
sticking everything in the filesystem. The filesystem is the common Unix
namespace, so if you want to expose something widely, you put it in the
So our solution to this problem is to have a directory called
which is set up so that
/u/<user> gives you the user's real home
directory regardless of just where it is. Our implementation uses
symlinks because that's the simple approach for us, but you could
equally well use the automounter. The name
/u is picked partly because
it is short and partly because it is relatively memorable.
Having a real
/u directory turns out to have a host of practical
benefits, just as you'd expect on a Unix system. Here's a couple.
First, it is truly universal; in anything that refers to files, in any
context, you now have convenient short way of referring to anyone's home
directory, yours included. You no longer have to worry about whether
a particular program supports
$HOME; you just use
(And yes, this includes
#! lines in shell scripts, so you can have
scripts that do '
#!/u/cks/bin/python3' if you need to.)
Second, we've wound up rewriting user home directories in
to use this form, because doing so persuades any number of programs to
embed this form in their automatically created user configuration files,
which in turn means that they no longer throw a spanner if we move a
user from one filesystem to another (Firefox used to be infamous for
this). Arguably any program doing this is buggy, but we're pragmatists;
doing this eliminates the bug for any program that is not excessively
(Excessively clever programs will try to determine the real path of the user's home directory, which can be done in our implementation.)
PS: if you are going to do this, it turns out to be convenient to do
this for all entries in
/etc/passwd (or at least all entries with real
home directories), not just the accounts of actual users.
Returning to the era of 'duplicated' Ethernet addresses
Once upon a time back in the old days, Sun caused quite a stir by deciding that they would make the Ethernet addresses for their hardware be an attribute of the machine, not of the network interface. Or to translate, Sun machines used the same Ethernet address on all of their interfaces instead of doing what everyone else did, which was to have a different Ethernet address on each interface. This is spec-legal but caused various sorts of annoyances for system administrators and network designers; among the set of people who care about this stuff at all, there were many who felt that Sun had made the wrong decision and life was just simpler when multi-homed machines had different MAC addresses on different interfaces.
Over time this became less important as Sun's servers became less popular, and today this particular bit of trivia is probably long forgotten in most places. Even Sun's x86 servers used per-interface Ethernet addresses (and for all I know, Sun gave up on this in the end on their SPARC machines too).
Well, guess what. Those days are back, courtesy of VLAN-aware hosts. Such a machine has only a single physical network interface with a single Ethernet address, but that single interface is used by multiple networks through VLAN tagging. Outgoing Ethernet frames on each VLAN generally have no choice but to use the physical interface's Ethernet address, and so the host will be seen as having the same Ethernet address on different VLAN networks.
(There might be a use for this in detecting whether a host is using VLANs or physically separate network interfaces, assuming that you even care.)
In short: Ethernet addresses are now back to being only unique on their particular network, not globally unique across your entire set of networks. Hopefully no switches will explode.
(However, you're less likely to run into problems with this than people were in the Sun era. Back then, problems ensued because there were legitimate situations where people wanted to connect two network interfaces from the same machine onto the same network and tell them apart.)