Firmware Goodness

I don't usually get too excited about firmware updates, mainly because the things they fix rarely tend to affect me, for whatever reason. But the last Leopard Graphics Update from a few weeks ago has actually caused me some problems. Two, I believe, to be precise.

The first problem I've had may or may not be related to the Leopard Graphics Update: occasionally my machine — my brand new, fresh-out-of-the-box machine — just locks up, requiring a force reboot. I don't remember where, but I do remember reading that people were associating this with the Leopard Graphics Update, and it definitely started happening to me immediately after that update, so I'm fairly sure the update was the cause. The second problem has been cosmetic: when typing in the Spotlight menubar the drop-down sheet flickers in and out, causing a really annoying strobe effect until the window stops updating. Very irritating!

The good news is, Apple's latest ATI Radeon HD 2600 XT Firmware Update fixes the second problem. Here's hoping it fixes the first one as well. Only time will tell.

UPDATE 3-28-07:
Yep. All fixed. Since applying this update my machine has not locked up. Nice.

A Rift in the Space-Time Continuum

I did it. Yes, I finally did it: I went and pissed off Time Machine.

I've been using the Staff Backup drive for my Time Machine backups, see. And that drive needs a certain amount of free space for any large chunks of data that staff might create during any given day. So when Time Machine finally ate up all the disk space on the drive, I decided to see what would happen if I cleared some space up by hand, the old fashioned way. And so I deleted the first month's worth of data from my Time Machine backupdb folder.

Now, I'm not totally stupid, and I have at least a good enough understanding of how Time Machine works to know that this would cause problems, but I was curious, and I wanted to see what those problems would be and how they would manifest themselves.

The first thing I got was a generic Time Machine failure:

Time Machine Failure
(click image for larger view)

Clicking the red info button revealed surprising details, considering my drive showed 200GB free:

Time Machine Error: Really? How do You Figure?
(click image for larger view)

So I decided to run a backup and see what happened. The backup appeared to start smoothly, but eventually I wound up getting this message:

Time Machine Error: Funny Math
(click image for larger view)

Hmmm... I think I broke it.

It makes sense, really. I mean, it stands to reason that, in Time Machine, the first and oldest backup actually contains the most actual data. It's the base for all the other data. Subsequent backups only copy changes, but the first backup is kind of the Mother of All Backups, if you will. Deleting that first backup will, unsurprisingly, wreak all sort of havoc on your backups.

Havoc that is, as far as I can tell, irreversible. The only way I've found to fix this is to start the backups fresh. That is, turn off Time Machine, delete the old backups (or at least move the old backupdb folder out of the way), and then set Time Machine up again.

Bummer.

Oh well.

UPDATE:
Ahhh! That's more like it.

Time Machine: Back Up and Running
(click image for larger view)

Duplicate Computer Names and IPs

So there's an incredibly annoying and puzzling behavior in Mac OS X with regards to duplicate computer names on the LAN. Most Mac Admins probably know what I'm talking about. Here's the deal: Let's say you have a Mac Pro on your home network named Spanky and it has an IP address of 192.168.1.25. Let's also say, for the purposes of argument, that your best friend — who likes to emulate you in every way — has a Macbook named Spanky with an IP of 192.168.1.25 on his home network. (Hey, it could happen.) Now let's say your pal decides to come over, and he decides, "Hey, I think I'll bring my Macbook over so we can swap some illegally obtained music and pornography." He gets to your house to find you happily surfing the 'net. He whips out his Spanky and plugs it into your network, fires that puppy up, and Bam! All of a sudden your Mac Pro locks up. You can no longer surf. And you get an error message that looks a little something like this:

Duplicate Computer Name Alert: Why Me?
(click image for larger view)

You go to your Sharing Preferences (or your Terminal, or what-have-you) and, sure enough, your computer has been renamed. Renamed! WTF! Why is your computer, on your network, suddenly called "Spanky-2"? Because that's how Mac OS X handles duplicate computer names on the same network. It renames the existing computer to existing computer-2. Not the intruder. Not the new kid on the block. Your computer is now the computer formerly known as your computer. Why, it's pure genius, I tells ya! Brilliant!

Seriously, what in God's name were they thinking? Because, the way I see it, this goes beyond annoying into the realm of the dangerous.

Case in point: Let's say your Mac Pro Spanky is actually a server that provides services — authentication, Kerberos, LDAP, file sharing, the works — for a network full of computers. And let's say your friend is actually a guest on that network. When that guest plugs his computer into your network, and it just happens to be named the same thing as your server, God help you. You just lost — well, I'm not sure how much, but — a significant portion of your services. And all it takes is a computer name? I can rename any Mac on any network from any other Mac on that network by just changing my Mac's name? What's more, if you can get the IP of that server, you can bring it down entirely. That is total shit.

Strangely, it's been this way for at least three iterations of the OS now — since 10.3 — and it's still this way in 10.5. I am appalled. Can someone please explain the rationale for this to me? Please? 'Cause from where I sit, this is a major security flaw. To my mind it makes way more sense to have the newly installed machine make changes to it's configuration than to essentially be able to force changes on another machine. It's just backwards. And dangerous. And it desperately needs to be fixed.

UPDATE 1:
Mat X points out two very important facts: 1) the name change in this instance should only affect the Bonjour (.local) name of the duplicate machine, not it's actual name (the name it calls itself) or it's FQDN (the name as resolved by a DNS server), and 2) a client name change on the LAN should not be able to bring down a server with the same name because of the previous fact.

Dude, you're totally right, though I have seen, way back in the old days (10.2 maybe?) a duplicate name kill a server. So it did used to be possible. Nowadays though, Mac OS X Server has better, smarter naming conventions that prevent such things. I will say, though, that what prompted this was that I booted a clone of my own machine up on the LAN (same name, same IP) and it killed my computer, internet-wise, probably more because of the duplicate IP address. It's possible that all would have righted itself over time if I'd waited to see. I was just so annoyed by the behavior that I went on a bit of a rant. I still think it would be better behavior to leave the existing LAN client alone and make changes only to the new Mac on the LAN. But still, I got a little carried away.

Thanks for keeping me on my extremely bitchy and unscientific toes!

UPDATE 2:
So I've been doing some more testing on this issue. And while duplicate names on the network will not bring down your Mac OS X Server, a duplicate IP address will. Here's what I did:

1. I changed my client's IP address to match that of the Mac OS X Server (both Leopard 10.5.1). My machine got kicked off the internet and I got this warning:
   
2. I rebooted my client machine. Once the client had rebooted, the server got the above alert.
3. At which point the server could not ping out to the internet. Bad Mac OS X! Bad!

So, while my rant is partially in error, there does seem to be a bit of a flaw in the way Mac OS X handles new duplicate clients — particularly duplicate IP addresses. And I maintain that a better way would be to only modify the behavior on the most recent addition to the LAN.

Spaces Switchery

Leopard's Spaces application is pretty cool. I have to admit, I'm using it more than I expected to. Sure, it has some issues compared to older *NIX-based implementations that have been around forever. But I've never used a virtual desktop implementation until now, and all in all I like it.

I have had one little annoyance, however, and it deals with the fact that, as John Gruber puts it:

...Spaces seems designed for app partitioning, not task partitioning.

Indeed. Let's take an example: I have my browser bound to and open in Space One. I also have a Finder window open in Space Four, and the Finder is not bound to any particular Space. Currently, I am viewing my browser, and then I command-tab to the Finder. The behavior is to switch me to the Space with the open Finder window, Space Four. Cool so far. But what if I have a second Finder window open in Space One in addition to the one in Space Four. Ideally I'd like a way to switch, via the command-tab Application Switcher, either to the Finder window in Space One (the one with my browser window) or the one in Space Four (the one with the lone Finder window). Fortunately, such a thing is possible through the magic of click-and-hold.

So, if I'm in Space One and the browser is in front, and I want to switch to the Finder window in Space Four, I click command-tab, then hold the command button for a second. This takes me to the Finder in Space Four. But, if I'm in the browser in Space One and I want to switch to the Finder window in the current Space, I command-tab very rapidly and I switch to the Space One Finder window. Not bad.

Now what happens if we add a Finder window to Space Two? Well, things start to get a bit weird. A rapid command-click will still take you to the Finder window in your current Space. A click-and-hold command-tab will alternately take you to one of the other Finder windows in the other Spaces. That is, the first slow command-tab will take you to the Finder window in Space Two. Switch back to Space One and slow-command-tab again and you go to Space Four again.

Confusing? You bet it is. But at least there appears to be some thought going on as to how to manage applications with windows in multiple Spaces. Hopefully this gets refined a bit as time goes on. For now, I'll take it.

The Death of NetInfo

Not sure how I missed this, but NetInfo is dead as of Leopard. And I don't just mean the NetInfo Manager application. I mean NetInfo technology. It's gone. Completely replaced by a generic set of plist files in plain ol', flat XML. The GUI functionality is found mostly where you'd expect it. Gone, too, are the command-line tools for modifying the NetInfo database. These have been replaced dscl and friends. To quote AFP548:

Since dscl can't do everything there are some new, and greatly enhanced tools to help you:

• dsenableroot - just like it sounds. This has been on OS X for a while now, but it may be more useful now that NetInfo Manager is gone.
• dseditgroup - also present in 10.4, but will get more usage now. Good for manipulating group memberships.
• dscacheutil - brand new in Leopard. This tools allows you to peek into the Directory Service cache and flush it if necessary. Semi-analogous to lookupd -d.
• dserr - a curious tool. Lives only to lookup DS error codes for you and return the text equivalent of the error. I half expected to find a quick shell script here just grepping the man page for DirectoryService.
• dsmemberutil - now this is a command you can sink your teeth into! Allows you to check group membership and do some debugging on what groups the system thinks a user is in.

That's about as good a description as I've seen on the topic in a nutshell. Suffice to say, this is a day we've all been waiting for, or at least expecting. That it's come with such little fanfare is probably, in retrospect, not all that surprising. It just took me off guard a little.

In the end I think this will basically be a good thing. So far, things once done with NetInfo look at least a bit easier to do with the dscl and GUI equivalents. So, cool. NetInfo has finally been replaced. Of course it's been replaced with something else proprietary and weird, but it looks like it's at least a bit easier to manage. But, whatever.

So long NetInfo, we hardly knew ye!