I was going about my business, as you do, having used the LocationChanger script and launchd agent to automatically switch my Mac between my home and non-home network locations. Of course, I decided I could do it a little better, and got to work.

Here is the result: AutoLocation.

I learned a few new things while cooking this up, including how to actually deal with arrays in bash, a nifty thing called process substitution (which resulted in my favorite line in the whole script), and a great way to return arbitrary values into variables from functions.

I really like it when I learn new things on the way to solving a problem for myself. It's the best way to learn something.

Dear Drugstore.com,

Please inform your software devlopers that their reasoning behind what is and is not a "valid" name is severely flawed and is thus resulting in my refusal to mutilate my name to fit your web store's idea of what is valid.

Yes, when I go to create an account for myself, and enter in my name:

• First Name: Gregory
• Last Name: Ruiz-Ade

And then I proceed to fill in my email address and create a password, and click continue, I get a dialog box that tells me I must enter a valid name.

This is absurdity.

Anyone who is old enough to be competent enough to design and implement an online storefront of the size and caliber of drugstore.com should surely know that there are hyphenated last names out there in the wilds of the internet (let alone the whole world.)

As such, I politely decline to make a purchase with drugstore.com today.

Thank you,

Gregory

Yes, I just emailed that to them.

Since my first Mac (an Aluminum PowerBook G4), I had relied upon SuperDuper! as my backup method for my Mac notebooks. It's a wonderful tool, and faithfully replicates an entire volume, including making it bootable, for a worst-case drive failure scenario. I've used it for migrating my system to a new disk when doing disk upgrades, transferring an image to a new/replacement notebook, and just plain backups.

I've long since switched to using CrashPlan for my backups. CrashPlan has worked wonderfully, and saved my bacon a number of times. I use it on every computer I own. Crashplan isn't, however, an ideal solution for migrating data to a new drive when upgrading your hard disk, simply because it's rather slow to restore a lot of data over the network.

So, back to SuperDuper! I go, as I'm planning to add an SSD to my current MacBook Pro, and re-instate the "build a DR boot volume on an external drive" policy at home. The wrinkle is that since the upgrade to OS X Lion, both my wife's and my notebooks are using FileVault2 for full-disk encryption. Given the sheer amount of personal information on these computers, it's the only sane thing to do, especially when the notebooks are bound to iCloud, with Find My Mac enabled. (This gives you remote-wipe capability on your notebook, which is very useful if it's lost/stolen.) Unfortunately, there's no clear way to use SuperDuper! with a clean hard drive and end up with an encrypted volume that duplicates the original.

At least, not directly within SuperDuper.

All is not lost, though, as there is a way to do it, and get a fully encrypted, bootable duplicate of your FileVault2-encrypted OS volume!

In short, the procedure is:

• Install OS X Lion to your destination hard drive
• Activate FileVault2 on the new install
• Reboot to your normal startup disk
• Use SuperDuper! to "Smart Update" the destination
• Boot from the destination (SuperDuper! target) disk again
• Open System Preferences -> Security, and click on the FileVault tab.
• Click the button to enable users to unlock the volume, and enable any additional accounts (if you have the users there to type in their passwords.)
• Reboot to your normal startup disk again
• Pat yourself on the back! You did it!

I've tested the procedure on my old MacBook Pro, from which I'm preparing to remove the SSD to transplant it into my new MacBook Pro. It works, it boots from either volume, and they're both encrypted (granted, with different recovery keys, as one would expect). I'll post a followup in about a week complete with screenshots of the whole process when I migrate my OS volume to the SSD in my new MacBook Pro.

Stay tuned!

I suppose this should be filed under "Get More Pageviews", but nonetheless, I took the click-bait to Sophos' calling Apple out on making the iPhone 4S safer to use while driving easy to access by bypassing your passcode. My main issue is that they take what is a legitimate concern regarding the tradeoffs between security and ease of use (and even safety of use while driving) and instead paint it as a deliberately cavalier attitude towards data security.

What's disappointing to me though is that Apple had a clear choice here.
They could have chosen to implement Siri securely, but instead they decided to default to a mode which is more about impressing your buddies than securing your calendar and email system. →

You see what he did there?

Ever notice how an expert in a certain field will only ever see choices from the perspective of that field? Interesting how there is the assumption that the only options were secure and insecure. It's like he just assumes that nobody will ever try to use a phone while driving, something that seems like it would gain a huge safety improvement by reducing phone interaction.

On my lowly iPhone 4, if I want to call my wife while I'm on the freeway to see if I need to stop at the store, I'd have to:

• Pick up the phone
• Press the home button or the power button
• Swipe across the bottom of the screen
• Tap in my passcode, or, as suggested in the Sophos article, my complex alphanumeric-with-symbols password
• Tap the Phone icon
• Tap the Favorites button if it's not already on the Favorites page
• Tap my wife's entry

With an iPhone 4S and Siri, I'd presumably need only to:

• Pick up the phone
• Tap the button that activates Siri
• Speak: "Siri, call my wife."
• Acknowledge Siri's confirmation of my request by saying, "Yes."

I wouldn't ever have to look at the phone. The only touch target I'd need is a physical button on the phone, which is easy to locate without looking. It's only marginally more complicated than asking a real person sitting in the car with you to dial the phone for you, because you have to push a button two times. I'm reasonably certain it's this use case which Apple designers and engineers had in mind when setting the default options on the iPhone 4S, with the assumption that the security-conscious people could find and disable the "enable Siri while iPhone is locked" option themselves.

After all, while the iPhone is a popular device for businesses, it's not the only market Apple sells to. Apple is going to make the choice, every time, to make it's products easy and delightful to use for its primary customer base.

You know, ordinary people.

Just a reminder, when you're migrating a lot of data and configuration information to a new machine, remember to make sure you pull all the relevant information.

I just spent the better part of my afternoon/evening chasing down a problem where a user could not log on via SSH. He had the right key. He were using the right passphrase. His account existed in /etc/passwd, and he was listed in the right groups in /etc/group. We did all sorts of debugging on his client, and then a clue popped out when we ran the server in debug mode:

Well, I thought it was a clue. Turns out there was nothing overtly obvious about what was going on. Nothing, that is, until I finally decided to check the contents of /etc/shadow, only to discover that the user in question had no entry there.

Remember to check the simple things first. For a Unix/Linux account to be happy these days, it needs an entry in both /etc/passwd and /etc/shadow! It's a step that is only really missed when you're copying the contents of these files from another machine, instead of using built-in utilities (useradd, groupadd) to create user accounts.

I was recently asked for my opinion on options for adding access control, or, more specifically, host-level authorization for users connecting to Linux systems. All the systems in question are a variety of CentOS, and all of them are configured to use LDAP for authentication and authorization via the pam_ldap and nss_ldap modules.

The Problem

In a default configuration, pam_ldap and nss_ldap will make user and group accounts in LDAP act just like user and group accounts in /etc/passwd, /etc/shadow and /etc/group. If it is present, it's a valid account for the system. In the general case, this is a good thing, and simplifies the configuration of your systems. Things get complicated, however, when you only want a subset of users to be allowed to log in to specific machines. Traditionally, the method for doing this has been to force pam_ldap to examine the LDAP entry for the user trying to authenticate, and only allow the authentication to succeed if some attribute of the user's object matches a configured value. The host attribute of the account objectclass is a great one to use, but if your user objects are based on person or inetOrgPerson, and you're doing the right thing and have strict schema checking, you can't use it. You'd either have to violate your schema and disable checking, or violate your schema and add the extensibleObject objectclass, which is basically a schema-valid end-around to schema checking.

There are similar tradeoffs for other object attributes you might choose for utilizing for access control, especially considering that you can only use attributes that exist in your users' LDAP objects, and not outside them. While it certainly can be done, and I have done it in LDAP implementations before, there's never a truly clean way to implement the policy, and changes to the policy induces the risk of breaking the host's LDAP configuration entirely.

A Good Solution

In the case I was most recently asked about, the only way to gain access to the system is via SSH. The application stack which the hosts run either doesn't do any user authentication, or handles it itself. Taking a step back from LDAP, then, there is an easier way to do access restrictions: the OpenSSH daemon's AllowUsers and AllowGroups configuration directives.

Utilizing the capabilities of OpenSSH takes one piece of complexity out of the already complex LDAP client configuration, and moves it into a service that is a lot easier to repair should something go wrong. This is especially true if you are utilizing a configuration management (CM) system like CFEngine, Puppet or Chef, where the ability of the CM to do anything might completely hinge upon the system user and group databases being intact. A configuration error that causes people to not be able to log in via SSH is less serious than all of your systems user and group records disappearing, which can completely unhinge your system.

Finally, utilizing OpenSSH's AllowUsers and AllowGroups let's you manage access to hosts simply by modifying group memberships of users, which can be easily done in LDAP with tools such as my personal favorite, the LDAP Account Manager. This nicely avoids the possibility of having to write your own management tool for access control to add/delete/modify attributes that aren't easily handled by existing tools, or may not even be visible to those tools. Saving time and effort is key to sanity as a systems administrator, and this will save you a lot.

The best part, though, is that this method works regardless of whether you use LDAP, NIS/NIS+, rdist /etc/passwd and friends from a master copy, or any other method of pushing user and group account data out to your hosts. On top of that, there's nothing saying you can't layer this on top of LDAP ACLs, too, for that extra bit of paranoia.

Loose Ends

There are, however, some downsides to doing access control via OpenSSH. The first is that it only applies to OpenSSH. This may seem like a statement of the obvious, but it's important to point out. Other services you may be running, which also rely on LDAP for authentication and authorization, will not be beholden do your policies configured for OpenSSH. Again, it may seem like I'm simply re-stating the obvious, but consider:

• Do you run an FTP server with user accounts?
• Do you run an IMAP or POP service?,
• Do you run SMTP AUTH?

Those are just three examples, but any service you provide that performs user auth and does so via PAM, SASL (backed by PAM) or directly with LDAP would need to have it's own ACLs in place if you don't want all your LDAP users to have access.

With that in mind, however, if your needs are simple, use a simple tool, and get the job done with less stress.

Happy hacking!

... Or at least add him to my daily reading.

My last source of confusion (on this matter, at least) is that people are going after Apple on this at all. Until the iPhone there was never an expectation that phones should either run Flash or be open. A phone is not a personal computer. It’s a phone. All smartphones are just phones. They play by a whole different set of rules. And that set of rules is much longer and stricter than that of a personal computer. No one ever complained that Nokia’s phones weren’t open. Or Motorola’s. Or Samsung’s. Why now is it completely offensive that Apple’s phones should be? Moreover, there are no phones in existence today that can display Flash content because of all the reasons cited by Jobs in his letter. Google’s phones don’t. Neither do Palm’s. So why is everyone going after Apple? It’s just crazy. →

Quick update: About the only thing that has changed since he posted this, I think, is that Google has announced with Adobe that they're going to get Flash on the Android platform. We'll have to see how that turns out, but I honestly don't have high hopes, primarily because touch is not the same as keyboard, monitor and mouse, and I'm not sure Flash content designed for web-on-PC will translate well.

If you're anything like me, you have a strong dislike for all the stupidity that surrounds the Adobe Reader (formerly known as Acrobat Reader.)

I won't go into the details here (though this guy can explain it in great detail), but because I very occasionally need features of Adobe Reader, I still keep it installed on my Mac, while I use Preview for all my other PDF needs. I've gone so far as to install the Firefox PDF Plugin for Mac for when I use Firefox, just to avoid Adobe Reader. And, really, there's no point in Adobe Reader for most cases where you just want to be able to view or print PDF files. Doubly so, since Mac OS X lets you print any document to a PDF file as a default feature of the OS.

There are, though, edge cases where having Adobe Reader installed and available are useful. So I have it installed, but I refuse to use their web plugin. Adobe doesn't care, though, and will periodically, sometimes randomly, and sometimes even without my consent, re-install the plugin. Even though I've told it not to. Adobe Updater, I'm looking at you, here.

Sadly, my solution is heavy-handed. I created a launchd task that will forcibly remove the Adobe Reader plugin from /Library/Internet Plugins whenever it's created. It's fast, efficient, and works.

And, as soon as I can figure out the new wordpress theme, I'll post it here in a legible form

UPDATE: Thanks to Lynne and Chad on Twitter for suggesting the Preserve Code Formatting plugin!

And now, the Launchd config. Save this as:
"/Library/LaunchDaemons/org.unnerving.RemoveAdobeReaderPlugin.plist"

Label
org.unnering.RemoveAdobeReaderPlugin
ProgramArguments

	rm
	-rf
	/Library/Internet Plug-Ins/AdobePDFViewer.plugin

QueueDirectories

	/Library/Internet Plug-Ins/AdobePDFViewer.plugin

WatchPaths

Apparently weblogs are not for busy people, who don't have time to write for them more than once a quarter. It would also help if I perhaps didn't use a weblog engine that required upgrading every month because of new security holes.

Bleh.

HTML is like bolting a wing onto your trunk lid. Javascript is like bolting a blower onto your motor. One is just decoration, and the other actually does something to your machine.

I amused myself, so I share it with you. Aren't you so much happier now?

You know your Home A/V setup is too complicated when you need to make a spreadsheet just to map out how everything connects together, and to figure out what to set how to watch what.

Dear LazyWeb:

My wife and I have something like 4000+ photos that we need to scan (at high resolution) and archive, and be able to logically manage.

My platform choice is Mac. I will likely be purchasing a Mac Mini to dedicate to this task (2GHz model). I do not want to afford a Mac Pro, as awesome as it would be to have such a powerhouse in my home. I already have an Epson 2400 scanner, and would prefer to not have to replace it.

I have no idea what software to use for the resulting photo collection. I'd like something better than simple files on the disk, and am considering either Lightroom or Aperture, even both of those seem aimed more directly at digital photography.

I would like a simple workflow, if possible, that doesn't rely on me naming the images. Tagging and notes/comments would be required.

Can I get away with Lightroom or Aperture, and whatever scanner software I can install for my scanner? Do I need something different?

Can Lightroom or Aperture store images on an external disk (which may not always be connected?) I've got plenty of storage already on my home network.

UPDATE:

Hardware will likely end up being a new 13" MacBook, instead of a Mac Mini, as my wife needs a replacement for her iBook anyway, and the new MacBook has way more power than the mini. This definitely necessitates the ability to store all the images on external storage, ideally via a network (SMB/CIFS) share.

I am finding myself simply not caring about the fact that this site is using the default WordPress theme.

That is all.

I have, for some time now, run my own Internet domains for purposes of having what are essentially vanity email addresses and web sites. The longer I've done this, however, the more picky I've become about what kind of service I have my email stored on. I use, primarily, IMAP to access my mail, but I do on occasion require a good web mail client for those times when I don't have my own computer(s) available to me.

In the past, I have made due with borrowed capacity on other people's servers, running my mail through UW IMAP or Dovecot IMAP or even Courier-IMAP. All three are very capable, stable IMAP servers, though I've had the most reliable mail with Courier over the years. For a web front-end, if there's been one, it's usually been either SquirrelMail or IMP. Both are serviceable, though SquirrelMail tends more towards the no-frills just-get-me-my-mail-please approach, whereas IMP has tried for a long time to be a flashy, high-class webmail package. Neither one was really good enough, in my eyes, but then again, I'm tough to please for web apps.

The most important thing of all for me for email is reliability and stability. After that, I look at things like "how hard is it for me to manage" and "does it also make my wife happy?". It's on this third point that I started becoming restless with the options I had available to me, and started looking with some envy at Gmail. Zimbra, too, was under serious consideration, but it's a heavy enough application for a server that I could not simply toss it on someone else's server when I was already getting access for free.

So a while back, along came Google with Gmail, and everyone jumped on it. Starting off with 2GB of storage per account, and now steadily climbing (I think my account has a 6.7GB cap, and it seems to go up all the time), email pack rats now had a place where they could send all their mail and not care. It's fully searchable, you can put multiple labels on a message (kind of like filing a message in a folder, but not really) and Google has some very good spam filtering. When Google introduced IMAP access, I did some testing and then moved all my mail over, taking advantage of Google Apps for Domains.

Right away, there was a big glaring pain-in-the-ass: Google Mail's "All Mail" folder. From the web interface, it makes perfect sense, but when Google created their IMAP implementation, it was apparently decided that all labels would be presented as if they were IMAP folders. This includes both the fixed, standard labels (Inbox, Sent Mail, Spam, Trash, All Mail) and the user-defined labels would all be listed as folders. Additionally, the fixed labels (excluding "Inbox") would all exist under a "[Gmail]" folder. Most people ended up renaming all their labels to be prepended with "[Gmail]/", and then setting their IMAP Path Prefix (or IMAP server directory, or some other name depending on IMAP client) to account for everything being under that "folder".

But there was that "All Mail" folder on the IMAP server. And it was exactly what it claimed to be: a folder containing all your mail, sans spam (which was in the Spam folder only.) This meant that any IMAP client that wanted to download full message data not only needed to download the copy that was in Inbox, or in a label/folder, but the second (or third) copy would get downloaded from All Mail, as well. The potential for enormous bloat for clients that downloaded offline copies of email is quite impressive, when you can have over 6.8GB of mail in your Gmail account. It bogged Mail.app down so badly on my wife's iBook that she simply refused to use it anymore, and has just been using Gmail directly. Her poor little iBook was trying to download some 650MB of email, twice. That's the side-effect of Google's "All Mail" folder.

She's told me she doesn't really mind, but I get the sense that she'd be much happier with Mail.app, and it's integration with iCal and Address Book. It just works better, especially when she doesn't have any contacts in her Gmail address book. As an IT professional for the last 10 years, especially as one who's maintained large mail systems, I could do better for her (and myself).

Now Apple is announcing a re-launch and re-branding of .Mac, Mobile Me. This is primarily interesting to me because we're planning on going for iPhones when our Sprint contract is up this summer, and the capability for over-the-air data synchronization is almost worth the $12/mo it would cost us for a Mobile Me Family Pack. The obvious side benefit would then be that we'd be able to sync our data between our respective laptops, iPhones and desktops nearly thoughtlessly. Basically, if they're on an Internet-connected network, they're synced to the latest data. That's cool.

But there's a mail service as part of .Mac and MobileMe. An IMAP mail service, with a web front-end that looks an awful lot like the Mail.app that I know and love and hammer on daily. Interesting. Sure, there's 20GB for me to upload web pages and iPhoto galleries and movies and whatnot, but if the service includes a mail service, IMAP at that, and "Push" IMAP if you're using an iPhone, this could be worth looking into! Sure, I'd need to set up something to handle mail addresses for our vanity domain(s), and forward them on, but it might be worth the hassle.

But .Mac/MobileMe doesn't support mail filters or rules on the server. You have to run them in the mail client. This, to me, kind of defeats the purpose of an IMAP server. I want to be able to have all the rules run on the server, so that it doesn't matter at all what client I use. If I have to use the web to check my mail, I don't want to have to wade through everything my rules would have sorted.

Part of the reason for this, I suppose, is that Apple expects you to always be using one of your Macs to read your mail (or, I suppose, your iPhone, though I'm not sure Mobile Mail actually processes mail rules.) It still seems to me like the .Mac/MobileMe mail service is a bit lacking for a power user like myself. What concerns me the most, however, are things I've heard regarding .Mac's issues with reliability for mail delivery, even for messages you send through .Mac.

Zimbra, the mail system we're migrating our department to at work, is a supremely solid IMAP (and POP3) server, that also just so happens to be a reasonably good web-based collaboration server with integration for all the major desktop platforms. We've been using Zimbra at work for nearly a year now, and I really have nothing but good things to say about it. It does what they say it'll do, and it's an extremely stable mail platform.

You need to pretty much dedicate a server to it, though, so it's not something you can load on to a shared system. If you don't have a server to through at it, though, there are a number of vendors who resell Zimbra accounts either individually or for hosting your whole domain. Luckily, I happen to know someone who's doing reselling, and since I maintain our Zimbra installation where I work, he's letting me have it at cost for the licenses I use while helping him with whatever questions he has. Seems like a good arrangement.

As happy as I've been with Zimbra at work, I'm almost positive that I'm simply going to move our email to Zimbra and off of Google. Need to set up a reliable test first, though, so that I can demonstrate the system to my lovely wife and get her reaction to it. That part, however, is proving to be a trial, and I'm not entirely sure why yet. More to come in a future post.

So, yeah, this is probably old news to everyone else, but I'm late to the party, as usual. I finally tripped over two menu options in the History menu of Safari that I had not previously noticed.

The first is "Reopen Last Closed Window." This is very useful.

The second is "Reopen All Windows From Last Session." This takes care of my biggest concern regarding session restore.

So I guess maybe a "Reopen Last Closed Tab" option might be about all I could add to that to be truly complete.

I do still look with great envy at Firefox's extensions system, particularly for Adblock Plus, FlashBlock and NoScript.

It's been about a week and a half since Apple release the last batch of updates for OS X, including the latest version of Safari. In the interests of keeping up to date with security updates, I went ahead and updated. I did my research first, though, and uninstalled Saft before the attempt (there were some who had problems with InputManagers installed during the upgrade.)

I was happy to discover, this evening, that Saft had been updated to support the latest version of Safari. Despite my general revulsion for running InputManager-based hacks (let alone other system behavior modification software, like Haxies, that hook in even deeper to the system), Saft offers a subset of functionality that I simply don't like doing without. A couple of the features, I feel, really should be integrated into Safari proper.

I've already mentioned my strong desire for one of the features, session saving and restoring. Firefox has this nailed, and it's a built-in feature. I feel strongly enough about it to mention it again here. Hey, Apple, are you listening? I want full session-saving, like what Saft does now, built into Safari.

Another feature Saft gives me is (rudimentary) ad blocking. The various Firefox extensions (namely Adblock Plus) that exist give tremendous power in blocking ads on the web pages you view. I don't know that Saft will ever approach the power of something like Adblock Plus, but it does a good enough job for the moment.

Here's a question worth investigating: Is it possible to write an Adblock Plus-like Safari plug-in using the official Internet Plugins API? My understanding is that API is restricted to the content of the page, and doesn't allow for any behavior modification of Safari itself. That should be enough, right? This is something I'll have to investigate.

I'd definitely like to stop having to install InputManager-based hacks on my system, though. Safari is, in my opinion, an excellent browser, but the grass is always greener on the other side of the fence. Firefox does seem to have a mighty green lawn around their extensions garden.

A few weeks ago, when Apple announced all the new features coming to the iPhone, and specifically mentioned ActiveSync, I was reminded of a thought I had a couple months back:

There really is no good reason why the iPhone should not be able to synchronize its data to a .Mac account instead of being restricted solely to syncing via iTunes on a computer. This would actually make the iPhone even stronger for people who need reliable access to the latest version of their data without having to remember to plug the phone in all the time.

And then, this evening, as I'm going through the various RSS feeds I didn't look at all day in NetNewsWire, If find this post on TUAW mentioning .Mac syncing on iPhones. Okay, that means the feature is most likely going to come some time this year.

Amusingly, even though I have my personal Mac at home (a 1.5GHz G4 PowerBook 15") and a Mac at work (2GHz Core2 Mini), I still haven't gotten myself a .Mac account. As much as I would like to synchronize my data between the two machines, I can't seem to justify $100 a year just to be able to keep my Safari bookmarks and Address Book contacts synchronized. I already keep all my calendar information on Google Calendar, which my wife and I both use, and sync it to my Mac with Spanning Sync. (Spanning Sync will eventually have Contact syncing between Address Book and Google Calendar/Gmail too, now that Google has finally announced a Contacts API.)

The iPhone being able to sync to .Mac, however, changes the game. .Mac syncing means that, for $100 a year, I can basically never have to remember to plug the iPhone into my computer just to make sure my calendar, contacts, bookmarks and notes (well, hopefully notes) are all current. I don't have to worry that when I add a contact in my iPhone, I need to plug in to sync it back to my Mac. For someone like me, who simply prefers for the technology to Just Work and do so on a consistent and transparent basis, .Mac syncing would sell itself.

Heck, it's hard enough for me to remember to sync my music to my current iPod, because it means I have to dig out my cable. It'll be interesting to see what really does come of this rumor.

I'm very slowly getting my ducks in a row with regards to my online presence. I've decided, for the time being, that it's probably simplest for me to keep this site as a WordPress blog, as that reduces the work I need to do to keep the site updated. Now that I've finally made an infrastructure decision, I can start dressing it. I'm still thinking of carrying forward the theme I used on Method, but I'm not entirely sure yet.

I've got comments turned off, primarily because I haven't had time to get them working while not getting spammed to death. It appears that there's an anti-spam plugin already included in WordPress these days, so I'll have to give that a go.

I am also thinking that this will be the end of method.unnerving.org, as well as public entries on my LiveJournal. I don't like being too distracted. Spread too thin, if you like. It's my hope that what I have to say will interest at least one other person in this world besides me, and so I'll put it here, for reading and ridicule and all to see. Expect a mix of things, with periodic dry spells.

Oh, and I'm on Twitter, too (just like the rest of the free world, it would seem.)

It may not be a good thing, depending on what you try to hide on your computer. :)

After seeing it reported elsewhere that Spotlight's "All Images" search on Leopard really does serve up every image on the system, I decided to give it a try myself and see what turned up. Sure enough, every single piece of spam I've received in the last week that included an in-line image (as a MIME attachment) ended up contributing to the show.

In this screenshot, you can clearly see all the images from the spam messages. The on of the woman in the hammock is actually from a spam message, if you can believe that. No idea who she is, but whatever email message that image was sent in got filed as spam.

A quickie for those that want to actually get their hands dirty with OS X's ipfw firewall: WaterRoof seems to be the tool for configuring an ipfw firewall, setting a startup script for it, etc. for Leopard. One of the nice things is that it comes with a few rules sets that make getting the basic firewall quite simple.

I've simply turned off the Leopard "Firewall" for now, and reverted to the tried-and-true ipfw firewall instead.

Worked my way through a bit more of my system, and found another thing that's not very happy with Leopard. Turns out that the MySQL Community Server (the free one you can download from mysql.com) really doesn't work on Leopard, and it seems that it's primarily the Preference Pane, startup item, and socket locations that need tweaking. Actually, people seem to be saying you should just ditch the preference pane and the startup item entirely. Apparently during the upgrade my data disappeared, too, which is somewhat entertaining. It was all testing data, and I can easily pull it from the production sources again (or even boot my backup drive and dump it from there.)

At this point, I'm probably going to just install the macports version of mysql (and postgresql) and use that. The Mysql.com version was nice because it included the StartupItem and a nice Preference Pane to control the service, but that was, really, its only benefit.

For an idea, simply searching on Google for "mysql leopard" will give you a number of useful and relevant items.

I've spent a weekend with Mac OS X 10.5 Leopard, now, including a couple aborted attempts at installing it, and I think I can safely say I'm liking it. I tend to shy away from *.0 releases, primarily because they never have all the bugs worked out. For the most part, I'm impressed at how 10.5.0 is. Sure, there's a couple rough edges, but I expect they will be addressed in point releases over the next couple months.

By far my biggest problem was getting Leopard installed. It had been long enough since I upgraded from Panther (10.3) to Tiger (10.4), that I had forgotten all the good advice and experience. My first attempt was an in-place upgrade (choose "Upgrade" from the install types). Due to my ignorance, I had left a number of relatively "hacky" things installed before the upgrade that wouldn't work post-upgrade. Once I restored my 10.4 system and pulled out the hacks, things worked much better. And, while I'm making a point to go into some detail here about these problems, the overall experience was actually very good. (My final system, for the record, was installed with the "Archive & Install" option, not the "Upgrade" option.)

Really, my biggest complaint about the upgrade was that it took a couple hours for the install, and then several hours of Spotlight re-indexing my HD. Starting the upgrade before going to bed cured me of having to wait for it, though. I imagine a current-generation MacBook or MacBook Pro would take much less time for the install.

Things That Wouldn't Work

• Saft
• GPGMail
• MailFollowup
• SideTrack

Saft

Saft is a "plug-in" for Safari that uses the deprecated – and now modified – InputManagers facility to do everything it does. Because of the changes in Leopard to make it more difficult for random InputManagers to be installed (think "trojans"), Saft needed to be modified so that it could still work. If you go to the Saft home page you'll see that a new version is already available, but is now a wrapper for Safari rather than a transparent plug-in. It's also $12, even if you already paid for the Tiger version.

While the cheap bastard in me is annoyed at having to pay again for the new version, I'm actually more bothered by the fact that Saft is now a wrapper that you launch instead of Safari. This simply gives more weight to my desires that Apple provide an actual plug-in API for Safari. I won't hold my breath, though. It's entirely likely that when I get annoyed enough with all the ads, pop-ups and uncontrollable web page animations, I might just buckle down and re-purchase Saft. Unless, that is, another product does the job better.

GPGMail and MailFollowup

I see these more as a single problem caused by differences in the Leopard version of mail from the Tiger version of mail. As a result, most Mail plug-ins (mailbundles) are very likely to not work. I removed them both when I realized what was crashing Mail. MailFollowup has since been updated for Leopard, and it seems to be working normally now. The GPGMail developer is working on porting the plugin to Leopard, and will hopefully have a release soon.

On a somewhat related note, the GrowlMail plugin I had been using simply doesn't work at all, and neither does the version included in the latest Growl download. More on that as I hear about it.

SideTrack

The loss of this third-party trackpad driver is really the one thing that hurts the most about the upgrade to Leopard. My machine is a 1.5GHz G4 PowerBook 15, which happens to be the generation before Apple added the two-finger scrolling to their laptops, so SideTrack was a life-saver. It didn't do two-finger scrolling or right-clicking, but it did let me define scroll areas on the trackpad edge, as well as defining actions for taps in the trackpad corners. I'm really missing my corner-taps (which I used for right-click and expose) and scrolling. The developer is working on figuring out how to get SideTrack working on Leopard, but until then I'm left waiting, and looking at other options.

Other Issues

Aside from those issues, what have I run into? Well, no show-stoppers, really, but I have found a couple problems so far that I am hoping get fixed in 10.5.1.

The Menu Bar

I groaned in pain when I first heard that the menu bar in OS X was going to be semi-translucent. While it's not as bad as I imagined, it's still quite horrible, in my opinion. The basic effect is that the menu bar takes on the shades of whatever colors are underneath it as part of your desktop background. I hate it. If I've got a blue desktop image, the menu bar is blue-ish. Right now I'm using the "Mohave" black-and-white photo that was included with Leopard, as it gives the menu bar a grayscale look. I consider it a temporary work-around.

Apple, please, do us all a favor and add an option somewhere (probably in the Desktop and Screen Saver preferences pane) that gives us the option of restoring our solid, white menu bar.

The Dock

I've always been a "Dock on the Right Edge" guy, even before I moved to Mac from Linux, so I was downright gleeful when Apple changed the look of the Dock (after public outcry over the mirrored-shelf look) when it's on a side edge of the screen. It's a little too dark, though. I suppose I'll live with it. I still can't stand the mirrored-shelf look when the dock's on the bottom, though.

I can has BlueTooth?

I haven't yet correlated it yet to exactly when or how I sleep my PowerBook, but I've noticed twice now that when I've woken it up, I've lost my BlueTooth. By "lost," I mean that it's no longer available. It's almost as if the driver module crashed when the system woke back up again. I think it's only happening when I force the PowerBook to suspend-to-disk (via Deep Sleep) and power off, which is my preferred way of sleeping the system when I know I'm not going to use it for a couple hours, or simply don't know when I'll next use it.

Nonetheless, this never happened with Tiger, so I'm going to assume it's a bug that will get quashed with 10.5.1. I can't be the only one experiencing this, but just to hedge my bets I'll have to poke around the Apple forums and see.

SpamSieve

I hate spam. You hate spam. Everybody hates spam. Thankfully, SpamSieve, which is possibly the best client-side spam filtering application I've ever used, works (mostly) fine on Leopard. For some reason, it's enjoying taking about a minute to start up on my PowerBook, which seems to be an issue the author knows about. Apparently Leopard is doing some things differently enough that it can have drastic effects on SpamSieve's performance. Thankfully, startup is the only time I get hit by this issue, so I've worked around it by having SpamSieve start up at login, and not quit when Mail quits. That way, it's already running when I need it.

Firewall

Oddly enough, the firewall in Leopard apparently doesn't use ipfw. I'm not entirely sure how it works, but as near as I can figure it's using the "sandboxing" stuff. The ipfw suite is still there, of course, and you can put any rules you want in there, but it appears to be completely seperate from the "Firewall" tab in the Security preference pane. Hopefully more knowledgeable people than I will expound upon this, soon.

What's particularly disconcerting is that when X11 is running, port 6000 is open. What's up with that? That's a security nightmare! I couldn't seem to get the Firewall to block access to X11, either (by adding X11, and selecting "Block incoming connections.)

On the bright side, at least nmap reports "access denied":

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 4.5 (protocol 2.0)
6000/tcp open  X11     (access denied)

Still, Apple, why exactly are you ignoring the excellent ipfw tools?

Miscellaneous

The upgrade deleted all my print queues. I suppose I should have expected this, but I still found it rude. On the bright side, managing printers feels simpler than it did in Tiger, and it was a snap to re-add all the printers I use (especially since my printer at home uses Bonjour.)

There seems to be some magic going on, likely with launchd, that causes X11 to be automatically started up when you reference the $DISPLAY environment variable in a UNIX shell. This happened both in Terminal.app and iTerm. Unexpected, but I tend to have X11 running all the time anyway, so this doesn't really change much for me, other than not having to remember to start it up myself.

I had to re-install the Cisco VPN client for work. I expected this, anyway, given that I did an "Archive & Install" upgrade, but as it turns out, work had a newer version anyway, so it was all good. I haven't actually tried connecting with it yet, though, so I'm not sure if it actually works with Leopard.

Xjournal, a somewhat popular LiveJournal blogging tool, crashes when trying to log in to LJ on Leopard. There's a fixed version available, and the developers are including the fixes in the next release. See the developer's blog and the Xjournal LiveJournal community blog for more information.

Most other apps had updates available (and easily installable) thanks to the fact that so many developers are using the Sparkle updating framework.

Some Advice

First of all, do your research on what's going to work, primarily regarding anything you've installed to enhance or extend the functionality of your Mac. Most of these will stop working, and a lot of them have already been updated for Leopard in the week since it's release. Secondly, I'm a very big proponent of the "Archive & Install" method of OS X upgrades versus the "Upgrade" method, as the "Archive & Install" more or less guarantees that you'll have a clean OS core installed. That said, I can safely say that the "Upgrade" method will work, and will likely work with very few problems, and leave with with fewer things you may need to either re-install or upgrade post-system-upgrade.

In fact, I can safely say that the issues I was having after doing an in-place upgrade (choosing "Upgrade" in the OS X Installer) were not due to OS upgrade directly, but were all related to the various apps and utilities I had installed. More correctly, the problems were in the apps and utilities, and not problems with the OS upgrade process. I can say this with some certainty because the same problems persisted after I fully restored my old system and re-tried with the "Archive & Install" option.

Just about every problem I have run in to seems to revolve around some last-minute changes in Leopard that none of the third-party developers could know about. They're catching up, though, and quickly. If you run into an application that has a problem on Leopard, check it out. You may find that the developers already know about the problem, already have a fix, or may even already have released a new version that includes the fix.

I'm a strong advocate of the "Archive & Install" upgrade method, though the "Upgrade" in-place upgrade method will certainly work just as well, especially if you want minimal post-upgrade hassle and don't have much (or anything) in the way of hack-ish functionality extensions installed. The installer is fairly solid.

I Like Cats. I Also Like Cheese.

Overall I'm pretty happy with Leopard. I'm a bit peeved at the firewall issue, which, in my eyes, is a glaring problem. All told, though, most of the issues are with applications that needed updates to work with Leopard. Given all the changes in Leopard over Tiger, I'm quite please that as many things worked without a hitch as have, and big kudos to all the developers responding so quickly where apps are encountering problems that didn't happen with the last developer seed of 10.5.

I am hoping, though that 10.5.1 doesn't take too long to come around, and carries a few fixes to remove some of these issues.

Even with everything I've outlined here, though, I'd still recommend Leopard as an upgrade over Tiger. It's still reasonably snappy on my PowerBook G4 (on par with Tiger.) Once we get past the .0 roughness, Leopard should shine even more brightly.

Hello from my new digs at my new domain!

I've finally figured out that trying to come up with a groovy, rippin' domain name that would sound cool and be thematic towards my writing was too much of a pain in the ass, and decided that I should simply be me. So, with that in mind, welcome to Ruiz-Ade.com, home of me, Gregory Ruiz-Ade, and my lovely wife, Lea.

I hope to be much more productive in my writing here than I've been at method.unnerving.org, or potentially even my LiveJournal blog. Time, of course, will tell whether this will be true or not.