Matt Ingenthron wrote: > 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.
A significant number of these are already being shipped, so you are duplicating existing work, that is incontrovertible. > 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. Do you have comparative numbers? Have you fed them back to the people responsible for those components in Solaris, along with your changes? > 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. The supposed 'bar' doesn't seem to stop the hundreds of engineers who contribute to Solaris from doing so, I think it is a perceived problem rather than a real one. And if it is difficult to know what to pick for Solaris, how is it any different for the CoolXXX stuff? > 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. The best way to do that is to fix Solaris, not do something separate and then assume that someone else is going to redo the same work for Solaris. That's duplication of effort and a waste of scarce resources. > 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. None of that requires that you duplicate software that is already in Solaris. > 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. Doing this properly means getting the changes back into perl itself, so that *anyone* building perl on Solaris can use the DTrace probes. Unfortunately I don't currently have time to work on it. -- Alan Burlison --
