>> Also, I have a reason to keep the binaries seperate, directory bloat.
>> Have you actually taken count of how many binaries you would end up
>> with if you put them all in the same dir on a heavily used box?
>
>Yes, but this is best done based on function, not origin.  Put your X11
>stuff in one place (/X11/bin), your sysadmin-only stuff in another place
>(/sbin), and all your common user applications in yet another (/bin),
>and that's separation (more than) enough.

I agree to a point on this.  I would not mind at all if things were
seperated this way, but I would still want one more level of
seperation.  I would want to keep base system and admin installed
packages seperate (so you can have /bin /sbin /x11 and also have
/local/bin /local/sbin and /local/x11).  I still think you are
going to have to many files in one dir though.  That's just personal
prefrence.

>> I (for one) am happy with the /usr/bin, /usr/local/bin, /usr/X11/bin,
>> /usr/pkg/bin thing.  I have also not gotten one single complaint 
>> from any of the users of my systems, ever, since I provide them
>> with profiles that work with the system that had to do with the
>> location of files (naming, use of, version, that I have had complaints
>> on, but never location).
>
>That's not a fair comparision.  You need to expose those users to a set
>of systems where all the add-on stuff is equally well integrated into
>the system as the base tools are.  Then only after those users have had
>some experience on such a tightly integrated system can you fairly ask
>them for their opinion of having stuff arbitrarily scattered amongst
>/usr/bin, /usr/pkg/bin, /usr/local/bin, and so on.

Ok, I'll elaborate.  A job ago I ran a network with FreeBSD and
Linux systems.  The FreeBSD systems installed things in /usr/ports (I
think, I would have to revisit my notes on that - but I do remember
they went somewhere else) and the RedHat RPM system put everything
in /usr/bin with the rest of the OS (since the entire OS is installed
via the package system this can make sence for them.)

I did not have complaints from either group of users, not only were the
paths setup in the /etc files but also in the SKEL files pushed in to
the user dirs during user creation. 

Two side notes on that configuration. The majority of the users were
SysAds (in that group), though not all were UNIX SysAds. Also there
were complaints about the Solaris system we had (packagse installed
in /opt and /sw but not added to the users path :P)


(snip)
>their $PATH.  They also don't have to worry about fixing up their
>private scripts when they move them from a system where perl is in
>/usr/pkg/bin and one where it's in /usr/bin, etc.  I think a couple of
>them would even like to get rid of the sbin-bin separation, though
>that's mostly because they often use some sbin tools even when not su'ed
>to root which really only suggests those tools are mis-classified.

The Perl issue is one I am aware of, and it's part of my NetBSD
build steps to move that to perl.xxx and link in the pkg version of
perl. Not the best solution, but it has yet to fail me.

-Sean