On Tue, Mar 4, 2008 at 9:23 PM, Rainer Heilke <rheilke at dragonhearth.com> wrote:
> Great, thank you. It has just been a while, so I merely wanted to know > the item hadn't been completely dropped. I haven't been on top of things > a lot (bad year), so the quick status update is much appreciated. Since > it is still on your radar, I'm sure it will happen "in the fullness of > time." ;-) I may ping every few months. (I should create a folder just > for things I want to keep an eye on. Wish I could code worth jack, so I > could help more positively.) > Heh, it's not the code that worries me -- it's the consensus building. If you feel like you could wrangle a cohesive plan with enough buy-in, I'd be more than happy just to "code up" whatever results. My impression is that this thing went around once before already, so I don't feel so bad that I couldn't get a unified approach through. And to my mind, this has some touch points with the impending "Enhanced profiles", so I think it make some sense to design carefully and purposefully here. The only personal investment I have in this is that I do miss the Windows-like (or /etc/init.d/ for that matter) functionality of just being able to start a service temporarily with full dependency "start"ing, but not have that persistent across reboots. That was one of the first conceptual hurdles I faced when learning SMF a few years back. I found my instinct to just "start the damn thing" had to evolve to "enable it to be runnable and trust the starter to start it". Yeah, "enable -t" is there, but the wording seemed somehow wrong to me, so I did a small mental shift so the "SMF way". But that's a small conceptual impediment compared to some of the discussion from other folks (whom I trust manage much larger sets of systems and services than I), so I tried to keep an open mind to identify real-world use cases and be passive about driving my own modest use case through. Maybe it does just need a slow simmer for a little bit longer. Reduce it down to the essential spices and flavors back there on that burner. That, and identify the decision makers and be more purposeful about it next time. Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/smf-discuss/attachments/20080305/14abe0ba/attachment.html>
