[clue-tech] upstart

[Dennis J Perkins]

On Mon, 2008-09-08 at 18:10 -0600, Nate Duehr wrote:
> dennisjperkins at comcast.net wrote:
> 
> > I doubt that the 6 run levels used by sysvinit are necessary.  Almost everyone either runs in single or multiuser mode.  I read somewhere that the 6 levels (actually there are more but are not used) are modelled after some switching device that ATT or some company had, and someone thought it was a good idea to copy it.
> 
> I can guarantee it.  Debian's really only used two run levels since -- 
> oh, forever.  I doubt they'll be picking up this RH wackiness as their 
> new "standard" either.
> 
> BSD servers seem to get along just fine with a single start script 
> managing everything too, for the ultra-purists in the crowd.
> 
> This new startup stuff is nothing more than "vendor lock in" to RedHat, 
> if you ask me.

Red Hat?  Upstart was started by a Canonical developer for Ubuntu.  It
appears to be catching on in a few other distros now.  And not without a
lot of debate in some cases.

> (Uh oh, did I fan that fire?  Yep.  I went there.  RH wants to lock you 
> in just like MS did in the 80s.  Naughty naughty RH.  Well, naughty if 
> you didn't see it coming... and are somehow upset that they need a way 
> to differentiate themselves from the Linux crowd.  Duh.)
> 
> > Upstart can also handle the addition and removal of USB devices.  This is being done by udev or HAL in most systems but an upstart job can do it instead.  DeviceKit is apparently going to replace HAL at some point, but that is the extent of my knowledge about DeviceKit right now.
> 
> And those were broken, how that we need the system startup software to 
> handle USB devices for us?  (sigh...)

I was looking at how it can be done.  It doesn't appear to be a big
change.  A udev rule runs something like 
       "initctl block-device-added %k -eDEVNAME=%k",
which triggers an upstart job to mount the device.  Right now this is
done via HAL, but you could probably do it in udev too.  Maybe this is a
mqtter of where the mount operation should best occur... in udev, whose
primary job is to dynamically create and destroy device nodes, or in
HAL, whose purpose is to organize information about hardware devices, or
in upstart, which is already responsible for starting and stopping
services.  The Unix philosophy of "do on thing and do it well".  It
might also be easier to understand and modify if it is in an upstart
job.

> > Abandoning run levels runs counter to LSB.  I don't know if the big distros are 100% compliant, but some distros ignore it because they feel some of LSB is wrong.
> 
> LSB isn't "wrong" per-se, but there's almost zero economic advantage to 
> a distro following it.  Pisses off the software vendors and really big 
> ISV's to no end that no one does, though... they see Linux as a bunch of 
> disorganized crap.  (And only time will tell if they're right, but 
> meanwhile they don't release Linux software packages.)

Some of LSB seems irrelevent. Standardizing certain libraries?  It might
be more productive to simply say that these libraries must be present in
an LSB-compliant system.  Many distros are aleady using those many of
those libraries already.

The section pertaining to starting and stopping, and runlevels, could be
applicable to those FOSS programs that need to install a bootscript.
Except that not everyone likes runlevels.

> > The development of upstart started in Aug 2006.  It reached 0.5.0 this summer.  The development plan seems to be small, incremental steps.  Build the basic parts first.  Run it.  Refine it.  Redo parts that don't work as expected.  Kernel development is the same way.  Look at how many schedulers the kernel has discarded.
> 
> So you're saying "when you're lost in the woods, make small changes in 
> course and direction?"  I thought the rule was "hug a tree".  :-)

No.  Big changes are often harder to adjust to, especially if they are
buggy.  Incremental changes can be easier to implement.  Udev's
development also appears to be incremental, and while that has probably
been a headache for distros, it is more flexible than the old static dev
method, or devfs.  I don't know if many users have noticed the changes,
except that some things suddenly work automatically, like a window
openeing when a USB stick is inserted. 

> > One goal is to add time-based events.  This means cron capability is planned at some point in the future.  Replacing D-Bus, acpid, etc, are not planned.  They handle different tasks.
> 
> Damn, maybe the thing can replace emacs and be a complete OS someday. 
> LOL.  Isn't all this cramming all of this stuff into one application 
> contrary to the Unix philosophy of "small and good" and stacking those 
> applications to get something accomplished?

The justification is that there is little or no difference between a
device event and a time event.  I don't know if I agree with that.  That
depends on how it would be implemented.  It might mean that a
crontab-style program provides the user interface, and upstart is the
back end.  It might not take much more code to do this.  Maybe.

> (Or is the world now saying that they want one big monolithic "managers" 
> of the whole OS?  Isn't that the Windows OS model?  Methinks -- RedHat 
> doesn't have a freakin' clue what they're doing, but they'd die before 
> just stopping DOING stuff, just to change things and be annoying.  Of 
> course, they might ... since they gotta get paid for adding SOMETHING to 
> Linux, I suppose...)

Sometimes its a refactoring.  Instead of reinventing the wheel, refactor
by placing commonly used procedures into libraries.  This is one
advantage of desktop systems, even if some garbage gets dragged in too.

> > Upstart can track daemons.  Sysvinit cannot.  If a daemon crashes, upstart can try to restart it automatically.  The number of restarts can be limited.
> 
> Gosh, we've handled this by launching a process from startup that acts 
> as a parent to children for decades.  Even one of the commercial 
> products I work on does this, and really doesn't need a "manager" 
> handling it, other than the 20 line shell script some engineer wrote to 
> do it years ago...

The bootscripts don't monitor the daemons they start and restart them if
they crash.  If cron, postfix, postgresql, etc., crash, are they
restarted automatically?  Maybe some of them, but probably not all of
them.  And if upstart's init crashes, the kernel restarts it.  Hmm, I
wonder what effect that would have?  No matter.  Sysvinit would have the
same problem.

> > There are probably other things that could be mentioned, but I think this is enough for now.
> 
> So far, they're all not very compelling reasons to swap out SysV and 
> switch to this thing, really.

Maybe not yet.  And maybe initng, runit or something else will be
preferred by most people or distros.

> > As far as higher priority things needed to be addressed first, there are plenty of hackers out there.  Upstart is not distracting the kernel hackers, the KDE hackers, or the GNOME hackers.  Upstart and its competitors are the result of an itch by distro developers for a problem they appear to have with hot-pluggable devices and dependencies between some programs.
> 
> Ahh yes, the broken but often flouted "many hands makes light work" 
> model... except that it leaves out who's DIRECTING the many hands...

The people working on upstart, initng and runit aren't working on these
other projects anyway.  It's not the same as diverting limited corporate
resources to another project.  And I've seen some pretty poor decisions
made by people directing the hands.

> Oh well ... something (unnecessary -- again) to learn to support the 
> darling little "Corporate" Linux distro that loves changing things for 
> no good reason, I guess.  Wasting my time here, RedHat... but thanks to 
> the list, I at least know it's coming my way...
> 
> Nate
> _______________________________________________
> clue-tech mailing list
> clue-tech at cluedenver.org
> http://www.cluedenver.org/mailman/listinfo/clue-tech