>On Jul 25, 2005, at 2:36 AM, [EMAIL PROTECTED] wrote: > >>> They're shipping ksh93, which is open source. Solaris includes ksh88 >>> (g I believe), which is not. We'd love to just upgrade, but they're >>> not 100% compatible. >> >> We can certainly ship ksh 93 as /bin/ksh93. >> >> It would be nice if we could somehow qualify the differences and >> have a single binary which detects how it is invoked so that the >> compatible >> extensions are available to ksh users. > >Why does it have to be 100% compatible? That is a serious question. >What breaks so bad that not having access to the source is considered >a viable solution?
Well, it certainly needs to be for a "Solaris" release. The problem with shells is that scripts are written so there's a body of code which may depend on this behaviour. We'd love to replace /bin/sh also, but ... >We must have a reasonable plan for progressing from closed binaries >to open source. That means there will be compatibility risks and >we must live with that fact -- staying put in a land of 100% backwards >compatibility is death. We can address those risks by installing the >current open source versions ASAP and addressing backwards-compatibility >issues as they are discovered and determined to be worth addressing. Absolutely; but if we can replace /bin/ksh with a dual mode binary which can do both. >If there is a serious compatibility issue, then Solaris can replace >the new executables with ones that are 100% backwards-compatible. >There is no reason for OpenSolaris to be so hobbled. Depends on whether OpenSolaris sees 100% (backward) compatibility as a constraint or just a goal. I think some in the community see it more as a constraint; and they also see that as one of Solaris' selling points. But others may differ. Casper _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
