To CUPS or not to CUPS

John Gay jgay at celestica.com
Tue Jul 1 21:59:05 PDT 2003


>> >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).
>
No, I said that because out of two installations, I've had a 50% sucess
rate. But that is entirely my fault, not CUPS. But, as you mention, CUPS is
more difficult to install and configure properly than many Linux packages.
I don't think CUPS is 'bad', it's just not the easiest thing to set up.
Personally I would prefer to use CUPS to integrate with my KDE desktop.
>
>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 never said it was. CUPS is a complex system to handle complex
requirements. And it takes a certain level of knowledge to get running
properly.

>> 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.
>
If you've ever followed any of my discussions on programming, you'd realise
that I can't script my way out of a paper bag (-:

>> 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.
>
Yes, I can see that point. Also, there is a new update to the printing
minority report that is much cleaner, doesn't bash CUPS any more and quite
useful for simple setups. So maybe the emphisis should be on an over-view
of printing options that explains which printing solutions are best for
which set-up that then pointed the reader to the relevant detailed and
updated hint. Also, BLFS does not seem to include enough info to
sucessfully install and configure CUPS for everyone.

>> 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:
>
Depends on your persective.

>LPR dates back to the original BSD unix systems.  It is a mess and
>completely inadequate nowadays.  Nobody should use it.
>
I've heard this hinted at, but never this strongly. Point taken.

>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.
>
So for someone with a small setup, this would probably be simpler to setup.
Although the new printing from scratch hint is even easier.

>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.
>
And this the an attempt at the 'Be all, end all' printing system. For many
users looking for small simple systems, this is overkill. For people
setting up large networked systems, it's indespensible. For those of us in
the middle, having info to help point us one way or the other would be
helpful.

For myself, I plan to have a full KDE Desktop. As CUPS is well integrated
into KDE, it makes sense for me to use CUPS rather than LPRng or the
printing from scratch hint. But at the moment, BLFS does not cover enough
detail to get CUPS working for everyone. I've been reading about foomatic
and such at http://www.linuxprinting.org but I still don't quite get it
yet. The first time I installed CUPS, it just listed the print driver for
my Xerox M750 printer, along with hundreds of other printers. The second
time, it only lists a few HP printers and the gs and raw printers. And I
used the same sources both times, so I must have forgotten something.

As I said, CUPS is an attempt to simplify UNIX printing. But it's not the
first, probably won't be the last and only time will tell if it's the best.

Cheers,

      John Gay



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



More information about the blfs-support mailing list