On Fri, May 8, 2009 at 6:33 AM, Eric J. Ray <Eric.Ray at sun.com> wrote: > > On May 7, 2009, at 9:12 PM, Mike Gerdts wrote: > >> On Thu, May 7, 2009 at 9:03 PM, Alexander J. Maidak <ajmaidak at mchsi.com> >> wrote: >>> >>> A long time ago back in the dark ages an admin in my shop read this Sun >>> blueprint: www.sun.com/blueprints/0802/816-7587-10.pdf >>> >>> Following this he created a highly customized the Jumpstart process and >>> net-install miniroot adding scripts and a netbackup client. This created >>> a really good bare metal restore process that has been used for years. >>> >>> Fast-foward to 2007 I ported this process to the Solaris 10 installer, a >>> less then simple task. ?The SPARC newboot process with the 10/08 >>> installer added even more quirks. ?Maybe there would have been a better >>> way to solve this, but sometimes when you have an highly scripted and >>> automated process that you're using to maintain 100's of servers its >>> hard to leave it all behind. ?Following usenet groups and OpenSolaris >>> forums I don't think my site is unique in customizing the S10 miniroot >>> and Jumpstart installer. >>> >>> The point of this story is that if the Jumpstart installer and >>> net-install miniroot were Open Source this is something that I think the >>> Sysadmin comminity would be interested in working on and contributing >>> too b/c it greatly impacts they're daily jobs. ?It may be a legacy mess, >>> but its a legacy mess we're quite invested in. >> >> Back when code was first being opened, jumpstart, live upgrade, and >> patchadd were the areas I was most interested in seeing open. >> Needless to say I have been disappointed about the way things have >> gone in this area. ?Now that it is pretty clear that new innovation in >> S10 is winding down and S10++ will completely replace these areas, I'm >> less inclined to focus on these legacy areas. ?To a certain degree, >> this means that I have just given up on being able to use OpenSolaris >> to make Solaris better. ?Hopefully this isn't repeated in S10++. >> >> In order to encourage sysadmins to help make the new technology right >> before it gets entrenched, I've invited sysadmins to join the caiman >> (re-)design discussions that are happening now. >> >> >> http://mail.opensolaris.org/pipermail/sysadmin-discuss/2009-May/002703.html >> > > Thanks, by the way--your contributions are really helpful over there! > > Mike's on the right track. The old code simply won't be opened, for a > variety of reasons, most significantly that it simply doesn't make business > sense to invest resources there. It's time to update the technology, and > fixing the old, in this case, simply didn't make sense.
>From my standpoint, opening up pdo (patchadd) three years ago would have made a lot of sense. The Solaris 10 re-write of patchadd removed important functionality[1] and generates very verbose and confusing messages. I'm pretty sure the sysadmin community would have been all over fixing it several years ago if Sun would have been willing to think of it as an open source component that applies mostly to Solaris rather than a component that is almost[2] irrelevant to SXCE. That opportunity has been lost and it is now time to move forward. 1. The (not-an-interface) return codes from patchadd in S9 and earlier were clear and very helpful. To this day I would have a hard time training a junior admin to understand the output of the S10 patchadd. 2. Not completely irrelevant because patchadd has been required to apply patches to Sun Studio in SXCE to do OpenSolaris development. -- Mike Gerdts http://mgerdts.blogspot.com/
