On 03-Apr-04 Graham Trott wrote:
A cautionary tale for anyone producing end-user software. Also an amusing and informative read.
The follow-ups on this thread have mostly headed off into irrelevant territory. For instance, whatever I may think about ESR's views on, for example, the right to own and use a gun, if he writes a spendid piece of software (and I'm not offering any views on whether he has or not) then I will be very happy to enjoy using it and give him the credit for writing it. Likewise if he writes a good and well-aimed article.
To come back to the main point of the above URL. This article is good, and very accurately aimed.
First of all, it is the best documentation on CUPS I have seen. In fact, it goes a bit further towards hinting about how you might just possibly get CUPS to work, having once failed, than the official CUPS documentation does, and a lot further than any help the GUI offers. Not that I think it would fully guide me through solving the problems I encountered. Also, it states up-front the one thing most people need to know about CUPS: "You may well not get this to work".
A summary of my own experience. I have two desktop boxes D1 and D2 at home, a laptop L, and an ethernet LAN that all three happily inter-communicate over. L is the machine I mostly sit at, and it also holds the files for much of the work I do since I can then take all this elsewhere if needed.
L is a reincarnation of a previous L (L0) which suffered major brain damage from ECT (in the course of one of those on-off-on-off events in the mains supply which our Anglian electricity so often serves up in the really rural areas; I now have L double-buffered via two Belkin surge suppressors; A and B are on a UPS anyway).
L0 had RedHat 7.1 on it, A has SuSE 5.1, and B has SuSE 7.2: all good sound stuff from some years back and (here is the point) all printing via good old LPD/LPR. Configuring this was no big deal once you sussed out a couple of things, the main one being that you need to edit /etc/printcap in a fairly straightforward way for which the "commented" examples in the file provide good prototypes. The 'man' page for printcap tells you all you need to know.
The physical printer is a PostScript laser on B's parallel port, and duly so specified in B:/etc/printcap, as "lp". On A (and on L0 previously) there is a corresponding "remote printer" entry in /etc/printcap on each machine: very simple to set up and, as ESR hints, if you need to change anything, running "kill -HUP lpd" causes lpd to re-read the printcap file. Also, since the printer itself does PostScript, no need to interpose a filter to convert into other printer languages: a lot of Linux software generates PS by default and if you need to print say a text file then utilities like "enscript" will generate it for you and (by default) send the output to "lpr". So it's a "raw printer". From any one of the three machines, "lpr <PS file>" duly and promptly produced hard copy as intended.
When L0 went gaga from the electricity accident (now just usable as an "archive" machine in text-only mode with a substitute motherboard salvaged from a different model), I bought L.
I also adventurously purchased RedHat 9 thinking that upgrading would be a good idea while I was at it. Installation seemed to work OK, and I blandly accepted the default installation of CUPS. Everything fine until it came to the stage of "setting up the printer". I think I accurately selected the GUI options for the printer, essentially remote networked raw printer queue using UNIX LPR/LPD. Cometh "Print test page". Outcome "header page rejected". Tried "lpr <PS file>" from L: nothing. The job simply sits at L and never gets seen by B.
The only way I can print from L is as follows:
On A (or B), NFS-mount L:/home/ted on say /mnt. In an xterm logged in to A (or B), cd /mnt/whatever. Then "lpr <PS file>". This works.
Literally days of work spent groping through the CUPS documentation on L (both what is available in the CUPS GUI and in the 'man' pages and studying the maze of config files in L:/etc/cups) got me nowhere except confused, annoyed and frustrated. I still cannot use CUPS and have given up hope on it. I suspect that the nub of the problem is that neither A not B is running CUPS -- simply the old-style LPR/LPD system -- and the protocol that CUPS uses does not talk properly to this (or I have failed to find out how to get it to do so). Quite possibly, despite my impression at the time of printer setup, I failed in some way to accurately select the GUI options for "remote networked raw printer queue using UNIX LPR/LPD."
But neither the GUI, nor its documentation, nor the man pages, nor the study of CUPS config files, got it right at the time nor sorted it out subsequently.
At one stage I thought: since I was offered the option to install CUPS and could have chosen not to, let's try uninstalling it and dropping back to old-style LPR/LPD instead (which RH9 says you can install instead). Tried that. Failed. It seems that once CUPS is in there you can't eradicate it, and you can't get LPR/LPD to work.
Eric Raymond's blast against CUPS struck me as totally accurate; it mirrored faithfully so many of the experiences I had suffered.
He uses this experience to justify a polemic against the way that Linux developers seem to be going. I don't think I agree with the extent to which he seesm to generalise the problems exemplified by CUPS to the whole of Linux software development. But in my view he is certainly spot-on about CUPS and, to the extent that similar problems arise in setting up other features of a Linux system, I would completely go along with him to that extent.
His main point, that Linux developers -- and especially those aspiring to provide a "mountain guide" GUI for ascents which may have perilous moments -- MUST pay attention to those tricky passages where some, experienced climbers as well as "tourists", may lose their hold or deviate onto a false route, is well made and perfectly sound, and is a valid warning. For expert guides to turn their back on their charges at critical moments, and allow them to venture unguided into risk from which they cannot recover unaided (and then not provide rescue), is not only unacceptable in terms of developer responsibility but will also quite deservedly create a reputation that Linux is a snakepit which even the moderately experienced computer user should not climb into.
The whole point about CUPS is that, acronymically, it is supposed to be a "Common Unix Printing System", capable of crossing the frontiers between different ways of doing the job and establishing effective security guards at the frontiers (and this means BOTH turning back undesirable intruders AND allowing in legitimate entrants without undue hassle). CUPS may or may not be good at the first (I can't tell), but in my experience it fails at the latter; I'd sooner use a printing system devised by Beverley Hughes.
Best wishes to all, Ted.
-------------------------------------------------------------------- E-Mail: (Ted Harding) Ted.Harding@nessie.mcc.ac.uk Fax-to-email: +44 (0)870 167 1972 Date: 04-Apr-04 Time: 14:40:06 ------------------------------ XFMail ------------------------------