Kyle McDonald wrote: > Joseph Kowalski wrote: >> We want to start putting all user utilities with non-conflicting >> names into /usr/bin. > Why? Please NO! > > I know I'm just a lowly long time user of Solaris, but please don't > polute /usr/bin with this stuff. > > I've always hated the linux approach of throwing everything in one > place. What was it another post said 4000+ programins in /usr/bin? > Yuck! I found the includion of GNOME in /usr/bin to be a mistake, and > I think others who orignally thought is was ok now think so too. You can't make all the people happy all of the time.
Personally, I'm with you. I think PATH was a nice little invention. However, the push these days is that things should just work out of the box and it seems that PATH is too hard a concept for newbees. Go figure. I'd personally like to see a model where FOSS utilities were considered on their own merit. If they were truly useful, they should go into /usr/bin. If they are simply another way of doing something, they should go elsewhere. (Just how many c-beautifier programs do we need?) The only trouble with this approach is there always seems to be somebody with a vote who thinks some utility is "truly useful". This is all just pragmatism. If the project team wishes to enhance their specification along these lines, I'd be more than willing to listen. >> Death to sfw! We intend to make the stability commitment clear on >> the man pages >> (and not by PATH) - this is why all of these utilities are required >> to have a (perhaps >> tiny) man page - only a synopsis, attributes section and pointer to >> other documentation >> are required. > PATH is the solution to this. It's a good solution. The developers > that we are looking to attract to work on solaris should have no > problem understanding how to configure their path for their preferences. Let's not confuse "Death to sfw" with a better solution to the distribution of utilities. Inclusion in swf is based on interface instability, not FOSS source (although the two are related). This semantic is now widely viewed as inappropriate. Now that the case is derailed, I hope directory semantics are the focus of the discussion. - jek3
