[ Removed opensolaris-discuss from the Cc and Bcc'ed advocacy-discuss and opensolaris-discuss. Folks, can we try to exercise some basic email etiquette here? ]
>> Sigh. We have made no statements about compatibility with anything, >> either past or future, in the preview releases. It's an experiment. > > Sun did make statements about long term compatibility and many Solaris users > did stay with Solaris _because_ of these statements. What Dave is saying is that no such statements have been made about Indiana. What has been stated is there is an intent to use the Indiana distribution as a basis for future releases of Sun supported OpenSolaris releases. The first two "Preview" releases (I actually prefer the name prototypes since that's what they are) were experiments more than anything. They contain new technology and some changes to existing technology; some of those changes will make it into the next "big" release of Solaris, whether it's called Solaris 11 or not. Some of them may not. In the meantime, there will be a series of six-month non-traditional releases aimed at *developers* (and not the traditional, enterprise customers) which will contain many of these changes. Some of the changes which appear in one release might end up being withdrawn or changed further. The point is we're making a transition from a one-size-fits-all-WOS model (Solaris 10 and earlier) to a model where there will be likely a core set of packages on a piece of media coupled with a network repository. As with most transitions of this size, there will likely be some rough patches in the road. That's why ISVs and traditional enterprise customers should continue to use Solaris 10. It will be supported for a *very* long time and it will not change in an incompatible fashion. And with the advent of virtualization, it should run effectively as a guest on modern SPARC and x86 hardware that support some form of hardware virtualization but where the host might be running Indiana or Solaris Next. However, there is no guarantee about the next "big" release. We at Sun have worked very hard to not break compatibility in those releases either but sometimes we do and that's documented internally and within the OpenSolaris community via the ARC process along with working with ISVs, release notes, developer outreach and general documentation. >> The negativity some of you have towards experiments just amazes me >> sometimes. > > You may like to call it "negativity" from the view you have on the problem. > > I call it the result of 26 years of experiences with UNIX hacking. > > With the right skills, you do not need to do every possible experiment because > you already know the results or because you know that the constraints under > which you run the experiment are not sufficient to give useful results at all. Joerg, I assume you're talking about the experiment where we replaced the traditional Solaris Bourne shell with ksh93. It's well know that the latter isn't 100% compatible with that particular Bourne shell (the latter, by the way, isn't compatible with anything modern shipped on other platforms which has been a source of complain from many ISVs.) So far, one issue have arisen which we're grateful for the bug report; we would like to have even more bugs filed if they're encountered. We'll be working with Roland and the ksh93 team to see where we go here. > You however cannot test a /sbin/sh /bin/ksh93 change inside Solaris only. > Indiana definitely has the wrong audience to give expressive testing depth for > this highly complex change. You only would reach the right testers audience if > you created a beta distribution that would be tested by industrial or > financial > customers in real world environments. Indiana is mainly targeted for > individuals > that used Linux before.....so you cannot use results from an Indiana based > test > for a Solaris change with high risk potential. You're right that the initial Indiana focus of the desktop developer is insufficient for a change of this magnitude. But the change isn't been put into the ON truck yet. We intend to further investigate including enlarging the test audience over time; if it turns out that ksh93 isn't an adequate replacement for the "old" /bin/sh, then that change won't be committed to the trunk. dsc
