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
