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.