An installation nightmare story [LWN.net]

The installation nightmare story was a fairly common feature of the late-90's press. Some reporter who had never tried to install any sort of operating system before would write about his or her horrifying week trying to get Linux running on some system or other. The conclusion, invariably, was that Linux wasn't ready for the masses.

You don't often see that sort of story anymore; the mainstream distributions have become ridiculously easy to install. And, if you don't want to worry about installation, plenty of companies will happily sell you a system with Linux already on it. But that doesn't mean that all the problems have now been solved...

Your editor recently needed to replace a failing inkjet printer. Some time spent wandering the detailed information at LinuxPrinting.org turned up a reasonably inexpensive model which, according to the information there, "works perfectly." That is music to a Linux user's ears, of course. So, a quick trip and some minor credit card damage later, the printer sat on the table, ready to start burning through expensive ink cartridges.

I'll not inflict upon you the details of what it took to make this printer work on an almost-current Red Hat Linux system. In general terms, it required building new versions of CUPS and gimp-print from source, editing the PPD file by hand, and several other hacks. It took a couple days of effort. Now, your editor has been making printers work on Unix (and other) systems for a good twenty years. Printers have always been a pain. But this was worse than many.

It should be pointed out that, in a lot of ways, things are better than they have ever been. It is possible to put an inexpensive printer onto a Linux box, get top-quality output in all of the modes that the printer supports, and make it available over the network. Only a few years ago, doing this required hacking on filter scripts and learning more about strange ghostscript options than one would ever want to know. Now, most of the hard work has been done; it's mostly a matter of getting the right software running in the right place. The people working on Linux printing have done an impressive amount of great work.

But it's not yet enough. Users should not have to rip out their print system by the roots and rebuild it from source just to plug in an off-the-shelf printer. They should not have to navigate a complex array of software with names like foomatic, gimp-print, ghostscript, etc. and figure out how it all goes together. They should not even have to upgrade to a bleeding-edge distribution to make their printer work.

Windows users don't have to go through that sort of process. Of course, they have the advantage that their new printer comes with a CD containing the software needed to make that printer work. Linux users do not (yet!) receive any such courtesy. So we have to come up with a different way.

Some of the work has been done. The PPD files used by modern free printing systems contain much of the information needed to present an interface to the user. What's missing is a description of how to drive the printer. We need a means of describing printers in data, so that support for any printer is just a text file away. This was done for terminals a good twenty years ago; getting vi to work on a terminal was just a matter of setting an environment variable. Printers are harder to describe than ASCII terminals, but we've solved a lot of hard problems over the years.

Imagine a world where any Linux user can go to the store and buy a nice looking printer, along with plenty of spare flesh-tone, DMCA-protected ink cartridges. The system, once it notices that a new printer has been plugged in, goes out on the net and grabs the right description files. And the printer just works. That would be a system that is ready for desktop and home users. And it's something that we should be able to achieve.

to post comments

An installation nightmare story

Posted Apr 17, 2003 1:50 UTC (Thu) by mbcook (subscriber, #5517) [Link] (1 responses)

I have tried for years to get many printers to work under Linux, with no real success until recently. The only success I've ever had was with my HP LaserJet 2100. It has a JetDirect adapter (ethernet for those of you not familiar) and even then I never could get it to work well despite the fact that it supports PCL6. I could get it to work if it was attached, but not by ethernet. It wasn't until I got a Mac and bought a PostScript cartridge for the printer (so it would work with the Mac) that it works.

So now I can print just fine from programs in Linux to my nice little printer. You'd think I'd be happy. But it's still a pain to setup. It has it's on internal print server (lpd). It understands raw text and PS and even PCL 6, so it doesn't need ghostscript filters to print things. You'd think it would be very easy to setup by editing the apropriate files in /etc. You'd be wrong. After a week of fidling I gave up and setup CUPS and now it works. I'm glad it works, and it works great, but I shouldn't have to be running CUPS to run a postscript printer that RUNS LPD.

Sound support in Linux is MUCH MUCH easier than a few years ago. Almost every kind of hardware is supported under Linux and really not that hard to install if you have the driver. Except printers. With all the "winprinters" on the market, I'm not suprised if it would be hard to set one of those up without a program like CUPS, but a PS printer? We've still got some work to do.

An installation nightmare story

Posted Apr 17, 2003 3:28 UTC (Thu) by komarek (guest, #7295) [Link]

Oh no, you've brought back memories of getting sound to work in the mid 1990s. AAAaaaaaaaggghhhh! Printing was easier in the mid 1990s, back when a DeskJet 500 had six buttons on it and photo printing wasn't a concern. When I recently bought a printer, I bought a black-and-white PS laser (Lexmark) and only had to copy the PPD file from the lexmark CD to the right directory in CUPS. However, I understand where the inkjet owners are coming from, given the nightmare of cheapening engineering that goes into modern inkjets.

As for printers that handle PS and supply a standard lpd server, it's tough to see what could go wrong. But since there are computers involved, it's always possible for something to go wrong. =-)

I'm excitedly watching as wireless networking (for multiple profiles) and ipsec approach truly easy configuration.

-Paul Komarek

Epson Stylus C82

Posted Apr 17, 2003 3:37 UTC (Thu) by yodermk (subscriber, #3803) [Link] (1 responses)

I got a C82 in January. It was recognized by Red Hat's Kudzu (in RH8) and worked with the C80 foomatic/gimp-print driver with CUPS. It was a little confusing which driver I should select, and I've been using Linux for years. That shouldn't be.

Upon installing RH9 (fresh install, not upgrade), and going into Red Hat's redhat-config-printer program, I could easily add a C82 and not have to worry about anything else. Works great.

The thing costs $150 and supposedly costs less per page to operate than most other models. Output looks great.

Epson Stylus C82

Posted Apr 17, 2003 8:16 UTC (Thu) by keithw (guest, #3127) [Link]

But the trouble I had with my C80 when it was new is exactly like what's described in the article - downloading, building, trying to mash components & drivers together. Eventually it got sorted in a later version of redhat - I guess your C82 experiences are good because the C80 driver is already sorted & the C82 is just a minor varient. The process with a genuinely new printer doesn't seem to have improved.

An installation nightmare story

Posted Apr 17, 2003 17:32 UTC (Thu) by iabervon (subscriber, #722) [Link]

It seems like sound support has been solved recently, printing support may have just been solved, and wireless ethernet support might be solved soon. Is there code that can be shared between these fields? It seems like there ought to be standard practices for most of the steps involved, from "how do you find the info on a device" to "how is the info on a device formatted" to "how do you store user preferences for a device"; then the people working on support for a particular kind of device only need to think about the things that makes their kind of device special (how do you detect the device and figure out what it is, what properties does such a device have), and we can skip straight from no support to good support without a stage of lousy support (when support is in place but needs to be managed by hand).

An installation nightmare story

Posted Apr 18, 2003 0:16 UTC (Fri) by liamh (guest, #4872) [Link] (1 responses)

I've setup several printers in CUPS without problems (admittedly though, not an inkjet). However, one thing I've noticed about CUPS and linuxprinting is that you are steered towards generating your own ppd file. I don't understand why; all manufacturers have their own ppd file, and it's on that CD you think is not for Linux users, or it's on their web site. Look under Windows 2000 (Windows now uses PPDs), dig around, and you'll find it. Dump that in /usr/share/cups/model, run the cups configuration, and everything should work. I don't understand what you mean by "What's missing is a description of how to drive the printer" - isn't that what the ppd does?

It is very nice to have all the interaction options that Windows and Mac users have in, e.g. selecting duplex, types of paper, etc. I like qtcups for doing this, but there are several GUIs. The options can also be selected from lpr on the command line.

An installation nightmare story

Posted Apr 18, 2003 6:16 UTC (Fri) by mcisely (guest, #2860) [Link]

What you describe works fine for native postscript printers, all of which have PPD files. In that case I agree - I've been running an HP 6MP Postscript printer that way for a long time, and the PPD is all you need.

But non-postscript printers don't come with PPD files, thus something else has to be "mashed together". If gimp-print directly supports the printer, then the CUPS gimp-print driver plus its enclosed printer-specific PPD file is enough. I have a C80 printer working this way, all nicely color-balanced even.

If however gimp-print doesn't support the printer, you're left hacking your way through a foomatic configuration and THAT is not easy. I've got an HP Photosmart 7550 here that I've gotten to work with a foomatic-driven filter that pumps to the HPIJS driver, but I spent days getting that to work correctly. It works well in Linux now. GIMP works with it too, provided I supply GIMP with the foomatic PPD file (otherwise with the "generic" Postscript PPD all the printing comes out too greenish). Why can't GIMP's print plugin just fetch the PPD data itself from CUPS? The API is there in CUPS. But I digress...

Just right now I've been working on getting that %##$&&@ HP 7550 to work from Win2K using the canned CUPS-Samba Win2K driver as the front end. I've already spent about 4 days struggling with it. The HP 6MP and the Epson C80 work perfectly this way, but the CUPS-Samba driver mysteriously fails on the foomatic-generated PPD for the HP Photosmart 7550. The cups.org web site is of no help - they specifically disclaim anything regarding the foomatic PPD files, even though the file passes CUPS' validation page.

After 4 days I've given up on doing the Windows side the "clean" way, and now I'm trying to load HP's native driver to Windows, with raw printing through CUPS. But %%@@!!@@! now Explorer crashes when I try to bring up its property dialog.

Yes, I definitely agree with the author of this article. Printing setup is still a pain is the *ss.

And don't get me started about Windows network printing setup :-)

-Mike

An installation nightmare story

Posted Apr 18, 2003 11:09 UTC (Fri) by jdthood (guest, #4157) [Link]

May I add that a lot of printer-related documentation is
confusing? There is no standard terminology used for the
various processes involved in printing. Translation of data
from one language (PCL, PostScript, ASCII) to another is done
variously by "filters", "interpreters", "processors" and "drivers".
Transport of the data is done variously by "drivers", "printers",
"interfaces", "backends" or "spoolers". And what is used to
connect it all together? "Foomatic".

Printer installation support

Posted Apr 18, 2003 19:38 UTC (Fri) by wa1hco (subscriber, #3628) [Link] (1 responses)

I tried posting a question in one of the printer support mail lists. Sigh... The reaction was the typical, "You must be a little slow, because I'm not have any problem over here, and I'm the author of the software." I reviewed the archive and they gave that same answer to many questions.

That was about 3 years ago and I haven't tried since...been waiting for the major distributions to catch up. Redhat 9 sorta supports my mainstream HP inkjet. I know because it mentions the model number specifically. Too bad the print doesn't come out right. I'm not going to try to debug it...printing must not be that important.

Asking for help

Posted Apr 18, 2003 20:28 UTC (Fri) by corbet (editor, #1) [Link]

Something I should have mentioned in the article (I done forgot) was that I asked a question on the linuxprinting.org forums, and got useful help fairly quickly. There are people out there who are willing to give a hand.

An installation nightmare story

Posted Apr 24, 2003 8:39 UTC (Thu) by job (guest, #670) [Link]

I would be interested in hearing more of these stories. The idea with a termcap
for printers is very good. This is probably something we should bring up with
the Ghostscript drivers. I don't know how much intelligence each driver
requires or if it's easy to describe in a text file, but given the speed of Perl and
such utilities it should definitively be possible. I have never used the newer
printing systems such as foomatic or cups, but aren't they just gs in a fancier
suit? Have they got support for easy (read: gui) selection of paper trays,
duplex modes, quality settings and such?

An installation nightmare story

Posted Apr 25, 2003 15:17 UTC (Fri) by grant (guest, #10894) [Link]

Right, so there's lots of work underway along the lines of many of the suggestions made here.

Basically, most of the infrastructure necessary exists, and it's now a question of extending the set of described printers and getting all the distributions to ship something that works (and ideally pretty much the same thing). There's also (finally) a volunteer updating the Printing HOWTO, and other work happening on the somewhat scattered docs at LinuxPrinting.org.

As for what exists and where it's going, there are three main parts:

CUPS is the spooler with the best "user experience". This is Mike Sweet's baby, and it's a good one; the kinks seem to be settling out, and it works well for a wide variety of uses. It's very plug-and-play for PostScript printers; non-PostScript devices are a bit tricker but also work well.
Foomatic is the driver/printer data-driven glue thing some folks are suggesting. It is a large database which describes all known free software drivers and many printers, and includes tools to cross-frobnicate any pair of these and spit out a working configuration for several spoolers. It works really well in the one distribution that uses it as intended: Mandrake. The latest Red Hat and probably a few others ship a sort of CUPS-specific subset of the universe of cross-frobnicated printer/driver data; this too works fairly well. (ObDisclaimer: I am the original author of Foomatic).
It should be noted that almost all of this project is done by one guy - Till Kamppeter of Mandrake, who took over Foomatic after I got busy. Tracking all the drivers and printers in the world is a huge, neverending, thankless task, and Till is seriously swamped. If anybody wants to help, pipe up!
Gimp-Print (from Robert Krawitz et al) and HPIJS (from HP itself) are the leading inkjet drivers in town. There are, however, a whopping 200-odd free software printer drivers in the world. Few distributions ship them all; few printer manufacturers can be expected to ship the necessary dozen compile permutations necessary. We still have no good solution beyond kicking distributions to ship all drivers and provide frequent updates.

Anyway, if you're wondering how to improve things, these are the projects to volunteer for...

An installation nightmare story

Posted Apr 28, 2003 23:51 UTC (Mon) by EricBackus (guest, #2816) [Link]

The problem was solved for terminal 20 years ago. Except that two separate and slightly different solutions were creates (termcap and terminfo). Now, 20 years later, there's not so much need for termcap/terminfo, since nearly all terminals are variants of ansi/vt100. But even now, 20 years later, terminals still usually don't work quite right. Somewhere there will be an incorrect setting for what the backspace key returns, or F1, or the home/end keys. There are so many places that these things can be set and/or overrided that tracking down what's wrong is beyond the abilities of most users. So people put up with minor breakage and move on.

So what I'm saying is I think printers are going to be a problem for quite awhile. They're less standard and more complicated than terminals, and they're still a moving target.