Martin Man wrote:
Roland Mainz wrote:
My personal complaint is that they stuff everything into /usr/bin/. Unix
had some kind of namespace support via the elements in ${PATH} so
having package groups seperated into /usr/dt/bin/ (CDE), /usr/kde3/bin
(KDE3), /usr/xpg4/bin/ (XPG4 personality) and so on is a much cleaner
approach than stuffing everything into /usr/bin/.
Good package management (that is not present ATM in Solaris) will take
care of /usr/bin for you.
I disagree - while this may be a solution for an individual host used by one
individual only, it has a tendency to get out of control in multiuser
environments,
where different users have different requirements they need fulfilled.
The resulting installation can often be named overstuffed rather than
complete, especially if version and library conflicts had to be met.
A modular approach using different paths is often able to resolve these
conflicts but - as has been outlined by others in this thread, carries its own
potential for confusion and conflicts.
Martin Man wrote:
debian comes with alternatives mechanism that works pretty well in most
cases.
This alternatives mechanism in particular struck me as something I immediately
and strongly disliked, once that I had found out why those programs that
claimed
to be there were obviously not what they claimed to be.
It's a good thing that there are different programs for similar tasks, but it
should
be up to the user to decide which one to use. When I'm calling vi, I want vi,
not
vim or whatever claims to be like vi. Same goes for awk - each implementation
has quirks of its own, and my script might not take them all into account. And
even more for programs disabled for security concerns. Telnet may broadcast
passwords all over the net, but someone forgot to teach my terminal server ssl
when they made that image 15 odd years ago. (And yes, I want to keep my
terminal servers, and yes, I have taken other means to protect them).
If a program is disabled on a distribution, I want to know, not start debugging
when things are behaving weird. Command not found is one way of letting me
know.
My main point is that while it's confusing to have 40 (as claimed by Chris
Ricker)
odd versions of ps in 40 odd locations of the filesystem, it's even more
confusing
to be handed -I don't know which- program by means of alternatives.
Erast Benson wrote:
may I ask what is wrong with 1000+ programs in /usr/bin ? As far as
performance is concerned, this directory usually cached out. What else?
Most users (me included) lack the cache to properly digest 1000+ entries in
a directory visually.
/usr/bin gets listed rather often, when a user tries to guess the correct name
for a program he fails to remember. Unfortunately, without the name, manual
pages won't help him that much either. It's a problem that's more aggravating
to novice users than experienced ones, obviously.
Tatjana
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
