Mike Gerdts wrote: > On 10/8/07, James Carlson <james.d.carlson at sun.com> wrote: >> Mike Gerdts writes: >>> I think that it is likely appropriate for both places, as it would be >>> a partnership between OpenSolaris and a distributor. As I said >>> before, I was bringing this particular issue up as something to fix >>> over the next 2 - 5 years and that pdo.c was likely already a lost >>> cause. FWIW, I was once again annoyed to read Jonathan's latest blog >>> entry that referred to Solaris as open source. >> In the time scale of 2-5 years, I think pdo.c becomes completely >> irrelevant. As best I can tell, we'd have to assume that Caiman is a >> failure for that picture to change. > > Right. But something else will take its place if Solaris is always a > closed branch of OpenSolaris. Sun won't have the resources to scratch > my Solaris itch. It pushes me to any number of other solutions where > Sun doesn't get to bill me for support. > >> It's a very different wasteland from LU. LU is stuck because of >> licensing issues. We don't own it sufficiently that we can put it > > Try to take this as best as possible - I'm not intending to knock the > efforts of anyone here. > > To me it is the same: either it is open or its not. There is a > slightly gray area there of "not open yet, but it is a high priority > thing with external visibility that it will be very shortly." I think > that this view comes from experience with various things from Sun > being delayed so long as to make it so that I put in long-term > workarounds that I'm not terribly interested in undoing. This has > come in the form of half-implemented features[1], bugs where I have > provided the lines of code to fix them[2], slow response on bugs > serious enough to force me to freeware equivalents[3], and IDR's stuck > at IDR stage. > > 1. e.g. wanboot was announced and /I think/ part of Solaris years > before I could find any firmware to support it. > 2. e.g. ptools leave processes stopped when SIGPIPE is received - I > provided bug reports and/or fixed code against 2.6, 7, 8 within 6 > months of GA of each of them. > 3. e.g. in.named memory leaks that consume all system memory within > days of operation > 4. I have multiple cases open where IDR's have been issued and the > fixes don't appear in patches well over a year after the first IDR was > presented to me. > > Admittedly, some of the above issues are old. It takes a long time to > build trust back up. Right now, nothing is being done to make me > trust that Sun will make it easier for me to leverage OpenSolaris to > make Solaris better. >
I don't think it's quite nothing, but admittedly there's a gap between contributing something to OpenSolaris and having it show up in a supported Solaris release. That won't get any better so long as Solaris 10 is the current fully-supported release, but one of the points of Indiana is to move us in the direction of having a supported Solaris that's based on OpenSolaris. Until that point in time, I agree, you're going to be frustrated if we have problems like the above (and yes, the WAN installation one represented a particularly galling lack of alignment between Sun businesses - I don't know enough about any of the others to comment constructively). >> under an open license. It doesn't really matter whether we throw >> resources at it, or if it's good or bad for OpenSolaris; we just can't >> legally do it. What would help in that case is a project to _replace_ >> LU with something different -- either a new installer/upgrade tool (as >> in Caiman) or a clean-room implementation of LU (any takers?). > > For some reason, I thought that snap upgrade was a LU replacement. > The latest requirements list makes me doubt that is the case. A > pity, really. > It's intended to capture the better features of LU and not the ones we could all do without. Please remember that the requirements docs and other things that are posted are meant to be the starting points, not the end points, for the discussion. Tim will be responding to your comments, I expect. Dave
