Nick Christenson
November 23, 2004
I want to tell a little story about setting up a new printer for use on my home network. Frankly, there's really nothing for the reader to learn from the act of setting up this printer, but there is a point to this story, I promise.
For about a decade I had been reasonably happy with a printer I own, an HP DeskJet 660C, although the model isn't really important. Well, one day the power supply crapped out, and I took that as a sign that it was time to get a new printer.
The old printer was hooked up to a FreeBSD machine running the venerable BSD print spooler, lpr/lpd. Other machines on my home network were configured to spool to that printer. In the printcap entry for the printer was a call to a little filter script I wrote that determined if the input file was PostScript or not. If it's not PostScript, it gets dumped to the printer raw, hoping that the file is plain text. If the input document is PostScript, it would get fed to Ghostscript to be converted into a format the printer understood. Ghostscript didn't have specific support built into it for the DeskJet 660C, but it does support the Color DeskJet 550, and those settings worked well enough. Basically, this printing setup met my home needs, which were quite modest, for nearly a decade.
So, I bought a new printer. I was fairly happy with my old setup, so I tried to keep it reasonably close. I purchased an HP DeskJet 5650. The new DeskJet's don't have specific device support in Ghostscript any more, these days it seems we're supposed to use a utility called hpijs, Open Source software provided by HP, to do the translation for us.
Well, I messed around with this utility and got the device to do plain text printing, but couldn't easily figure out how to get it to support PostScript. I figure I probably could have gotten it to work, but I didn't know how much research and effort it would take to get it running. (As it turns out, I now believe the missing piece I didn't know about is an application called foomatic.)
Instead, it occurred to me that on my internal network I had a nice, stable Linux box running SuSE 9.1 to which I could probably connect the printer. I did so using YaST (SuSE's system administration GUI, "Yet another Setup Tool") to configure the new device. After spending just a few minutes figuring out how to make YaST do what I wanted, I got the printer set up without any real problems. Local printing worked.
Of course, now I'm using CUPS. This is a much more flexible and friendly printing system, but despite the reputation of lpr as being obtuse, CUPS is a significantly more complicated system. I still had a number of machines that use lpr for printing, so I wanted to configure cups-lpd to perform this translation on my print server. I couldn't figure out how to turn xinetd on in order to support this service, so I went back into YaST. After a few minutes of poking around, I figured out what I needed to do on the server, configured the print clients, and the whole network was happy again.
While I was very pleased to be able to print once more, and the new printer and print system worked extremely well, I felt more than a little uneasy. Harken back to the "old" days of Berkeley-based Unix printing, whether we're talking about BSD4.3, SunOS 4, or an OS of similar vintage. The lpr system was the recipient of a great deal of cursing by a generation of system administrators. Little documentation was available, it wasn't user friendly at all, its syntax, especially the printcap file, was tough to follow, and the error messages it would kick out when something went wrong very rarely seemed to have anything to do with the problem at hand.
On the other hand, in the great scheme of things it really wasn't terribly complex. Nobody ever wrote a book on lpr. Why? Well, because there isn't enough to it to fill a book. Heck, you could write everything there is to know about administering lpr, include the complete source code, and still not make a very thick book out of it. Yes, learning the printcap configuration was awkward. Yes, learning in what order to execute printer commands using lpc was tedious. Yes, learning what the error messages really meant was annoying. However, once all this was known, and there really wasn't that much to it, any junior SA could solve essentially any Unix printer problem with relative ease.
Here I am, though, having just got a new printer up and running on a Linux box, and I have only the vaguest notion of what's going on under the hood. I think just about everyone would consider me to be a pretty senior system administrator, but I couldn't easily figure out how to get cups-lpd working without using the GUI administration tool. Oh, I'm sure I could have rigged something together eventually, and there's probably documentation somewhere on the 'Net that would tell me how to do it correctly by hand, but I've certainly lost a significant measure of understanding of how my network works compared to the old setup.
Further, using only command-line tools, I believe it would take a great deal of research and poking around to figure out how to properly set up a CUPS printer from scratch. Of course, CUPS is significantly more advanced and flexible than lpr, but it's really not the complexity of CUPS that disturbs me. Making systems complex in order to make them more capable is a reasonable trade-off to make. What worries me is the lack of transparency into what's going on in my system. When I click in the GUI there are consequences. Services get turned on, files get created and moved around, changes get made. I don't know what these are. When something goes wrong, I don't know where to look, and I don't know where a problem might lie.
The use of tools such as YaST makes it much easier to diagnose and fix anticipated problems with simple solutions, such as installing a new printer. Just about anyone who isn't completely technophobic should be able to perform the basic printer setup steps just as I did. Moreover, the vast majority of problems that are likely to occur can be solved just as easily, and that's a wonderful thing. The same cannot be said about systems running lpr. However, not understanding the specific components and installation steps that make up my new printing service make it very difficult to diagnose and fix complex problems that the GUI author hadn't anticipated. We've given something up, and I fear that in many cases it's something valuable.
Basically, in many ways administering my SuSE box is a very similar experience as administering a Windows box. Once I find what I'm looking for I can make most changes using the GUI system. When those changes are made, I have very little idea what's actually going on under the hood. If the GUI can't solve my problem, though, I'm in some deep water.
At the same time, I hear very few concerns from my younger IT colleagues that system administration is opaque. This isn't because they really understand what is going on under the hood, it's quite clear to me that in general they have no more deep understanding than I do about these things. But, this fact seems to disturb them less. I've found others who fret as I do about the decrease in transparency in these systems, but almost all of them are old farts like me who remember the days when they could tell you what changes were actually occurring. These days, we seem much more content to attribute these changes to GUI magic.
The barrier to entry for me to understand the underlying system, diagnose the problem, and fix it has gone way up. Admittedly, my Linux box is still an open system, and that's a big plus. But, I fear that system administrators are no longer expected to know the inner workings of things like printing because the GUIs mostly work and complex problems are rare. When YaST can't solve a printing problem, though, what is to be done? Have we been reduced to "uninstalling and reinstalling"? Didn't we move to open systems precisely because this was something we disliked?
Right now if my printer really goes ape, I must learn and understand:
With my previous setup, I needed to understand:
Despite the fact that there are many very nice things about CUPS, for all intents and purposes these two setups had the same functionality. Really, they did the same things. One I understand, and its intricacies could be communicated to a fellow professional in a few minutes. The other is quite a bit more complex.
This is not a slam on the Linux folks who make a fine operating system. This is not a slam on the SuSE folks who make a distribution I'm happy to continue to purchase and recommend. This is not a slam on the CUPS folks who have built an impressive and flexible printing system. This isn't a slam on the HP folks who have tried to unify Open Source support for their printers. I also don't want to come down against creating user-friendly environments. However, I don't think that any of these things require a loss in transparency of the system.
Maybe I'm a curmudgeon who is getting old and slow. The environment in which computer systems operate these days is certainly more featureful than it used to be. These features come at a cost of reduced simplicity, and I understand and accept that. In the old days, system administrators used to distrust tools that didn't provide reliable information about what tasks they were performing. There seems to be less value placed on this today than there was, and this bothers me. I believe it should bother other IT professionals as well.