To CUPS or not to CUPS

Steve Bougerolle steveb at
Tue Jul 1 21:03:01 PDT 2003

On Wed, 2003-07-02 at 03:33, John Gay wrote:
> >CUPS is not that hard.
> Yes it is (-; 

No, CUPS is really not that bad.  I think it just seems bad to you
because you are judging it by the standards of a simple single-user
utility instead of seeing it as the huge and complex server package that
it is.  CUPS is harder to configure than, say, vi or fcron but it's at
about the same level as other server software like Samba, and
significantly easier than configuring things like SQUID or BIND.  (And
it's absolutely trivial compared to Qmail but there are different
reasons for that).

LPRng, in comparison, is easier to get going at first, but if you need
to make any sort of significant change to the setup you will quickly
start pulling hair out and longing for CUPS again.  (LPR doesn't rate on
the scale at all any more).

Having said that, DO make sure you have the latest version of CUPS. 
1.1.19 is significantly better and more stable than 1.1.18, which in
turn was better than 1.1.17 and so on...  The drivers for CUPS (and for
Linux generally) are under constant development, too, which partly
explains that and also suggests you should look for the latest version
of those.

Now it's a fair point to say that a lot of people don't need a complex
network printing system and it would be nice to have something simpler -
but this is not a problem with CUPS.

> I had the experience of building two LFS systems on identical
> PC's, using the same printer. I used the same sources, followed the same
> steps. The first time, CUPS listed the correct driver for my printer by
> it's name, Xerox M750. The second time I spent three weeks trying to get it
> to connect to the same printer before I gave up. Obviously I must have
> skipped something the second time, but I still can't figure out where.

Script the installation.  I do this routinely for all server packages
now, just to avoid this problem.  They ALL have a pile of configure
options  and it's generally pretty easy to lose track of how you built a
server, then rebuild it the wrong way.  Scripting is the answer and it
works very well.

> Yes there are other how-to's and hints, but they are scattered over the
> 'net, many of them are dated, and there are holes in the info. As I
> suggested, if the few people here who know UNIX printing got together and
> put together a generic printing document that covered most of the bases,
> and explained what was happening and why, this would help a lot of people.

Yes, but not for very long at all because Linux printing software is in
a constant change of flux, with VERY heavy development going on in a lot
of different areas.  It would probably be at least as productive simply
to check the hints every couple months and remove any that are
dangerously out of date.

It is a mess, I agree, but there really is no simple good solution to it
that will keep everyone happy.

> I, and many here obviously, would prefer to use CUPS for printing. Of
> course others would prefer something simpler like lpr or lprng. 

Whoa whoa whoa.. you've got this exactly backwards.  Here's the history:

LPR dates back to the original BSD unix systems.  It is a mess and
completely inadequate nowadays.  Nobody should use it.

LPRng was the first attempt to replace it with something modern.  It
works quite well but predates a lot of Linux development and isn't very
scalable or flexible.  For example, adding new drivers or backends or
filters to it can be a pain.

CUPS *IS* the attempt to simplify this mess.  Despite its flaws (mostly
bugs) it is a nice (relatively?) well-organized system for printing AND
it takes advantage of the latest standards.

Steve Bougerolle <steveb at>
Creek & Cowley Consulting

Unsubscribe: send email to listar at
and put 'unsubscribe blfs-support' in the subject header of the message

More information about the blfs-support mailing list