> Sun has already been doing that. If you pay for > support and use the > support repository, you are using a closed fork. > Since > penSolaris-dev and OpenSolaris-support are pretty > close together > temporally, this isn't a big deal. You can look at a > snapshot of the > snv_111 code and the list of fixes applied to get a > pretty good idea > of what the code looks like. After several years and > potentially > thousands of fixes, a lot of the benefit of the open > source roots is > lost. > > While the typical customer doesn't have an interest > in modifying the > code, many have an interest in looking at it to > understand observed > behavior or to aid in writing dtrace scripts that > journey into fbt > probes. As the years have passed since the fork > between what became > Solaris 10 and what became OpenSolaris, I have > increasingly less > confidence that looking at any version of OpenSolaris > code will allow > me to really understand what is happening on a > Solaris 10 system. > That is, as the number of fixes and features included > in Solaris 10 > increases, the value of the open source roots > decreases. > > I have always expected that the same will happen with > Solaris 10+1 > (11g?). I have consistently asked Sun to make the > code for supported > OS's available to customers, even if it is under a > license other than > the CDDL. I encourage others to make similar > requests. > > -- > Mike Gerdts > http://mgerdts.blogspot.com/
With you 1000% on that. I'd always like nothing better than to have as much of the source as possible (i.e. not locked up in some agreement to keep it proprietary) _matching_ what I'm running there to look at. I'm most unlikely to have the time or patience to do a full build often, and as the code sits now, it's not pretty to try to build one thing without having first done a full build of everything. So even on a development system, I might never try _fixing_ something myself. But the better the code I can look at matches what I'm running (esp with tools like DTrace or (k)mdb), the better the chance I can at least understand whose problem something is (OS vendor, 3rd party, in-house) and do enough of the diagnosis that I can get a quick turnaround out of them. OpenGrok is pretty good for looking at the code, but it could be great if one could tell it what one was running and have it show just that version of the code. Too few people anywhere are good at troubleshooting, and the ones that are tend to be busy and shielded by layers of helpdesk types and the like; so whatever someone can do for themselves can really make a difference. And if there's an easy workaround, one might be able to find it oneself. And then there's sunsolve. Not terrible, but not great either. Not near as good at relevance of unfielded keyword searches as the major search engines, nor capable of good old fashioned Boolean queries (like AltaVista used to be way back when). -- This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
