Announcing printerd

Posted May 22, 2012 14:21 UTC (Tue) by aaron (guest, #282)
In reply to: Announcing printerd by cthart
Parent article: Announcing printerd

Some reasons, off the top of my head:

Not enough daemons. (If history is a guide, printerd would run in addition to the various CUPS daemons, "just in case.")
Nobody's announced a new daemon in weeks.
We need more core services that depend on DBUS and GLib.
LPR is so last century, y'know?
Linux printing works too well.
Force everyone to go graphical/PDF, since we don't need to support receipt/invoice/check/line/Braille printers anymore.

Tim's code looks good, and I'm quite certain he is sincere in his intent to improve things, but it does lead me to wonder: how much code + innovation + promotion does it take to troll the Linux community?

Announcing printerd

Posted May 22, 2012 15:11 UTC (Tue) by mbt (guest, #81044) [Link]

Not enough daemons? How long will it be before this code gets merged into systemd?

If all your users are sitting at seats around your single host, you don't need network transport for reaching printerd/systemd. It can even wake up your printer when you start printing.

Argh! With all these daemons around, we need an exorcism.

Announcing printerd

Posted May 22, 2012 15:19 UTC (Tue) by nye (subscriber, #51576) [Link] (3 responses)

I hope you'll forgive the stupid question: why does this need to be a daemon at all? What gain is there from a constantly running process rather than an executable launched when required?

Announcing printerd

Posted May 22, 2012 15:35 UTC (Tue) by drag (guest, #31333) [Link]

I suppose you have a way to manage the print spool centrally rather then trying to deal with lock files and whatnot to avoid race conditions when you have lots of programs kicking off print jobs simultaneously.

Normally I am happy to see new developments, but I personally really don't understand the point. The 'print spool' itself has never been much of a problem.

It's the printers themselves and the applications needed to properly support print jobs.

Like: I have to print labels in a automated manner on a Xerox Laser using PCL. Or a home label maker. Or if I want to use a Lexmark printer in Linux or the dozens and dozens of things that Linux tends to really suck at.

The task 'Add or remove pdfs from print spool' doesn't strike me as a problem that users had to overcome in the past. Other then the fact that the GUIs for selecting printers and printer features are miserable, tend to be missing controls, and have no consistency.

Announcing printerd

Posted May 22, 2012 15:39 UTC (Tue) by gioele (subscriber, #61675) [Link] (1 responses)

> why does this need to be a daemon at all? What gain is there from a constantly running process rather than an executable launched when required?

From the dbus homepage:

> D-Bus […] makes it simple […] to launch applications and daemons on demand when their services are needed.

Announcing printerd

Posted May 22, 2012 23:05 UTC (Tue) by lindi (subscriber, #53135) [Link]

From doc/TODO: "Service termination when no clients or jobs running".

Announcing printerd

Posted May 22, 2012 16:14 UTC (Tue) by randomguy3 (subscriber, #71063) [Link]

> 1. Not enough daemons. (If history is a guide, printerd would run in addition to the various CUPS daemons, "just in case.")

Although printerd can be on-demand, due to the D-Bus interface. Or it could provide a cups compatibility layer.

> 6. Force everyone to go graphical/PDF, since we don't need to support receipt/invoice/check/line/Braille printers anymore.

Presumably applications where that is relevant wouldn't use printerd's D-Bus interface, but talk to (and require) cups directly.