I’m a Mac guy, but, as with many others, my position as an IT support person requires me to use Windows regularly (and know it inside and out, of course). As such, Parallels was a no-brainer when I got my MacBook Pro. When Parallels stopped working for me after installing the Mac OS X 10.5.1 update, and at that absolute worst time for me, when I needed my Windows system for some work I was doing right then, I had a choice. I had already been toying with the idea of playing with VMWare Fusion after reading some reviews, but nothing I had read was really pushing me over the edge to jump in and try it. Most of the reviews I were reading said that, yes, the performance was better in VMWare Fusion, but they were really neck and neck, all things considered. When Parallels stopped working, it became just as easy to download a trial of VMWare Fusion than to try an uninstall/reinstall of Parallels, so that’s what I did. The result for me was that I realized that the reviews I read were all wrong, and in a good way. The performance gain of VMWare is so noticeable that there’s almost no comparison. I can now boot my Boot Camp partition containing Windows Vista, and not have to wait 15 or so seconds to have enough available system resources for me to continue the work I was doing before. In addition, I can actually leave that Vista system running in the background constantly without having the noticeable drain on resources that was very apparent in Parallels. It’s just much smoother, seamless, and less of a drain on the main system.

There are a number of other small things I like about the VMWare product as well. I like the fact that the screen saver doesn’t activate while the VM is running (yes, I know I could have deactivated this myself, but its little touches like this that make a product better). One of the things before that had me really thinking about switching to VMWare Fusion was the ability to use the growing number of VMWare appliances, something that comes in handy as an IT support person. I like the fact that I have the ability to run 64 bit guest OSes. There are just a lot of features like this that really round out the product and make it a much better product for a serious user.

So, Parallels, you were first on the scene with a good product, but you’ve fallen behind. What happened? I tend to like to see the underdog win when possible, but you’ve lost the edge. As such, VMWare Fusion is my new friend, and I think we’re going to be pretty good friends.

As a Zimbra hosting provider, I often get questions from clients about iPhones. One of the glaring omissions in the iPhone is the lack of any sort of over-the-air syncing capability. I completely understand the need to plug it in to iTunes so it can check for software updates, sync lots of large media files fast, etc. The truth is, though, that calendars and contact, something business people live by, aren’t very big and are easily synced over the air.

A number of blogs, such as this one, have pointed out the fact that .Mac is a natural addition to the iPhone. My thoughts are almost identical to the ones in this post in particular. Putting .Mac on the iPhone allows users to sync their calendars and contacts in real time with their .Mac account, something I would absolutely have to have as a business owner, and part of the reason I do not have an iPhone. Doing this, though, as the poster points out, actually has the potential to create a second halo effect for the Mac itself. Since users could then sync their contacts and calendars with their Macs, the iPhone push would translate readily to a Mac push. Not only that, I GUARANTEE that it would make sales of .Mac accounts skyrocket. Only with the recent updates to .Mac for Leopard have I actually taken a look at .Mac and noted that it wouldn’t be a complete waste of money. With this though, it might become a must have for some users. My wife does have an iPhone, and if this were available, I’d probably purchase a .Mac account for her.

The one final piece that would make this a real contender in the business world is the .Mac iPhone server. Blackberry already makes the Blackberry Buiness Server for keeping your company’s Blackberry crowd in sync with your corporate collaboration system, why not for the iPhone? An on-site iPhone server would allow direct syncing of your employees’ calendars and contacts with their iPhone without having to be tethered to their machines. In addition, for companies like me that do hosted collaboration, being able to plug those iPhones directly into the collaboration suite would be a big win, whether it was with a server I hosted myself or via a contract for .Mac services.

So, Apple, if you’re listening, where is it? Seems like a no-brainer to me.

I had reason recently to purchase a copy of Steve Gibson’s SpinRite utility to try to recover some data on a backup drive that went kaput. Since all of our workstations in the house are Macs, and I wanted to be able to let SpinRite perform its sometimes lengthy drive analysis without tying up any currently-running machines in the house, I decided to use a spare x86 server that had been sitting idle in our rack for some time. The machine itself was basically nothing more than the case, power supply, and motherboard (with on-board video and LAN). I didn’t have a spare CD drive at the time, and I didn’t really want to go buy one for this application, so I set out to run SpinRite the same way I install my server operating systems - via PXE. The one thing I did install in the system was a removable IDE drive tray, which allows me to easily install drives that I want to run through SpinRite (the “SpinCycle”? :)). I actually started calling this setup my SpinStation, since it turned out to be a very easy way to just pop a drive in and let it run. But I digress. It dawned on my while I was setting this up that organizations, including the ones Nearband Networks supports, may have good use for being able to boot SpinRite via the network. Imagine desktop support technicians responding to the call of a non-booting workstation due to a hard drive failure. Instead of having to carry a CD with SpinRite on it, they can simply set the machine to boot off the network, and let SpinRite run its course. Imagine the case of a server in amongst a rack of servers who’s hard drive has failed. Instead of having to remove that drive for testing, simply boot up SpinRite on the server from the network and let it do its magic. Finally, imagine performing maintenance (yes, as Steve Gibson is fond of pointing out, SpinRite is a drive maintenance tool just as much as it is a recovery tool) on a lab of machines. You could burn a CD for each system, run each system sequentially, or you could boot all of the systems from the network into SpinRite simultaneously and let them perform their maintenance overnight. These are some of the useful examples I was able to dream up while thinking about using SpinRite in this fashion. So, without further ado, on to how I set up SpinRite to boot via PXE.

PXE, or the Pre-boot eXecution Environment is an Intel standard on how to boot x86-based machines via the network. Many different system architectures through the years have had ways to boot from the network (Sun, Apple, etc). PXE is basically network booting for Intel-and-like-based machines. As I mentioned before, I use PXE to perform my server installs, usually Linux. If you’re familiar with the Windows way of doing things, then you may have used Remote Installation Services to install Windows over a network, a technology based on PXE. Most x86 systems built within the last 5+ years come with client-side PXE capabilities built in, especially if they have on-board ethernet, so chances are the systems you’re using now already support it.

Since my home network is Linux-server based, I already have the capability to boot via PXE. The basic requirements are DHCP and TFTP. I use the standard ISC DHCP server that is freely available and comes with most Linux distributions and the TFTP server that is included as well. In order to boot a PXE image off of the network, you’ll need to update your DHCP configuration to tell the client where your TFTP server is and what PXE image file to retrieve and boot from. Most DHCP servers are capable of sending clients the appropriate DHCP options to perform PXE booting with the appropriate configuration, but the specifics that follow will focus on the ISC DHCP server. For ISC DHCP to pass clients the necessary options, you’ll need to add two options to your configuration:

• next-server
• filename

The next-server option is followed by the IP address of your TFTP server, and the filename option is followed by the path to the file on the TFTP server. I use pxelinux to PXE boot my clients, and my TFTP server IP address is 172.16.24.1, so my lines look like this:

# For network OS installs
next-server 172.16.24.1;
filename "pxelinux.0";

Once you have DHCP set up to pass the appropriate bootstrap information, you need to configure pxelinux. Here’s where things get interesting. SpinRite comes with two image options: It can write out an ISO image or a floppy image for you. Normally, you’d use the images to create the necessary disks to run SpinRite from. With pxelinux, however, comes a very handy feature called memdisk, which allows you to boot a floppy image from the network, allowing you to take the floppy image written out by SpinRite, and use it directly with your PXE clients with no doctoring necessary. You’ll need to take the memdisk image and SpinRite images, and place them in the root of your TFTP directory alongside pxelinux.0. Next, edit the pxelinux.cfg/default file in your TFTP directory. If you have other network booting options, be sure to set prompt to 1 so that a prompt is displayed where you can type your booting option. You can also set up a boot message, which can display a menu of choices. Once you have that configured, add the following lines to the file:

label spinrite
kernel memdisk
append initrd=spinrite.img

When the spinrite option is invoked from the pxelinux boot command line, the client will retrieve the memdisk image and use it to then boot the spinrite.img file, which is the floppy image containing SpinRite’s FreeDOS and the SpinRite application.

That’s pretty much it. There may be some details left out, but most of those can be found from other PXE booting tutorials or the pxelinux documentation. If you’re feeling adventurous, you can even open up the SpinRite floppy image, using your image tool of choice, and make changes to the image, such as setting the auto option when invoking SpinRite from the autoexec.bat. This will basically make SpinRite a mostly hands-off operation (other than choosing to boot from the network and, optionally, choosing the spinrite boot option), as the machine will boot from the network and immediately begin checking all available drives in the system. Using this setup, I actually ended up testing every old and unused hard drive I had around the house, so that I could begin using them in my new Icy Dock external USB enclosure.

Finally, one last note. If you’re thinking about using this in a large organization, be sure that you pay attention to Steve’s modest site and enterprise licensing requirements.

As part of our community network management service offering (a mouthful, I know - we manage a number of community WiFi networks), we sometimes have to employ measures to insure that some users don’t overrun the network with malware infections, peer to peer file sharing applications, etc. Instead of limiting what people are allowed to do on the network, like some ISPs have been getting heat for lately, I tend to prefer limiting how much they can do. I personally don’t care, and I don’t think that other ISPs should care, that a person is using Bittorrent, as such applications do have completely valid uses. I do care, however, if the use of that application, or an infection of some kind, is causing other users of that same network to suffer. So, this week I set out to employ the connlimit iptables match to help limit to some degree how many connections a runaway application can create through the firewall at one of our networks. Unfortunately, the process of getting to the point where I could include connlimit rules in my iptables configuration was not an easy one, so I thought I’d do my own writeup here to help those who may be looking for how to do something similar.

In most of my Linux systems, I use the Fedora distribution. Its free, easy to install, has much of what I need in the stock systems, and usually has a good combination of stability and the newest versions of packages. Unfortunately, as I discovered very quickly after my research in to how to best handle the connection limiting problem in iptables, the stock Fedora systems (Fedora Core 5 in this case, but its still true in Fedora 7 at least) do come with the iptables module for connlimit matching, but they do not come with the matching kernel module. So, I was going to have to roll my own kernel that included the connlimit module. Luckly, kernel building is not something I have to make a habit of since the kernels that come in all recent Linux distributions usually meet my needs. Sometimes, like in this instance, though, I do need to add modules that aren’t included in the stock kernels (and lately, those cases all seem to revolve around various network requirements). The issue here was that patching the kernel was not a simple matter.

The Netfilter folks have put together a system by which people can patch their Linux kernels with any of the netfilter modules they need. It’s called patch-o-matic. Unfortunately, much of the documentation on the Netfilter website relating to patch-o-matic is old and out of date. In fact, they’ve switched to the newer patch-o-matic-ng, but the link for the new patch-o-matic-ng system referenced the Netfilter Extensions HOWTO. This HOWTO, however, says nothing about the new patch-o-matic-ng, instead talking about the old system that no longer works or is even downloadable from what I can tell. It took quite a bit of digging through newsgroups, etc. to discover that the problem is that it appears that the Netfilter folks never started building and publishing new documentation from their source repository after switching to Subversion. The currently published documentation on the Netfilter website still references CVS revision numbers, but the current documentation is now kept in Subversions in it original SGML form and does not appear to be getting built into the HTML and other versions for public consumption. So, if you’re looking for the documentation for patch-o-matic-ng, you’ll have to peruse the original SGML formatted documentation, and the new HOWTO is available here.

So, finally having the correct documentation in hand, I proceeded. Given that the machine in question was still running Fedora Core 5 and was located on the west coast, making an update to a newer revision not completely feasible, it took some digging to find a mirror for the older distro’s source RPMs. Upon finding one, I grabbed the source RPMs for the latest kernel and iptables, as you’ll need both to work with patch-o-matic-ng. Here’s where the documentation’s usefulness comes to something of an end. If you, like me, are going to build a new RPM to apply to the system, you’ll have to apply the netfilter patches to a kernel, then use that to create a patch suitable for the RPM building process. To do this, you’ll need to run through several steps:

1. Install the kernel and iptables source RPMs, then run an rpmbuild -bp <specfile> on each of the kernel and iptables rpm spec files. This runs through the RPM build “prep” stage which unpacks the stock source and applies the patches that come with the source RPM. This is important so that you come away with clean patches for building your RPM. If you were to patch against a stock kernel, your patches may be difficult to apply when combined with the source from the source RPM that has already been somewhat patched.
2. Now that you have a fully prepped source tree, which will be located in /usr/src/redhat/BUILD/kernel-<version>/linux-<version>, make a backup copy in the /usr/src/redhat/BUILD/kernel-<version> directory, so that you have an original tree with which to make your own patches from.
3. Armed with the fully prepped source tree and a pristine backup of it, run through the patch-o-matic-ng instructions to apply the patches you need to the kernel tree. Be sure to feed it the paths to your prepped kernel and iptables sources in the BUILD directory. Also, if you’re looking for the connlimit patch, as I was, you’ll have to perform a ./runme –download followed by a ./runme external, a procedure which isn’t really documented in the HOWTO.
4. Now that you’ve patched your kernel tree with the Netfilter patches, create your patch files by running diffs between your backup tree and your newly patched tree. For me, this was a two step process, since the netfilter patching created some new files. Here’s what I ran (my backup/pristine source tree was in /usr/src/redhat/BUILD/kernel-2.6.20/linux-2.6.20.i386.old, and I had cd’d into the patched source directory of /usr/src/redhat/BUILD/kernel-2.6.20/linux-2.6.20.i386):
   1. for i in `find . -type f`; do diff -u ../linux-2.6.20.i386.old/$i $i; done > /tmp/connlimit.patch
   2. diff -u /dev/null net/ipv4/netfilter/ipt_connlimit.c >> /tmp/connlimit.patch
   3. diff -u /dev/null include/linux/netfilter_ipv4/ipt_connlimit.h >> /tmp/connlimit.patch
5. You now have a patchfile that can be used with your RPM building. You may have to doctor your patch just a bit to insure the directories referenced will work with your Patch statements you add to the spec file. Do any doctoring you need, then move the patch into the /usr/src/redhat/SOURCES directory.
6. Next, you’ll need to edit the .config files that are used to configure each kernel build (because there are a number of kernels that are built from that one source RPM). They’re located in the SOURCES directory, and each has a name similar to kernel-2.6.20-i586.config. In each one, add the line CONFIG_IP_NF_MATCH_CONNLIMIT=m. This will cause the new connlimit module to be compiled as a module.
7. Now you’re done. You can try to build your new kernel. You’ll need to specify your architecture on the rpmbuild line, so, in my case, I ran rpmbuild -bb –target i686 /usr/src/redhat/SPECS/kernel-2.6.spec. The i686 target for this kernel builds 19 separate RPMs, so the process takes quite a while (like 6 or so hours in my case). When its done, though, you should have the kernel you are looking for with your new iptables match modules in place.

The effort required was more than it should have been, in my opinion, but it was well worth it. I’m now able to limit the number of connections each user can create. The iptables man pages included some information to get you started, but there are some things that aren’t completely intuitive. First, each iptables rule does its own connection counting. You might figure this out if you look at other people’s rulesets, but no one seems to come out and say that. What this means is that you can set up rules for, say, different ports and the connlimit module only does matching in that case for that rule. The connection matching for that rule does not affect matching for any other connlimit rules. This was nice for me, because I was able to severely limit the number of outbound SMTP connections (to stop spambots from being able to create hundreds of simultaneous connections), but kind of lump everything else into a “you get so many connections before you can’t create anymore”. One other gotcha to keep in mind is that the connlimit kernel module keeps its own cache of connections (part of the reason you can apply different connection limits to each rule). As such, though, if a machine currently has a high number of connections prior to applying the connlimit rules, those pre-existing connections will not get counted against the limit for that client.

In the end, as I mentioned before, it took more effort to get this working than it should have, but it was well worth it, and tt has been satisfying to see the rules, especially the SMTP rules, have a positive affect on the availability of network resources - and hopefully cut down on the number of spam complaints we get.

Maybe its just me, but I expect any tier 1 data center that I or my clients use to be able to handle a power outage, and I mean a full power outage. As you may or may not know, Rackspace experienced a severe outage yesterday. A truck collided with the main power transformer outside their building severing them from the grid. According to their statement, they switched over to their backup power feed, but the power company was turning that feed on and off in order to assist the first responders trying to rescue people from the accident scene - totally understandable. What’s not understandable is why Rackspace didn’t have enough generator capacity to run its chillers as well as the machines, or if they did, why they didn’t execute on that. Anyone who runs equipment rooms knows they must have proper cooling, or the machines located in that room will self destruct in very short order. So, it stands to reason that it does no good to have generator backup in case the power is cut if you can’t run your chillers off of that generator system as well. You’ll just be running your machines literally to death.

I’ve had Leopard fully installed and running now for about 2 weeks, enough time to get to know it pretty well, and I like what I see so far. Unfortunately, I was one of the unlucky few that preordered and received a defective Family Pack DVD. This was a quite frustrating experience, but a trip to the Apple Store to exchange for a new disk remedied that problem, and I was off and running. My views tend to focus more on the nuts and bolts - what goes on under the hood. So, some of the features I talk about aren’t the ones you’ll hear about in Apple’s glossy advertisements. Since it took me longer to get this out than I originally anticipated, some of this is already well known, but some isn’t. Anyway, without further ado, my observations after about 2 weeks of Leopard:

1. Naming Services Changes
   NetInfo was officially supposed to die with Leopard, and, with great joy, it has. The replacement is very interesting. There was speculation that there would be a local copy of OpenLDAP slapd running with the naming information for each machine, but they did not choose to go this route. Instead, each “node” of the various naming services (each machine entry, user entry, group entry, etc) for the local naming services database is a plist file. Take a look at /private/var/db/dslocal. This is where the local directory info is stored. Under the nodes directory is where each directory type (machines, users, groups) is stored, and inside each directory are the plist files containing the entries.
2. Local Kerberos KDC
   I can’t see that anything is actually making use of it as of yet, but Leopard is running its own local MIT Kerberos KDC. The configs live in /var/db/krb5kdc. If you look at the plist file for a local user in /var/db/dslocal, you’ll see that the AuthAuthority attribute (the attribute used by Open Directory to determine how to authenticate a user) even contains a Kerberos listing for the local KDC along with the standard ShadowHash entry.
3. StartupItems is gone
   One of the very welcome enhancements is the removel of any stock services relying on StartupItems, the pre-Tiger way of starting up services. Everything has finally been moved to launchd control, with the exception of a couple of mach_init services. I also noticed that there are quite a few more entries in the system LaunchDaemons directory, and the system LaunchAgents directory is also heavily populated (where the system LaunchAgents directory in Tiger was empty on install). Since launchd is the application launching platform for the system, its interesting to note that launchctl list now displays all processes, daemons, and agents launched for a user instead of just the managed LaunchDaemons/LaunchAgent jobs.
4. ACLs on by default
   Filesystem ACLs are enabled by default now, and some good default ACLs are applied to certain folders (/Applications, /System, home directories, etc) that keeps anyone from accidentally deleting them. See the chmod man page for how to edit ACLs from the command line. Beyond that, the Get Info dialog in Leopard has received a workable update to allow editing ACLs from the GUI.
5. Quarantining of Internet downloads
   This one is kind of interesting. It was one of the touted items in Apple’s list of 300 updates. I don’t know yet if this is implemented in one of the Frameworks or the kernel, but this appears to be enforced using a filesystem extended attribute. On downloaded files, the system applies the com.apple.quarantined extended attribute to the file (or files in the case of a bundle, etc). The system looks for this attribute when executing a program, and, if present, displays the are-you-sure dialog. If you answer “Yes”, Leopard clears that extended attribute, and the file is cleared to run.
6. Firewall
   The Leopard firewall has already received quite a bit of attention. The firewall is completely renovated in Leopard. The Tiger firewall was based on the ipfw subsystem. Tiger would keep track (via plist files) what ports were used by default in certain applications and open them when the service was activated from the Sharing preference pane. ipfw, however, is based on the standard port/address/etc rules system that most firewalls are. ipfw is still there, but it only contains a single rule no matter how Leopard is configured by the GUI: allow all. This is because the default firewall is now an application based firewall, the daemon of which is /usr/libexec/ApplicationFirewall/socketfilterfw. There is a corresponding kernel extension com.apple.nke.applicationfirewall. The ALF (Application Level Firewall), from what I can tell, has a list of allowed applications and watches for any socket requests for that application and allows them and opens ports for them, etc. If the application opens a Listen port, you’ll see a popup asking if you want to allow the application to listen. I have mixed feelings about the ALF so far, as do many others. On the surface, its a very good thing, closing ports unless they’re allowed explicitly, and indeed, it may be a pretty good improvement over the way the firewall was handled in Tiger for the average user. Its not extensible enough yet, though. As a network administrator, I routinely allow port access to machines from specific networks, etc. The ALF is not smart enough yet to do that, as it only knows whether or not an application is allowed to talk to or listen to the Internet in an all-or-nothing fashion (at least from what I’ve seen so far). For a truly robust one-two punch firewall, it looks like both the ALF and ipfw utilities may be necessary. With the combination of the two, however, things can be locked down very tightly. If a ruleset system could be applied to the ALF such that applications could be locked down in a more fine-grained fashion, it would be a killer firewall, especially if those settings could be distributed via Open Directory.
7. Networked filesystems updates
   First of all, the SMB/CIFS mounter now uses the newer CIFS ports: 445. This is a welcome update since some enterprises are disabling the older and chattier NetBIOS subsystem on Windows machines. In additon, there are a couple of other gotchas to look out for here. The SMB/CIFS mounting has been overhauled, and one thing to keep in mind is that it now appears to support the UNIX CIFS extensions. This means that if you’re using a Samba server to serve your Leopard clients, and you haven’t disabled the UNIX CIFS extensions in Samba, Leopard will see the actual symbolic and hard links instead of simply seeing a link as the file it links to. This took me off guard, and may take quite a few other sysadmins off guard as well. Second of all, a very updated automounter system is now present, including something UNIX admins are used to seeing: a /net directory for dynamic host mounts and an automounter-controlled /home directory. In addition, the Directory Utility will now let you easily specify directory service-based mount points on your local system (basically local automounter maps). I don’t know yet if they’ve ditched the old /Network/Servers automounting system for this more standardized approach, but I’m willing to bet the older approach is still there. Hopefully the automounted /home directories will be candidates for use with Portable Home Directores. I’ll be looking into this very soon. Finally, for NFS updates (which I haven’t personally tested but are welcome), the NFSv3 subsystem is now includes Kerberos authentication as an option, allowing more secure NFS mounts, and NFSv4 is supposed to be coming to Leopard at some point.
8. Account defaults changes
   In Leopard, Apple has departed from the old standard of creating a group for each user. My guess is that this is, at least in part, due to the fact that ACLs are now enabled by default, meaning that careful manipulation of your umask is not as much of a requirement as it once was to insure that all users who needed write access to files and directories maintain that access.
9. ssh-agent Enabled
   This is another item that’s been pretty well covered by some folks aready. Leopard now enables the ssh-agent on accounts, and it will store the passphrases for your SSH identity files in your keychain. This is a welcome update and mitigates the need for SSHKeychain to a large extent, though SSHKeychain is very handy for creating port forwarding tunnels.
10. Network configuration
    While there have been some issues surrounding the new network configuration system, overall, I like it very much. Apple did a good job of cleaning up the interface and aggregating all of the network configuration items into one place. The old system of having Internet Connect as well as the Network preferences pane was indeed a pain at times. Now that its all in the same place, things are much cleaner.Being a wireless and security aficionado, I was very interested in their updates to the 802.1x interfaces in Leopard. This has been one place where the initial use was a bit rocky, but I like what they’ve done with it. Now, you can set up per-system authentication credentials, per-user credentials, or, for a nice option for Enterprise machines, you can tell it to use the credentials supplied in the Login Window as the network authentication credentials. On top of that, 802.1x is now a GUI option for wired ethernet networks as well. I’ve said for a long time that I expect to see more use of that going forward, and this makes it easier for the Mac OS X users to live in that environment.Finally, while you could do this before from the command-line, it is now possible to set up VLAN or bonded ethernet interfaces from the Network preference pane. This will be of little use to some, but the ability to easily define VLAN interfaces is definitely of use to me from time to time.
11. Directory utility
    Leopard now includes a Directory application in the Utilities folder, used for searching any directories set up in Mac OS X. I have yet to set up a directory and play with it, but I intend to. From what I can tell, it basically is a directory search tool for anyone looking for items in the central directory (machines, users, groups, etc) - basically a poor man’s LDAP browser, but it could prove pretty useful for that quick directory search.
12. Mail
    As far as actual user applications go, this was the one I was looking for updates in the most. I’m a Mail user simply because I like the interface and integration with the other Mac OS X applications, but Mail always had a few things that nagged me. The first was no ability to forward an email as an attachment. As a postmaster, this was one of only a couple of items that could always force me to use a different email application for particular purposes. Now, Apple has finally decided to grace us with this ability, which is a godsend. Now, if they would only let you select that as a default option instead of hiding it in the menus.The second nag, and one that actually cause me to write my own Mail plugin, was the lack of IMAP folder subscriptions. Previously, Mail would simply show all IMAP folders you had access to (all folders showing up from a LIST IMAP command). In an environment where there are lots (and I mean LOTS) of folders, this would take Mail.app down hard as it tried to index them all. Now, Mail does include IMAP subscription capability, but how they do it is interesting, like they’re being smart about it. Mail pays attention to the IMAP Namespace. When you go in to subscribe to folders, Mail presents you with a list of folders from the shared folders namespace. So, basically, Mail will always display all of your personal/INBOX folders, but will only show you the subscribed folders from the shared namespace. In some ways I like this, and in others I don’t. It would be nice if you could turn that feature off, because there are times when I have archival IMAP folders that I don’t necessarily want to be subscribed to. On the other hand, Mail now includes archival ability. As you can see, I’m still torn on this, but its definitely much better than it was before, and now very much workable.Mail also seems much faster. My take on this is that Apple may have allowed multithreaded access to the Envelope database. In Mail, the Envelope database that contains the headers of all of the indexed messages, is an SQLite database. In Tiger Mail, it seemed that access to this database was very serialized. For instance, if you switched folders, and Mail was in the middle of a sync operation, your display would hang until the operation was done. That doesn’t seem to be the case anymore, which means that SQLite locking use in Mail is probably much better such that Mail can read the tables while some other thread is still writing to them.Finally, I do like the Activity Viewer pane in the bottom left, and I’m using the heck out of the new Notes feature, but I’m still loathe over the fact that Mail offers no way of doing mail identities. As a sysadmin, I often send mail from various addresses (postmaster, hostmaster, etc). With a standard IMAP account, you still have to hack the com.apple.mail.plist file directly to be able to send mail from those addresses (and even when you do that, you can’t change the “real name”, only the From email address).
13. iCal
    Last, but not least, there’s iCal. Several of my issues with Tiger’s iCal have been addressed. iCal now supports https calendar subscriptions, which is important when using authenticated web servers. iCal also seems to have addressed some time zone problems when interacting with Microsoft Outlook clients. With CalDAV support in Leopard’s iCal, version 5.0 of Zimbra should be an even bigger win for Mac OS X users than it is now.