On Mon, Jul 25, 2005 at 03:48:52AM -0700, Roy T. Fielding wrote: > 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?
100% compatibility is not always required. Sometimes, no compatibility is required at all. See the interface stability taxonomy in chapter 7 of the developer's reference. ksh, unfortunately, is Stable. Nothing I said should be interpreted to mean that not having source is acceptable. You're overlooking the point of this thread: that neither staying closed nor breaking compatibility are viable options. The right solution is to do the necessary work to reimplement sufficiently compatible functionality that can be integrated into OpenSolaris - which means open source. > 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 Risks, yes. Those risks can be mitigated through the ARC process and other reviews. There is no '100% backwards compatibility' guarantee associated with either Solaris or OpenSolaris as a whole; that would stifle development. There are, however, compatibility constraints on some components. As I've explained many times in similar threads, this does not preclude the implementation of open-source alternatatives to replace existing code. All it means is that the implementation must be complete and sufficiently compatible by the time it goes back. > 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. Compatibility is a value that Solaris engineers, users, and third-party developers share. This community and the Solaris community overlap almost completely; therefore it is unlikely that you will find support here for destroying compatibility. That the contents of a putback can be made open is a necessary *but not sufficient* condition for their suitability for inclusion. Let's be frank: Sun will be investing a good deal of effort in replacing some of the closed code with open equivalents. This process will not be completed overnight, as much as we might like it to be. In a perfect world, it would have been done before launch; as it is, we worked our asses off to make available what's there today. But not only Sun should participate in this process; elsewhere in this thread someone has helpfully posted a list of ksh93 incompatibilities. The ksh93 sources are available to the world, and a motivated individual with access to both those sources and that list of incompatibilities could certainly create a ksh93 that, when invoked as ksh, operates in the same way as Sun's ksh88. Following review, that ksh would be added to OpenSolaris and would appear in subsequent releases of SchilliX, Solaris, and any other distributions. All this development could be done in the open, like any other project. -- Keith M Wesolowski "Sir, we're surrounded!" Solaris Kernel Team "Excellent; we can attack in any direction!" _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
