Hi,
On the issue of /usr/sfw.. the problem for users and companies alike is that
you don't see /usr/sfw on any other UNIX or UNIX-like system. It's not
something people would even think of looking at, unless they took the time to
explore.
However, to suggest that /usr/bin, /usr/sbin, /sbin, /bin, /usr/X*/bin, etc.
are somehow outdated is a bit unfounded. Users, sys-admins, and developers
alike are familiar with these directories on other platforms, so they are very
relevant. The biggest compliant I've seen in large shops about S10 is how all
the *desktop* stuff has been dumped into /usr/bin, specifically Gnome. As a
result, many shops un-install these components to *clean* things up and then
wonder why things are broken when they try to login to Gnome.
And there are plenty of shops that go install things like the blastwave
packages to give everyone the choice of things like a newer version of Gnome,
KDE, xfce, etc. Does it make sense to put Gnome in /usr/bin for customers who
want the flexibility to install or roll their own?
The real problem that's coming out of this is.. who is our target audience? Are
we trying to cater to the Linux crowd? Realistically, we'll probably never
convert them as a whole to Solaris. Just as you can't expect every Windows user
to switch to Mac OS X. But those who do make the switch do so because it's
different and because it provides value. The goal here should be to provide
real differentiating value. Solaris has stood out in the sense that it embraces
standards at the API and ABI level. We should build upon that, not emulate
another OS just to be the *same*.
Overall, I think we can agree there are definitely some out-dated components,
conventions, and directories in Solaris. Perhaps things like /usr/games,
/usr/sfw, or /usr/sadm don't make a lot of sense. However, there are items that
exist for compatibility, standards, and compliance. We supply personalities..
/usr/gnu, /usr/xpg4, /usr/xpg6, /usr/ucb. Why? To give customers choice.
Users know that they have to change their $PATH to get the desired result. To
assume that customers at some level don't understand the use of $PATH, is a bit
short sighted and perhaps even insulting. There will always be a user that
needs help with things like this, but that is why sys-admins and application
owners (web admins, db admins, etc.) are employed.
Now, does that mean we shouldn't bother making it easier for users? Of course
not. But, I am deeply concerned that we may take things to the extreme and
ultimately make /usr/bin a nightmare for both users, sys-admins, and developers
alike. I'd hate for users to complain that there's "too much stuff" in /usr/bin
and that they can't *find* the command they're looking for. This only leads to
users requesting the amount of stuff to be cut back.. which means extra cycles
spent by sys-admins creating a scaled down OS install. Not my idea of fun!
If we're trying to make Gnome better, then perhaps we need to make better $PATH
statements in the login session that users inherit? Perhaps we need to include
more of the GUI tools in the Gnome menus. I don't see dhcpmgr, printmgr, or smc
in the Gnome menus for example. And the menus are not dependent upon $PATH.
Wouldn't it be easier to have better default $PATH statements? The concept that
was mentioned earlier of having an AUTOPATH was interesting.
Another way to look at this is.. when customers install something like Oracle
or Weblogic for example.. they don't install it into /usr/bin. Why is that? If
we were to apply the logic of throwing everything into /usr/bin to make life
easier, shouldn't those binaries go into /usr/bin? The answer is simple. It is
generally accepted that /usr/bin contains OS tools and commands, not 3rd party
apps or non-OS related items. Directories and paths are used to separate tools,
apps, data, etc. just in the same way that humans have organized everything
from libraries and filing cabinets to cities and governments. To not separate
things in some logical manner is counter intuitive. The mind seeks
organization:)
We are in this quandary because we are including more components into Solaris
that are not really related to the core OS functionality and need some way of
making it easier for users to find those items.
When users login from the command line, we have standard methods for setting
things like $PATH, for example /etc/profile. When users log into CDE or Gnome,
there is a multitude of shell variables that are set automatically. If we
leveraged these tools, is there a real need for having everything in /usr/bin??
So where do we draw the line? How do we determine what should go into /usr/bin
vs. /usr/sbin or /usr/<app>/<version>/bin? Kinda brings us back to what I had
suggested earlier..
1. If an app is to go into /usr/bin, it must meet these requirements:
- It is not an administrative command that requires privs. If so, it may have
to go into /usr/sbin.
- Its name does not conflict with a standard command already located in /usr/bin
-It does not conflict with the default Solaris behavior. If so, it should be
located in the appropriate/usr/<behavior> name space, (/usr/gnu, /usr/ucb,
/usr/xpg4, /usr/xpg6).
- It does not require the support of multiple versions.
-It is not a large suite of software (i.e. X11, Gnome, CDE, OpenWindows,
Postgres,MySQL, Apache, Sun Cluster, etc.).If so, it should be located
in/usr/<app name>/<version>/ directory.
2. If an app is to be sym-linked into /usr/bin, it must meet these requirements:
-It must be appropriate for general consumption by users and otherapplications
(i.e. mv, ls , pgrep, soffice, firefox, gcc, cc)
- Itis part of a larger suite of software, located in /usr/<appname>/<version>,
that is appropriate for general consumptionby users and other applications
(i.e. StarOffice, Gnome applications,Firefox, gcc, cc, perl, java). This does
not include application leveladministrative/priv binaries (i.e. Xsun, httpd,
scinstall, gdm, xdm).
- The latest version is sym-linked without a version number. For example,
/usr/bin/java would link to java 6, and /usr/bin/java1.5 would link to java 1.5.
This would lead to things like:
/usr/gnome/<version>
/usr/kde/<version>
/usr/apache/<version>
/usr/mysql/<version>
/usr/postgres/<version>
/usr/JES/<version>
/usr/webmin/<version>
etc.
Of course, this could lead to a larger /usr. For example, it would be silly to
separate out the JES software since all the components are part of a larger
suite. So there is possibility for some consolidation.
This seems like a more reasonable approach when combined with proper $PATH and
shell environmental variables. The concept of having auto-discovery is
interesting. Perhaps something like /etc/auto{path, man, lib, etc.} would make
sense. That way when software is installed, it updates those configuration
files. If someone wants to use those variables, they can set a variable, like
"export AUTODISCOVERY=true" in their profile. Perhaps make it the default or a
GUI option in Gnome?
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Octave J. Orgeron
Solaris Systems Engineer
http://www.opensolaris.org/os/community/sysadmin/
http://unixconsole.blogspot.com
unixconsole at yahoo.com
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
----- Original Message ----
From: Bart Smaalders <bart.smaald...@sun.com>
To: Garrett D'Amore <gdamore at sun.com>
Cc: Danek Duvall <Danek.Duvall at sun.com>; Octave Orgeron <unixconsole at
yahoo.com>; Shawn Walker <swalker at opensolaris.org>; PSARC-ext at sun.com;
Joseph Kowalski <jek3 at sun.com>
Sent: Monday, March 10, 2008 12:04:32 PM
Subject: Re: Nethack 3.4.3 [PSARC/2008/172 FastTrack timeout 03/11/2008]
Garrett D'Amore wrote:
> There's another performance aspect though. Searching through
> directories is proportional to the number of entires in it.
If you're using UFS. On ZFS, no.
> One could
> argue that the most frequently accessed stuff should be in /usr/bin, and
> other, less frequently accessed stuff, could live in directories that
> appeared later in the search path, or were more easily pruned from
> user's paths.
Given that the next release of Solaris will use ZFS as it's root filesystem,
any arguments about lookup performance are moot. (They're moot on
UFS, too, of course, because of the DNLC.)
-There is no good reason to place commands in multiple existing directories.
There is REALLY no good reason to propose new directories.
Using directory location as an indexing method for software makes
no sense, because the user and system admin cost is so high when
someone decides to add a new directory - every Solaris user around the
world would need his/her path variables changed to see the new software.
Ask around and find out how many people never discovered that gcc
was present on every S10 full install in /usr/sfw.
If you want better indexing and information on available commands,
fine. Build better docs, help tools, etc - _don't_ try to implement
this via
adding more directories in the user's path.
- Bart
--
Bart Smaalders Solaris Kernel Performance
barts at cyber.eng.sun.com http://blogs.sun.com/barts
"You will contribute more with mercurial than with thunderbird."
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
