Re: [9fans] Man pages for add-ons

[Ethan Grammatikidis <eekee57@fastmail.fm>]

On 26 Mar 2010, at 21:32, erik quanstrom wrote:

>> Oh, yeah, lets all learn about namespaces and the counterintuitive
>> things they do and don't do, and compiling and everything to do when
>> it goes wrong, and a billion other things JUST to save devs having to
>> work out a good solution!
>
> mmm.  i don't know of any counterintuative things
> that namespaces do.  do you have an example?
> further, you're going to have to know how namespaces
> work to use plan 9 interactively or as a developer.

I wish I could put my finger on a specific example. Coming from Linux  
I really struggled to understand how name spaces and file servers  
worked together for some time. One day it just clicked, and I think it  
was well worth learning, but compiling stuff isn't in the same class,  
it's a means to an end and more of a chore. I take the perspective  
that computers should reduce chores as much as they possibly can. ;)

>
> i think the valid — and deep — question here is how
> complicated a namespace one wishes to construct.
> i see practical limits to how many entries a human can
> understand.  the machine of course, doesn't care.

Indeed, and a limit which varies from person to person, hence why I'm  
fighting namespace growth. ;) You could say I'm trading one complexity  
for another: arguing for growing system directories instead. I find a  
good package manager helps a great deal with the filesystem. When you  
can query to find which package a file comes from, then query on the  
package name to find the docs, config files, executables, anything you  
want by filename and then some, that's quite a help with organising.

You know... /opt style might not be so bad after all. It may make the  
namespace a long list, but it would be a list which could very easily  
be grepped for package name and I'm sure quite a simple script could  
find which package a file in the 'bound tree' is really in.

-- 
Simplicity does not precede complexity, but follows it.
  -- Alan Perlis