Tiger Hates Leopard

So I'm sitting in my office, waiting for the Mac OS X 10.5.2 Leopard update to show up in my Software Update, and it just isn't happening. And at some point I realize, "Hey, maybe it just hasn't been downloaded to our Software Update Server yet." Yes, we run our very own Software Update Server under Mac OS X Server 10.4. It's super cool. It downloads all Apple updates to itself, and then any Mac in our lab can get all the Software Updates from our own internal server, rather than Apple's, which just saves gobs of time and bandwidth. Oh, we love it. But there appears to be a catch: Tiger Server will not download Leopard updates.

So I'm sitting there waiting, like, forever. And the 10.5.2 update never shows. Nor does the Leopard Graphics Update, or the HP Printer Drivers Update, and I'm all like, "Dude, what the fuck?" When all of a sudden the iLife Support Update does show up.

And that's when it hits me: Tiger totally hates Leopard.

But that's okay, 'cause Tiger's a total bitch.

In any case, I'm not sure if the converse is true — if Leopard Server will fail to download and serve Tiger updates — but if it is, good luck running a Software Update Server in a mixed Tiger/Leopard environment. Geez! You'd think Apple's software would be more compatible with, um... itself!

Highly annoying.

Oh, and by the way, after removing my Leopard box from the SUServer client list, these commands got me back in business without a restart:

sudo killall DirectoryService

sudo dscacheutil -flushcache

Just so you know.

UPDATE:

It would appear that Leopard's Software Update Server is a bit less finicky when it comes to older updates, for previous versions of the OS. Hmmm... Do you get the feeling Apple's trying to tell us something? (You know, like, "Upgrade your server." Or something.)

Leopard Software Update Server: Backwards Compatible

(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.

Safari Remembers

The new Safari 3 is out for both Leopard and Tiger (it's included in Mac OS X v.10.4.11). It's pretty nice, I have to say. It now works with Blogger's HTML editor dealio, which is excellent (though slightly buggy at present). The find function now kicks some serious — and, more importantly, some Firefox — ass. Safari now handles tabs intelligently, letting you not only rearrange them in a window, but also letting you tear them off or drop them into existing windows. All extremely slick. Oh, and it's really pretty and fast as Hell. Seriously, it's smokin'.

But perhaps my favorite improvement to Safari 3 is that window placement is now remembered properly. You see, Safari of yore (of Tiger, actually) would remember the placement of the last window opened, rather than the placement of what I'd call the "base" window, or the first window opened. So, after using Safari, if you'd opened any windows other than your first window — even if you then closed them — the next time you opened Safari you'd get a blank window where the last open one had been. Or sometimes in seemingly random spots. I complained about this a long time ago, and it never got fixed to my liking. It was part of the reason I ended up switching to Firefox — I'm rather anal about my window placement and I like my browser pinned to the upper right hand corner, but in Safari it was always moving. Argh!

Well, Safari 3 fixes this. Sort of. Actually, I'm running Safari 3 in both Tiger and Leopard. The behavior remains unchanged in Tiger, but in Leopard, all is as I like it. So perhaps this is a fix in Leopard and not so much a Safari fix.

Either way, it's just one more reason I like Leopard and can't wait to be done with Tiger.

Can't. Frickin'. Wait.

That said, will I switch back to Safari once I've successfully transitioned to Leopard? Only time will tell. But somehow, I doubt it.

What Everyone's Bitching About

There's been no shortage of commentary on Leopard's 3D Dock, mostly because it's just ugly as Hell. But that's fixable.

There's been almost as much bitching about two other new visual changes in Leopard. The first is the menubar, which is now translucent. I'm ambivalent about this one. On the one hand, I understand that, from a usability standpoint, it's a bad idea. It's now slightly harder to read a primary interface element under certain conditions, those conditions being, in particular, the use of busy Desktop pictures and/or patterns. The default Desktop picture for Leopard, in fact, is an image of outer space whose star field can directly compete for visual attention with text in the menubar. My argument to this, however, is that busy, distracting, high-contrast Desktop pictures are a far greater hindrance to usability than slightly-harder-to-read menubar text, and if you're really bothered by the menubar changes, you should probably switch to a nice, solid or muted Desktop background and remove all distractions from your life once and for all. That's what I do and, so, while the I understand that translucent menubar is not the best idea for usability's sake, it really just doesn't bother me in the least. Actually, I kind of like the muted, lower-contrast lack of in-your-face-ness of the new menubar.

The other big gripe has been about pulldown menu transparency. No. Seriously. David Pogue of the New York frickin' Times for Pete's sake:

The most serious misstep in Leopard is its new see-through menus. When the menu commands — Save As, Page Preview, whatever — are superimposed on the text of whatever document is behind them, they’re much harder to read. Often, Apple’s snazzy graphics are justifiable because they make the Mac more fun to use. In this case, though, nothing is gained, and much is lost.

This one I don't get. Pulldown menus have been transparent in Mac OS X for a long time. (Oh, wait. I mean forever!) The difference between how Tiger deals with them and how Leopard does is extremely subtle.

Tiger Pulldown Transparency: Pinstripes! Ew!
(click image for larger view)

And Leopard does away with the pinstripes, which to my mind is a huge usability gain. At worst we break even here.

Leopard Pulldown Transparency: A "Serious Misstep." Really?
(click image for larger view)

I wonder sometimes if people are forgetting that pulldowns in Tiger were transparent. You'd think, by the level of general annoyance with this change, that they had. Honestly, people. It's really not that bad. I'm totally on board with the Dock thing (though a lot of people don't mind that even). But when it comes to the new transparencies, they just don't bother me much at all. I hardly even notice.

UPDATE:
Oddly, Firefox's group bookmark pulldowns exhibit the old-style, non-blurred menu transparency, minus the pinstripes of course. I can't find another application that does this. Weird.

Firefox's Group Bookmark Pulldown: Old Skool
(click image for larger view)

Notes on Google Desktop

Google Desktop, the Google-made search utility for your computer, is finally out for the Mac. I've been playing around with it, putting it through its paces, and comparing it to Spotlight. Here's what I've found so far:

1. Google Desktop is much, much faster at searching than Spotlight. Spotlight took nearly a full minute to search the term "test" on my computer (that's measured from the time I hit return in the search bar to the time the pinwheel stopped spinning). Google Desktop was nearly instantaneous at returning results. I found both sets of results about equally useful — or useless, depending on your perspective.
   
   Spotlight Search Results: Slow and Useless
   (click image for larger view)
2. Google Desktop also returned fewer results than Spotlight. I'm not quite sure why this is so. My guess is that Google Desktop searches metadata and/or file contents differently than Spotlight. But who knows? I've often wondered how Spotlight determines what results get returned, and how relevancy is determined. It's mysteries like that that make these things perhaps less useful than they could be. I know how to optimize my web site for Google's internet search engine, at least to some extent, because how Google searches the web is not completely opaque to me. I do not know, however, how best to save my local data to optimize it for searching via Spotlight or Google Desktop. So my results tend to vary. The nice thing about Google Desktop, though, is that I at least don't have to wait 50 seconds to see my useless results returned. I get them instantly. Yee-haw.
   
   Google Desktop Search Results: Fast and Useless
   (click image for larger view)
3. Spotlight stores its index files on a per drive basis, which is smart: index your drive on one machine, it's indexed everywhere. Spotlight's index files are also really small. Google Desktop, on the other hand, creates much bigger index files than Spotlight, and those index files are all stored on the root drive (in /Library/Google/Google\ Desktop/Index/). This is bad for two reasons. On the location side of things, if you move, say, a firewire drive to another computer with Google Desktop, that computer will have to re-index the drive, and that index will always be out of sync with the ones on other systems, causing Google Desktop to constantly index external drives. On the size end of the equation, since the Google Desktop index is entirely on the root drive and can get quite large, it is quite possible, given a large quantity of data and a relatively small root partition — like, say, on my system — for Google Desktop's index files to completely fill your hard drive and lock up your system. Yes. This did happen to me. Thank you for asking.
4. Google Desktop also shows you other useful information right in the list of search results, which is nice. Info like the file path and a preview of the document's contents appear right there in the search window.

In terms of functionality, though, I like Google Desktop about as much as I like Spotlight, which is to say, not all that much. Mainly because I just don't get very useful results. There are some interesting features that Google Desktop offers in terms of Gmail integration that I've yet to try. These might add some appeal to the program. But as far as searching my local system goes, thus far even Google has yet to make a desktop application that rivals its internet search engine. Seems strange that searching local files is a harder nut to crack than searching the internet. But I guess it is after all.

UPDATE:
First off, I meant to mention that the initial indexing for Google Desktop took a very long time. I'm not sure how much because I ran it on my work machine and let it go all weekend long. Judging by the size of the index when I left the machine versus the final size, I'd guestimate it took roughly 24 hours. Very rough estimate. And bear in mind that I have probably around 1.5 to 2 terabytes of data.

Today I find that Google Desktop is hogging my CPU. I get a big performance hit whenever I'm doing large file writes to disk, which is understandable though hardly forgivable. Times like these the processor can hit near 120%. So, for instance, a file copy involving many files will cause my Quad G5 to bog down noticeably.

Google Desktop: Processor Hog
(click image for larger view)

In addition, since Google Desktop is apparently pretty damn slow about indexing, said file copy will cause Google Desktop to start indexing again, which makes its processor usage hover between about 50% and 90%. Google Desktop's indexing process is both slow — far slower than file copies — and processor intensive — to the point of making other apps run noticeably slower. I'm uninstalling it now. I have work to do.

That was fun while it lasted.