Not only is this the final icon for Photoshop CS3, but Adobe has redesigned the entire CS3 application suite around the same concept. People all over the Mac web are weighing in on the matter, and they’re generally sitting in one of two camps: They either love it or they hate it. Here are some links to the ongoing commentary:
John Nack
Veerle
Jason Santa Maria
Dave Shea

Personally, I’m on the fence. No, that’s not actually completely accurate. Personally, I can see both sides, and in the end I think that the icon redesign sort of breaks even. I think we basically lose as much as we gain between form and functionality with these new icons. And I think that there is another approach that would have worked better than the one taken by Adobe on CS3.

The new CS3 suite icons are all based on the same idea. A colored square with a two-letter identifier that mimics the periodic table of elements. It’s a nice concept in a way, especially considering its entire purpose seems to be to unite a vast and sprawling suite of applications. And I think on this level it works. Applications from the Adobe suite will be immediately recognizable as such in the Dock, and telling each application apart shouldn’t be too terribly difficult. I even kind of like the sparse, minimal appearance of these new icons.

The Adobe CS3 Icon Set: Confused Yet?
(click image for larger view)

My first problem, though, is that they’re not particularly iconic. They’re basically text. Or, the thing that’s used to identify each application is text. Conceptually, this bothers me a little. The Adobe suite of applications is, for all intents and purposes, visual in nature. It’s made for processing imagery moreso than text. These are not text applications, but image editing applications. They’re made for visual people working on visual projects. So using text as an identifier seems a strange — maybe even an inappropriate — approach. I can see it for something like the Microsoft Office suite, which does indeed use text-based icons. But for image editing apps it just seems wrong to not use something image-based.

My other complaint, from a practical standpoint, is that text is a much clumsier, more difficult way to identify an application than symbolism. It requires hard looking, reading, something more than a mere glance. Icons are, at their hearts, symbols, and symbols are intuitively easier to grasp than text. Which is the whole reason icons tend to be made from images rather than text in the first place. It’s the reason almost everything on a GUI-based interface is a picture rather than (or in addition to) text. Can you imagine a folder on your Desktop that was a big square with the letters “Fo” on it? Imagine an entire OS described this way. I’d guess it’d get a bit trickier to navigate. (Actually, you don’t have to imagine it. Just open up the Terminal. It’s called the UNIX command-line. And we all know how popular that is with the design crowd.)

Adobe CS3 Apps in the Dock: Imagine an Entire OS Like This
(image stolen from Dave Shea)
(click image for larger view)

It seems to me that there is a better approach for Adobe — one that could unify the suite, while at the same time keeping in step with a more purely visual approach. We can see traces of it in the one exception to the rule with the new suite icons: Acrobat. Acrobat’s icon uses the same sparse approach as the other applications — an application identifier on a colored square — but instead of using text as an identifier, it uses the well-known Acrobat icon image — that weird little loopy-loop we all know so well, and that we immediately associate with Acrobat — in the center of the colored square. Veerle (who likes the new icons) had this to say about it:

You might wonder why Acrobat Reader hasn’t “Ar” as icon or “Pd” or something, just to take the same line with the rest of the products. The curvy triangle is so well known that it’s obvious they kept using it for the icon. I think if the other applications had a similar icon over the years, they would have done the same. Since there are none they decided to use a two-letter mnemonic ‘nickname’ system as their primary identifier.

And therein lies both the problem and the solution. I think the best approach Adobe could take — both from a conceptual and a practical standpoint — would be to actually create memorable, iconic symbols for each of their applications. Thus far they have not done so, and choosing instead to represent their apps with plain two-letter text identifiers just seems a little cheap, lazy and ineffectual. Why doesn’t Photoshop have such a memorable symbol associated with its product line after all these years? Or Illustrator? By now they really should. Maybe it’s time to start working on these.

Past Adobe icons were visual in nature, but suffered from a lack of readability in the Dock. They were pretty, but they looked too similar and their imagery made no sense whatsoever — form over function. But this new set will suffer from the same sort of unreadability. They’re less visual, less image-based, but still very similar. And they’ll now require yo

u to read them and decipher their two-letter code. Still, they’ll be somewhat easier to discern from one another (since the letters at least correspond to something in the real world, i.e. the application name, whereas the previous icons used images that were completely arbitrary and nonsensical) and a bit more unified as a group, though arguably less attractive — function over form. It’s a tradeoff. But one that, again, we break even on with the new icon set. This new icon set offers no functional or aesthetic advantages over its older counterpart. Or what advantages it may offer are offset by disadvantages it spawns. Creating real symbols that speak somehow to the nature of the application — like they’ve done in some respects with Acrobat — for the rest of the suite would solve the problems of both form and function: Icons created from these symbols would be both more beautiful and more functional. You would think a big, giant, design-based software company would get this. But so far, they seem to have missed the boat.

I don’t hate the new icons. I actually think they look kind of cool in a minimal sort of way. But they’re just not particularly visually interesting, nor will they add much functionality over their predecessors. So I can’t say I’m overly enamored with them either. For a major change to a major application suite — one that has a lot of folks up in arms — I have to say, I’m feeling quite… neutral on the matter. And that’s a little disappointing in and of itself. I wish I were feeling excited.

The Installer
I wanted to briefly mention the installer for Photoshop CS3, because it’s pretty nice, particularly in contrast to the Acrobat Reader installer. No, it’s not an Apple Installer, but it does offer a great deal of control (and some features not available from Apple Installers), and from a systems perspective, this is wonderful. Most notably, the Photoshop CS3 installer (called Setup.app) contains an uninstaller. Awesome! Yes, it may be hard to believe, but there have been times I actually wanted to completely uninstall Photoshop, and I couldn’t. Now I can.

Adobe Photoshop CS3 Beta: Uninstall or Reinstall
(click image for larger view)

The uninstaller even gives you the option to delete application preferences. Wow. That’s pretty thorough.

Adobe Photoshop CS3 Beta: Uninstalling Components
(click image for larger view)

Secondly, the installer allows you to choose which Photoshop components get installed, or to reinstall or uninstall specific components of the suite. Don’t use Camera RAW? Don’t use Bridge? Fine. Don’t install ‘em. Change your mind? Fine. Go reinstall ‘em.

Adobe Photoshop CS3 Beta: Reinstalling Components
(click image for larger view)

I can’t believe I’m saying this, but Adobe has really gotten this installer right. If I can’t have drag-’n'-drop or package installers, then this is what I want. The only problem is, I’m pretty sure it won’t work with Apple Remote Desktop (but then it never did anyway). Otherwise, I’m pleased as punch.

One other thing to note about the beta installation: Adobe requires you to produce a valid Photoshop CS2, Creative Suite 2, Production Studio, Adobe Web Bundle, or Adobe Video Bundle serial number to use the beta for longer than the 2-day trial period. Supply this serial number and you’ll be given a new serial number for the beta. The new serial number can be used to activate the software until the beta expires, ostensibly some time around the official release date. The software gets activated online via a connection to Adobe, and it keeps tabs on how many machines you’ve installed the beta on. The limit is two computers. I installed it on two machines, but then, after installing it on the third I received this alert when trying to activate the software:

Adobe Photoshop CS3 Beta: Too Many Activations
(click image for larger view)

This seems relatively fair to me. The only thing I find somewhat irksome is that we have a 20-seat volume license. So, to my way of thinking, our serial number should be good for 20 installs of the beta. Apparently Adobe feels differently. I also wish I could deactivate machines remotely, via this interface (like you can with iTunes music, for instance). But no, unfortunately I’ll have to go over to the machines in question, log in and deactivate them locally. Oh well.

The Icon
The first thing I noticed after installing the Photoshop Beta was the strange, minimal application icon. I kind of like it, but it seems somewhat inappropriate to me that Photoshop — an image editing application that’s always had pretty fancy icons — has such a plain one. I’m assuming that this is just the icon they’ll use for the beta, and that a more sophisticated icon will come with the shipping version.

Adobe Photoshop CS3 Beta: Minimal Beta Icon
(click image for larger view)

The Hot New Features
One item of significance — in fact, according to the scuttlebutt, it’s a big reason the beta was released — is that this is the first version of Photoshop to run natively on Apple’s latest Intel hardware. Amazingly, this comes off as a footnote in most of the reviews, overshadowed by the fact that this also happens to be the first major revision of the photo-editing powerhouse to actually be packed with exciting, new and useful features. In fact, after trying it out, it’s the first time I’ve been impressed with an Adobe release other than Lightroom in years. And it’s Photoshop, man. Frickin’ Photoshop!

One of the most discussed aspects of Photoshop CS3 is the interface, and it’s certainly worth a mention here. It’s been quite extensive

ly overhauled, and yet still feels completely familiar. Everything is right where you’d expect it, but there are numerous productivity enhancements throughout the app. Little touches, really, like a toolbar that is one tool wide, giving you more room for viewing your image. Palettes are more logically (and attractively) presented and unified, instead of floating around all over the place. This seems to be the trend with a number of apps, and if AfterEffects 7 and Lightroom are any indication, Adobe is following it. This is a good thing. I truly hate moving windows and palettes around. And with today’s big screens, there should be little need to.

Adobe Photoshop CS3 Beta: Nice Interface Refinements
(click image for larger view)

My one big beef is that there still seems to be no key command to switch between open documents. Almost every other application on the Mac nowadays uses “command- `” to switch between open docs. Yet Photoshop CS3 still not only fails to adhere to this standard, but apparently lacks the ability to switch between open docs with the keyboard at all. This seems like a strange oversight for such a significant interface overhaul. I also wish Adobe would use standard Apple key-commands for things like hiding the app (“command-h” on the Mac, generally) but at least the ability exists to do this from the keyboard, and it’s configurable.

Finally, the Refine Edge tool is quite the talk of the town. And for good reason. Anyone who’s ever tried to select a color range and then tried to tweak the selection has longed for this tool, which basically allows you to interactively refine the edges of your selections. And it’s finally here!

Adobe Photoshop CS3 Beta: Refine Edge
(click image for larger view)

Video (Yes, Video!)
But there’s another fantastic new addition to Photoshop CS3, and it’s one no one’s mentioned, maybe because no one’s quite as weird as me: Animation. For years I’ve wished Photoshop — with it’s powerful layering capabilities, selection tools and brushes — could be used as a 2D animation tool. I always wanted to be able to import and draw on video in Photoshop. You could always fake this with ImageReady, which came with basic Quicktime import/export functions and a pretty useful Animation palette, and which I’ve demoed in my class numerous times. But it was clunky and confusing. ImageReady was not well equipped to deal with large numbers of relatively large images — it became painfully slow — and it lacked WACOM touch-sensitivity and the full range of brushes found in Photoshop. Plus, it was just plain inconvenient to use ImageReady when Photoshop was sitting right there. Well, my wait is finally over. Photoshop CS3 now includes the very same Animation palette formerly found only in ImageReady. It’s there, and it works exactly as it did in ImageReady. Only now we get all that Photoshop goodness and the familiar interface we all know and love (or at least are accustomed to). Hooray!

Adobe Photoshop CS3 Beta: Holy Shit! Animation!
(click image for larger view)

There are a few new video-specific features too, though you might not know it from the coverage. There’s a “Video and Film” Workspace, for one, which highlights all video-related menubar items and brings forth video-related palettes, including the Animation palette.

Adobe Photoshop CS3 Beta: Video and Film Workspace Highlights
(click image for larger view)

And now, since Photoshop CS3 does video, it only seems appropriate that it should have the ability to preview that video to a monitor, which in fact it now does.

Adobe Photoshop CS3 Beta: Video Preview
(click image for larger view)

All these new video capabilities were a huge surprise to me. And a hugely pleasant one. There was a time when I got pretty excited about new Adobe releases, but it was a long time ago. It’s great to see Adobe, once again, release a really compelling version of Photoshop. I’m amazed at how much thought and care they’ve given “the little things,” from the interface to the installer to, of all things, video. And yet they’ve still managed to keep all the good bits. This version has something for everyone. I, for one, am truly impressed.

UPDATE:
Looks like I was wrong. The new Photoshop CS3 icon featured in the beta is here to stay. Not only that, lots of people are buzzing about it. Personally, my favorite comment on the “issue” so far (I haven’t had time to read them all — Help! I’m on dialup!) is one from John Nack:

[Not dismissing your opinion at all, but isn't it nice that in this world, at the end of 2006, it's computer iconography that constitutes our nightmares? We are very lucky to have literacy, intelligence, and leisure enough to give a damn about this stuff. -

-J.]

Totally agree. Still, I’ve decided to add my voice to the already huge compendium of opinion on the matter.

Installing RsyncX
I do not use, nor do I recommend the version of rsync that ships with Mac OS X 10.4. I’ve found it, in my own personal tests, to be extremely unreliable, and unreliability is the last thing you want in a backup program. Instead I use — and have been using without issue for years now — RsyncX. RsyncX is a GUI wrapper for a custom-built version of the rsync command that’s made to properly deal with HFS+ resource forks. So the first thing you need to do is get RsyncX, which you can do here. To install RsyncX, simply run the installer. This will place the resource-fork-aware version of rsync in /usr/local/bin/. If all you want to do is run rsync from the RsyncX GUI, then you’re done, but if you want to run it non-interactively from the command-line — which ultimately we do — you should put the newly installed rsync command in the standard location, which is /usr/bin/.¹ Before you do this, it’s always a good idea to make a backup of the OS X version. So:

sudo cp /usr/bin/rsync /usr/bin/rsync-ORIG
sudo cp /usr/local/bin/rsync /usr/bin/rsync

Ah! Much better! Okay. We’re ready to roll with local backups.²

Local Backups
Creating local backups with rsync is pretty straightforward. The RsyncX version of the command acts almost exactly like the standard *NIX version, except that it has an option to preserve HFS+ resource forks. This option must be provided if you’re interested in preserving said resource forks. Let’s take a look at a simple rsync command:

/usr/bin/rsync -a -vv /Volumes/Work/ /Volumes/Backup --eahfs

This command will backup the contents of the Work volume to another volume called Backup. The -a flag stands for “archive” and will simply backup everything that’s changed while leaving files that may have been deleted from the source. It’s usually what you want. The -vv flag specifies “verbosity” and will print what rsync is doing to standard output. The level of verbosity is variable, so “-v” will give you only basic information, “-vvvv” will give you everything it can. I like “-vv.” That’s just the right amount of info for me. The next two entries are the source and target directories, Work and Backup. The –eahfs flag is used to tell rsync that you want to preserve resource forks. It only exists in the RsyncX version. Finally, pay close attention to the trailing slash in your source and target paths. The source path contains a trailing slash — meaning we want the command to act on the drive’s contents, not the drive itself — whereas the target path contains no trailing slash. Without the trailing slash on the source, a folder called “Work” will be created inside the WorkBackup drive. This trailing slash behavior is standard in *NIX, but it’s important to be aware of when writing rsync commands.

That’s pretty much it for simple local backups. There are numerous other options to choose from, and you can find out about them by reading the rsync man page.

Network Backups
One of the great things about rsync is its ability to perform operations over a network. This is a big reason I use it at work to back up staff machines. The rsync command can perform network backups over a variety of protocols, most notably SSH. It also can reduce the network traffic these backups require by only copying the changes to files, rather than whole changed files, as well as using compression for network data transfers.

The version of rsync used by the host machine and the client machine must match exactly. So before we proceed, copy rsync to its default location on your client machine. You may want to back up the Mac OS X version on your client as well. If you have root on both machines you can do this remotely on the command line:

ssh -t root@mac01.systemsboy.com 'cp /usr/bin/rsync /usr/bin/rsync-ORIG'
scp /usr/bin/rsync root@mac01.systemsboy.com:/usr/bin/

Backing up over the network isn’t too much different or harder than backing up locally. There are just a few more flags you need to supply. But the basic idea is the same. Here’s an example:

/usr/bin/rsync -az -vv -e SSH mac01.systemsboy.com:/Volumes/Work/ /Volumes/Backups/mac01 --eahfs

This is pretty similar to our local command. The -a flag is still there, and we’ve added the -z flag as well, which specifies to use compression for the data (to ease network traffic). We now also have an -e flag which tells rsync that we’re running over a network, and an SSH option that specifies the protocol to use for this network connection. Next we have the source, as usual, but this time our source is a computer on our network, which we specify just like we would with any SSH connection — hostname:/Path/To/Volume. Finally, we have the –eahfs flag for preserving resource forks. The easiest thing to do here is to run this as root (either directly or with sudo), which will allow you to sync data owned by users other than yourself.

Unattended Network Backups
Running backups over the network can also be

completely automated and can run transparently in the background even on systems where no user is logged in to the Mac OS X GUI. Doing this over SSH, of course, requires an SSH connection that does not interactively prompt for a password. This can be accomplished by establishing authorized key pairs between host and client. The best resource I’ve found for learning how to do this is Mike Bombich’s page on the subject. He does a better job explaining it than I ever could, so I’ll just direct you there for setting up SSH authentication keys. Incidentally, that article is written with rsync in mind, so there are lots of good rsync resources there as well. Go read it now, if you haven’t already. Then come back here and I’ll tell you what I do.

I’d like to note, at this point, that enabling SSH authentication keys, root accounts and unattended SSH access is a minor security risk. Bombich discusses this on his page to some extent, and I want to reiterate it here. Suffice to say, I would only use this procedure on a trusted, firewalled (or at least NATed) network. Please bear this in mind if you proceed with the following steps. If you’re uncomfortable with any of this, or don’t fully understand the implications, skip it and stick with local backups, or just run rsync over the network by hand and provide passwords as needed. But this is what I do on our network. It works, and it’s not terribly insecure.

Okay, once you have authentication keys set up, you should be able to log into your client machine from your server, as root, without being prompted for a password. If you can’t, reread the Bombich article and try again until you get it working. Otherwise, unattended backups will fail. Got it? Great!

I enable the root account on both the host and client systems, which can be done with the NetInfo Manger application in /Applications/Utilities/. I do this because I’m backing up data that is not owned by my admin account, and using root gives me the unfettered access I need. Depending on your situation, this may or may not be necessary. For the following steps, though, it will simplify things immensely if you are root:

su - root

Now, as root, we can run our rsync command, minus the verbosity, since we’ll be doing this unattended, and if the keys are set up properly, we should never be prompted for a password:

/usr/bin/rsync -az -e SSH mac01.systemsboy.com:/Volumes/Work/ /Volumes/Backups/mac01 --eahfs

This command can be run either directly from cron on a periodic basis, or it can be placed in a cron-run script. For instance, I have a script that pipes verbose output to a log of all rsync activity for each staff machine I back up. This is handy to check for errors and whatnot, every so often, or if there’s ever a problem. Also, my rsync commands are getting a bit unwieldy (as they tend to do) for direct inclusion in a crontab, so having the scripts keeps my crontab clean and readable. Here’s a variant, for instance, that directs the output of rsync to a text file, and that uses an exclude flag to prevent certain folders from being backed up:

/usr/bin/rsync -az -vv -e SSH --exclude "Archive" mac01.systemsboy.com:/Volumes/Work/ /Volumes/Backups/mac01 --eahfs > ~/Log/mac01-backup-log.txt

This exclusion flag will prevent backup of anything called “Archive” on the top level of mac01′s Work drive. Exclusion in rsync is relative to the source directory being synced. For instance, if I wanted to exclude a folder called “Do Not Backup” inside the “Archive” folder on mac01′s Work drive, my rsync command would look like this:

/usr/bin/rsync -az -vv -e SSH --exclude "Archive/Do Not Backup" mac01.systemsboy.com:/Volumes/Work/ /Volumes/Backups/mac01 --eahfs > ~/Log/mac01-backup-log.txt

Mirroring
The above uses of rsync, as I mentioned before, will not delete files from the target that have been deleted from the source. They will only propagate changes that have occurred on the existing files, but will leave deleted files alone. They are semi-non-destuctive in this way, and this is often useful and desirable. Eventually, though, rsync backups will begin to consume a great deal of space, and after a while you may begin to run out. My solution to this is to periodically mirror my sources and targets, which can be easily accomplished with the –delete option. This option will delete any file from the target not found on the source. It does this after all other syncing is complete, so it’s fairly safe to use, but it will require enough drive space to do a full sync before it does its thing. Here’s our network command from above, only this time using the –delete flag:

/usr/bin/rsync -az -vv -e SSH --exclude "Archive/Do Not Backup" mac01.systemsboy.com:/Volumes/Work//Volumes/Backups/mac01 --delete --eahfs > ~/Log/mac01-backup-log.txt

Typically, I run the straight rsync command every other day or so (though I could probably get away with running it daily). I create the mirror at the end of each month to clear space. I back up about a half dozen machines this way, all from two simple shell scripts (daily and weekly) called by cron.

Conclusion
I realize that this is not a perfect backup solution. But it’s pretty good for our needs, given what we can afford. And so far it hasn’t failed me yet in four years. That’s not a bad track record. Ideally, we’d have more drives and we’d stagger backups in such a way that we always had at least a few days backup available for retrieval. We’d also probably have some sort of backup to a more archival medium, like tape, for more permanent or semi-permanent backups. We’d also probably keep a copy of all this in some offsite, fireproof lock box. I know, I know. But we don’t. And we won’t. And thank god, ’cause what a pain in the
ass that must be. It’d be a full time job all its own, and not a very fun one. What this solution does offer is a cheap, decent, short-term backup procedure for emergency recovery of catastrophic data loss. Hard drive fails? No trouble. We’ve got you covered.

Hopefully, though, this all becomes a thing of the past when Leopard’s Time Machine debuts. Won’t that be the shit?

1. According to the RsyncX documentation, you should not need to do this, because the RsyncX installer changes the command path to its custom location. But if you’ll be running the command over the network or as root, you’ll either have to change that command path for the root account and on every client, or network backups will fail. It’s much easier to simply put the modified version in the default location on each machine.

2. Updates to Mac OS X will almost always overwrite this custom version of rsync. So it’s important to remember to replace it whenever you update the system software.

Since this site is primarily about systems, it seemed appropriate to focus on an art form specifically related to the computer. And since I dabble in icon creation, and have worked up quite a collection over the years, I’ve decided to post a little sampler, and talk about my process. Just for a wee change of pace. Just for fun.

This is the first icon I ever made. I labored on this thing for days, trying to get that shiny, translucent, jelly bean look so prevalent on the Mac. Yes. It totally sucks major ass.

My First Icon: It Sucks Major Ass
(click image for larger view)

I quickly outgrew the glossy, candy-coated style — especially once I realized that I sucked at, and didn’t enjoy making them — and started developing my own. I have two basic styles. The first one to emerge was a very flat, geometric style. My process is not very elegant, but I’ve used it for some time now and it works so I stick with it. Basically all the drawing is done in Illustrator. When I get a version I like I simply copy and place it into a 533×533 pixel Photoshop document. Typically, some color correction is required after the transfer. Mainly, the blacks get washed out, so I have a Photoshop action that selects the black range and drops it down to zero. Then the image gets resized to 128×128 pixels. Finally I use IconFactory’s IconBuilder 5.1 plug-in (no longer current) for Photoshop to export the image to the icon format. Typically, here I just do a “QuickBuild” (which, unfortunately seems to be missing from later versions of IconBuilder). I don’t really worry about creating multiple versions of my icons for different icon sizes and views. I just try to make icons that scale reasonably well. This is for fun after all. I’m not a pro, nor do I aspire to be.

Geometric Icons: Not Quite as Sucky
(click image for larger view)

The second style, and the one I generally prefer to work in nowadays, is more hand-drawn and cartoonish. Still somewhat flat, with some shading but no gradients and far less geometry than the above. These are all done using my trusty WACOM tablet, which I simply adore. Working this way allows me much greater expressiveness through line weight and shape, and through the individuality of my own particular drawing style. Plus it’s just way more fun, though it can be a lot more work to get everything looking just right.

Hand-Drawn Icons: My Personal Faves
(click image for larger view)

A lot of these icons were intended as drive icons. I have a few different computers I work on regularly, and I tend to file-share between them a lot. Each has a SysApps partition and Work partition. Labeling each SysApps and Work drive on each system, while being aesthetically pleasing, also has the added advantage of making it very easy to distinguish which SysApps or Work drive I’m accessing at a glance when file-sharing. It’s both practical and pretty. (Well, I think so anyway.)

Marx Brothers Icons: I Got Paid!
(click image for larger view)

Recently someone took notice of some of the icons I’d used in he lab and commissioned me to make him a custom set based on the Marx Brothers, he being a big Marx brothers fan and all. We worked together to figure out what he would like, and he gave me all kinds of resources and suggestions for the project, but I had a lot of freedom. It was the first and only job I’ve ever had like that. The first time I’ve ever had to create something visual for someone other than myself, but he was very cool to work with, I liked the challenge, and it was a really fun process. Basically I worked on it in my spare time, and I’d show him progress sketches every so often. He’d give me feedback and I’d go work on them some more and show him the results when things got good. The thing I liked best about the project was this outside feedback. It really kept me from being lazy. And in the end the icons were far more polished than I think they ever would have been had I just been working on them alone. I’m kind if a loner in a lot of ways, both professionally and personally. Not a big collaborator. But every now and then it’s great to have some outside eyes. Some second opinions.

Which, now that I think about it, may be the whole reason to have a blog.

After reading this hint I was reminded of a script I wrote a while back based on yet another MacOSXHints hint that uses ditto to create Finder-like .zip archives. So it seemed like a good time to post the script here and add it to the waning ScriptSharing series.

So here it is: my Archive script. It will both archive and expand folders or files using ditto, and it places these archives on the Desktop.

Archiver Script
See the code

Um… What The Fuck?… I’m irked.

Anyone know a way to sort del.icio.us bookmarks in some logical order, once and for all? Please. I’m begging.

Let me give an example. I have a script that creates user accounts. At the beginning of the script it asks me to supply a username, among other things, and assigns this to a variable in the script called $username. Kinda like this:

echo "Please enter the username for the new user:"read username

Later in the script that variable gets called to set the new user’s username, and a whole bunch of other parameters. Still later in the script, I need to send a command to a remote machine via ssh, and the command I’m sending contains the $username variable:

ssh root@home.account.server 'edquota -p systemsboy $username'

This command would set the quota of the new user $username on the remote machine to that of the user systemsboy. But every time I’ve tried to include this command in the script, it fails, which, if you think about it, makes a whole lot of sense. See, ’cause the remote machine doesn’t know squat about my script, and when that command gets to the remote machine, the remote machine has no idea who in the hell $username is. The remote machine reads $username literally, and the command fails.

The solution to this is probably obvious to hard-core scripters, but it took me a bit of thinkin’ to figure it out. The solution is to create a new variable that is comprised of the ssh command calling the $username variable, and then call the new variable (the entire command) in the script. Which looks a little something like this:

quota=`ssh -t root@home.account.server "edquota -p systemsboy $username"`echo "$quota"

So we’ve created a variable, called $quota, which is the entire ssh command, and then we’ve simply called that variable in the script. That $quota variable will have the $username variable already filled in, and the command will now succeed on the remote machine. One thing that’s important to note here: generally the command being sent over ssh is enclosed in single-quotes. In this instance, however, it must be enclosed in double-quotes for the command to work. I also used the -t option in this example (which tells ssh that the session is interactive, and to wait until it’s told to return to the local machine) but I don’t actually think it’s necessary in this case. Still, it shouldn’t hurt to have it there, just in case something goes funky.

But so far nothing has gone funky. This seems to work great.

The occasion for learning all this was a wee little problem I had with my Mac OS X clients. For some reason, which I’ve yet to determine, a batch of them became hopelessly unbound from the Open Directory master on our network.

Weird Client Problem: “Some” Accounts Available? Huh?
(click image for larger view)

The solution for this was to trash their DirectoryService preferences folder, and then to rebind them to the server. This was always something I’d done exclusively from the GUI, so doing it on numerous clients has always been a pain: log into the client machine, trash the prefs, navigate to and open the Directory Access application, authenticate to the DA app, enter the OD server name, authenticate for directory binding, and finally log back out. Lather, rinse, repeat per client. Blech! The command-line approach offers numerous advantages, the most obvious being that this can all be scripted and sent to multiple machines via Apple Remote Desktop. No login required, no GUI needed, and you can do every machine at once.

The command-line tools for doing all this are not exactly the most straightforward set of commands I’ve ever seen. But they exist, and they work, and they’re quite flexible once you parse them out. The first basic thing you need to understand is that there are two tools for accomplishing the above: dscl and dsconfigldap. The dsconfigldap command is used to add an LDAP server configuration to Directory Access. The dscl command adds that server to the Authentication and Contacts lists in Directory Access, and is used to configure the options for service access.

So typically, your first step in binding a client to an OD master in Directory Access is to add it to the list of LDAPv3 servers. This can be done via the command-line with dsconfigldap, like so:

sudo dsconfigldap -s -a systemsboy.com -n "systemsboy"

We like to use directory binding in our configuration, and this can be accomplished too:

sudo dsconfigldap -u diradmin -i -s -f -a systemsboy.com -c systemsboy -n "systemsboy"

The above command requires a directory administrator username and interactively requests a password for said user. But if you want to use ARD for all of this, you’ll need to supply the password in the command itself:

sudo dsconfigldap -u diradmin -p 'DirectoryAdmin_Password' -s -f -a systemsboy.com -c systemsboy -n "systemsboy"

Directory Access: Adding an OD Server Configuration
(click image for larger view)

So, there you have it. You’ve now added your OD master to your list of LDAPv3 servers. You can see this reflected immediately in the Directory Access application. But, unlike in DA, the command does not automatically populate the Authentication and Contacts fields. Your client will not authenticate to the OD master until you have added the OD server as an authentication source. To do this you use dscl. You’ll need a custom Search Path for this to work. You may already have one, but if you don’t you can add one first:

dscl -q localhost -create /Search SearchPolicy dsAttrTypeStandard:CSPSearchPath

And now add the OD master to the Authentication search path you just created:

sudo dscl -q localhost -merge /Search CSPSearchPath /LDAPv3/systemsboy.com

Directory Access: Adding an OD Authentication Source
(click image for larger view)

If you want your OD server as a Contacts source as well, run:

sudo dscl -q localhost -merge /Contact CSPSearchPath /LDAPv3/systemsboy.com

Again, this change will be reflected immediately in the DA application. You may now want to restart Directory Services to make sure the changes get picked up, like so:

sudo killall DirectoryService

And that’s really all there is to it. You should now be able to log on as a network user. To test, simply id a know network-only user:

id spaz

/>If you get this error:

id: spaz: no such user

Something’s wrong. Try again.

If all is well, though, you’ll get the user information for that user:

uid=503(spaz) gid=503(spaz) groups=503(spaz)

You should be good to go.

And, if you want to view all this via the command-line as well, here are some commands to get you started.

To list the servers in the configuration:

dscl localhost -list /LDAPv3

To list Authentication sources:

dscl -q localhost -read /Search

To list Contacts sources:

dscl -q localhost -read /Contact

A few things before I wind up. First, some notes on the syntax of these commands. For a full list of options, you should most definitely turn to the man pages for any of these commands. But I wanted to briefly talk about the basic syntax, because to my eye it’s a bit confusing. Let’s pick apart this command, which adds the OD master to the configuration with directory binding and a supplied directory admin username and password:

sudo dsconfigldap -u diradmin -p 'DirectoryAdmin_Password' -s -f -a systemsboy.com -c systemsboy -n "systemsboy"

The command is being run as root (sudo) and is called dsconfigldap. The -u option tells the command that we’ll be supplying the name of the directory admin to be used for binding to the OD master (required for such binding). Next we supply that name, in this case diradmin. The -p option allows you to specify the password for that user, which you do next in single quotes. The -s option will set up secure authentication between server and client, which is the default in DA. The -f option turns on (“forces”) directory binding. The -a option specifies that you are adding the server (as opposed to removing it). The next entry is the name of the OD server (you can use the Fully Qualified Domain Name or the IP address here, but I prefer FQDN). The -c option specifies the computer ID or name to be used for directory binding to the server, and this will add the computer to the server’s Computers list. And finally, the -n option allows you to specify the configuration name in the list of servers in DA.

Now let’s look at this particular use of dscl:

sudo dscl -q localhost -merge /Search CSPSearchPath /LDAPv3/systemsboy.com

Again, dscl is the command and it’s being run as root. The -q option runs the command in quiet mode, with no interactive prompt. (The dscl command can also be run interactively.) The localhost field specifies the client machine to run the command on, in this case, the machine I’m on right now. The -merge flag tells dscl that we want to add this data without affecting any of the other entries in the path. The /Search string specifies the path to the Directory Service datasource to operate on, in this case the “Search” path, and the CSPSearchPath is our custom search path key to which we want to add our OD server, which is named in the last string in the command.

Whew! It’s a lot, I know. But the beauty is that dscl and dsconfigldap are extremely flexible and powerful tools that allow you to manipulate every parameter in the Directory Access application. Wonderful!

Next, to be thorough, I thought I’d provide the commands to reverse all this — to remove the OD master from DA entirely. So, working backwards, to remove the server from the list of Authentication sources, run:

sudo dscl -q localhost -delete /Search CSPSearchPath /LDAPv3/systemsboy.com

To remove it from the from the Contacts source list:

sudo dscl -q localhost -delete /Contact CSPSearchPath /LDAPv3/systemsboy.com

And to remove a directory-bound configuration non-interactively (i.e. supplying the directory admin name and password):

sudo dsconfigldap -u diradmin -p 'DirectoryAdmin_Password' -s -f -r systemsboy.com -c systemsboy -n "systemsboy"

If that’s your only server, you should be back to spec. Just to be safe, restart DirectoryService again:

sudo killall DirectoryService

If you have a bunch of servers in your Directory Access list, you could script a method for removing them all with the above commands, but it’s probably easier to just trash the DirectoryService prefs (in /Library/Preferences) and restart DirectoryService.

Lastly, I’d like to end this article with thanks. Learning all this was kind of tricky for me, and I had a lot of help from a few sources. Faithful readers MatX and Nigel (of mind the expla

natory gap fame) both pointed out the availability of all this command-line goodness. And nigel got me started down the road to understanding it all. Most of the information in this article was also directly gleaned from another site hosted in my home state of Ohio, on a page written by a Jeff McCune. With the exception of a minor tweak here and there (particularly when adding Contacts sources), Jeff’s instructions were my key to truly understanding all this, and I must thank him profusely. He made the learning curve on all this tolerable.

So thanks guys! It’s help like this that makes having this site so damn useful sometimes, and it’s much appreciated.

And now I’m off to go bind some clients command-line style!

UPDATE:
Got to test all this out real-world style today. Our server got hung up again, and we had the same problem I described at the head of this article. No one could log in. So I started trying to use the command-line to reset the machines. I had one major snag that caused it all to fail until I figured out what was going on. Seems I could not bind my machines to the server using the -s flag (secure binding). I had thought that this was the default, and that I was using it before, but now I’m not so sure. In any case, if you’re having trouble binding or unbinding clients to a server, try the dsconfigldap command without the -s flag if you can, like so:

sudo dsconfigldap -u diradmin -p 'DirectoryAdmin_Password' -f -a systemsboy.com -c systemsboy -n "systemsboy"

That’s what worked for me. I’m a little concerned that this is indicative of a problem on my server, but now’s not really the time to go screwing with stuff, so I’ll leave it alone for the time being.

This update brought to you by the little letter -s.

Apple Mighty Mouse: Pretty but Dumb
(click image for larger view)

But this isn’t just a review of the Mighty Mouse. That’s been done to death at this point. What I really wanted to talk about was design over function. And, of course, how all this relates to The lab.

Not long after my first foray into Mighty Mouse usage, we purchased a bunch of Quad G5s for the lab. These machines shipped with the Mighty Mouse. In years past we replaced our Apple mice with three-button mice (yes, those very same Logitechs I mentioned above) because many users — particularly those using Maya — really require three-button functionality. I was actually pretty excited that, with the Mighty Mouse included, this would be the first year in some time I didn’t have to go buy new mice for our Macs. There was some initial confusion among users, as the Mighty Mouse is configured in one-button mode by default. So educating the students about configuring the mouse for three-button functionality was necessary. That turned out to be quite easy, and before long those folks who wanted to be were up and running. But after a month or two I got a request generated by the student body in one of the Student Representative meetings for — yup, you guessed it — new mice. The consensus was that people really hated the Mighty Mouse, preferring, like I do, the cheap but wonderful Logitech alternative.

The Logitech El-Cheapo Premium Optical Mouse: Best. Mouse. Ever.
(click image for larger view)

Let’s look at this Logitech mouse for a minute. The Logitech Premium Optical Mouse lists on MacMall for $12.99 as of this writing (it no longer appears at Logitech’s online store, and is becoming hard to find, sadly). That’s less than 1/4 the price of the Mighty Mouse. But, while the design of the Apple mouse is beautiful, the Logitech’s design is brilliantly functional (and not terribly hideous, actually). The Logitech features big buttons and a big scroll-wheel. The buttons make a both an audible and a physical click when pressed, and the scroll wheel also makes physical clicks when you move it. This feedback, and the size of the controls let you know that you’re actually using the mouse in the way you intend. I’d bet the resistance of the buttons and wheel even reduce the likelihood of repetitive strain injuries, though if not they’re certainly far more psychologically satisfying to me than the practically invisible Mighty Mouse controls. Do they look as nice? No. But they feel great. And how much time do you spend looking at your mouse versus holding it? The other thing I appreciate about the Logitech is that it has a great ergonomic shape. This is something I’m really picky about, and it was the initial thing that sold me on the Logitech. This basic, early-nineties mouse shape — the one with a little hump on the back where your palm rests — is ideal for me. I find it very comfortable. Feedback and comfort: two important things that the Mighty Mouse simply lacks. (Sorry, but a speaker-generated “click” sound just doesn’t cut it for me.)

I think it’s great that Apple finally decided to start making three-button mice. And I think they did so in some truly innovative ways. I can’t even say I really hate the Mighty Mouse. It’s just that there are far better alternatives for a lot less money. And I expect more from Apple. The look of Apple’s mice has long been stunning, if not always very functional. Unfortunately, design over functionality just doesn’t fly for those of us who use computers all day long. A mouse needs to feel good more than it needs to look good. It is, after all, a device for the hand. And while it may just be my opinion that the Mighty Mouse is bested by the cheapest Logitech mouse on the market, a whole department of staff, faculty and students agrees with me. Not at all scientific, but that’s pretty damning evidence, if you ask me.

Apple is king when it comes to combining function and aesthetics. You see it in the iPod. You see it in their computers. You see it in their software. Their monitors are heaven to look at. Their products usually work the best and look the best, in my experience. But they always seem to blow it when it comes to mice, and unfortunately, the Mighty Mouse is no exception. While Apple made the right move supplying its users with a true three-button mouse solution, I’m afraid they blew it on the implementation. Here’s hoping they keep at it, though. I’d love for Apple to produce a mouse I can love.

Autodesk Combustion Splash Screen
(click image for larger view)

Other software manufacturers, however, are not so trusting and approach software license management via far more convoluted and Byzantine methods. Autodesk is among these companies. To install Combustion, not only do I have to provide a serial number, I also need to provide an authorization number. This authorization number can be obtained by registering each and every copy of Combustion I intend to use. The process of installing just one copy of Combustion goes something like this:

1. Install the software from disk.
2. Launch the application and type in the serial number for this copy.
3. Activate the “Licensing Wizard.”

Autodesk Registration Splash Screen: Here We Go…
(click image for larger view)

4. Upon magical transportation to the Autodesk registration page, register the software by entering every personal or professional detail they can think to ask you about, including the serial number of said copy of said software.
5. Check your email, where you should shortly receive the authorization number for your copy of Combustion.
6. Enter this Authorization Code into the special box.
7. You should finally be able to use Combustion.
8. Lather, rinse, repeat for every copy you bought.

Autodesk Registration Panel: Are We Having Fun Yet?
(click image for larger view)

Whew!

Okay, there are a couple of big problems with this scenario. First off, if there’s any problem along this insane route, you can get quite stuck. In my case, the registration site did not work. The error page directed me to file a Customer Service Request, but the link to said request was also broken. This means that I will have to register my software either by fax, mail or possibly telephone. It also means I will have to do this myself for each and every copy of Combustion I’ve purchased. I have five copies. Thank god I don’t have more, because it’s going to take me a while to install this software. And this is the other problem with this sort of arcane licensing scheme: It doesn’t scale. Imagine if I had a hundred machines I wanted to install Combustion on. It’s practically infeasible at worst, unbelievably annoying at best. And I have to say, all it makes me want to do is buy any product other than Combustion, just to avoid the install hassles.

Autodesk Online Registration: Broken!
(click image for larger view)

There are a number of software companies besides Autodesk that use these sorts of tactics: Cycling ’74 and Digidesign spring immediately to mind as some of the most heinous offenders, but there are others. They seem to think that the best way to protect their intellectual property is to make their products difficult to install and maintain. The companies that do it right are ones like Apple, Adobe and, shockingly, Microsoft. These companies have volume license schemes and educational versions of their products that are relatively easy for institutions to install and maintain. They recognize the value of getting their software in the hands and minds of young users, and they make it as easy to do so as possible. And I think they recognize the value of happy SysAdmins, too. They know we’re the ones who make the recommendations for future purchases, and that maybe — just maybe — it might be a good idea to not make our lives a total living hell.

So, to Autodesk and others like you, here’s a little secret: Systems Administrators hate you. We hate your fucking guts. Because, for us, installing your software is ten kinds of torture. There’s no reason for you to do this except for a clear contempt on your part towards the SysAdmin community, and most likely your users in general. Or just general stupidity. You’re not stopping anyone from stealing your software, and frankly you’re keeping those of us who plan to use it legitimately from even wanting to do so. In fact, I’d argue that stealing your software is far easier than installing it legitimately. So all you’re really doing is punishing your legitimate users. It’s so stupid, and I’m so sick of it, and I’m sure I’m not alone. But more than that, it’s just bad business. The next time someone asks me to recommend a piece of compositing software, I’ll think of all the hassle I had to go through to install Combustion.

And then I’ll recommend AfterEffects.

UPDATE:
In the comments some astute readers have provided a link to a whole site that deals with application installers and requirements that present problems from the standpoint of educational lab administration. The site is more concerned with apps that require user-level authorization files or user-level access to parts of the filesystem that should be protected, while my article deals more with plain-old annoying installers and licensing schemes. Still, it’s a great site, and a good compliment to this post, and I wanted to link to it directly:
Poorly-Made Applications

Amazingly, some of these practices are holdovers from the OS 9 days, when security and multiple users weren’t really issues to Apple or developers (or Lab Admins). It’s shocking to me that after all this time a lot of software developers still can’t figure out how to properly, securely, or even conveniently install apps in Mac OS X.

Thanks to those who sent in the link.