MacOS X — so right, and yet so wrong

My wife and I finally caved in and bought a new computer for her, an iMac G5. Her old, slow PowerMac running Mac OS 9 just couldn’t cut it anymore. The slowness, crashes, hangs, and nondeterministic behavior just finally got to be too much to bear. Also, now that the kids are starting to use the computer, it’s important to have one that’s good at keeping track of different users and has effective parental controls; Mac OS X, which the old PowerMac couldn’t run, meets both of those requirements.

There are so many things that are so very, very good about the iMac G5 and OS X (Tiger). It’s an extremely elegant design, and the keyboard and mouse are top-rate. None of this is surprising, since this is what Apple does best. Of course, it’s orders of magnitude faster and more powerful than the old computer. The UI is elegant and clean, and Safari is a pleasure to browse with. Overall, the machine makes an extremely good impression on naive users.

Alas, I’m not exactly a naive user. The iMac needs to fit into our home network, which is Linux-based rather than Mac-based, which means the iMac needs to be configured in ways that aren’t quite off-the-shelf. This is exactly the area in which Mac OS falls flat on its face. Once you stray from the bright line of the Right Way inscribed by the folks at Apple, things start to get messy. I’m not terribly surprised by this, since Mac OS 9 had the same problem, but I am disappointed.

Since I spent a substantial amount of time debugging and finding workarounds for some of the problems I ran into, I thought I should put them on-line for the edification of others who might be trying to do some of the same things I was trying to do. These problems are a mixture of little gripes that Apple should fix in a future OS X release, and bigger problems requiring workarounds to get work done.

• When I drag and drop a bunch of fonts onto the Mac OS 9 Classic System Folder, a dialog pops up telling me that one of the files I’m dropping has to be moved into a subfolder to work properly (i.e., the Fonts subfolder) and asking if I want that to happen. This dialog repeats for every single font I dragged and dropped, which is rather annoying when dropping a large number of fonts. The dialog should only display once, perhaps with a checkbox indicating the the answer applies to all, a technique which is already used in some other dialogs.
• When I drag and drop a bunch of files and folders onto an SMB volume, and one or more of the files can’t be copied or moved to the target location because their names have characters that aren’t allowed in SMB file name, I get a dialog telling me the operation couldn’t be completed because one of the files has a bad name, but the dialog doesn’t tell me the name of the problematic files, and other files which could have been copied / moved aren’t. At the very least, the dialog should indicate the name of the problematic file. Also, there should be an option to ignore problematic files and proceed with the copy. Even better would be a button to open the folder containing the problematic file so that it can be renamed. Or how about prompting the user for an alternate name for the file on the target volume? There are lots of ways the handling of this problem could be improved; what’s clear is that something needs to be done to handle it better than it’s handled now.
• I configured four accounts on the iMac, two for my wife and me and two for the kids. Three of the four accounts were able to see Classic fonts in OS X applications including the Font Book, but the fourth was not, and there was no discernable difference between that account in the other three. Attempts to enable the Classic fonts group in Font Book failed silently, i.e., did nothing and displayed no error message. I chatted with Apple Support, and at their suggestion tried removing all the preferences from the problematic account. That didn’t help. I even tried totally removing and recreating the account. That didn’t help either. Restarting the machine also didn’t help. I finally managed to get it to start working again through a combination of deleting the account, removing all folders and files on the hard drive with the deleted account’s username in them, restarting the machine, and then recreating the account. Font Book should have told me what was wrong, and Apple Support should have been able to help me solve the problem rather than forcing me to figure it out on my own.
• After installing PageMaker 7.0.1 in the Classic environment, I was able to print from PageMaker to a PostScript file using my own account, but when my wife tried to do so from her account, she got an error dialog: “Error 8315:16411 Can’t create temporary file”. I searched the Web about this and found several references to temporary folders filling up and using a tool like AutoPurge or Eraticator to clean them up. It turns out that neither of those was the problem. The problem was that the folder in which PageMaker was trying to create the temporary file was writeable by the person who installed PageMaker (i.e., me) but not by other people. Changing the permissions on the folder (the RSRC folder underneath the top-level PageMaker folder) with “chmod a+rwX” in a terminal window solved the problem. I imagine that addressing issues like this isn’t a priority for Apple, since they’d like people to stop using Classic, but one would think that after people have been using Classic for years, somebody at Apple would have figured out that there are permissions issues when a Mac has multiple users and come up with a fix of some sort.
• OS X uses CUPS, which is great, but it doesn’t understand the concept of letting a remote CUPS server interpret the PostScript, which is not so great. When you configure a remote IPP printer as a “Generic PostScript” printer in OS X, OS X does indeed transmit PostScript to the remote printer, but it tells the other end that the file is in “application/vnd.cups-raw” format, when I believe what it should be claiming is “application/vnd.cups-postscript” or “application/postscript”. The result of this is that when you configure OS X to print to a remote CUPS printer, what comes out of the printer is the PostScript language text, i.e., essentially garbage, rather than the formatted printout you wanted.
  Workarounds for this problem have been posted on the net. They involve either using the CUPS administrative interface (i.e., http://localhost:631/) to configure the printer as raw after creating it using the OS X Print & Fax GUI, or creating the raw print queue using lpadmin (lpadmin -p printer-name -v ipp://host-name/printers/printer-name). The problem with both of these approaches is that OS X isn’t quite sure what to do with printers created in this way, hence the next bullet item.

  There’s really no good reason why OS X should be unable to support printing properly to a remote CUPS printer where the rendering should take place on the remote end rather than the local end.

• OS X is supposed to allow Classic applications to print to OS X printers. The instructions for doing this say to select the “LaserWriter 8” driver in the Classic Chooser. Then, when a Classic application pops up a print dialog, all the OS X printers are supposed to appear in a drop-down so the appopriate one can be selected.

  Unfortunately, remote, raw printer queues created as described above don’t appear in the drop-down. Therefore, to print from a Classic application to such a printer, you have to print into a PostScript file, then double-click the file to open it in the OS X Preview application, then print it from the Preview application. This is rather sub-optimal.

• Of course, there were several inexplicable hangs, one of which required me to do a hard power-down, while I was trying to get everything set up. OS X may be more stable than OS 9, but it’s not rock solid yet.

I’ve submitted bug reports to Apple about most of these problems. One can only hope that they’ll actually address some of them.