On 2/14/06, Gunnar Ritter <gunnarr at acm.org> wrote:
> Roland Mainz <roland.mainz at nrubsig.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.
Maybe nawk needs to be renamed then. And lots of other tools in Solaris, too.
And I agree with Irek that naming the current /usr/bin/ksh a "ksh88"
is a clear affront against the original version of ksh88. The current
Solaris ksh is compatible to NOTHING except itself.
>
> > - 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.
Sure... in that case java needs to be downgraded to java1.1 ASAP, perl
needs to be frozen and the kernel must be frozen at 5.6 level.
Gunnar - software evolves. Software is not a static thing. And Sun's
policy of ignoring that ksh has evolved in the last 13 years has
become an EXCEPTIONAL PAIN for the people.
I've been in this kind of hell quite often recently since the majority
of the operating systems uses korn shells based on ksh93 and NOT on
the old ksh88 flavor, resulting in the problem that shared home dirs
which are used by multiple operating systems requires two kinds of
scripts: One for the normal ksh and one for Solaris ksh.
>
> 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.
> 05-06-24 A race condition which could cause the exit status to get lost
> on some fast systems has been fixed.
>
> do not really make me trust in the stability of ksh93.
As David Korn himself explained these arguments are invalid.
>
> > 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?
It is still better than the current version of ksh in Solaris. At
least its actively being maintained. From what I have hear Sun only
has ONE person who is assigned to maintain Solaris ksh - and I fear
this person is likely being consumed by just dealing with those bugs.
>
> > - 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.
The memory footprint of ksh is important. And your pun on libast is
just useless - AFAIK it is just a portability layer similar to NSPR in
Mozilla. And no one complained about NSPR yet.
> 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.
This is an invalid argument. The usage of libshell will actually
REDUCE the disk requirements as things like the profile shells and
other tools can use libshell instead of using their own copies...
>
> > - 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.
This is a SIGNIFICANT issue for home dirs which are shared between
operating systems. AFAIK Roland said it originally: "The Unix shell
scripts were designed to be portable." Solaris ksh BREAKS this promise
in a VERY ugly way.
> > 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."
There will only be one update - to ksh93. And from what I have read it
will be announced years before the switch will be made. And the old
Solaris ksh will remain for another couple of years.
It is much more important that Sun is no longer compatible to the de
facto standard of the korn shell - and this is ksh93.
> 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;
>From what I have read above you are opposing in many ways.
> 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.
At some point ksh93 will become /usr/bin/ksh but as I said: The
current Solaris ksh is not going away.
> In my experience,
> Solaris ksh is a stable shell that has always served me well.
Yes, but it is not serving much well anymore. And the resources to
maintain it are not available, neither Sun nor the community has the
strength to maintain this nightmare.
> I would not like to see it dropped; to the contrary, I would
> like to see an open source version of it.
Please no. It would generate another burden for the community. IMO
there are not enough people to work on both ksh88 and ksh93 and ksh93
is DEFINITELY the future. We have to look forward. Looking backwards
isn't wrong - but in this case it will likely be FATAL for the
OpenSolaris project.
> So please release both ksh88 and ksh93 as open source and let
> people choose their preference on their own.
ksh88 will likely not be released as open source. Doing so may damage
OpenSolaris in the long term. And neither Sun nor the community has
the resources to deal with it.
--
_ Felix Schulte
_|_|_ mailto:felix.schulte at gmail.com
(0 0)
ooO--(_)--Ooo
