Not Just Another Leopard Review

There's not much in Leopard that you could call new, as in never seen before. What I see instead is what I call a revolution of evolution. There are many things that suddenly work better than ever before, or just more efficiently, or, in some cases, finally work properly. None of this is new, per se, but it's the product of years of hard, diligent work by the development teams at Apple.

Unlike Microsoft, which backed themselves into a corner with the numerous delays on Windows Vista, Apple has been on a fairly disciplined release schedule. While the two-odd years between Mac OS X 10.4 and Leopard is the longest period between releases we've had in the history of Mac OS X, Apple didn't have to make everything look new to satisfy discriminating users.

With this in mind, I'm going to focus this article on the changes in Leopard which will make my life as a sysadmin and user easier and better. Some of these changes will be the ones you've heard about, others, not so much.

Netinfo is Dead

By dead, I mean gone. Doesn't exist. No legacy mode. No "just there for pre-existing accounts." It's dead; all the ni* utilities are gone. The Netinfo databases in /var/db are gone, too. So is the lookupd process?

What has taken its place? Directory Services, and, specifically, the DirectoryService and related processes.

While Netinfo was, for its time, a really solid system, it had a number of issues that made it unable to fit well in a modern computing environment. Were these issues fixable? Probably, but the question then becomes, "What does Netinfo have that other directory systems in far wider use, such as OpenLDAP, Active Directory, and eDirectory don't? Once you get beyond legacy support and liking Netinfo because you're familiar with it, the answer is really nothing. So Apple gradually moved Netinfo out, and in Leopard, it's gone, along with lookupd and the rest.

There are two benefits to the new system. First, without the Netinfo database, all local records formerly managed by Netinfo are now XML .plist files. If you look in /var/db/ you'll see a new directory, dslocal. This is the root container for all local Directory Services records. Drilling down into /var/db/dslocal/nodes/Default/ we see the following:

If I go into computers, I see an entry for my machine, with all its Directory Services information, local, and for the Active Directory and Open Directory domains it's bound to. If I look in config, I see a number of things, such as the KerberosKDC.plist file, which is used to auto-generate the /Library/Preferences/edu.mit.kerberos file, the Kerberos plist that is specific to my domain, including my KDC and other information. The Sharepoints directory in config contains one .plist file for every share point you create in Leopard, with things like the name of the share point, the mask for create permissions, etc. The machines subdirectory contains the information for the localhost and broadcast host. The networks subdirectory contains the loopback info, groups and users are fairly self evident.

Now, I know you're thinking that this was all in Netinfo too. That's correct. However, with Leopard, if I have a machine with a local user record that's corrupt, I can fix that by editing an XML file, or replacing the whole thing from a backup. If I find spurious local user records, I can delete them, archive, them, whatever, without needing any kind of utilities or manager application. By getting rid of Netinfo, Apple has made Mac OS X more maintainable. (Face it, XML is child's play to script compared to Netinfo.) It's also more repairable, because now I can fix local Directory Service entries with nothing more than a text editor.

A second benefit is that all the problems you had with binding laptops to Directory Services like LDAP and Active Directory in Mac OS X 10.4 and earlier versions, are gone. Even in Mac OS X 10.4, if your machine was bound to a directory service, and you booted in a situation where the domain controller for that service was unreachable and/or unresolvable, you had problems. You might not ever get to a login screen, you might not ever get logged in, or even if you did, you'd lock up the first time you did anything that required any information from lookupd and friends.

In Leopard, it all just works. My work laptop is bound to both an Active Directory and (Tiger) Open Directory service that doesn't exist outside our firewall, yet I can reboot, shut down and start, and there are no problems and no delays. In Leopard, it all just works, and for the first time, you can have mobile systems bound to a directory without goofy workarounds. That right there will make many, many IT managers extremely happy.

The Directory Access application has become the Directory Utility application, and picked up some nice features along with the new name. One improvement designed to help troubleshoot basic directory service issues is the initial display: The "Directory Servers" tab shows you the Active Directory domain and/or the Open Directory Server to which you're bound. That is admittedly a small thing, but being able to quickly see what you're attached to can clear up many support calls rather quickly.

The second new tab in Directory Utility is the "Mounts" tab, which lets you set up NFS automounts for your system. Adding a mount lets you specify NFS server info, mount location, and other options. You can manually add in other advanced NFS parameters, like the new support for kerberized NFS. Since these are automounts, they don't require the user to do anything or any specialized scripts to set up, and they apply to all users. Are easier automounts as sexy as Core Animation tricks or Time Machine? No. Are they something that a lot of people need and want? Definitely.

Time Machine And File System Events

Time Machine is something backup has needed for a long time. With every other backup system, if you want to go back to an earlier version, you have to stop what you're doing, start up the backup application, figure out what file you need, restore it, quit the backup application, and then get back to work. If you have a central backup server, then you have to deal with either the limitations of the backup client's restore features, or getting the backup administrator to restore the files. Either way, you're stopping work to deal with the backup as a completely separate thing.

With Time Machine, you deal with the backup without having to fully leave the context of the application you're working in. If the application you're in directly supports Time Machine, then the modality of restores is even less noticeable. Say you're in Time Machine's Pages paradigm, and you realize that you need a version of a document you're working on from a week or so ago. Simply onvoke Time Machine, scroll back, find the version, and keep working. That's a far more intuitive way to deal with restores, and restores are always more tedious than backups.

On the backup side, while Time Machine is definitely not an enterprise backup solution, it's still a solid, useful way to create serverless, automatic disk-to-disk self-grooming backups. The automatic part is critical for Time Machine's target market. No one wants to deal with backing up manually. Disk-to-Disk allows backups and restores to run as smoothly and quickly as possible, and the self-grooming features ensure that the Time Machine backup disk image doesn't keep an every-increasing in size backup of every version of file you've ever had on your system.

One of the handier system tricks which helps make Time Machine work is file system events. These are a way for the file system to tell applications, such as Time Machine, about changes to files and directories.

Obviously there are some security issues here, so file system events do have to comply with file system permissions. So, if I'm running an application that monitors all file system events, and makes a copy of any changed files, I will only see events for files whose permissions give at least read access to the user my application is running as. Another security consideration with file system events, is that they log all file system events. This could be used to give an attacker insight and information into what is going on for a particular machine. However, you can prevent this, and Apple documents how to do this in the Event Security section of the File System Events Programming Guide:

So not only does Time Machine make basic backing up simpler and easier, but implementing it created some fun new opportunities for the makers of other backup applications to use the mechanisms Time Machine uses to improve their own applications.

What about AppleScript? As it turns out, Leopard does far more than just up the version number for AppleScript to 2.0. There's system automation across the board. One of the first improvements in AppleScript for Mac OS X 10.5 is that AppleScript is now entirely unicode based. That's really important for scripts that need to generate or handle text in other languages, or languages that cannot be adequately represented by ASCII. This also means that there's exactly no difference in AppleScript between strings, text, and Unicode text. It's all the same.

Application status identifiers, such as "is the application running," "is it frontmost," and "what is the application version" no longer require workrounds via System Events for the first two. As well, getting the version no longer requires the application to be running, or using other methods than just asking the application.

Another application scripting improvement that fixes a bug I've been dealing with is in how you target an application. Prior to AppleScript 2.0, you could only target an application by the four-character code for that application. To target, say, Adobe Acrobat, you might write "Adobe Acrobat Professional," but the script used "CARO." While this worked well 90% of the time, if you had a vendor that used the same code for multiple versions of an applications, (such as Adobe for Acrobat), then ensuring you were targeting the correct version of Acrobat, (say, Pro, not Reader) required a lot of extra work that might not work anyway.

This issue hit me rather hard with a script I had written that targeted Acrobat Pro. In cases where both Acrobat Pro and Reader were installed, there were times when, because Acrobat Pro and Reader both have the exact same creator code ("CARO"), the wrong application could be targeted. With AppleScript 2.0, I can now target com.adobe.Acrobat.Pro, which is the bundle identifier for Acrobat Pro. Since Reader's bundle identifier is com.adobe.Reader, by using the bundle identifier, I can now avoid that problem.

One other relevant point: You can now reference applications in a tell block, without having them launch as the frontmost application, or even visibly, and moving applications is now easier.

While the release notes for AppleScript specifically talk about the new scriptable network preferences, in fact, most of the standard System Preferences are now directly scriptable. This makes a lot of administrator's lives easier, as they can now script a lot of the basic setup of various system preferences without needing to drop into UI scripting, a choice fraught with error.

For those who made use of the /usr/bin/osascript command line executable to run AppleScripts from the command line, there's a new feature for that functionality, too. With AppleScript in Mac OS X 10.5, the '#' character is now recognized as a comment in AppleScript the same way it has been in shell and other languages. This allows you to add a #!/usr/bin/osascript statement as the first line in a plain text AppleScript, give that script execute permissions, and run that script via osascript without the earlier workrounds for using osascript with complex scripts. This adds quite a bit to an administrator's ability to integrate AppleScript into a more traditional Unix command-line workflow.

Scripting Bridge

Related to AppleScript is the Scripting Bridge, new in Mac OS X 10.5. What the Scripting Bridge does is to make it far easier to use languages other than AppleScript to communicate with scriptable applications in the same way as AppleScript. This means that programmers more used to Objective C, Ruby, or Python -- three implementations of the scripting bridge that ship with Mac OS X 10.5 -- can use those languages for tasks that they would have formerly had to drop into AppleScript for. This is a big win for higher-level scriptability on Mac OS X. It should encourage more developers to add scripting implementations to their applications, because now it's not just "an AppleScript thing." Personally, I'm not dropping AppleScript for Python any time soon, but I'm in favor of anything that gets me more scriptable applications.

iChat

Talking about improvements in AppleScript brings me to another application that has been almost rewritten for Mac OS X 10.5, and gotten some neat new AppleScript improvements, namely iChat. Two features that I personally like are Apple's implementation of tabbed chats, and the new support for multiple logins.

Tabbed chats reduces the number of open windows on my system. Plus, when I quit iChat with any chats open, the next time I open iChat, the chat windows contain the same buddy entries they did at the time I quit. This isn't earth-shaking, but it's a nice touch.

The multiple logins make my life easier when I'm testing other IM clients, but want to keep iChat open. Having Google Talk added to the list of default account types is nice, too. However, for those of us who have to share documents with people who are in different cities/time zones/countries, there's another feature that is of greater importance, and that is the new support for document and screen sharing.

With iChat in Mac OS X 10.5, not only do you get dead-simple video and audio chats, (now based on h.264 and AAC), but you can also share screens with the person on the other end, ala WebEx and others. You can also use iChat as a remote presentation tool via iChat Theater. About the only thing this is missing in Mac OS X 10.5 would be a whiteboarding/direct editing feature. For that, you still need third party applications, but if that's not a requirement, then iChat just got a lot more useful.

Finder And The Desktop

It's probably impossible to review a new release of Mac OS X without spending some time on the Finder and the Desktop. However, unlike some others, I don't have any strong feelings on either, one way or the other. What I really want from the Finder and the Desktop is a negative quality: Don't get in my way. With Mac OS X 10.5, that neutralness has been enhanced with one notable exception: the translucent Menu Bar.

I understand the need to tweak the user interface. There's always a better way to do something, but honestly, I have yet to see a single advantage to a translucent menu bar. At best, it's just dark, and at worst, it can be hard to read. Neither seem like laudable design goals, so I really have to chalk this up to a case of "It's a new version, we have to change stuff" disease.

The same can be said about the new Dock. However, I find that due to the insane amount of items I have in my Dock, the bad parts of the shelf effect are minimized, so I'm not as annoyed by the Dock as I am by the Menu Bar.

On the other hand, I'm not annoyed at all by the changes made to the network file system mounting code, also known as AutoFS. This puts every mounted share on its own thread, so that one boggy mount or one problem mount doesn't lock the Finder the way it did in Mac OS X 10.4.

How well does it work? With Mac OS X 10.5, I'll forget to unmount shares, and go home. I get home, in a different network config, with the servers both unreachable and unresolveable, and I'll be working for a few minutes before I get the disconnect dialog. However, I can't tell that there's a disconnected share, because the Finder never locks up. That's another long-standing bug which wasn't technically a Finder bug, but one that was associated with the Finder, because you never really saw the bug outside of the Finder.

Speaking of network code, one thing I don't like about the new networking implementations in the Finder is the way it handles displaying network mounts. While they still mount on the Desktop, they don't show up separately in the Finder sidebar with the rest of the disks. You have to go to the new Shared section of the Finder, and navigate to the server. Those are extra steps that don't provide any improvements to the process. If you have a lot of servers, then there's a chance that your server won't even show up in the sidebar. If that happens, then you have to navigate the entire /Networks tree to get to it. I like the idea of the "Shared" section, but the current implementation needs work. I've also found that the new server connection routines in the Finder via browsing don't work consistently for me, and that's just a bug.

Another new features I really like in the Finder and the Desktop is Spring-Loaded folders in the Dock. That's probably the one thing I've been waiting for since OS 9, and something that I've really missed. Another item that I'm really loving is Quick Look. The ability to whack my space bar, and get a quality preview of documents and images has become a major time saver for me, and I find myself using Quick Look almost constantly.

Overall, I find the new Finder and Desktop to be a huge improvement over Mac OS X 10.4.

Like quite a few people, I'm not only a sysadmin, but a parent as well. Normally, the sysadmin part gives me an edge over most in keeping an eye on what my son is doing. Unfortunately, like many sysadmins, I am also lazy. Therefore, the improvements in Mac OS X 10.5's parental controls makes me happy. Not only can I lock down things like iChat, Safari, and Internet access better than I could in Mac OS X 10.4, but I can also have the system keep logs of application usage, Internet history, and better chat histories. Another new feature is the ability to specify what time of what day a given account can use the computer, and for how long. I'm rather pleased with such things, though my son undoubtedly isn't.

In truth, Parental Controls are just the existing Managed Client, (MCX) features repackaged to work outside of an Open Directory environment, with a more human friendly interface. So it's not that there's any great new feature here, but it's a far better implementation of existing features than you had in Mac OS X 10.4.

Preview

One of the nicest things Apple has done for users was to make Preview the best way to read PDFs and browse other image formats in Mac OS X. The UI, the speed of opening large PDFs, and the search functionality are all far and away better than anything coming from Adobe as far as reader functionality goes. The only thing I use Adobe Reader for anymore are forms, and for that, I use Acrobat Pro. With Mac OS X 10.5, Preview gets even better. My personal favorite is the ability to add pages to a PDF file, and rearrange existing pages in a PDF file. I can drag pages between PDFs with ease. No problems, and it's got a user interface that's far easier to use than Adobe Reader. If Preview ever gets better forms and PDF JavaScript support, my need for Acrobat (any version) will approach zero.

Safari

Safari for me has always been a mixed bag. I like the user interface, and with the new tab functionality in Mac OS X 10.5, I like it even more. But there are times when it chokes on simple sites that Firefox handles adeptly. (If Firefox ever gets a decent Mac UI, I'll switch in a heartbeat.) In addition to tabs, I am really in love with the "Hey, you have n tabs open, are you sure you want to close this window?" feature that Safari lifted from Firefox and others. I also really like the new Find functionality, since it is less modal than it was in Mac OS X 10.4, so I don't have to mess around with changing windows just to find stuff. There's also some kind of odd autofill for the Find field, which I have yet to figure out how to work. It's a nice idea, but I find the "changed your find term" schtick it likes to surprise me with more annoying than anything else.

Speaking of autofill, somehow, it's gotten noticeably worse. It was never as good as Internet Explorer 5 on the Mac was. That's something I really miss, but at least with Mac OS X 10.4, it wasn't as random as it seems to be now. What little predictability Safari autofill had is almost completely gone now, and it's been a low-level tooth-grinder all the way. I'd also like to add that I really, really, miss IE 5 Mac's URL autofill. That is still the best one I've ever seen on the Mac, and I still mourn its loss.

Security

With Mac OS X 10.5, Apple has added some features that will, overall, enhance security. Is Mac OS X 10.5 perfectly secure? Not at all, and anyone saying any OS is perfectly secure should be dismissed as ignorant of the subject at hand. The question is, do the new features increase overall security from Mac OS X 10.4? I think it's fair to say, yes.

One of the new features that people will see quite a bit is application tagging. Basically, the first time you run an application, you're going to get a dialog saying Hey, you're about to run this app for the first time, and it comes from . Is this what you want to do?" This could be a really annoying feature. However, in practice, you see it once per application, and it is a fairly human-friendly, in that it tells you how you got the application in a clear manner. This is obviously of greatest use for applications you download from the Internet, since those are the ones most likely to cause problems.

Another feature introduced in Mac OS X 10.5 is that of application sandboxing. In a nutshell, sandboxing allows the OS and developers to limit what an application can do. So, a sandboxed e-mail application can't create system accounts, or change permisssions on system files, or a text editor can't install an IRC server. A popular quote of a friend of mine is: "Once you run the application, you're at the mercy of that application's code." Sandboxing is a way to help reduce the risk of that condition.

Along the lines of reducing risk, Mac OS X 10.5 takes steps to reduce the ability of Input Managers to do things you don't want. For the uninitiated, an Input Manager is a bundle that is loaded into every running application that can modify the behavior of that application. It was originally created for things like allowing different languages to be used within a document, or to assist with accessibility. However, people realized that Input Managers are a great vector to implement system hacks, Unsanity being the most famous of the Input Manager software writers.

Prior to Mac OS X 10.5, you could have an Input Manager running from within the user's home directory. This was bad, because stealth installing software into a home directory is trivial. With Mac OS X 10.5, they can only run from /Library/InputManagers, and they can only run if they're owned by root. So it's now far harder to install and run Input Managers on the sly, always a good thing.

For people running Mac OS X 10.5 on an Active Directory 2003 network, Mac OS X 10.5 now supports SMB packet signing, so you can now use Macs on such a network without having to drop the security level of the network to do so.

A trick that has been implemented in other OS's, most popularly Vista, is that of library randomization. This helps prevent attacks that use memory addresses of various system calls and functions as their attack vector. If you can't predict the memory address used by a function, it's harder to attack it via buffer overflows, heap overflows, and other poinst of entry. Apple's implementation is not perfect -- not all libraries are randomized -- but it's a good start.

Spotlight And Spaces

Spotlight is much faster, and much kinder to the OS. It is also dead simple to use it as an application launcher. (I use it to launch Twitteriffic all the time, because the idea of typing "twit" and having that be the first hit is quite amusing to me.) Boolean search support and syntax are improved as well. As far as spaces go, if you like virtual desktops, then you'll like Spaces.

Unix And Networking

"Huge" isn't descriptive enough to account for all the changes here. I've been touching on them throughout the article, but I've not even come close to enumerating them all. Mac OS X is, in fact, officially Unix certified. For developers and sysadmins who have a need to monitor the low-level activities of any application on a given Mac, Mac OS X 10.5 now comes with its own implementation of DTrace. On the networking side, Bonjour has been extended to operate across multiple subnets. Considering how nice Bonjour makes using network services for normal humans, this is something that's long overdue.

For NFS users, Mac OS X 10.5 is implementing Kerberized NFS, increasing security for that file sharing protocol. However, from what I can see, there s no NFSv4 support in Mac OS X 10.5 yet.

Also, the whole OS is now 64-bit. Most people won't care. However, for vendors such as Adobe and Oracle, this is a very big deal. There's just one fly in the 64-bit ointment: Carbon UI code is not 64-bit. From what I've heard, this is not making Adobe too happy. Having to do all the UI code in Cocoa is not an easy task for Adobe's CS team

On the other hand, I doubt Microsoft much cares; the Mac doesn't have anything that would much benefit from 64-bit outside of Excel.

And The Verdict Is. . .

I've spent a lot of space on various Mac OS X 10.5 features, but those aren't the most important concern. It's the overall "feel" of the OS that really counts. Is it nicer to use? Does it make getting through your work or play easier? Thus far, my experience with Leopard has been consistently, and almost constantly, pleasurable. I've had far fewer problems with a lot of things than I did with Mac OS X 10.4, and Mac OS X 10.5 fixes quite a few bugs that were, for me, almost crippling to deal with.

I've literally done every install type available and had zero problems with each. I'm even pleased with how much better the “archive and install” options work in Leopard compared to Mac OS X 10.4.

Thus far, Mac OS X 10.5 has been a solid upgrade for me. The only thing that would keep me from upgrading almost any desktop would be specific application issues. (Servers operate under different rules, so I'm not including them in that statement.) Mac OS X 10.5 may have been delayed a few months, but when I look at all the improvements and just how Leopard has evolved from Mac OS X 10.4, I have to say, it's worth the wait.