Hello Till, all,
thanks for picking this up and pioneering on-demand startup in Ubuntu!
Unfortunately cups is probably the most complicated case for on-demand
startup, so I have some remarks.
Till Kamppeter [2014-02-03 18:11 -0000]:
> Blueprint changed by Till Kamppeter:
> Whiteboard changed:
> + tkamppeter, 2014-02-03:
> + (After discussion with xnox on Desktop Sprint) For on-demand starting of
> + daemons (avahi-daemon, cups, cups-browsed) instead of using Upstart
> + bridges (which can get rather complex and is still buggy in Upstart) let
> + them get started when the user opens the print dialog. Queues in the
> + network get all visible within around 5 seconds. Stop daemons when
> + dialog is closed, but let CUPS keep running for printing the job(s).
> + CUPS has then to remove temporary queues and close by itself when queues
> + empty out.
Will this only be done on the phone or the desktop as well? I want to
point out that starting daemons several times on demand like that is
not universally better than always having them running as we do now.
It trades using less memory against using more CPU/IO/battery as now
the daemon loading, linking, and initialization has to be done several
In a system with swap or plenty of memory (i. e. laptops) where you
want to optimize for power it's generally better to not constantly
stop and start services.
On a phone this makes much more sense of course, as printing from a
phone is a rare task, memory is usually scarce, and there usually is
The initial starting on demand is always fine of course, provided that
picking up remote printers is really that fast (it used to be 30
seconds with the old browsing protocol?). So perhaps as a compromise,
on a phone cups could still immediately quit after finishing its jobs,
but on a desktop it would just keep running for e. g. an hour before
it times out?
I assume cups would never auto-quit and always auto-start at boot if
you have printers that get shared remotely?
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)