Alan Burlison wrote: > 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.
Incorrect. Cool Stack may be duplicating things. Blastwave may be duplicating things. Sun Freeware may be duplicating things. The Web Stack project has no binary distribution. Will it stay that way long term; will it make sense to just putback into Solaris? Again, I think the goal is that it all goes into Solaris. Can we putback all of the extensions/libraries/etc? Will it ship somehow unbundled? I don't know yet. Your point is valid though, and we should make an effort to engage whomever owns perl in OpenSolaris these days. We've already been engaging the people working with other components. It's much more confusing around things like perl, but ruby, memcache, etc. are far more clear cut: they don't exist in OpenSolaris at all right now, end users want to be able to use them there, and it's non-trivial for them to build/test the software. Also, projects like Blastwave, Cool Stack and Sun Freeware do the whole Solaris community a great favor by targeting something other than the next Solaris Nevada build or the next Solaris 10 update. I know there are long term solutions for this in the works, but we aim to generate the best practices/optimizations that all of these projects (and the upstream source) can use to get a Web Stack to the whole Solaris community. > >> 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 do not; I'm a field guy trying to help companies use Solaris/OpenSolaris. Keep in mind, some components don't exist in OpenSolaris, and part of the reason for the project is to experiment, engage with the community, and determine what should go into OpenSolaris. > >> 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? We have emperical evidence to the contrary; it's proven to take some effort to work through the ARC cases, etc. to put things in to OpenSolaris, and more to do the same with Solaris. I'm not arguing this is bad or wrong, there is clearly value there in knowing the OpenSolaris commitment level, but the work of those hundreds of engineers on the process behind Solaris is quite different than trying to get a customer the stack they need for the Solaris/OpenSolaris they already have installed. In terms of how it will be easier to pick things, one major difference is this project *exists* to work *with* interested people to find out what they'd like to see available to OpenSolaris prior to putting something in and seeing if it was correct. The Cool Stack forums are proof that even the 1.0 of Cool Stack missed the mark, 1.1 is closer, but even it doesn't have everything people need/expect to be there out of the box. It's by talking with people interested in using OpenSolaris, and creating a place interested users will hopefully find if they have questions about how to approach something, etc. > >> 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. You and I agree here, and we're working toward that end. I'll reiterate, not everything in the scope of the Web Stack project is also in scope for Solaris Express or the existing OpenSolaris source code bases. > >> 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. We agree that where the components exist in Solaris, the two should be close to each other. Having said that, there are those other components/libraries/etc. and there have been times it's made sense to make a change or get something to a user without forcing them to follow the Solaris or Solaris Express cadence. There's also all of the soft stuff: how to get extension Foo to work with Bar on the Apache webserver. Especially if the exact version of Foo I need is not available 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. Agreed, getting it back into perl itself would be the goal, but we'd want to start somewhere, right? Do they exist as patches or anything other than the blog? I don't know, but does Hg provide a way for this to live out there for interested people to work with? - Matt -- 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
