[clue-tech] upstart

[Nate Duehr]

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.

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?

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.

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

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

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

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.

> In some cases, such as servers, or security-sensitive sites, some of this automatic operation might not be wanted.
> 
> 
> I like my computer to boot fast.  Ubuntu is slow compared to Arch.  I think Arch does not start as many services.

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

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

Nate