From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <200306200654.h5K6sq709001@augusta.math.psu.edu> To: 9fans@cse.psu.edu Subject: Re: [9fans] The new ridiculous license In-Reply-To: Your message of "Fri, 20 Jun 2003 11:52:33 +1000." <20030620115233.3dc850df.ggm@apnic.net> From: Dan Cross Date: Fri, 20 Jun 2003 02:54:52 -0400 Topicbox-Message-UUID: d246b0ee-eacb-11e9-9e20-41e7f4b1d025 > "On the other hand..." > > speaking as a (l)user, and sometime sysadmin, I have almost never had a > /etc/printcap -> lpr -> problem I couldn't fix simply. You must be very pious, as you escaped Dante's fifth level of hell, err, I mean transcript. :-) But seriously, here's an anecdote about the BSD printing setup. This is from my own personal experience. When HP printers with directly attached network cards first became available, it was thrilling. No more clunky serial or parallel cables strung up to the back of Sun's or VAXen or early model RS/6000's or whatever workstation du jour one was using; putting something in /etc/printcap pointing to a remote machine (the IP address on the printer) using port 515 seemed to work like a charm. Except for a couple of things, one of which Geoff alluded to but I'll give gory details on. The printer would only respond to one TCP connection at a time, and what's worse, it was single tasking. So you still needed to set up a central Unix machine to spool to the printer (using the print spooling protocol, oddly enough). The single tasking nature of the printer meant that if you spooled a file to it, and then tried to check the queue with lpq while it was printing, lpq would hang until it was done printing that job. Also, since you were printing to a remote printer, and lpd wouldn't run filters for remote printers (unless rm= was set to the local machine, which it wasn't, since rm= was set to the printer), you couldn't do any preprocessing on data sent to the printer. So setting up a filter to convert, say, TeX DVI files to postscript automatically once they were spooled flat out didn't work. The solution was to define a fake printer entry for a local printer, with its output file set to /dev/null (remember to create a new character special device file with mknod, using the null device's major and minor numbers so that /dev/null itself wouldn't be gratuitously locked by lpd!) and then set up a filter that would make a direct connection to the printer on your behalf (luckily, one could magically connect to port 9000 on the printer and just dump postscript into it), possible relaying status information from the printer to the local queue's status file. We had a perl script to do it all for us which was kind of neat. It would put the number of the currently printing page in the printer status file, so lpq could tell you how far through the file you were (a *big* improvement). Apparantly HP had some stuff that worked reasonably well, too, but we didn't use it. Overloading the if= filter, and doing content conversion there was easier than dealing with all the special file types and font options and so on that the LPD protocol sort of magically recognized (the list was woefully out of data; we had postscript and line printers, not Varian's or phototypsetters). In the intervening six or seven years, the situation has scarsely gotten better. It's still nearly impossible to just plug a postscript printer into the network and print to it from a Unix machine without fiddling around a bit. Sure, the interface might have gotten better, but the underlying technical problems are still there. Again, I think this goes back to the definition of `wrong' thing. A lot of people don't care if their sysadmin widget gives them a way to configure printers in a relatively painless way. You could be spooling stuff using the latter day equivalent of punched cards (oops, you kind of are with the Berkeley protocol...), and it wouldn't matter as long as it worked. However, to others, it would still be an incorrect solution because you have to put too many wrappers around it to get it to smell nice. > But the twisted train-wreck of filesytem-embedded pipes, sockets, binary > loaded files, non-optional filters, definitions files, logs which is SysV > printing control is even worse. Oh, don't get me started on that. I used to do ersatz ports of lpd to Solaris and other System V varieties because, even though the BSD printing subsystem was suboptimal, it was a lot easier to deal with than the SysV stuff. When Solaris 6 came out with support for /etc/printers.conf, we were all quite happy. We could finally set up a reasonable print spooler on some old recycled machine (usually an older model Sun running one of the BSD's) and have the Solaris machines point to that. It, in turn, would fan out to the network printers using the above mentioned setup. Clunky though the whole thing was, it was more reliable than the Solaris implementation of System V printing. Another interesting variety was AIX printing, where ``lpd'' wasn't so much a printing daemon as it was a generic batch queuing system. I remember once someone who was rather fond of AIX defending it to me by telling me, ``what other system do you know where you can kick off a batch job using lpr?'' My mind boggled and I utterly failed to come up with an appropriate response. I had already ported Berkeley lpd to my AIX machines. > CUPS is silly. Things designed by committee usually are..... > The problem is really with PRINTERS. people never quite got used to the idea > of write-only devices. Printers have to 'chatter' and also have to be slapped > around a bit to do things like [fold|spindle|mutilate] or optional headers, or > meta-state like "load font" or other crap. > > If thats taken out of the print spooler path, it can get much simpler. Well, in defense of the printers.... It *is* nice if they have some way to tell you that they ran out of ink or had a paper jam or any of the myriad of things that can go wrong in such a sensitive device with so many moving parts. That more or less implies that they have to talk back to you. However, I will agree with the idea of seperation of spooling duties, and ``talking to the printing device'' duties. The funny thing is that VMS did this pretty well. > Does anybody remember the piano-device to sit on an IBM golfball, and make > it a printer? I've seen IBM wine, but never golf balls. I didn't even know they were into sporting equipment.... :-) - Dan C.