On Tue, Jul 26, 2005 at 02:43:02PM +0200, Joerg Schilling wrote:
> We have either _no_ ksh in OpenSolaris or we have ksh93.
Please take time out and think about what you're suggesting.
Intentionally breaking compatibility with Solaris has the following
implications:
Beginning immediately, applications that run on Solaris today may or
may not run on other OpenSolaris distributions. The ability to use
existing and future software, both open and proprietary, will be
retarded. At first, perhaps some small incompatibilities in ksh will
have little or no apparent impact. Later, perhaps someone decides
that because libc_i18n is delivered as a binary, and the value of
openness is greater than the value of compatibility, i18n should no
longer be supported by OpenSolaris distributions because it's easier
than doing the work to reimplement the functionality in a compatible
way. Or perhaps you go even farther and decide to ship glibc instead.
Eventually many more things are broken, and the pace of divergence
increases without bound.
Who loses there? Everybody. Distributions lose for the same reasons
GNU/Linux distributions lose (and the same reason they frequently
renew failed efforts to unify or provide better compatibility!). Sun
loses because the other distributions it was hoping would spring up
have much lower value to their users, and don't drive interest or
development in ways that can benefit Solaris. Third-party vendors
(open and proprietary) lose because their market is smaller than it
could have been. And more than anyone else, users and developers
lose: we're forced to choose between openness and compatibility - the
worst of GNU/Linux and the worst of Solaris, and we will have a
smaller set of usable software from which to choose, with more work
required to maintain what we do have.
I'm not overlooking that we have this problem now - as you point out
correctly, ksh is already an incompatibility because it's missing from
distributions other than Solaris. It's fair to say that Sun should
bear the burden of supporting proprietary code if it does so for its
business reasons. It's also fair to say that proprietary code should
be replaced as quickly as possible with code that's useful to
everyone. Collaborative development means we work together to find
solutions to this problem that are acceptable and beneficial to
everyone (not just Sun, as a few have unjustly implied). Offering
compatibility means more work for us and more value in what we produce
- we do the work ourselves instead of pushing it up the stack to
developers and users. Three major strategies have been suggested for
that work:
- Add ksh93 to ON ASAP. Deliver it as /bin/ksh93. Rename
/bin/ksh to /bin/ksh88 and provide a hard link /bin/ksh to
/bin/ksh88. Repeat for pfksh and rksh. [For Solaris only,
announce EOF for ksh88 and remove in Solaris 12, or sooner if
possible.] [For pure distributions only, link ksh to ksh93 and
warn users that they need to use ksh88 from Solaris if they
want a compatible environment.]
- Add ksh88 compatibility to ksh93 sources as an open project,
and replace the ksh sources in ON with those. This is higher
risk but offers a compatible solution sooner.
- Make pdksh compatible with the existing ksh. This could be
combined with the ksh93 strategy as well, and might require
less work to provide both shells, possibly forever, on all
distributions.
A few issues: /usr/xpg4/bin/sh is a variant of ksh. How
should it be provided? What about pfksh and rksh support in
ksh93? ksh93 also requires an odd build environment; what's
the best way to integrate it into ON?
> We cannot wait as you seem to asume.
Urgency is perception. We - this entire community - have been waiting
20+ years for this. Is it so important, just 41 days in, that we
solve this problem RIGHT NOW, TODAY that we disregard that 20 years'
worth of values and technical decisions in doing so? We certainly
*can* wait. We can wait until we're all reasonably satisfied that we
have the right solution, the right long-term approach that will make
SchilliX and Solaris and any other distribution that comes along
valuable to their users and developers. If OpenSolaris were to launch
on September 14 instead of June 14, you might be mildly disappointed
by the extra quarter's delay, but you wouldn't be shipping SchilliX
now, with or without ksh. Would you still be arguing today that we
can't wait any longer to replace ksh even at the cost of divergence?
A constructive discussion of the technical options could start on
opensolaris-code or opensolaris-arc. See John Plocher's mail in
particular for more details on architecture, and the list of ksh93
incompatibilities for the technical points. Because I'm an
irredeemable optimist, I'm setting reply-to to -code in the belief
that the replies will be on topic for that list.
--
Keith M Wesolowski "Sir, we're surrounded!"
Solaris Kernel Team "Excellent; we can attack in any direction!"
_______________________________________________
opensolaris-discuss mailing list
[email protected]
