> In any event, meem's original point was not that someone needs to fix
> every one of these cases individually (obviously, they do need fixes),
> but instead the point is that as changes go, this *particular* one
> (changing /usr/bin/sleep) had a substantial blast radius.
Yes. I also have broader questions about where all of this is going.
Most would agree that our core UNIX toolchain is lagging behind other
UNIX-like systems in terms of feature set, completeness, and familiarity.
Further, most would agree that as a whole this is a notable dissatisfier
for OpenSolaris and thus that we need to address it.
Where things get murkier is how we go about doing that. Userland is not a
monolithic beast, and all the world is not (and will never be) ksh93. In
some cases, it may be best to leverage the ksh93/libshell implementations
of core commands. In other cases, it may be best to use other versions
from e.g. GNU or *BSD. In still other cases, it may be best to enhance
the ones that we already have (e.g., because the command interacts with
other core Solaris differentiators). In some cases, it may even be best
to write a new command from scratch. The best choice will depend on a
host of factors, such as the manner and context in which a command is
used, its complexity, its maturity, interdependencies with other
functionality, standards issues, and so forth.
In short, I'd expect us to have a simple technical strategy that plots the
path for various commands based on the issues mentioned above, and then
have us execute against that. I am not saying this will shield us from
mistakes, but it will allow those mistakes to be understood in the broader
context of where we're going with all of this, and moreover will allow us
to adjust in the large as we learn things in the small.
Perhaps such a write-up has already been circulated and I missed it?
As best I can tell, the current (unstated) plan consists of:
Convert everything we can to use ksh93/libshell implementations.
... which is at best incomplete (ksh93/libshell doesn't have everything we
need), and I believe too simplistic (e.g., as sleep as shown, even when
ksh93/libshell support is available, using it may prove more trouble than
it's worth).
So, in short, I request that we go back to the problem statement and
requirements, come up with the strategy, and then execute on that
strategy, adjusting it based on implementation experience.
--
meem
