======  openprinting.org: LPD Must Die! ======

I'm starting a new campaign--a crusade for the death of LPD.

LPD has a number of problems:

  *  New security flaws are discovered way too often for a critical system daemon that's been around for over a decade.
  *  It is a support nightmare; there are more flavors of LPD out there than I can count, and more vendor-specific hacks and configuration tools than anyone could possibly support.
  *  As if to add insult to injury, it's gratuitously devoid of actual features.

\\ Unfortunately, there are no perfect alternatives to LPD. And ideal replacement would:

  *  Be secure, both by design and in implementation.
  *  Offer lightweight and efficient IPP and LPD (the protocol) service.
  *  Offer a simple and extensible interface for filters, drivers, accounting, queue management, etc.
  *  Support a selection of clients; ideally with a client library offering job operations and printer status and capability information.

The three current alternatives are LPRng, CUPS, and PDQ.

LPRng and CUPS are the primary competitors; both offer IPP and LPD protocol service, a structured and extensible filter and driver interface, accounting features, and queue management. Both are not well tested on the security front; CUPS is brand new with a limited security design, and LPRng, while designed for security, is rumored to suffer from spaghetti code and a lack of external maintainers. CUPS offers the best client functionality of the two; LPRng offers little client support beyond the traditional ''lpr'' client.

PDQ offers excellent client and filtering facilities, but lacks management and queueing features. These can be added by bolting PDQ onto another spooler; PDQ plus LPD is actually not a bad combination.
=====  Recommendation =====

I ask vendors to commit to offering a viable alternative to LPD ASAP. For now, this will mean shipping one or more of the imperfect alternatives described above (actually, some vendors already do). Hopefully the wider exposure given to the spoolers from this first step will help boost the development efforts needed to adapt or create a complete good system. Only at that point may we sensibly discontinue shipping LPD.

Similarly, I ask vendors to join in an open discussion around configuration and management issues. There are many (6-12, at least!) ongoing configration-related projects; it would be nice if we could cut this number down a bit (ideally to one!).

Finally, if you are a Linux distributor; please either participate in the open discussion or email me to keep in touch. It's //very// important that we reach a consensus about what a good system is and what the parts are so that we can have a bit of standardization across distributions. The current state of affairs is dreadful.
=====  Discussion! =====

Let's discuss how best to go about this in the [[http://www.openprinting.org/forums.cgi?group=linuxprinting.general|general forum]] here on openprinting.org. (If traffic warrants I'll create a dedicated forum.)