> That's perhaps because not many people have integrated Coda in an
> existing infrastructure, or they looked at how AFS gets integrated.
> Every infrastructure has it's own tweaks, there is no one way of
> deploying something. Common combinations are AFS/kerberos or NFS/NIS+,
> but there are always other choices such as LDAP, or X500, or simply rely
> on local-only /etc/passwd files.

I agree that installing _any_ kind of sharing system is complicated. I feel
that to achieve a wider usage of Coda:
-  O'Reilly should have books on using it. Well, at least one. Compare a
search for "Coda" at their site, with a search for "NFS".
- There should be a collection of "success stories" somewhere, because the
Documentation on the web site is mostly technical.
- I won't talk about the FAQ, you know how it is.
- The CODA howto should be referenced in the HOWTO-INDEX, see
<http://www.linuxdoc.org/HOWTO/HOWTO-INDEX/index.html>
- And if you write the ARCHITECTURE-HOWTO that generally explain how to
setup a sharing system, then the World will be thankfull because it's
really needed. Also, you will be in a good position to explain why/when/how
Coda is better than ASF, NFS and the like.

> What large chunk of diskspace?

2-300Mo. I guess i was being subjective in my use of the "Large" adjective.
That is just 20% of this Laptop model's hard drive.

> As far as the rationale for /coda is
> concerned, AFS, from which Coda stems has always used /afs.

This argument does not seem very strong to me.

> Also, many
> people use /mnt as a point to temporarily mount devices, and not
> subdirectories in /mnt. Now if we had /mnt/coda, surprise, the Coda tree
> disappears as soon as an unexpecting user mounts his CD.
>
> More reasons? When the mountpoint is arbitrary, someone might assume
> that Coda is like NFS, and tries to create Coda mountpoints everywhere.
> Now, /coda provides a common centralized access path to a large
> distributed filespace. It is always the same, whether your client is
> running Solaris, NetBSD, FreeBSD, Linux, etc.
> 
> Also, several client applications need an authenticated path to the
> cache manager (clog, ctokens, cfs), which happends to go through a
> control file in the mounted Coda FS. How are they going to known/find
> which mounted fs to use, and where it is mounted.
> 
> And then we have the subtle advertising, when someone does 'ls /', they
> see that the system has something interesting named "coda". That is
> ofcourse the real reason we're not using "/abracadabra" as the name of
> our mountpoint. 

 All this is convincing. Moreover, the FHS rationale against new root
subdirectories (it takes disk space on the partition and it may mess-up
administration of shares) are indeed very weak in this case.

 I think this should be pointed out to the FHS. Why not ask them to
provision /coda and /afs in their standard. While I volonteer to ask them
myself, I also realize Jan would have much more legitimacy.

Minh.