James Carlson wrote: > Simpler for whom? It probably makes sense for those writing software > that has to deliver on multiple platforms, but I'd definitely question > whether it makes any sense for the _administrators_ of those > platforms.
Because our administration is complex even under SMF - at least, none of us could figure out how to start and shut down a set of related services with single SMF command - we already wrap it under our own administration interfaces. Were we to use an SMF-on-Linux it would remain hidden under those interfaces. (Presumably one could start a related set by having a service that depends on all of them, and then recursively enabling it. Shutting them down, OTOH, is a bit different. I think you could do it by having another dummy service on which they all depend, and then recursively disabling it. That would be ugly, though, having to know two different FMRIs to manage the application.) > Things only start to get complicated if you have to factor your > application out into multiple SMF services for dependency or > administrative control reasons. But that's certainly not a > requirement of SMF, nor a consequence of just having multiple > processes that make up a given service. Our application is indeed composed of multiple SMF services. I'm not sure how much of that is necessary, how much is misunderstanding, and how much is a legacy of N semi-independent components, but it's the situation today. > In other words, when in Rome, do as the Romans. Understood and agreed. The theory here (and this is just a thought, not a complete plan) would be to hide the SMF-ness and use it as a mechanism to make the software simpler. The practicality of that plan would depend largely on the difficulty involved in implementing the SMF subset... and so see the Subject.
