Hello Burt,

> Then I started up venus.  I was able to cd to both directories 
> /coda/192.168.0.154 and also to /coda/laptop.

it is not supposed to work "correctly" - to access the same objects from
the same client via different paths. Use just one, any of them should do.

> steps I need to take so that I can create a symbolic link such that:
> 
> /coda/l -> /coda/192.168.0.154

Sorry, it looks like you are thinking in the wrong direction.
If you want to have shortcuts, use symlinks in your home directory...

Objects under /coda are meant to be global, i.e. have the same name
all over the world.

Manual creation of objects in /coda would inevitably collide with someone
else...  I'd create /coda/l containing my favourite "ls" clone runnable on
z800 processors... :) and somebody else would make it a directory instead...

You have got your realm, which you have the administrative power on,
put your objects there... Then you are guaranteed that on any Coda installation
in the world your files will be where they are, at the same paths.

Of course, as your whole realm is on a private net, you can feel like
you are the world - you administer the whole net.
Then set up a dns record "l 192.168.0.154" and you are done.

Do not be confused by the existence of "realms" file - it is a workaround,
convenient when we cannot use dns - but otherwise the realm names are
nothing client-specific, they are truly global. It is ensured by
the dns infrastructure. That's why I can access my environment being
on the other side of the globe, without asking the host administrator
to edit "realms" file properly...

It differs radically from the AFS shortcoming which enforces client
configuration to be able to reach a certain AFS cell, and a special
authority which would coordinate the cell names so that they do not collide.

> thereby giving me a very small amount of typing and a very short prompt, 

I'd rather solve the "short prompt" with some magic that substitutes
/coda/your.realm.dns.name/ say with MYCODA/ in your prompt.
I think bash has suitable hooks for that...
Otherwise it is just a limitation of the environment which can not cope
with long paths. Unfortunately, for lots of different data you need long
paths anyway - and it happens when you go global.

See it like ip v4 and v6 - surely it is convenient with short addresses,
but they do not suffice...

> rather than having things stretch out on the terminal window.  Currently I 
> have no non zero size CodaRoot volume that allows me to do that, and "ln 
> -s ..." gives me an error.  I am asking about something that was done 

It is the way it should and can be, without opening a big can of worms.

> extensively at IBM when they used AFS and had many cells.  For example, 
> the cell
> 
> /afs/lair.raleigh.ibm.com
> 
> was abbreviated with a link:
> 
> /afs/lair -> /afs/lair.raleigh.ibm.com

Come to Chalmers and find a host with AFS installed.
You either do not see your home /afs/lair/something at all or,
say, discover that it points to /afs/lair.chalmers.se/.... :)

Then you can no longer transparently use your AFS files, even if
you set HOME=/afs/lair.raleigh.ibm.com/something
as all paths are different compared to what the programs believed
when you were at IBM.
(as an example, Mozilla becomes unusable)

> My question is, with enough 
> time and energy and work put into the complex CODA system -- can it be 
> made to be as user friendly as the simple NFS like systems? Or is that a 
> misguided wish.

You can not compare a complicated system to a simple one.
"User friendliness" of NFS is a lot due to its limitations.
(no authentication to the filesystem, trusting all of the clients
and the network, no replication, no mobility)

Depending on the kind of problems you are going to solve, Coda can be
an overkill. For simple things use simple tools like NFS.

Besides that, Coda tools (say conflict resolution ones) are far from
being intuitive.

On the other side, if Coda properties suit your users' needs, then
they probably will be happy - given a lot of care and education,
and certainly a lot of your time helping them when something goes wrong.

> Burt Silverman

Good luck,
--
Ivan