[ubuntu-us-ut] Grievances: Upstart, Launchpad, and Misuse of anacron

Charles Curley charlescurley at charlescurley.com
Mon Sep 13 22:06:36 BST 2010


On Mon, 13 Sep 2010 14:07:56 -0600
Aaron Toponce <aaron.toponce at gmail.com> wrote:

> On Mon, Sep 13, 2010 at 12:48:17PM -0600, Charles Curley wrote:
> > Why do Debian and Ubuntu have this screwy setup where cron calls
> > anacron if it is present? Let anacron run at boot and otherwise let
> > crontab do things.
> 
> First, let's make it unequivically clear that the cron daemon Debian
> is using, as well as most other GNU/Linux operating systems, is
> heavily, _heavily_ patched. The reason for this is Paul Vixie has
> stopped updating it years ago. So, Ubuntu moving anacron, cron and at
> into Upstart makes tons of sense.

Maybe Vixie considers it perfect. :-)

Perhaps a re-write of cron is in order. But I still don't see the need
to mush the clear dividing line between cron and anacron.

> 
> Second, can you be more explicit in what you mean "Debian and Ubuntu
> have this screwy setup where cron calls anacron"? There does exist an
> /etc/cron.daily/0anacron file, but this is so anacron can update the
> timestamps to know what has been run and what hasn't. Further, anacron
> does start on boot, as is evident by the /etc/init.d/anacron config.

See /etc/crontab, for the kludge used to run
cron.[daily|weekly|monthly].


> 
> > upstart is a mess. Give me good old System V startup code. I
> > understand how it works and can make it do what it wants. I find
> > upstart opaque and confusing.
> 
> I'll clarify it for you: Upstart is a push service. The big difference
> between Upstart and SysV is when an event is created, a service will
> start. With Upstart, if there are services that depend on the started
> service, it will start those too.
> 
> However, the service(s) will remain running, unless you've configured
> upstart to stop services on an inverse event, say pulling the USB disk
> from the port.

Maybe I'm dense here. SysV already handles service dependencies.

I'm not sure what events you are referring to. Starting and stopping
services because hardware is plugged in doesn't strike me as something
the startup code should do. We already have code that detects new
hardware and handles it, e.g. udev. If a device needs a service, let
udev launch it. E.g.: gpsd. If a service becomes unnecessary when a
device is removed, then let udev shut it down.

It it too late to have plea for simplicity in Unix design? What ever
happened to the Unix idea of having each program do one thing, only
one thing, and do it very, very well?

Windows and most office suites try to be all things to all men. As
a result, they are bloated, buggy, and often insecure precisely because
they violate this precept. I don't want it invading Unix.




> 
> Right now, Ubuntu hasn't taken full advantage of what Upstart can
> deliver. They've been playing it safe with SysV backwards
> compatibility mode, as has Fedora.

Wonderful. I'm not impressed with what I've seen so far.

> 
> > And launchpad is a slow opaque buggy mess. I've used a lot of issue
> > tracking tools, and launchpad is far and away the worst. Let's start
> > with a useless search that returns far to many false hits. I have
> > pretty much quit filing bugs partly because launchpad is so user
> > hostile.
> 
> Yeah, I'm not really digging Launchpad. I've always been curious what
> the point of karma was, why the navigation sucks so bad, and why the
> Ubuntu wiki forces you to use the Launchpad OpenID, rather than an
> existing OpenID account that you've already had.
> 
> I do understand why bzr came to be though. At the time, there just
> weren't any reliable or real solid distributed versioning control
> systems. Git wasn't invented, and Mercurial was resource intensive,
> and slow as hell. Others didn't deliver the features Canonical wanted.

OK, so allow the user to select his/her/its favorite VCS.

> 
> > Also management: apparently some of the people using launchpad don't
> > know how to use an issue tracking system, so issues that should be
> > marked closed aren't, etc.
> 
> I'm of the opinion that submitting bugs shouldn't be particularly easy
> or available. While making bug submissions easily accessible, you risk
> getting really lame bugs submitted (Ubuntu brainstorm anyone?) or
> nothing more than "+1" and "me too" comments. When you make it a
> hassle to submit bugs and to comment on them, then the noise to
> signal ratio decreases immensely.
> 

Not necessarily. When the issue tracking software is so lame
that it discourages people from filing legitimate issues, you have lost
good information.


-- 

Charles Curley                  /"\    ASCII Ribbon Campaign
Looking for fine software       \ /    Respect for open standards
and/or writing?                  X     No HTML/RTF in email
http://www.charlescurley.com    / \    No M$ Word docs in email

Key fingerprint = CE5C 6645 A45A 64E4 94C0  809C FFF6 4C48 4ECD DFDB
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/ubuntu-us-ut/attachments/20100913/bbce9342/attachment.pgp 


More information about the ubuntu-us-ut mailing list