On Tuesday 18 April 2006 03:27 pm, Philip Brown wrote: > Hate to say it, but: "no", because of all the qualifiers you put in. > If you take some out, then yes it is possible. > possible.. but not likely.
And there-in lies the rub...it seems that all parties need to get together and put everything out on the table, and that most all parties would need to make some compromises. I don't know that a common set of libs would please folks like Blastwave for instance, and some of the comments I've read from Dennis would support that thought. > "from sun + the community" is NOT "from sun". That needs to be true for Sun to be successful with OpenSolaris, IMO. > Sun would have to go 180 degrees in the direction they have gone, and hire > full-time staff, to keep the "important stuff" up to date, solely by sun's > efforts. I don't see this model working, and quite honestly, will almost certainly fail. Sun has staff now to handle most of what they do, but this doesn't allow Sun to work with the community. > 1. things change slowly in "core" solaris for a reason. some of sun's > customers are very change-averse. So, to have bits in sun-shipped > solaris, change rapidly, would possibly alienate that important > userbase. > > [it might be possible if sun split out that stuff to a separate chunk, > and said, "ok, we commit to stability for stuff <over here>, but > stuff on this GNOME cdrom/whatever we do not commit to keeping > unchanged for x number of years, or even x number of months] I thought an unstable gate for tracking OpenSolaris, as well as a static gate built against what Sun ships could work. If folks wanted to get the latest and greatest bits, easy, just download the current gate. Blastwave essentially dropped their stable tree anyway, didn't you? This only proves that it's too hard to keep updating both trees. And folks shouldn't have to. As long as the most current libs/bits are developed with on the most current build, things will work. Now, getting the static builds of the same software in place is not so easy, I'll admit, but it doesn't mean everyone shouldn't try. > 2. Some of the issues of keeping nasty open source libs up to date, is > then that you have to recompile a buncha stuff, because there is an > extreme lack of API stability in the open source world. It's the linux > disease of "oh, you should just recompile everything" Right, but we need to play with those folks because, quite honestly, Linux has become the standard today for the most part. Folks are willing to run their companies on Linux, and things are changing. Sun's community/customers will need to change also, as Sun must change. This imposed change will have an effect on Solaris, IMO. Sun really doesn't have a choice, they must change. > 3. Sun would have to actually comit to the long-term expenditure of > creating and maintaining such a team. That's something that Sun is good at, but that doesn't really solve the problem of not having a common, open, and usable set of libs. > The cost to convert everything, and then get dumped after a year, > is simply too high to take a risk on it at this point. > Re-engineer 1500 packages... and then re-engineer them AGAIN? > no thanks. As I have said, maybe it is that Blastwave doesn't choose to participate in such a project, or that Nexenta doesn't, or Schillix, or Belinix...but this shouldn't prevent everyone from trying to do what is right for everyone. -- Alan DuBoff - Sun Microsystems Solaris x86 Engineering _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
