(I've removed PSARC from this for now.)
On 03/19/10 04:26 PM, johansen at sun.com wrote:
>
> I don't have a problem with ksh93 or the builtins, nor am I advocating
> an entirely GNU userland. What I am suggesting, however, is that the
> folks who decided to put /usr/gnu in the default path did talk to our
> customers, and also took note of the fact that Linux is widely adoped
> across the industry.
>
We have more flexibility with the ksh93 builtins. IMO, the ksh93 tools
are much more closely aligned to our needs and long term goals ...
largely because they are concerned with some really key items where the
GNU folks are not:
1) compatibility with non-Linux systems
2) POSIX conformance
3) performance on all systems, not just Linux
4) support for compilation systems (and hence optimization) other
than GCC (this ties into #3)
I realize that not all the GNU tools fail all of the above points, but a
non-trivial number of them fail to consider all three of them.
Additionally, because the ksh93 team works with us, we have the ability
to provide input into them, which benefits both our team and ksh93. I'm
not at all convinced that anyone associated with the GNU tools gives a
nickel about what the users of Solaris want, never mind what Oracle wants.
By making GNUs tools part of "default" (or "premiere") tool set we
effectively hand control over the user environment to the GNU folks, who
if anything have a vested interest in *not* supporting our needs.
For example, what about support for extended attributes? Can
/usr/gnu/bin/cp handle them?
Architecturally, given that we *do* have a suitable alternative
available to us, I'd rather not see us leave ourselves hostage to the
compatibility concerns of GNU folks.
Of course, we can still ship /usr/gnu, and let users/admins who really
want GNU versions of tools (and not just a generally familiar
experience) still have that choice. Without being architecturally
hostage to GNU.
This whole discussion at the moment has wandered pretty far from the
original case though, except in so far as this case exists largely to
satisfy performance concerns coming from the /usr/gnu -- and there would
be little motivation to solve that if /usr/gnu was not part of the
default user environment.
I really do think that the way this was handled in OpenSolaris -- which
occurred without any significant ARC discussion of the concerns
surrounding this -- is unfortunate. I am half tempted to bring forward
a case to change this if only to cause the conversation (that I think
didn't happen) to occur.
- Garrett
