This is going to be one of those postings that my mother wouldn’t have understood. But I thought I should save what I’ve learned today about setting up printers on Mac OSX 10.4 so I’ll have them next time around.

I was trying to solve two problems when printing from the Mac:

• When I printed to my Samsung ML-2151N, it would take minutes per page
• I couldn’t reliably print to my Brother MFC-7820 at all

I could, of course, print just fine from my Windows XP systems.

For the Samsung, I suspected I had a bad driver. The system showed three different drivers which claimed to be for the ML-2150 family, two of which had the same name. So I went to linuxprinting.org, which pointed me to the new Gutenprint drivers. I tried installing them, but trying to print failed. I suspect the problem was that I didn’t have a proper level of Ghostscript, but while reading the site, I eventually found a claim that there was a good Mac OSX driver on Samsung’s German site. After some searching, I found this page, which contained an archive of new PPD drivers.

I uncompressed it and tried to install the English-language file. It didn’t ask for permission to run as root, so the install failed; I tried again, this time just “installing” to my desktop. Then I dug into the file to find the actual PPD file at

~/Desktop/Library/Printers/PPDs/Contents/Resources/en.lproj/Samsung ML-2150 Series.gz

I needed to copy it somewhere the system could find it, and I also wanted to get rid of the bad drivers, so I went hunting, and discovered I had Samsung printer drivers in two different locations on the system:

• /Library/Printers/PPDs/Contents/Resources/en.lproj
• /usr/share/cups/model

I deleted the ML21xx drivers in both locations, then copied my new driver to the first location, since that’s where the installer wanted to put it.

And it worked — I can now print to the printer at something approaching full speed.

The MFC-7820N turned out to be much easier; Brother had posted a driver on this page. The page shows a PPD file and a CUPS driver, but they both link to the same package, which expands into a self-installer, which worked just fine (although it required a system restart, which probably shouldn’t have been necessary). I also found a firmware update, but I haven’t gotten around to trying it yet.

And in the meantime, I’ve also installed a new version of Ghostscript, just in case.

I remember when I thought I was going to treat the Mac as an appliance. *sigh*

I needed to install Red Hat Enterprise Linux 4 on a machine at work today; normally, that’s a very simple process, marked only by tedium.

Not this time. When I first tried running the install CD-ROM, the screen blanked and I couldn’t wake it up; a friend suggested using the text-mode installer to get around the problem. And, indeed, that did get me through the install — but then when the system booted, the screen went blank and I couldn’t wake the system up.

So I tried reinstalling, with no change; I even tried to use Ubuntu, but it died in the same way.

I thought it must be a hardware problem, but before punting, I asked for help. My colleague came down and walked me through the install, and we had the same results. But then she had a brainstorm — we booted into single-user mode successfully and compared the xorg.conf file on my machine with one that worked. And, sure enough, there were significant differences.

Apparently the KVM on this bank of systems lied to anaconda, so that the installer wrote a configuration file claiming that the display could work at frequencies which were far in excess of what it could really handle. I edited the file to specify horizontal rates around 35 and vertical rates of around 60, and all was well.

Then I changed /etc/inittab to only come up in runlevel 3, which would have worked, too; since I never plan to use the physical console again (it’s in a very loud and very cold machine room), there’s no sense in starting X there.

Moral of the story: don’t panic. And wear earplugs.