Endlessly Underwhelmed by Software Updates

Here is my peculiar list of observances of the latest spate of Mac updates, specifically: Mac OSX 10.4.4 (which includes a 2.0.3 version of Safari), iTunes 6.0.2, and Quicktime 7.0.4.

Mac OSX 10.4.4:

• The bug wherein the Finder's "Inspector" (command-option-i) — which is supposed to dynamically update it's properties based on the selected file — does not update the view of the file's ownership and permissions, is still not fixed. Unbelievable. I'm pissed.
• The update, unsurprisingly, overwrote my "kill metal" Finder mod. No big, I guess. Just something I noticed. And for the record, the mod still worked after I reinstalled it.
• iChat active-window inconsistencies, I'm happy to say, seem to be fixed in the latest version included with 10.4.4.

Safari 2.0.3:

• Safari seems the same to me. I'm not sure what, exactly, is different, but it's nothing that affects me. The window placement bug is still there. And I still can't use the web apps I need to use with it. I'm sticking with Firefox 1.5 (I'm now on the G5 version).

Quicktime 7.0.4:

• Quicktime 7.0.4 features a new visual effect. When going into full screen mode, as the window grows, everything behind it gradually dims, much like the dimming of the background that happens when you use Exposé's "All Windows" function. It happens when you toggle out of full screen as well. It's pretty. I like it.

Quicktime 7.0.4: Nice Effect
(click for larger view)

iTunes 6.0.2:

• Honestly — and this could totally be my imagination — but iTunes seems to open a bit faster for me. Who knows? Maybe I'm just desperate for some kind of improvement here.
• The "multiple speakers" option is nice. But guess what? Doesn't work with videos; just audio. Still, better than nothing, I guess. We likey.

Really, so far, that's all I've noticed. There are some nice little touches, but all-in-all, considering we have updates to four fairly major applications here, and considering we have some rather longstanding bugs (the Finder Inspector is particularly glaring) still hanging around after several months, I guess I'd say I'm underwhelmed. And a bit disappointed.

Oh well.

Built-In Spell Check Ignores Built-In Dictionary

Here's a thing: Apparently, Mac OSX's built-in spell checker — you know, the thing that leaves all the little red dotted lines all over the misspellings in your text files — uses a separate dictionary than Mac OSX's built-in dictionary that pops up when you hover over a word and press command-control-d.

To wit: I was typing up my latest blog post and the spell checker bitched about this:

The Spell-Checker: Fandom Not a Word?
(click for larger view)

The little red dotted line means I've typed something that isn't in the dictionary. So, being fairly certain that fandom was both a word and that I'd spelled it correctly, I hovered and pressed command-control-d and got this:

The Dictionary: Oh, But it is!
(click for larger view)

See? See that? I was right! Stupid spell-checker! What do you know?

But seriously, I find it somewhat strange that the spell-check dictionary differs from the OS dictionary. I realize that the spell-check one is customizable, whereas the OS one is not, but it seems like they should at least start off the same, doesn't it?

Or maybe it's just me.

Tiger Lab Migration Part 11: Panasas Crashes and Caches

The last time we visited this topic, I thought we were done. Well, turns out I was wrong.

Things are, for the most part, working well now. Finally. We're running Tiger and we've managed to iron out the bulk of the problems. There is one issue which has persisted, however: the home account RAID.

To refresh, our network RAID, which is responsible for housing all our users' home account data, is made by a company called Panasas. Near as I can figure, we've got some experimental model, 'cause boy does it crash a lot. Which is not what you want in a home account server, by any means. After upgrading the Panasas OS awhile back, the crashing had stopped. But it was only temporary. Lately the crashing is back with a vengeance. Like every couple of days it goes down. And when it goes down, it goes down hard. Like physical-reset hard. Like pull-the-director-blace-and-wait hard. Like sit-and-wait-for-the-RAID-to-rebuild hard.

Again: Not what you want in a home account server.

So we've built a new one. Actually, we've swapped our backup and home account servers. See, awhile back we decided it would be prudent to have a backup of the home account server. Just something quick 'n' dirty. Just in case. This was built on a reasonably fast custom box with a RAID controller and a bunch of drives. It's a cheap solution, but it does what we need it to, and it does it well. And now we're using it as the new home account server. So far it's been completely stable. No crashes in a week-and-a-half. Keep in mind, this is a $3000 dollar machine, not a $10,000 network RAID. It's not that fast, but it's fast enough. And it's stable. By god it's stable.

And that's what you want in a home account server.

Moving to the new server — which, by the way, is a simple Linux box running Fedora Core 4 — has afforded us the opportunity to change — or, actually, revert — the way login happens on the Macs. In the latter half of las semester, we were using a login hook that called mount_nfs because of problems with how Mac OS X 10.4.2 handled our Panasas setup, which creates a separate volume (read: filesystem) for each user account. Since we're now just using a standard Linux box to share our home accounts, which are now just folders, we have the luxury of reverting to the original method of mounting user accounts that we used last year under Mac OS X 10.3. That is, the home account server is mounted at boot time in the appropriate directory using automount, rather than with mount_nfs at login. Switching back was pretty simple: Disable the login hook (by deleting root's com.apple.loginwindow.plist file), place a Startup Item that calls the new server in /Library/StartupItems, reboot and you're done, right? Well, not quite. There's one last thing you need to do before you can proceed. Seems that, even after doing all of the above, the login hook was still running. I could delete the scripts it called, but it would still run. Know why? This will blow your mind. Cache.

Yup. It turns out — and who would have ever suspected this, as it's so incredibly stupid — login hooks get cached somewhere in /Library/Caches and will continue to run until these caches are deleted. I'm sorry, but I just have to take a minute and say, that is fucked up. Why would such a thing need to be cached? I mean maybe there's a minimal speed boost from doing this. The problem is that now you have a system level behavior that's in cache, and these caches are fairly persistent. They don't seem to reset. And they don't seem to update. This is like if your browser only used cached pages to show you websites, and never compared the cache to files on the server. You'd never be able to see anything but stale data without going and clearing the browser cache. At least in a browser — 'cause let's face it, this does happen from time to time (but not very often) — there is always some mechanism for clearing caches — a button, a menu item, a preference. In Mac OS X there is no such beast. In fact, the only way to delete caches in Mac OSX is to go to one or all of the various Cache folders and delete them by hand. Which is what I did, and which is what finally stopped the login scripts from running.

If this isn't clear evidence that Mac OS X needs some much better cache management, I don't know what is.

In any case, we're now not only happily running Tiger in the lab, but we've effectively switched over to a new home account server as well. So far, so good. Knock wood and all that. Between the home account problems, the Tiger migration, and getting ready for our server migration, this has been one of the busiest semesters ever. Though I keep this site anonymous because I write about work, I just want to give a nod to all the people who've helped me with all of the above. I certainly have not been doing all of this alone (thank god) and they've been doing kick-ass work. And, though I can't mention them by name, I really appreciate them for it. At the dawn of a new semester, we've finally worked out all of our long-standing problems and can get down to more forward-looking projects.

So ends (I hope) the Tiger Lab Migration.

Spotlight Problems with Networked Homes

Well, I had a feeling this would be a problem. Spotlight is having trouble with our networked home accounts. Actually, that may not be entirely accurate. Spotlight is probably also having problems with the sheer number of users in our networked lab. Basically, the Spotlight indexes on user accounts, which reside on an NFS mount, are failing all over the place. We've got mds crash logs on all our systems as a result of these failures, and mds tends to freeze a lot and cause Finder beachballs. I think what's going on here is this:

User logs in. Spotlight begins to index user's account. User plugs in firewire drive. Spotlight begins indexing that. User then unmounts firewire drive, and logs out. Spotlight's all like, "What the fuck? Where'd everybody go. I'm crashing now." And that's when we see our mds crash log.

On my own personal networked home account, this whole state of affairs has rendered Spotlight completely useless. As in, I can't search for shit. As in, command-space, search-for-term yields nothing, anywhere, ever. Using Spotlight on a local account on the same machine works fine, though. So clearly my Spotlight databases are okay, at least the local ones. And clearly there is something about networked stuff Spotlight does not like.

My understanding was that Spotlight was supposed to never index networked volumes. So believe me, I was surprised to find it indexing our home accounts. Perhaps, since they're mounted via NFS, it was unaware that they were network volumes (which would be incredibly stupid). I don't know. But it sure is confused now.

Ironically, now that Spotlight has become completely useless in our lab, it's gone from being one of the most excitement-generating features of Tiger, to one of the most ignored here. Once again, it's lack of configurability, it's premature release, and Apple's continued ignorance of multi-user environments has given this product a head start on the road to obscurity. Remember how cool we all thought Sherlock would be when it started taking after Watson? But then Apple just ignored it, and now it's gone the way of the Dodo. (Does anyone ever use Sherlock anymore?) I don't think Apple will do the same kind of thing with Spotlight. It's got way too much potential, and way too much press to let languish. But if they do with Spotlight what they did with Sherlock, it will wither and die, as has Sherlock, and as I can already see Automator doing. (Is anyone using Automator these days that didn't already use AppleScript?)

What all these technologies have in common is that 1) they rely on third-party developers to develop for them before they really become useful, and 2) they are essentially there to make our lives easier, not harder. If either of these things doesn't come through, the product stagnates. Of all these technologies, Spotlight is the least relaint on third-party development to be really useful. So its incumbent on Apple to really see the product through. Apple needs to get to work on this, and fast. They really need to make Spotlight work better, and they really need to make it way more configurable. It needs to work better for the folks who don't want to configure it -- the folks who just go to Google and use the regular search field. And it needs to be more configurable for the power users, the lab admins, and the folks who use Google's advanced search.

As an admin, all it's done for me so far is create extra work. I'll be spending this week devising a method for turning off Spotlight on our networked home accounts. And that's not exactly what I'd call productivity enhancement.

Command-Line Smackdown: cp vs. ditto

There are a couple methods for copying files via the command-line in OSX. The standard UNIX cp command exists, as it does on all *NIX systems. Historically -- that is, through Mac OS X 10.3 -- it's had certain limitations with regards to the HFS+ filesystem, however. Specifically, the cp command was never able to handle resource forks common to that filesystem. Any files copied via cp would have their resource forks stripped, which in some cases would render the files useless. The solution was to use a Mac-specific command called ditto. When supplied with the proper arguments, ditto can copy files and retain their resource forks. It's a great tool, with a lot of other features, and I use it all the time.

In Mac OSX 10.4 (Tiger), cp -- and most other UNIX commands -- have been enhanced to remedy the HFS+ resource restrictions. Using cp to copy files in Tiger (or between two systems running Tiger) will handle resource forks quite seamlessly, and the command works just as it would on any *NIX system. So I've been trying to revert to using cp like a regular UNIX fellow, but I still find myself preferring ditto, for a few reasons.

The ditto command has a few idiosyncrasies that anyone who's coming from traditional UNIX and is used to cp might find distressing. Indeed, I initially found them to be confusing. The main difference lies in how each command specifies the copy behavior for files in directories. The cp command uses a trailing slash to indicate that the contents of the directory -- but not the directory itself -- are to be copied to the specified location. So a command like this:

cp -R /Users/systemsboy/ /Users/test

will copy the files inside the systemsboy directory to the test directory. Whereas:

cp -R /Users/systemsboy /Users/test

will copy the directory systemsboy and its contents to the test directory.

This is a nice way to do things. It's how most *NIX commands work, and to my mind makes a lot of sense. But it is not how ditto works. The ditto command doesn't care about trailing slashes at all. The ditto command always copies the contents of a directory. So, following the example above:

ditto -rsrc /Users/systemsboy/ /Users/test

will copy the contents of systemsboy to test. And so will:

ditto -rsrc /Users/systemsboy /Users/test

I repeat, ditto does not give a shit about the trailing slash, and always copies the contents only. The two above commands, therefore, function the same, trailing slash or no. So, if you want to copy the entire systemsboy directory to the test directory, you must say so thusly:

ditto -rsrc /Users/systemsboy /Users/test/systemboy

Here you are specifying a directory that does not exist. If you tried to do that with cp you'd get an error message stating that the directory didn't exist. One nice thing about ditto is that it will create the directory for you. There are other niceties as well.

The ditto command, by default, preserves mode, access time, permissions and all other file attributes. If you want these functionalities with cp, you'll need to specify them with the -p (preserve) flag. The ditto command also has other uses. For instance, ditto can be used to create a .zip file of a directory that is comparable to those created in the Finder.

So, despite the fact that the latest versions of standard UNIX commands included with 10.4 are resource-fork aware and can finally be used as they would on any *NIX system, I've become accustomed to using commands included by Apple to mitigate the previous lack of support of the standard UNIX ones. The ditto command still has a very useful and important place in my admin toolbox, and I continue to use it in favor of cp in many situations. It's tried, it's true, and I trust it. And it will work with previous versions of the Mac OS.