[clue-tech] upstart

[Nate Duehr]

Dennis J Perkins wrote:

> Sorry, I'm not an admin.  I program PLC's. :)

Smart guy.  Staying down "there" with the hardware means your bugs are 
your own.

Me, I'm as close to the end-user as it gets.

Recently watched a GCC bug take down some very expensive systems that 
previously had been using Sun's compiler.  But not during 
testing/deployment... AFTER deployment.

(The silly thing wouldn't post-increment variables on a Sun box 
properly, so all variable++'s had to be quickly replaced for ++variables 
and the code checked to make sure it'd work, or modified for an 
emergency patch to a VERY expensive system... it caused some LOVELY 
behavior that was VERY subtle in the field... thanks GCC)...

It took an engineer a day and a half (including time to package and 
release through any semblance of a NORMAL release cycle) to fully fix it.

Meanwhile, my end-customer is down... all the way down, once the reality 
of what was happening to their data and systems was found.

> Upstart's job files might be simpler than regular bootscripts.  That's
> why I might install it and play with it to see how good and easy it
> actually is.  Or how many problems it has.

Ever seen software WITHOUT problems?  :-)  SvsVinit had MOST of the crud 
worked out of it and focused on one small job.  Not twenty.  Complexity 
breeds bugs.

> I haven't seen any info on how they plan to try cron-style stuff.  They
> aren't even focusing on that yet.  But if crontab can talk to upstart,
> maybe the interface will be the same.

Or perhaps they could just leave cron alone?  Cron works.

> Think about it.  They have a common printing library, or it's
> incorporated into a bigger library, so every program can provide the
> same interface instead of reinventing the wheel.  The same is true for
> fonts, window layout, widgets...  Now why did I even mention
> desktops? :)

They are both using the SAME common printing library, aren't they? 
(CUPS)  CUPS was probably more a "good thing" than bad.  GNOME/KDE still 
fighting over the desktop is retarded.

> If it's in inittab.  But what if it's started by a bootscript
> in /etc/init.d?

Move it where it belongs for the task at hand.

> Ubuntu and Fedora are still running in SysV compatabiity mode, so the
> traditional /etc/init.d and /etc/rc.d still works.  

With RH still skipping straight to a run-level without running anything 
in the preceding runlevels which it's done for years, instead of doing 
what the commerical Unix's did at the time... proceed up THROUGH the run 
levels... (sigh)... even SysVinit had to be "different" than everything 
else out there first...

> Inittab itself is
> mostly gone.  Only the default runlevel line is left.  There are a few
> tty jobs in /etc/event.d to handle the old tty lines.  At the
> moment, /etc/event.d seems to only be used to replace what inittab did.
> Unless you run Frugalware, which decided to push the envelope and see
> how far it could go.

Sigh.  Thanks for the warning.  :-)

Nate