On 27 Mar 2010, at 16:46, Tim Newsham wrote:
enough. We say we deal with it with namespaces, but the bindings on
a freshly-installed Plan 9 box already make a much longer list than
any $PATH I can imagine!
but you don't have a LD_LIBRARY_PATH, a MANPTH, or any number of
other search paths. Or symlinks. What is the total length of all
of your paths plus symlinks?
PATHs on my box (including MANPATH and INFOPATH) total 27 entries.
Symlinks, excluding libraries, Wine, and backups of old systems: 1,
for a total of 28. Wine has 17 symlinks but what I do with Wine could
almost as easily be done with a VM.
There are 42 binds and mounts in my Plan 9 VM's namespace, but several
seem to be no-ops (bind / /; bind /n /n), and it's a bit hard to
filter out both those and the hardware and system mounts from the
list. The number of functional dir-to-dir binds seems to be around 7.
I feel like I'm missing something. Adding the number of mounts on my
un*x box brings its total to 36, still lower than Plan 9's.
All this reminds me of one of my biggest gripes with unix, which may
be relevant to the discussion here. Both env vars and namespaces are
inherited, and while that's a strength it's also a weakness. I haven't
used Plan 9 enough to know if it's a problem for Plan 9, but using
Linux outside the wonderful world of desktop environments I would
regularly run into trouble because I'd have to change a variable,
whether $BROWSER or $PATH or whatever, and for it to take full effect
I'd have to log out & back in. I always have several things on the go
at once: typically a couple dozen web pages open; several files of one
sort or another; IRC and frequently another communication program;
mail; a calendar; often a music player; you get the picture. In such
an environment "re-logging" is a huge disruption.
Perhaps if namespace changes only require restarting the plumber it
wouldn't be bad, but there's still the matter of entering the binds at
least twice too; once in lib/profile (which you have to go and open)
and once per relevant terminal window.
--
Simplicity does not precede complexity, but follows it.
-- Alan Perlis