On Sep 20, 2007, at 7:55 PM, Andrew Sackville-West wrote:
my dirty little secret is that I've *never* had trouble with CUPS and
don't understand all the problems that people have. Some of it I think
is just inertia (used lp* for a long time why should I change) which
is perfectly reasonable, IMO. And I do agree with those who think that
there are many printing solutions and the heavy use of cups as a
dependency is not a good thing.
But for me it just works. shrug.
I hated it at first. I've since found that the automatic
configuration tools some distros try to use with it are generally
junk, and I'm usually better off going to the CUPS web interface and
dealing with it directly. Now I greatly prefer it to mucking around
with /etc/printcap and trying to set up filter packages by hand.
When I was using lpr-style printing systems, lpd always seemed to be
the flakiest daemon on the system. I remember frequently having to
restart it to clear hung jobs and stuff like that. That rarely seems
to happen with CUPS.
CUPS does have some warts, though. Having to figure out the proper
URL for your printer is NOT user-friendly and requires a level of
knowledge that not everyone has. Few printers have any obvious
documentation to tell you if you should be using socket://, ipp://,
or lpr://, and what queue name you should be using. And despite its
vaunted auto-detection capabilities I've never seen CUPS auto-detect
anything on the network -- even printers that readily show up on
Windows and MacOS X systems are invisible to CUPS unless I give it a
URL. (This may be due to security-conscious distributions turning
off auto-detect or blocking the ports, though.) Printing to SMB
shares on Windows servers is also painful to set up and doesn't work
very reliably, especially if the Windows server is part of a domain.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
