[clue-tech] upstart

Nate Duehr nate at natetech.com
Mon Sep 8 22:04:24 MDT 2008


Dennis J Perkins wrote:

> 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.

That is THE MOST important part to any ISV trying to create BINARY 
software that works on any distro!  Linux/Unix is generally hostile to 
binary software in general, so it's not too much of a surprise to see a 
talented Unix/Linux admin as yourself surprised that it's important.

I agree with you however, that it shouldn't demand the libraries are 
used, just available and working...

> 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.

It takes a LOT of retraining for sysadmins, though... relearning 
something other than cron after almost 20 years of using it, and the new 
thing adds nothing a good scripter (sysadmin) couldn't do with cron and 
sysV?  ONLY if it makes the hard things EASY for more than just 
sysadmins... maybe then it's worth it.  If it's just to change things 
for change sake, it's not.

> 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.

Time to dump KDE/GNOME and "refactor" the desktop.  LOL!

> 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.

init itself does a great job of restarting things that need to run all 
the time, actually... /etc/inittab ... and an app written well enough 
not to run multiple copies of itself...

>>> 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.

If "not yet" is the answer, it shouldn't be the default then.  Leave 
SysV init and let the devs rip it out and replace it on their boxes 
until they have a COMPELLING reason to use the new one done for the rest 
of us.

Nate


More information about the clue-tech mailing list