Agreed. :) As long as we end up with the correct result (customers able to hands-off install systems, ISV software, configs, security profiles, disk mirroring, third party stuff, whacky drivers, systems management tools, etc.), I am all for making life better.
My real concern is that we could miss a significant piece of customer need, and render the new system "feature incomplete". I have confidence that your teams' goals align with those drivers, and absolutely hope that AI/IPS/other cool stuff reduces overall complexity and makes the admins' lives easier. That said... leaving an open door for pre- and post-install activities makes good sense if we do hit a case where we are feature incomplete, or discover some new whacky twist that a customer wants to implement. Post-installs are an ugly hack. No doubt. But they do cover the corner cases and account for "stuff we haven't even thought about yet" which (without a doubt) our ISVs, developers, and admins will dream up. Consider the iPhone. You can't just drop in an mp3 file for a ringtone. Ringtones have to be imported and managed through iTunes. With this restriction from Apple, folks immediately look for whacky, unsupported ways to jam self-made and free download mp3's into their iPhones without going through the "overly restrictive Apple tools". I'm willing to bet that some iPhones got turned into bricks trying to wedge simple hacks like that in. :D I don't want iPhone hacking and screwy tools in my datacenter. :D Apple might have avoided this by implementing a way for folks to drop files, possibly files of a certain type or format, into their phones... flexibility is good. bill. Eric J. Ray wrote: > > On Mar 25, 2009, at 2:03 PM, Casper.Dik at Sun.COM wrote: > >> >>> Glenn Lagasse wrote: >>>> AI is different, intentionally so. Among other things, we're actually >>>> trying to improve automated installation of OpenSolaris. >>> >>> Agree that AI, IPS, and lots of things going forward are much better. >> >> I have no proof that AI will be better than jumpstart; the people >> designing don't even know how people use jumpstart. The AI documents >> alone are a proof of that. This is all sounds like designing from an >> ivory tower. if you have not installed 100s of systems with jumpstart, >> and run those systems in production (i.e., it wasn't some lab exercise at >> Sun), then you're probably not the right person to redesign jumpstart. >> > > Casper, > > Bluntly, that's simply incorrect. There is ample knowledge of > how people use Jumpstart--and what does and doesn't work there. There's > also a willingness to step back and make sure that we're solving the > correct problem, and that problem is not "how is it done currently > in Jumpstart". The "let's build on what people currently do" approach > didn't get us to dTrace, ZFS, or (at least in the case of Solaris) IPS, > and isn't the obvious right answer for AI either. It may end up being > the right answer, but if we don't ask that question, we don't know. > > Would you like to be part of the solution, or just make more rude > comments about my team? I'd suggest the former as a more productive > use of everyone's time. > > Please let me know if you have questions or need more information. > > Thanks, > Eric >
