Jordan Brown (Sun) writes: > That's one of our possible alternatives. In some ways, though, it would > be simpler for us to have an SMF implementation (even if it's a subset) > so that our various components would all plug into the same > infrastructure on all platforms, rather than having each component have > to have support for _both_ SMF _and_ some more traditional scheme.
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. Consider what happens if Sun delivers SMF on Linux and other vendors (with their own schemes, such as IBM's SRC/ODM) all do the same. Doesn't the user just end up with a mess? Do I "startsrc -s foobar" or "svcadm enable foobar"? Does anyone remember the semantics and whether the change survives reboot? If we were to do this, I'd very much prefer to see us create our own Linux distribution, and base it all on SMF. I don't think that's really a worthwhile project, but it'd at least be self-consistent. In the meantime, and in most cases, I'd expect portable software to deliver start-up and shut-down scripts that just do the right thing. The SMF 'wrapper' for a script like that is trivial, as is the work involved in installing the script somewhere in /etc in order to integrate into the local administrative framework. 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. In other words, when in Rome, do as the Romans. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
