[sf-lug] SF-LUG meeting notes for Sunday 7 January 2018

Rick Moen rick at linuxmafia.com
Mon Jan 8 14:53:17 PST 2018

Quoting acohen36 (acohen36 at SDF.ORG):

> IIRC, Jackie was trying to get a Xerox printer, its driver(s), and
> its managing software recognized in 16.04.3 Ubuntu.  First Bobbi S
> and Ken S were trying to use the LPRng commands 'lpc', 'lpq', and
> other commands to see what they could do on Jacki's Toshiba (see
> [02], [03] and others.) They then investigated using CUPS [04] to
> better activate the software recognizing the Xerox printer.

I'm a little curious about why LPRng?  

Short history of Unix printing, from memory so not guaranteed completely
accurate in all details:

Berkeley Unix (BSD) emerged as one standard architecture for printing
'Berkeley printing system' or 'lpd' for short, with commands lpr
(command to print), lpq (show the print queue), lprm (removes a print
job from queue), and lpd (daemon).  In introduced the lpd printing
protocol (still supported by the various other printing systems).

Meanwhile, AT&T System V gave us the riveal 'System V printing system',
or 'lpr' (alternatively 'lp') for short.  It had two daemons (whose
names I can't remember), one for scheduling and the other for remote
printer communication.  User commands were lp (command to print), lpstat
(show the print queue), cancel (removes a print job from queue), lpadmin
(configure print system), and lpmove (move jobs among multiple print

Both of these simply sucked, being difficult to configure correctly and 
diagnose.  The Berkeley system was generally more popular because of
being simpler and better-built, even though the AT&T rival was heavily
pushed by proprietary Unix interests including Sun Microsystems with

Around the time Linux came around in the '90s, we had LPRng as an effort
to drain the swamp.  It was mostly based on the Berkeley system (despite
the 'lpr' name reference, with emulation of the best parts of the AT&T
system.  This noble effort was stared and run by Patrick Powell until 
2005 when he orphaned the project, and was considered to suck... less.
New developers revived the project in 2006 and have continued to
maintain it.  And we-all used it with gratitude for Powell's work
(because it sucked... less) but not a lot of enthusiasm.

Meanwhile, a short-lived small firm named Easy Software Products (which
was mostly one guy, Michael Sweet) released CUPS (Common Unix Print
System[1]) as a fresh, from-scratch approach starting in 1999, and was
immediately and enthusiastically adopted by practically all Unixes 
including Macintosh OS X (but not Free|Net|Open|DragonflyBSD, which
stuck with lpd)... because it doesn't suck.  It's easy to administer,
has a built-in Web interface, and easy to setup and debug.  The
scheduler and queue contiue to support popular printing methods from
Unix history including lpd-type printing, and it added its own
quite-good IPP (Internet Printing Protocol) printing type, that routes
print jobs over HTTP/1.1.  For backwards compatibility, it emulates 
all Berkeley and AT&T print commands.  

It was, in short, a completely successful fix to the problem of Unix
printing sucking, while losing nothing anyone wanted.  Easy Software
Products closed up shop in 2007 and handed off the CUPs codebase to
Apple, Inc., which continues to maintain it as open source.

Also in the 2000s, coder Jacob A. Langford brought out another fresh,
better approach, a simple, lightweight printing system called 'PDQ', 
standaing for 'print, don't queue'.  Langford's point is that almost 
nobody actually needs a print daemon with job queuing.  Just send the
job directly to the printer, man.  Printers tend to have, y'know, RAM
to store and spool out print jobs, so it's not necessary to have system
software to do that, too.  I wish PDQ had remained viable, but it seems
to have been unmaintaine for 11 years.

So, anyway, I'd not personally touch LPRng without a really good reason,
because there's compelling history about why it got replaced.

I would use CUPS -- _and_ (critically) be really careful about printer
selection to avoid walking into dependencies on brittle proprietary
drivers.  Which is the theme I'll cover next:

> I see that the former linuxprinting.org website is now managed by
> the Linux Foundation and is now the OpenPrinting site [05]. The
> OpenPrinting site has a comprehensive FAQ at [06] that I think will
> be very helpful for Jackie's and others' printing needs under Linux.

Like everything that Linux Foundation takes over, Grant Taylor's
linuxprinting.org site has become vastly _less_ helpful and useful under
LF management as www.openprinting.org .  For example, Grant had some
pages explaining why certain B&W laser printer models were excellent
choices for Linux on account of durability, low price, and avoidance of 
dependency on proprietary secret sauce and other specific makes/models
really sucked.  All gone.

Also, Grant's linuxprinting.org site was really clear about which driver
choices were heavily proprietary and which were not, making it a key aid
to intelligent printer shopping.  The carryover of his linuxprinting.org
site to www.openprinting.org cannot be bothered.  Here's a small


  works Perfectly        
  Recommended Driver: hplip 

Grant would have warned you that hplip is an 'open core' codebase where
the basic engine software is open source but most supported HP printers
& scanners require separately downloaded proprietary & binary-only
'plugins' housing HP's secret sauce tricks.  

www.openprinting.org cannot be bothered, because Linux Foundation
doesn't care about Linux users and open source, only about corporate
sponsorship money and its own self-perpetutation.  Rob Landley explains
the problem, here:

> The OpenPrinting site also has a list of specific Xerox printers
> that are "Penguin-rated" for Linux compatibility [07]; all the way
> from a Perfect three-Penguin rating down to the Paperweight
> null-Penguin rating.

Beware of proprietary traps.  Unfortunately, LF has punted on open

Here's an example, color 600x600dpi laser printer Xerox Praser 6280.

  works Perfectly        
  Recommended Driver: 6280_Linux.tar

What does 6280_Linux.tar have in it?  You can't find it there because
the download link is broken, the View PPD file link is broken, and the
Directly Download PPD link gives you a zero-length file.  In some cases,
this reflects a file being a temporarily offered, proprietary,
binary-only filter directly from the vendor that nobody else even had
the right to redistribute let alone maintain, hence it was a mayfly.
This is typical.  Stuff gets EOLed and then vanishes.  However, in this
case, Xerox merely moved  6280_Linux.tar to a different download
location and Linux Foundation never noticed:

It turns out, the tar archive contains a single file,
Xerox-Phaser-6280-1.0-1.noarch.rpm, which in turn contains:


Now, I've not bothered to poke further, but I can confidently predict
that the PPDs are proprietary. Searching the Web for discussion reveals
large number of problems with them.

[1] Official word since 2012 is that 'CUPS' no longer stands for
anything, because the custodians of the trademark over the word 'UNIX',
wankers named 'The Open Group', raised a fuss over licensing.

More information about the sf-lug mailing list