Hi Alan, I'm not sure if you had intended to have all of these mailing lists on this question. So the answer gets to all of them, I'll cc them now, but we may want to take further discussion to the webstack-discuss at opensolaris.org list.
Alan Burlison wrote: > > I'm interested to hear why the project team think it is necessary to > ship duplicate versions of software that is already included in the > base OS, specifically perl. > First off, this project isn't necessarily about shipping duplicate versions of software. As you probably already know, there are already multiple sources for things such as Apache, Perl and PHP for Solaris/Solaris Express (other distributions may do something else entirely in user space). This project is more about working on how to optimize and best use the stack, as well as discuss things with people that use the stack in one of it's various forms. I can't speak to the specifics of Perl, but I can speak to the history of other Cool Stack components. The Cool Stack and CoolTools projects were put together out of some things that had been learned working on customer engagements. More specifically, many of these components in Solaris/Solaris Express were old versions, were missing common/popular extensions, or had been been built/configured in a way that was incompatible with other things customers needed to use. Other components had also not been compiled optimally, and as a result performed or scaled poorly on Solaris. I believe everyone involved with this project would much rather the components in Solaris 10 or Solaris Express be perfect for everyone out of the box. The reality is that there is a high bar between finding a needed change and putting that change back into Solaris/Solaris Express. Also it is, in some cases, difficult to know exactly which release/configuration of something to put in to Solaris. What I hope for, and I won't speak for all of my colleagues, is that through this project we'll be better in tune with what people are asking for, can help with the best approach to what customers need with these things, and can iterate faster and experiment more. Ultimately this means we can come up with the right contributions to make to the upstream Open Source communities, and hopefully influence/simplify what Solaris and Solaris Express ship. For instance, Stefan has been diligently working through the OpenSolaris ARC project to get some updates putback in OpenSolaris, which will then filter it down to Solaris Express and hopfully Solaris 10. If other contributors (including groups in Sun that are not directly involved in software) come up with a way to make things faster/more scalable/more observable/more secure, then Stefan will hopefully be able to make use of that in his work on Solaris. If someone in the community is trying to make the AMP stack on Solaris do something like they do on another platform, they now have a more specific place to go than opensolaris-help and opensolaris-discuss. One thing I'd love to see in there is the DTrace work you've done with perl [1], even if it lives in an experimental branch or something along those lines. The comments on your blog seem to indicate there are other people interested in it as well, but the bar is high right now since they have to figure out how to patch the source. We hope the web stack project will give people a place to go if they need help/want to find/contribute this sort of thing. Sorry for the long winded explanation, - Matt [1] http://blogs.sun.com/alanbur/date/20050909 -- Matt Ingenthron - Web Infrastructure Solutions Architect Sun Microsystems, Inc. - Global Systems Practice http://blogs.sun.com/mingenthron/ email: matt.ingenthron at sun.com Phone: 310-242-6439
