I got what you're saying... don't worry Sun will do what they have been doing with Solaris 10 updates. They won't keep the security/regression related ones from you. Now I think there needs to be source for what was/is open, may it be a current cloned mercurial repository or a finger pointing to the exact (buildable) revision in OpenSolaris which the closed bits was built from.
James On Tue, Jun 10, 2008 at 2:33 PM, Mike Gerdts <[EMAIL PROTECTED]> wrote: > On 6/10/08, James Cornell <[EMAIL PROTECTED]> wrote: > > If there are other encumbered bits you are speaking of, please identify > > which ones so I can get a feel for what you expect. While I don't work > for > > Sun I have some legal experience because of contracts, and through > somewhat > > easy deduction naming the 3rd parties responsible for 3rd party bits > would > > make it easier to identify which ones would be the problem since source > > licensing is a tricky situation. > > I think you missed what I was trying to say. > > Today the source for (e.g.) the libc is open source. If I am running > snv_77 then upgrade to snv_80 and see something good or bad with a > function in libc, I can look at the changes between snv_77 and snv_80 > to understand what they are. If I need to dig into it with the dtrace > pid provider, I can read the source code associated with snv_80 and > figure out what the pid provider is telling me. > > If OpenSolaris 2008.11 has one fork at opensolaris.org that tracks > each build of Nevada and another fork that goes behind the Sun > firewall and only gets critical bug fixes, there is a reasonable > chance that I would want to run my production environment on the one > that is getting the minimal set of changes. There is also a > reasonable chance that I want a support contract with it. > > When January 2009 rolls around and an updated libc is released to the > supported fork and something really good or really bad happens, I may > want to be able to read the source code that was used for building > that release of libc. Just because I am paying for support doesn't > mean that I want to give up my ability to understand how and why my > system does or does not work. There have been many times where being > able to point to the exact lines of code where bugs exist have saved > hours to days of time with the first couple layers of support. If the > source is forked and I don't have access to the fork I am running, it > is nearly impossible to point at the lines of source code associated > with newly introduced bugs. > > The closed stuff - well that's closed. If I don't have access to the > source code of the closed stuff I'm not losing any ability to do > self-support by paying for the supported version. > > -- > Mike Gerdts > http://mgerdts.blogspot.com/ >
_______________________________________________ indiana-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
