I. Szczesniak writes:
> On 4/21/06, James Carlson <james.d.carlson at sun.com> wrote:
> > In other words, the solutions that make sense to me are:
> >
> > 1. /usr/bin/ksh stays the same, and /usr/bin/ksh93 is shipped as
> > the new ksh93. Perhaps someday the two converge again, but not
> > now.
>
> That's bollocks. May I remind you that the RFE in your bug database is
> from the last century? How long should the customers of Solaris wait?
> Ten more years? Until David Korn is dead? When?
Frankly, the wait is simply bounded by the amount of time it takes
some project team to deliver a suitably compatible replacement.
Neither more nor less than that.
It has nothing to do with the passage of time or passing of people.
> >From the point of view of a software vendor this is still UNACCEPTABLE
> as each piece of code needs to be reviewed whether it uses /bin/ksh or
> /bin/ksh93.
Whether written as upper or lower case, I understand that issue. I
haven't been disputing it. I simply don't know why you seem to be
arguing as though I have.
What I have been arguing is that any plan to replace /usr/bin/ksh --
for the better, one hopes -- simply _must_ take compatibility into
account, and that plan must explain how compatibility issues are dealt
with. "Things just break" is not an acceptable answer for a stable
interface, and one that I would vote to deny without hesitation.
In other words, I see _multiple_ conflicting priorities that need to
be balanced, where it seems others see only one, or are simply
choosing to ignore the others.
The burden, as it always is, is on those who come later. We can gnash
our teeth and curse those who came before us and delivered these
compatibility problems, and we might even feel better for having done
so, but that doesn't actually make the problems go away.
> Again, the interoperability issue is there: Neither Linux or Mac OSX
> ship with something called /bin/ksh93.
Some other systems (e.g., AIX) do.
> > 2. /usr/bin/ksh is replaced by a suitably modified (to be
> > compatible) variant of ksh93. The old Sun ksh is sent to the
> > great bit-bucket in the sky.
> >
> > I don't see a self-consistent case where we're both confident enough
> > to replace /usr/bin/ksh but not so confident that we can't let go of
> > oksh.
>
> And who is going to maintain such a version?
Who is going to maintain /usr/bin/oksh? There's no free lunch here.
> I doubt Korn Shell
> maintainers will tolerate such patches and Sun will have to maintain
> again their own breed of ksh, something which contradicts idea to
> "lower the burden" on the side of Sun.
That part has yet to be demonstrated.
Does anyone who is complaining about this problem have a _concrete_
analysis showing just how hard maintaining compatibility might be?
There seems to be a lot of shouting here, some justified at the age of
that CR, but very little useful data.
> The Sun version of /bin/ksh will differ AGAIN from all other versions
> of Unix. The result will be a chimera which is not going to serve
> anyone except the religion of downward compatibility at all costs. And
> I doubt that this will be in the interests of your customers.
I'd certainly like to avoid that, if it's at all possible.
Maintaining diffs can be hard.
It's quite unclear so far what buckets the problems fall into. There
are several; at least these:
1. Problems which are easy to fix, likely to be encountered by real
scripts, and for which the ksh maintainers would be willing to
accept useful patches.
2. Problems that are very unlikely to be encountered by real
scripts, and it's easier to convince the ARC members that the
incompatibilities don't matter.
3. Problems that are hard to fix and/or for which the maintainers
won't accept fixes, but likely to be encountered.
Only those in (3) are really at issue, and the more that can be pushed
out of that bucket by effort by this project team, the better.
> > I'd prefer (2), as I'd like to see us get rid of the old stuff as soon
> > as possible.
>
> And how should this help software developers? A version of SunKsh93
> which differs significantly from the version shipped by other
> operating systems is IMO NOT better than the current version of ksh
> delivered with Solaris.
There's no concrete proposal on the table. I don't see how you can
come to that conclusion.
I don't really know what "differs significantly" here means without
some clear project proposal.
Sombody, please, provide one.
--
James Carlson, KISS Network <james.d.carlson at sun.com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
