[clue-tech] upstart

[dennisjperkins at comcast.net]

 -------------- Original message ----------------------
From: Nate Duehr <nate at natetech.com>
> dennisjperkins at comcast.net wrote:
> 
> > One problem is a lack of documentation.  I've spent some time searching the 
> web for information and I've got some notes assembled.  Some of it is clear.  
> Some requires testing to make it clear.  Some of this confusion seems to be due 
> to changes in upstart.  I really wish that people would put dates on their blogs 
> and documents.  It would make it easier to know that I am looking at obsolete 
> information.
> > 
> > The use cases seem to have been hastily thrown together.
> 
> Crappy engineering, exactly as Michael has been saying.  Make a real 
> case for replacing SysVInit BEFORE replacing it in multiple distros, 
> seems like it should have been more important than writing the 
> replacement code.

It's no worse than I've seen from some companies that we work with.  That doesn't justify it, it's just an unfortunate fact.
 
> Coders code, they often don't engineer.  It's a big difference.  I've 
> been saying that here on the list for a few years now... Software 
> Engineering often... ISN'T.  It's just slapping crap together.
> 
> No engineering standards/rules across the industry, little quality 
> control or REAL code re-use (avoiding bugs), no culture of engineering ...
> 
> ... just a culture of "hacking".
> 
> Fun, yes!  Professional?  No.
> 
> How would we all feel if Doctors used methodologies like the typical 
> Linux coder?  If computers are "running our lives" doesn't software 
> development at least deserve that level of care about HOW things are 
> done that there's some kind of oversight?

I think it's still on a level above politicians. :)

> Want to work on financial systems, you have to be Board Certified as a 
> Professional Software Developer, perhaps?

> It'll never happen.  Software devs aren't mature enough to realize that 
> it's even needed.  Shiny new toys are more important than stability and 
> standards.

Yep.  Like so much else in our lives.

> > Dependency information seems to be the traditional means of trying to modify 
> init.  I think a few people were already exploring this in the late 90's or in 
> 2000.  This can affect manual starting and stopping of services as well as 
> startup and shutdown.  If you want to start a service, are all of its 
> dependencies running?  If not, start them.  If you want to stop a service, does 
> it affect other services?  If so, do you still want to stop the service and 
> every affected service?
> 
> Dependencies are the application's problem, not the OS's.  And certainly 
> not some pseudo-manager that's released as part of the OS.
> 
> Or at least it HAS been.  Now we have to learn a new paradyme on someone 
> else's whim, I guess.

Yes.  Giving the system enough smarts to help.  

> > Upstart's use of events might be due to USB, which is event driven.  Plug in a 
> device.  Unplug it.  This causes events in the USB hardware which propagate to 
> the kernel.  And out to udev, if you are running udev.  After udev has created 
> or destroyed a device node, it generates an event and sends it out via D-Bus to 
> any interested program.  This would be Nautilus on Gnome, which starts 
> gnome-mount to mount a USB memory device.  KDE's window manager might do the 
> same thing, but a different program might handle this.
> 
> Kernel's job.  All of it.  Kernel needs to get smarter about hotplug and 
> USB.

No.  Some things are migrating out of the kernel for flexibility.  Devfs was in the kernel.  Udev is in user space.  I read that video drivers might be moved out of the kernel, or part of X moved in.  Isn't FUSE an attempt to move filesystems out of the kernel?

> > Linux seems to be converging on udev/dbus/HAL to handle hot-pluggable devices, 
> with DeviceKit to replace HAL in the goal of "making things just work".  This 
> triad impinges on fstab, /mnt, and whatever variant of init is being used 
> (sysvinit, initng, runit, upstart).  I know of two daemons that attempt to 
> handle LAN and wireless connections to make networking just work.  This might 
> affect the network bootscript.
> 
> Linux never "converges" on anything.  Give it two years and it'll be 
> something else handling this basic stuff (stuff that already by now 
> should "just work" like it sure seems to on my other commercial 
> OS's!)... but it'll take Linux another four years or more to decide to 
> stick with something, and even then, no guarantees.
> 
> How do you build any kind of quality products on that moving mudslide 
> where stuff changes without documentation all over the system on a 
> regular basis.

Isn't this the complaint some BSDers use?

> Are "bug" and "security" patches on all distros LIMITED to JUST fixing 
> the bug or the security issue?  Rarely.  Functionality and features 
> OFTEN change during security patches.  That's WRONG.  (Granted some 
> distros avoid this, but get slapped for "patching upstream's code" 
> instead of just releasing whatever the "latest and greatest" version is 
> to fix the security problem.
> 
> Continuation/Maintenance engineering versus Development engineering.  A 
> never-ending tug-of-war.

The same is true in hardware.  Why do they move things around on the dashboard and steering wheel?



> Does Upstart do parallel starts?  Is that REALLY the driving force 
> behind it's "uptake"?

Partly, to shorten the boot time. But they are also attempting to make it easier to install a package that needs a bootscript.  And maybe to remove it later.   The package maintainer doesn't know what will be on a system.  Package managers help a lot, but not with setting up the bootscripts, I guess.

If you write the job files to do parallel starts.  Just specify the same start trigger and the jobs will start together.  I think the only place where Ubuntu takes advantage of it right now is starting the ttys.

> Booting fast is easy... don't start up any useful software!  (GRIN)

You mean stop when the kernel is loaded?  :)