Are We Beta Testers?

Apple's Mac OS X v.10.4 -- or Tiger, as we affectionately call it -- has been out for a few months now. I've been testing the Hell out of it, and I, like so many others, have found a plethora of bugs and minor issues with the new OS. My attempts to solve these problems often land me on a number of The Usual Websites, not the least of which is Apple's own discussion forums. One of the most frequent complaints I hear on these sites is that Apple's initial release of any given OS is a beta version, and that we in the Mac community are all just beta testers for Apple. So, is this true?

I'd say the short answer is yes. I don't think this is entirely a bad thing, however, but I do have some problems with it.

When the latest, greatest version of just about anything -- a cell phone, a computer, a hard drive, what have you -- comes out, there are bound to be some little problems here and there. Operating systems are certainly no exception. In fact, because new operating systems are expected to do so many things and support such a wide variety of activities, as well as be innovative and better under-the-hood, as it were, they are perhaps the products most prone to these initial glitches. I would argue that the only way to properly test such a product is, ultimately, in the field, i.e. release the software to the general public for final bug testing, compile a list of complaints, and then fix those issues, in order of priority, with point releases. Indeed, this is what Apple does. It's also what Microsoft, Adobe, Macromedia, and everyone else does. There's simply no way for Apple to test the immense array of possible problems that even the most basic user is apt to encounter. The range of hardware and software combinations is simply too great. Sure, these bugs make me cranky from time to time. But I'd say, for the most part, Apple's quality control is pretty decent when it comes to OS releases, and their update system is pretty efficient as well. Overall, I'm fairly happy with the way Apple handles their OS releases.

There is one area in which, however, I feel Apple drops the ball. This is in the realm of the server OS. Since OS X arrived, Apple has been capable of producing simply amazing server operating systems that perform astounding feats and that work beautifully with their client counterparts. Mac OS X Server has made a quantum leap from the AppleShare Server days. Its Open Source UNIX underpinnings have everything to do with this leap. It has been truly amazing to be a part of. Unfortunately, Apple all too often wants to treat the server community the same way they treat the desktop user -- as beta tester. So when they release a new desktop operating system, the server version is released very shortly thereafter, and suffers many of the same -- or at least the same number -- of bugs and glitches. This is so not cool.

A server admin should not be, nor have to be, a beta tester, ever, and for a number of reasons.

First of all, server software is inherently production software. It has to work. If your server breaks, you're dead in the water. Typically, the first three point-versions of Mac OS X Server have problems so big that I can't use them in production. And building a server is a much bigger, much more delicate task than building a desktop machine, so if it's screwy, I'm out a lot more time and effort building a product that's unuseable to me. Because one little problem on a client is no big deal, but one little problem on a server can be a deal breaker. Because of these issues, Apple should test the Hell out of their server software. Permissions problems on a client can be worked around. Permissions problems on a server (documented in Apple's Knowledge Base) are simply unacceptable.

Second of all, quality control testing of server configurations is much easier than testing client configurations: Server software runs on far fewer hardware configurations, and typically has much less software installed. There are only a handful of computers that any reasonable admin would run OS X Server on, and usually no productivity software gets installed on those systems at all. On my server, there are almost no third-party apps installed. So what's so hard about this? Install your own software on your own hardware and test it against your own clients. Done.

Lastly, server software is almost four times more expensive than the client version. Making someone pay $499 for software that just doesn't work and does not include support is unacceptable and I truly resent it. I think it shows a huge level of contempt for the admin/server market. $129? Fine. $499? Fuck that shit.

The problems inherent in desktop OS quality control are almost completely absent from server OS quality control. And servers are difficult to build and maintain, and are mission critical. Yet, from what I can tell, Apple treats them the same: same bugs, same number of problems, same point-version release schedule. Same beta bullshit. Personally, I wouldn't mind waiting a bit longer for server software that worked out of the box. I mean, I always end up having to wait for a useable version anyway. And on the desktop, that's understandable and fine. But on the server level, it's just not.

I really like the Red Hat Linux model for OS distribution. Red Hat releases both free and paid software. Red Hat Linux is the paid version, and it comes in numerous configurations, each available for a different price. Red Hat is always a version or two behind the current build of Linux, though. Know why? Because the previous builds are the stable ones. That's right, Red Hat's paid product is the older, but stable OS. If you want the latest, greatest build, you can get it under the Fedora moniker. It's not guranteed to be stable, and comes with no support, but it's 100% free. And, I believe, all the userland beta testing that's done in Fedora makes it into subsequent Red Hat releases.

This is a great model. Unfortunately, Apple being a corporation with trade secrets and a bottom line, it's one they can't really use. But I think they could borrow one element of the Red Hat scheme: When Apple releases a new server OS, they should make sure it's stable, even if it means making the customer wait a bit longer, or providing a build that's slightly older.

'Cause frankly, I want to build servers, not beta test them.

Undo After Save or: Published at Last

Wow. This hint actually got published on MacOSXHints. I have a few more in the pipe. Maybe they will be too. Either way, you can always find them here. This is my latest discovery:

In TextEdit you can now use undo and redo after (that's right, after) you've saved your document. That is, create a document, type some text, save it, make some changes, save it again, and then hit undo. Voila! It works. In previous versions of TextEdit, after you saved the document, the undo/redo history was gone. Now it's not. Hell, if you want to, you can undo all the way back to the beginning when there was no text in your document at all. Even after you've saved ten times. Neat-O! Just remember, though, once you've closed the file or quit TextEdit, the undo/redo history will be gone.

Now I admit, this is a small hint. Not earth-shattering in the least. But it's been a great thing for me. I write a lot of shell scripts in TextEdit, and you have to save changes to the script to test them out. This means I can now make changes to a script-in-progress, test it, and if I don't like the changes I just made, I can revert it back to its previous form. I like that. A lot.

Nice to know I'm not the only one.

Spotlight/UTI Conflict or: Still Useless

Awhile ago I wrote this regarding Spotlight:

The other thing that's helped me understand the usefulness of Spotlight is actually coming up with a reason for using it. Initially I had no real need for it, or at least I didn't think I did. But the other day I was looking for something in a script that did a particular something or other. Problem was I had no idea what script I had put that something-or-other line in. So I'm looking through nested folder upon nested folder, trying to decipher my own script names, and realizing that it was all futile because I had no idea what the script was about, only that it had a line in it that used such-and-such a command. And that's when it hit me: how great would it be if I could search inside my scripts? And then it hit me again: Spotlight!

I also wrote a brief rant about Tiger's new UTIs and how they screw up my scripting workflow:

Tiger, as in many of my other workflows, has made fundamental changes to the operating system that break the original functionality to some degree, and thus break my workflow. In Tiger, text files with the .command suffix open in Terminal, but so do ones with the .sh suffix. If I change the "Open With..." application for .sh to TextEdit, using "Get Info" and apply the "Change All" option, files with the .command get changed too, though the ensuing warning message still (erroneously) states that the change will only affect files with the .sh suffix. So for some reason, Tiger is now associating .sh and .command files with the same application type -- essentially seeing them as the same types of files, which, in a way, they are. But Panther didn't do this, Panther allowed me to specify which apps opened certain types of files based on their suffix.

Today in another cruel twist of fate, the promise of Spotlight and the annoyances of UTIs collided, merged, and then mutated into one horribly disfigured total and utter lack of functionality. Not only are the UTIs for the .command and .sh suffixes hard-coded to one and only one application at a time, but Spotlight treats them differently than regular text files as well. In fact, Spotlight does not index the content of files with the .sh or .command suffixes. That's right. The one area where Spotlight could really prove its usefulness to me is one of the many areas it doesn't work as one might hope. I can't search inside any of my scripts -- the one place I could really see myself wanting to search by content -- because, like a good boy, I named all my scripts with either the .sh or the .command suffix.

I'll say it again, this use of UTIs, which are allegedly supposed to alleviate file suffix dependence, has actually stolen a very useful feature away from the user. Namely, the ability to have two files that are identical in content open in different applications based on some property other than content -- in this case, the file suffix. This was a great thing to be able to do, and, conversely, it sucks to not be able to do it. So I don't get it. What's the advantage? And not to developers, what's the advantage to the user? From my point of view, I just lost functionality, and the only way to get it back is to rename all my scripts with a file suffix that Apple has now taken full control of. I'm locked in. I have fewer choices and less control. And I'm more dependent on file suffixes than ever.

Actually, the file suffix thing is still around. File suffixes still determine the UTI to which the file belongs. So they still do the same thing. It's just that now they're more limited because of the hard-coded and seemingly arbitrary groupings imposed by Apple's implmentation of UTIs. Am I missing something? This is worse, not better.

Until someone can show me otherwise, I have to say that UTIs are bad.

Or at best, badly implemented.

Tiger Lab Migration Part 5: File Sharing Broken

I've been building my Master Tiger system. Actually, it's built, and I've been testing it. And I was going to make it my Radmind Master Client, but I've since scrapped my Radmind plans altogether. So fine. It's now just a matter of uninstalling Radmind from the Master and testing it and making sure all is well. Well, all is not well. Somewhere along the line, Apple File Sharing broke. I don't know exactly how or why. All I know is that, yesterday, after uninstalling Radmind, I tried connecting to the Master from my admin machine via AFP. The share mounted for a few minutes, then my Finder beachballed and I got a new error message alert. I'd never seen this one before:

Pressing the "Disconnect" button does just what you'd think: It disconnects you from the now defunct share.

So, looking into this a bit more, I've discovered that the AppleFileServer process on the Master is crashing whenever I try to connect to it via AFP. After the crash there is copius and completely useless output in the AppleFileService.crash.log, and Personal File Sharing is off in the Sharing System Preference pane. I can connect in the opposite direction -- from the Master to my admin box. File Sharing on the Master, however, seems hopelessly broken.

I'm not sure what to do.

I figure I have three options: 1) I can spend forever and a day trying to figure out what went wrong and maybe fix it, 2) I can wait for the much-anticipated 10.4.2 update and hope that whatever got broken on this machine gets overwritten with fresh new copies from the update, or 3) I can wipe and reinstall. Since it's likely I'll have no luck figuring out the problem, and since I'm not really the wait-and-hope type, I think I'll go with option 3.

Time to build another system.

I hate Tiger.

Tiger Lab Migration Part 4: Spotlight Worries

Here's an interesting little gotcha. Not sure if it's a good thing or a bad thing yet.

Probably bad.

In our lab, home accounts are on a server. Or, more accurately, they're on an NFS mount that is shared from a network RAID. The way this works is fairly simple, but kind of tricky. The Macserver handles the authentication for network users who log into client workstations. The clients always have the NFS RAID mounted at /home. When users log in, Macserver specifies their home accounts as /home/username. To make sure the RAID is always mounted, we use a little startup item that's just a very simple automount script to call the RAID and mount it in /home.

There's one other little thing that's weird about our setup, and that's the way the RAID is configured. Our RAID is a very nice, but proprietary system made by a company called Panassas. The way user accounts are created on the RAID is unique, and I don't fully understand it, as I did not set the RAID up, nor do I maintain it. But essentially, from my understanding, each user's home account on the RAID is a separate partition.

Does anyone see the problem here?

Well, I won't keep you in suspense. If you haven't figured it out, here's the problem -- and the more I think about it, the more I realize that it is a problem and not a boon: Whenever a user logs in, a new partition is mounted via NFS. And guess what happens then. You guessed it (or maybe you didn't): Spotlight starts indexing.

Holy fucking shit.

I have 207 users currently on the RAID. They have quotas between 2 and 7 gigs. And they're mostly completely and totally unaware of Spotlight and its idiosyncrasies. If one of them logs in and then, say, shuts down the machine (it will happen, trust me), the Spotlight index will get hosed and the machine will most assuredly begin acting flakey. Or how about this: What if a user logs in, checks his email, then logs out? Then what if another user logs in, does same, and logs out? What if five users come along and do this? Now we've got spotlight indexing five different network mounts on the same machine. What if that machine then gets rebooted before indexing is complete? I shudder to think. Or, what if a user logs in to a machine, indexing begins, she logs out and then logs into another machine? Now Spotlight is indexing the same mount point -- accessing the same database -- from two different machines. I'll say it again: Holy fucking shit.

This is a recipe for disaster.

Fortunately, I am an expert in the various methods for turning off Spolight. And that's what we'll have to do: turn off Spotlight for all 207 mount points. This isn't really that big a deal. One simple command should do it (I hope). But it gets me thinking about all the various other Spotlight related problems we're bound to encounter. For instance, our users do a lot of video, and they're encouraged to use firewire drives for this. Well, firewire drives are indexed as soon as they're mounted. I have no way to change this. What happens if indexing on a firewire drive is stopped (i.e. the user unmounts his/her drive) before it's complete? Now we have a hosed index on the user's firewire drive. Next machine he/she goes to will try to index the drive again, possibly completing the index, possibly not. And, during the indexing period, will performance drop to levels that do not permit video editing? I just don't know. But if they do, it's going to be a real problem. And just how do you educate 200+ users about this? It's way over most people's heads. This is a technology that is supposed to "just work." Unfortunately, in a multi-user, networked environment like ours, my worry is that it will "just break."

I'm feeling very hesitant about this migration. It wouldn't be the first time Apple's plans for the home user have come at the expense of the networked lab user. They often seem to forget about us, even though, in many ways, it's this sort of environment for which OS X is so great. Ironic. But if you think about it, one of the greatest features of Tiger -- Spotlight -- is completely useless in a networked environment. In fact, Spotlight is not even supposed to run on networked volumes. (Why it does on ours, I do not know, though I suspect it's because we're using NFS.) But the firewire thing is really disturbing, and I think really underscores the need for significantly more control over the behavior of Spotlight. If, in the Spotlight Preferences, there were a checkbox for "Disable Spotlight Indexing on External Drives," I'd be the happiest man alive right now.

As it is, I'm just plain worried.

UPDATE:
Another thought occurs to me: Okay, so I disable Spotlight on all 207 accounts. Well, what happens when we create a new account? Spotlight needs to be turned off for that account too. So basically, what this amounts to now, is a script that gets run at least every time a new user account is created -- possibly at every login, just to be safe -- that disables Spotlight on all mounted home accounts.

Oh joy.