[NTLUG:Discuss] init differences

[Chris Cox]

On Mon, 2009-09-14 at 23:05 -0500, Leroy Tennison wrote:
...
> It's obviously been a while since this message but that's been work - 
> busy (which is far better than worried about an imminent layoff).  Tell 
> me more about stupidity and hideous.  What are the drawbacks to 
> dependent runlevels?  I knew they replaced scripted init with something 
> (I heard they called it the registry - if this is true: Really, REALLY 
> bad move after M$ use of the term).  What is it and what is hideous.

System V runlevels are independent states.  The are NOT interdependent.

Thus when Sun made runlevel 3 dependent upon runlevel 2, they were
simply showing their lack of understanding of what Sys V runlevels are.

More embarassing than anything.  However, because of the dependency, you
just had to remember that with regards to anything you might do with
regards to Solaris runlevels.  IMHO, the only reason they didn't fix
their mistake was PRIDE.  Which is what I believe ultimately led to
their demise.

The SMF replaces the idea of runlevels, however Solaris still supports
runlevels... (not sure if it maintains their warped view between
runlevel 2 and 3 though... my guess is probably so).

There are MANY problems with the smf.  For one thing you can no longer
write scripts to control startup and shutdown (unless you use the
obsolete runlevel integration).  The problem is that it's not nearly as
visible to the user what exactly Sun is doing when starting their
services.  And some services do not operate correctly under smf.  One
goal of smf is to automatically restart services.  Thus it is like a
watch dog process that makes sure when a service dies that it is
automatically restarted again (IMHO, it's better to just have services
that don't mysteriously die).  They referred to this as "self healing"
and it's supposed to make you want to use Solaris.  Service
configurations for inetd are also moved into the SMF... again, less and
less is visible, more is hidden and thus "friendly"... I guess according
to Sun.

I also think the idea of smf was to create a cross SUN (Sun only of
course) mgmt platform.  Sun always believe that they, and not
Microsoft/other, should dominate the datacenter as the ONLY platforms.
Thus they were always looking for ways to lock the customer into their
world.  That was another goal of smf.

Finally, smf objects are supposed to allow you more granular fine tuning
of security and probing rights, etc.  This sounds like a good thing in a
way, it's just that when you have a simple security paradigm, an
administrator can develop security policies and constraints more easily.
The SMF adds a heavy layer of complexity that makes it VERY diffcult to
actually determine the security... you know?  So what they did for our
"good" actually shields us from knowing exactly what is going on....
sigh...

Oh.. and SMF is in a high state of flux.... changing, fixing, etc.