The /org name space

The problem

Unix is plagued by a problem. A problem that used to be a mere nuisance, but one that has now become such a hindrance that it is slowing down the whole software industry. I am speaking of identification of software: software packages, components within those packages, and files within components.

A typical scenario

Johnny likes to write programs. He creates the command $HOME/bin/ack. Later it gets adopted site wide and continues life as /usr/local/bin/ack, along with a configuration file /usr/local/etc/ack.conf. Next, any combination of the following may happen.

  1. An operating system integrator starts distributing the command as /usr/bin/ack.
  2. Johnny loses interest. His friend, Nick, continues with an incompatible version called nack (for “new ack”).
  3. nack becomes really successful, causing the GNU project to ‘start their copiers’ and create /usr/bin/gnack. gnack is upward compatible with nack, but due to its many new command line options including one that allows the user to check for new mail, gnack is not backward compatible with nack.
  4. An OS integrator likes to keep all GNU wares in a special place, so they distribute it as /usr/gnu/bin/gnack.
  5. Another OS integrator thinks a GNU specific bin is enough, hence /usr/bin/gnu/gnack.
  6. Yet another OS integrator has developed an “alternatives” mechanism. In their systems /usr/bin/nack is really gnack.
  7. New users just out of school don't know the history and think all nacks can read mail.
  8. There is a version fork. Freddie's new faster version of nack is called fnack.
  9. Over time fnack becomes standard and some OS integrators start adding the symlink nack -> fnack.
  10. Johnny becomes interested again and decides to continue where he left off with his original ack. Only now there's a problem: when nack was introduced, Nick continued to support the old name for the configuration file (“ack.conf”), with Freddie following suite, and now it is incompatible with Johnny's original.

And so on, ad infinitum, ad nauseam. The Unix name space has become a mess! (Frankly, I am not sure it has ever been anything else.)

Fixes that have made the problem worse

This problem is of course well known, and various solutions have been presented:

  • /opt and /etc/opt
  • /var/opt
  • /package/[admin|data|mail|map|math|misc|net|prog|web]/
  • ... and several others ...

These ideas have received some support because people would really like for the problem to go away. But they have not received very much support because these ideas all have flaws in them (often very bad design flaws). So, however well-meaning, these half-baked “solutions” have unfortunately ended up compounding on the problem.

The ultimate solution

Fortunately, this problem has now been addressed once and for all. The solution is the /org name space.

Simply stated, everything not part of the core operating system gets installed under

/org/vendortag/

where vendortag is a developer specific, unambiguous, perpetually valid moniker.

This is not just for executable commands, but for all installed files. The developer controls the name space under /org/vendortag/, but in a typical case it might have subdirectories such as:

/org/vendortag/bin/
/org/vendortag/lib/
/org/vendortag/doc/

Benefits of /org

A system can continue to maintain a systemwide /usr/bin, which simply contains symlinks to the desired versions of the commands of interest. But, now a script or component that depends on the quirks of a specific version can reliably and unambiguously refer to it through /org/vendortag/bin/.

/org helps in cross-platform interoperability. Example: the GNU version of ls is located as /org/gnu/bin/ls no matter what the platform. Or, to return to our hypothetical scenario from above, the various commands could have had these pathnames:

    /org/johnnysoft/bin/ack
    /org/nicksbits/bin/ack
    /org/hackerfreddie/bin/ack
    /org/gnu/bin/ack

Of course, Freddie could have still named his version fnack and GNU could have named theirs gnack, say, for trademark reasons. The /org name space eliminates unintended naming collisions no matter how developers choose to name their files.

Why it matters to UnixObjects

UnixObjects brings the Unix name space problem to the surface because for the UO concepts of dynamic inheritance, shared objects and prototypes to work at all, objects need to have unambiguous permanent identity.

For this reason, UnixObjects makes it a mandatory requirement that all UO components in their entirety shall install under /org/vendortag/.