De-lurking for a while... On Nov 20, 2007 6:56 AM, Liane Praza <liane.praza at sun.com> wrote: > > I believe the rough summary of the 3 main positions involved in this > discussion are: > > 1) "start/stop" is useful for novice admins and new users due to > familiarity with other systems. Either init.d or Windows (or > something else), and the goal is to be familiar, though not totally > abdicate the SMF model. This camp seems to be losing some steam > because of a combination of factors. Among those factors are > concern about guiding new admins towards temporary enables, and > the concerns from Rainer and Darren Reed that it neither helps > new users nor experienced admins. That's OK -- closing the bug now > doesn't preclude the ability to revisit later if new or more data > comes to light. > > (Whether this is an 'alias' for existing enable technology or not > is irrelevant. The functionality must be described to users in > terms of behaviour, not in terms of an alias.)
I'm no longer sure the familiarity argument is that strong. Originally my position was simply that "svcadm start foo" and "/etc/init.d/foo start" ought to behave the same. I still think that's true, but then why not simply let users use the "/etc/init.d/foo start" version (which might do all sorts of things, including issuing svcadm commands)? My experience getting users completely unfamiliar with smf to use the existing svcadm syntax is that they took to it far more easily that I expected. > 2) There's a mode which is useful for advanced admin/developer use, > which might map to a "start" verb in terms of some similarities to > historical behaviour. Its value isn't in familiarity, but in its > actual functionality while actively developing and debugging a > service. The requirements of this are still in progress, but > this group is quite certain that existing SMF functionality > available through svcadm cannot be leveraged to meet their goal. > > 3) "start/stop" verbs for svcadm are good if they fill a useful purpose, > don't lead novice admins down a path that leads to errors, and > don't lead to confusion or grave misunderstandings about the > general SMF model. But, are equally happy to see it go away > if it can't do all that and satisfy the other positions. (Just to > clarify on the above assumption about the SMF team being in camp > #1, I actually hold position #3.) I started out somewhere in camp #3, and initially the discussion was nudging me towards camp #1. Currently, I'm not even sure that I'm happy with camp #3 - I'm now convinced that if we can't really agree on what start/stop mean then introducing them can only be harmful. So abandoning start/stop (for now) seems sensible. As for #2, one thing that occurs to me is that it's not clear to me what the division is between adding more stuff into smf and building better stuff on top of it. Oh, and is there a url for the wiki that's been mentioned? -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
