Subject: Re: [ksh93-integration-discuss] Re: ksh88->ksh93 migration plan
--------
> Roland Mainz <roland.mainz at nrubsig.org> wrote:
>
>
> > Gunnar Ritter <gunnarr at acm.org> wrote:
> > - Move current /usr/bin/ksh to /usr/bin/oksh (now called "old" korn
> > shell) [...]
> > - Put ksh93 into /usr/bin/nksh ("new" korn shell. ksh93 MUST NOT be
> > placed to /usr/bin/ksh93 - arguments can be listed here but that is
> > AFAIK outside the scope of this mail))
>
> To the contrary, there should be /usr/bin/ksh88 and /usr/bin/ksh93.
> Names should be chosen for their descriptive clearness, not for
> political reasons.
With that logic each command would be given its name and its version
number. For example, instead of make, the name would be make3.80
and so on.
>
> > - ksh93 is under active development - there is an "upstream" (David
> > Korn, the AST community and others) who are working on it, doing
> > bugfixing, enhancements, patch integration etc.
>
> This may or may not be seen as an advantage. One of the finest
> properties of the current Solaris user space is that one always
> knows what one can expect. Certainly, this sometimes means that
> one expects bugs, but a known bug (usually with a known workaround)
> is better than a surprise at the next system update.
This sounds better than the reality. Over the years, Sun has made
changes to ksh88 that have broken it so I frequently do not know
what to expect. If you want to know what to expect, you should
document the behavior and stick to it.
>
> If Solaris would follow the ksh93 development more closely in the
> future, it would definitively have a less stable shell in that
> sense.
>
> Also, looking at the long list of bug fixes and changes in recent
> versions of ksh93: Yes, there are many fixes indeed, but when can
> one expect a stable release? Issues like
>
> 05-09-15 A for/while loop optimizer bug in which $OPTIND was not
> correctly expanded has been fixed.
The use of the optimizer was an option. I would expect early adopters
to use this and production systems to wait several years until
all the kinks have been worked out before enabling this.
> 05-06-24 A race condition which could cause the exit status to get lost
> on some fast systems has been fixed.
The same race condition existed in ksh88 and I don't know whether
anyone fixed this or not. Any complex piece of software will have
bugs and some won't show up for years.
>
> do not really make me trust in the stability of ksh93.
Should you trust the stability of any software? To a large extent, it
depends on the regression test suite. Do you trust the stability
of cc or gcc? Should you stick to one version forever? Should you not
bring in new features to the language? What if standards bodies
dictate changes?
>
> > Solaris ksh is Solaris-only - it has no "upstream" and Sun engineers
> > have all the burden of maintaing it. I've heared lots of complains in
> > the past about this maintaince nightmare called /usr/bin/ksh from Sun
> > engineers... ;-(
> > And Sun's bug database is still full of unfixed bugs which no longer
> > exist in ksh93...
> > The introduction of ksh93 (and depreciation of /usr/bin/oksh (= current
> > Solaris /usr/bin/ksh)) would be another good opportuniny for Sun to save
> > lots of engineering time in the long term.
>
> I doubt that. ksh93 has bugs on its own. Sun will have the choice to
> either wait for an upstream bug fix or to get its engineers to handle
> it in-house. But then, have a look at the ksh93 source code. In case
> the ksh88 code should really be a nightmare, what is the ksh93 code
> with its close integration to large libraries such as libast and its
> very special build environment?
In order to be successful, a mechanism for merging changes by Sun
and others is necessary. Otherwise, each vendor will likely have
its own incompatible version. Clearly Sun needs to meet the immediate
requirement of its customers, but it should make sure that changes
get filtered back to the broader ksh community. The ast-users
group has been a forum for this feedback.
>
> > - Better performance and lower footprint: ksh93 does not only perform
> > better than current Solaris ksh - the concept of sharing most of the
> > code between various versions of ksh (/usr/bin/ksh, profile shells,
> > dtksh, dbx etc.) via libshell.so should also reduce the overall resource
> > (memory) usage a lot...
>
> I doubt that. First, ksh93 is at least four times as large as ksh88
> (as far as I can see mainly because it reimplements almost the
> entire libc functionality). Second, memory usage is not really an
> issue here anyway; we are talking about a few megabytes, at most.
>
> What can be much more of an issue is the size of the executable
> file because it directly affects the storage requirements even
> of a stripped-down distribution e.g. for embedded systems.
Even though ksh93 is much larger, if you look at the basic UNIX
commands provided via libcmd, the overall size is smaller
than ksh88 + the same set of basic utilities. Several years
ago we replace ksh and utilities on a small i-paq and found that
it used less space and performed much better.
>
> > - Greater interoperability between operating systems: Currently Linux
> > and some of the other Unix derivates (AFAIK AIX) ship ksh93 as
> > /usr/bin/ksh
>
> This is not an issue in my opinion. For a complex shell script,
> it is relatively easy to also create an installation script which
> finds a matching shell.
Maybe it is easy for you, but this has not been our experience.
I suspect that Glenn Fowler has many war stories in dealing
with the shells on about 40 different systems.
>
> > And (sales) people would no longer be able to refer to Solaris as
> > an "outdated" operating system ("... Solaris is stuck in the 80' of the
> > last century - just check the version of ksh they're shipping..." etc.).
>
> No, they could say instead, "look, Solaris now updates its critical
> system binaries as often as Linux distributions do, resulting in
> comparable trouble at every system update."
Both extremes have their problems. If you never update you fall
off the technology curve. If you update too frequently, you frustrate
users that just want a stable release. An intermediate solution
is needed. Don't update too often and have good testing.
In the twelve years that ksh93 has been around, there have been slightly
over 20 releases. However, the comp center has only updated
/bin/ksh 4 times in these 12 years. We typically have three versions
of ksh available to users:
1. /bin/ksh
2. /usr/common/ast/bin/ksh - the last stable release
3. a working version of the next release.
>
> > - There would be no need to make the old ksh88 OpenSource (which also
> > means: Less work for the lawyers... :-) ).
>
> I do not understand that issue anyway. As far as I know, ksh93
> is a derivative of the ksh88 code. If AT&T allows to ship the
> ksh93 code, why would there any legal reason not to ship the
> ksh88 code? Or is there rather another reason behind this?
The ksh88 code has never been made Open Source and given the effort
for ksh93, there seems to be little incentive to do so.
I beleive that there are three organizations that have the
right to make ksh88 open source but so far none have
chosen to do so.
>
> What I can feel in this debate is a lot of politics. There are
> obviously people who want to deploy ksh93 for many good reasons.
> I do not want to oppose against that; I think it would be a
> very good thing to deliver /usr/bin/ksh93 for those who want
> to use it.
>
> But I do really not like the fact that these people also want
> to prevent others to continue to use ksh88. In my experience,
> Solaris ksh is a stable shell that has always served me well.
> I would not like to see it dropped; to the contrary, I would
> like to see an open source version of it.
>
> So please release both ksh88 and ksh93 as open source and let
> people choose their preference on their own.
Much easier said than done.
>
> Gunnar
David Korn
dgk at research.att.com
