The Adventures of Systems Boy!

I've been hopeful in the past about Adobe installers, and there have been improvements. But Adobe's update process still leaves a bitter taste in my mouth every time I try to use it, which is with less and less frequency, largely because of said bitter taste.


Even more frustrating is the fact that Adobe's updaters continue to annoy even after being expressly told not to. To wit, this dialog popped up out of nowhere recently, despite its preferences being set otherwise.


I contend that Adobe's automated update process is just plain broken. It's actually much easier to use their support site than their updater. That's what I do when I need to run Adobe updates. And I keep the updater turned off.

Or at least I try to.

Labels: Applications, Rants

I've been using Time Machine for a while now. And I've noticed some interesting things about its behavior. Of particular note, I've noticed that Time Machine does not back up your data when you are logged out. I found this strange until I figured out why this is the case.

I first noticed Time Machine not backing up logged-out users after setting up the staff computers here at work. Oddly, my work computer did back up when I was logged out, which I realized when I noticed a backup failure due lack of drive space. According to the Console logs this backup attempt had occurred in the middle of the night. Clearly Time Machine was able to backup when users were logged out, but it would only do so on my machine. So what was the difference?

By default, Mac OS X wisely un-mounts external volumes when a user logs out. This makes sense for a number of reasons, not the least of which is the fact that it's what users expect, and it's the least likely to break something if a user logs out and pulls their firewire plug without ejecting their disk. It's a very sane default that errs on the side of data protection. But it's not always what you want. For instance, say you have network shares, like external RAID drives, that are connected via firewire (which, in fact, we do). Or say your network backups that run in the middle of night get stored on a firewire volume (which ours do). If you want these drives constantly available you need to be able to keep them mounted even when no user is logged in. Fortunately, Apple provides a method for doing this, though it's by no means obvious.

The trick to keeping external drives mounted after a logout lies in a little .plist file. The name of this file is autodiskmount.plist, and it does not exist by default; you have to make it. In the file should be the following text:



Put this file in:
/Library/Preferences/SystemConfiguration/

And reboot. (Yes, reboot.)

Now all external drives (firewire, USB, eSATA, etc.) will stay mounted after a logout. If they're shared, they'll always be available. And they'll always be available to Time Machine.

So the difference between the staff machines and mine? My computer is set to never unmount drives at logout. Apparently, Time Machine is perfectly capable of running even when no one is logged in. But it obviously needs the Time Machine drive available to do so. Keeping firewire drives mounted post-logout will allow Time Machine to work all night long. Sweet!

And since I'm so crazy with the Installer Packages these days, I'm including one here that will install the necessary preference file to make all this happen. You know, just to make your lives a little easier.

Download KeepExternalDisksMounted

You're welcome!

UPDATE 1: A reader asked in the comments how I came to have the preference file installed on my system. I'd put it there long ago because I needed firewire drives mounted for rsync backups of staff machines. But I certainly didn't figure out how to create that file myself. Credit for that goes to this Mac OS X Hints hint. It's got all the details if you're interested.

UPDATE 2: One other thing I forgot to mention: Why is this useful? I mean, if you're logged out you're not really capable of creating any new data, so there's nothing really new to backup anyway, right? This is mostly true, indeed. But imagine your boss uses Time Machine for his hourly backups. Now imagine he creates a whole buttload of data — I don't know, emails to the CEO, photos of his kids, whatever — and he creates this data right before he leaves for the day. Then, safe in the knowledge that Time Machine's got his back, he logs out and goes home for the weekend. That weekend there's a power surge or something, and his machine is fried. "No problem," he thinks, "I have my backup." But his most recent data is gone. His photos, his draft to the CEO, gone. And guess who's to blame? Yup. The Systems Admin. Your ass is grass, and Time Machine is the lawn mower. (Uh, this is why I don't write in the mornings.)

Personally, I think it would be smart if Time Machine asked you at logout if you'd like to make a backup, or at least warned you that backups would not be performed after logout. This seems like a bit of an oversight on Apple's part.

The other time this can be useful is when you're creating your first backup. This is typically a lot of data. Here in the office we told folks to let it run overnight. But they couldn't log out. So we dropped them to the Login Window with Fast User Switching. Still, it would have been that much more intuitive if we'd just told them to log out like they always do, and that their backups would be ready in the morning.

So yeah, not earth-shattering, but still potentially useful. And interesting on an academic level to know that Time Machine will run sans login.

I have to go install that preference file on my staff machines now. Bye!

Labels: Applications, Hardware, Lab, Leopard, MacOSX

The fact that John Gruber is trying and writing about the latest Firefox betas — which, by the way, I am frickin' loving — is a testament to how good this release will be. Though he's not switching for a variety of reasons, his review is still quite complimentary.

Most of Gruber's Firefox complaints either don't bother me or don't affect me, but there is one that has always bugged the crap out of me: a single-click in the URL field of the browser highlights the entire URL. This is almost never what I want to do. If I want to highlight the entire URL, I'll just hit Command-L and be done with it. If I'm clicking in the URL field it's because I mean to edit that thing, and I want my click to place the cursor right where I clicked, damnit. Despite Firefox 3's attempt — and, I should mention, general success — to integrate better with your platform of choice, it gets it wrong here.

Fortunately, Gruber's posted a link to a dude who has the skinny on the fix. Here it is in my own words, if you don't feel like following the links:

• Type "about:config" in the URL field
• Filter by "clickSelectsAll"
• Change the "browser.urlbar.clickSelectsAll" to "true" (just double-click it)

From now on clicking in the URL bar in Firefox will behave as it does in Safari: single-click places the cursor; double-click highlights the word; triple-click highlights the whole URL.

Oh, sweet merciful heaven, that's good stuff.

Labels: Applications, Interface

I've become quite the package whiz, if I do say so myself. Actually, I'm probably doing something ass-backwards, but still, I wanted to share some of my working methods as they seem to be, well... Um... Working...

One of the things I'm doing is using packages to run shell scripts that make computer settings (like network settings and user-creation) rather than actually installing files.



This can be done in PackageMaker by taking some creative liberties with preflight and/or postflight scripts. The only hitch is that PackageMaker insists that you install at least some files onto the target system.



So the majority of my packages contain only a single script. That script first gets installed to /tmp, thus fulfilling PackageMaker's "must install files" directive.



The script then runs as a posflight script, and the last line of the script deletes the instance of the script in /tmp, just for good measure.


It could be argued that there's no reason to create packages from scripts, that you could just as easily run the scripts directly in ASR, but packages offer a couple of advantages. For one, packages leave receipts, so it's easy to check and see if something's been set on a computer. For two, packages are easy to deal with; assistants and other SysAdmins know how they work and can easily understand how to use them. Need to change a machine's settings? Don't run a script. Hell, don't even bother opening System Preferences. Just open and run a package. What could be easier (and less error-prone, I might add)? From an ease-of-use perspective, packages have a huge advantage. And ease-of-use adds efficiency. Which is why I not-so-suddenly find myself in the envious position of being able to build systems in about half the time (or less!) it used to take. That's a huge improvement!

Using this method (and sound DNS) I've been able to write packages that configure network settings, create computer-specific users, set custom disk and file permissions, set up autofs, bind to our authentication server and set up SSH for password-less login.

Next on the list: File Sharing!

Should be fun.

Labels: Applications, Lab, Leopard, MacOSX, NetBoot, Server

I did it. Yes, I finally did it: I went and pissed off Time Machine.

I've been using the Staff Backup drive for my Time Machine backups, see. And that drive needs a certain amount of free space for any large chunks of data that staff might create during any given day. So when Time Machine finally ate up all the disk space on the drive, I decided to see what would happen if I cleared some space up by hand, the old fashioned way. And so I deleted the first month's worth of data from my Time Machine backupdb folder.

Now, I'm not totally stupid, and I have at least a good enough understanding of how Time Machine works to know that this would cause problems, but I was curious, and I wanted to see what those problems would be and how they would manifest themselves.

The first thing I got was a generic Time Machine failure:



Clicking the red info button revealed surprising details, considering my drive showed 200GB free:



So I decided to run a backup and see what happened. The backup appeared to start smoothly, but eventually I wound up getting this message:



Hmmm... I think I broke it.

It makes sense, really. I mean, it stands to reason that, in Time Machine, the first and oldest backup actually contains the most actual data. It's the base for all the other data. Subsequent backups only copy changes, but the first backup is kind of the Mother of All Backups, if you will. Deleting that first backup will, unsurprisingly, wreak all sort of havoc on your backups.

Havoc that is, as far as I can tell, irreversible. The only way I've found to fix this is to start the backups fresh. That is, turn off Time Machine, delete the old backups (or at least move the old backupdb folder out of the way), and then set Time Machine up again.

Bummer.

Oh well.

UPDATE:
Ahhh! That's more like it.

Labels: Applications, Leopard, Systems

Just wanted to quickly post that the complaint I had about Mobile Safari's browser cache being pointless appears to have been a bug.




And, happily, that bug has been fixed in the 1.1.4 update.

Yay!

Labels: Applications, Hardware, Internet, iPhone

I recently wrote some criticism of a couple very promising new applications: ScreenFlow and Opacity. Both these apps came out at roughly the same time, and each was of particular interest to me. Each also had some pretty glaring bugs.

One of the great things about being a member of the Mac Community is that it actually is a community. Loosely, It's a group of people with similar interests and ideas about the computing experience. And Mac software developers — perhaps more than anyone — feel keenly this bond. At least the good ones do.

So, in true Mac Community fashion, shortly after my initial reviews (like, the next day) I got comments from the developers of ScreenFlow and Opacity. And those comments basically said, "Hey, I addressed the bugs you mentioned, and have released an update to my software. Check it out!"

I have checked it out. And it is good.

Unfortunately, I don't have time to do a complete review of these products. And I'm sure that someone more qualified will beat me to it in any case. But I did want to mention a few things about each.

ScreenFlow
ScreenFlow is a revolutionary approach to screen capturing and screen-based presentation. It is a complete environment for creating computer-screen-based presentations, in fact, letting you capture both your computer screen, its audio, and the video and audio from an external camera all at the same time. ScreenFlow then drops you into a very elegant editing mode that allows you to do all sorts of tricks specifically designed for screencasts (the Callout Actions are particularly nice).

I had a few problems with the 1.0 version, but I'm happy to report that the latest update, v. 1.0.1, fixes them all. I've been playing around with it a lot, and I can't say I've really had any problems at all, at least on my home machine. My work machine sports a 30" monitor, however, and ScreenFlow has problems with its native resolutions. The good news is, it says so:



The bad news is that this alert comes up after you've captured your too-big screen. Still, it's absolutely crucial information, and this alert is better than the nothing we had in version 1.0. I'll take it.

Otherwise, ScreenFlow has been a complete joy to use, and I do anticipate buying it for our lab at some point, probably in the summer. I've even showed it to my boss, who was duly impressed.

If you're looking for such a beast, ScreenFlow makes all the others I've tried pale in comparison.

Opacity
Opacity is a graphics app dedicated to creating, editing and outputting screen graphics — for the web, applications or desktop icons. As an occasional icon creator I can tell you, something like this has been a long time coming. In the past I've used a combination of Illustrator, Photoshop and the IconBuilder plug-in for Photoshop to create icons. Opacity costs only slightly more than IconBuilder, and it doesn't require Photoshop. In fact, it doesn't require anything. It, like ScreenFlow, is a dedicated environment for doing one thing. Unified, task-based apps like this are all the rage right now, and I for one think it's great.


Opacity is more personally interesting to me than it is something we'd need for the lab. It's also something I need more time to explore. ScreenFlow is almost instantly intelligible. But Opacity will require a bit more investigation on my part before I decide whether or not I need it. Since many of my icons are hand drawn with a Wacom, I'll need to investigate the level to which this will be possible in Opacity.

But there are two things I want to point out about Opacity. One, I like the idea of it very much, and I think it's actually fairly novel on the Mac. I'm sure professional icon designers are loving that this exists and that it might actually turn out to be good. Two, it seems to be a very well-though out application. I think icon design is actually a much more complex task than screencast recording. But Opacity strikes a really good balance between the complexity of the task and a clean, elegant UI. It might not be right for me in the end, but if you design computer graphics of any kind, you should certainly take Opacity for a spin.

Oh, and one other thing about Opacity I'd like to mention: Its latest version (1.0.1) resolves every issue I mentioned in my initial article.

So, my thanks to the creators of these fine applications. Not only have they made what look like a couple of really neat apps, but they've handled initial criticism with the aplomb worthy of a Mac Developer.

Great work, guys!

UPDATE:
Testing of Opacity continues, and not without issue. The program is a good deal more solid than it was in version 1.0, but, for the record, attempting to import very large Illustrator documents causes the "Out of memory" alert to rear its ugly head once again. This alert will cause the application to quit. And, unfortunately, the default behavior of Opacity is to open the previous document on launch. If that document happens to be a large Illustrator file that causes the alert and subsequent quit of the program, you will be unable to successfully launch Opacity without moving the offending file. Bummer.

Also of note, Opacity is not currently pressure-sensitive when used with a Wacom tablet, which may be a bit of a problem for some — myself included — though perhaps not a deal-breaker. I'm certainly not averse to creating line-art in pressure-sensitive programs (like Illustrator) and importing them into an app like Opacity if it beats my previous workflow. But obviously this won't work if the Illustrator file essentially kills Opacity.

In any case, like I said, this is all for the record. I still feel Opacity has great potential. That's why I'm testing it so rigorously.

Labels: Applications, Art, Interface, Video

It's 1.0 release week, here at TASB, apparently. It also appears to be crash week.

Another useful-looking app has caught my attention: Opacity. It's a graphics editor designed especially for doing one of my favorite things: icon creation.

Opacity, like ScreenFlow, looks like a really nice application built for doing one specific thing. Which makes it really good at doing that specific thing. And Opacity appears as though it will, someday, be quite good at icon creation. In fact, it looks to be the best icon-specific graphics editor I've seen thus far. But — and this seems to be a theme here lately — it crashes constantly.



I mean, like, unusably. Like during the tutorial. Not good. The saving grace here is that it at least autosaves a copy of your document. But when an icon editor, working on a single-layer, 512x512 pixel vector image, tells you it's out of memory (I have 5 GBs of RAM for crap's sake) when you're trying to save your file, you know there are some serious problems with the app. Am I right people? Seriously, who's with me here?



'Nuff said, I think.

Opacity looks like it might be a really good application for icon creation — maybe the way to go. It's got some great tools for preview and output, and the price is right — it's about ten bucks more than Icon Builder, but is completely self-contained and doesn't require Photoshop. But it's far too unreliable for serious use at this point.

It's too bad that developers are releasing such buggy stuff. It leaves a really bad first impression, and makes me not want to rush out and purchase the product, no matter how hot it might look. I hope I get over that first impression before something else better comes along, or simply steals my attention.

In the meantime, as with ScreenFlow, I'll try to remember to check back for Opacity's 1.0.1 release.

Labels: Applications, Art

Holy poo! ScreenFlow is one of the nicest, most polished, yet useful applications I've seen a really long time.

On the surface, Vara Software's ScreenFlow appears to be just another in a series of applications designed to capture your computer screen to a Quicktime movie as you work. Typically such captures are then used for demonstration purposes for new products, or workflows, or videocasts, or what-have-you. But ScreenFlow is much more than just another screen capturing app. ScreenFlow is really an entire environment for creating and finishing computer demonstration videos.

And it's gorgeous!

The most obvious thing that sets ScreenFlow apart from its competitors is the fact that, along with the computer screen, it can capture iSight (or DV camera) video and audio at the same time. By default it sticks this video in a reduced-size window in the lower right hand corner, though, as you'll discover, this can easily be changed. That's because ScreenFlow, in addition to being a screen capturing application is also a presentation editor.



Once you've captured your computer screen actions and your iSight video, ScreenFlow presents you with an editing interface. Here you can perform all sorts of actions, including zooms, pans and something called "Callout Actions," which allow you to highlight specific windows as well as the mouse cursor. Vara has a nice demo of this feature (in a video, of course, which by the way, is where I pulled these screen shots from) on their site. But the application is so smart and well thought out, that if you've ever used a screencast app, you'll find the learning curve incredibly gentle.


I do want to point out that this is a 1.0 release, and I have experienced numerous bugs. On my work computer (a Quad Intel box with copious amounts of RAM), the application completely crashes my machine. Force quit will not rectify the crash; a hard reboot is required. On my home system (an 8-core Intel with 2 GBs of RAM) ScreenFlow functions well enough, but there are still problems. The iSight registers video and audio in the setup screen, but no audio gets captured for some reason. Also, when exporting my final product to DV-NTSC, I was presented with a set of options, one of which was "Letterbox Content." Though I checked it, ScreenFlow did not honor the "Letterbox Content" option, and my movie came out squished. In fact, I exported the same movie without the box checked and there was no difference between the two movies. Clearly this function is broken. Clearly, ScreenFlow has some kinks to work out.

Still, once the problems are solved — and I sincerely hope that happens soon — ScreenFlow is poised to be the application of choice for regular producers of screen-based videos. And beyond. I admit, I don't do a lot of screen-based capturing, but I'm starting to wonder if the reason is because there haven't been any great apps out there for doing it. ScreenFlow is one of those apps that gives you ideas. It instantly makes you want to use it and then you start thinking of ways to do so. Being in education, this has been pretty easy for me to do. Something tells me I'll be buying and using ScreenFlow in the very near future.

UPDATE:
Version 1.0.1 has just been released, and it seems to fix at least some of the problems mentioned above, in particular the iSight audio problem. Expect a re-review sometime in the near future.

Labels: Applications, Video

If you've been using Software Update (like I have, up 'til the other day), you've probably missed one of the new features of Leopard: Installer Certificates. Major updates from Apple now come with certificates of authenticity.

So, for instance, download the standalone Mac OS X 10.5.2 installer and launch the package in the Installer application, and you'll notice a small, new certificate badge in the upper right hand corner of the installer window.



Click the badge and you can take a look at the certificate that's attached to the installer, replete with details about said certificate under the "Details" disclosure triangle.



It's another preemptive step in the right direction, security-wise. Always nice to see.

Labels: Applications, Leopard, MacOSX

I love my iPhone. It is increasingly important to me for getting things done. I use it for everything: appointments, reminders, fact-checking, contacts, text, entertainment and, of course, as a telephone. It's boosted my productivity immensely, yet made my life easier and better in so many ways. I'm not sure how many products I can say that about.

Nevertheless, I have one persistent gripe when it comes to the iPhone, one thing that just pisses me off and confounds me every time I encounter it: Mobile Safari's cache is simply too small, to the point where it almost seems pointless to have cache at all. Case in point: I open a web page. It gets cached. I open a new window, and a new page in that new window. It too gets cached. Unfortunately, this new cache invariably wipes out the previously cached page, so that when I navigate back to the other window, the first page has to reload. And, just for the record, these are mostly text-based blogs, sometimes with a picture or two. It doesn't always go down this way, but more often than not it does. This defeats the usefulness of both cache and the multi-page interface available in the browser. I'm not sure what the point is.

I'm sure the browser cache equation rides a fine line between usefulness and unnecessary disc overuse. But for anyone who uses the Edge network on any kind of regular basis, I think they've got that balance wrong. And I can't help wondering why they don't give us a setting — just like in any other desktop browser — for cache size, within a sensible range, of course. Or, if not that, simply make the default a bit larger. The current one is pointlessly small.

UPDATE:
Fixed!

Labels: Applications, Hardware, Internet, iPhone

I'm not sure why, but the concept of the WYSIWYG HTML editor has really taken a beating. The most recent comment I've heard comes from Shawn Blanc's review of MarsEdit, an offline blog editing product. Shawn says that:

"In all my experience with WYSIWYG editors I have found them a clumsy enemy of fine web typography."

This, apparently, is the major rationale for what seems to be the prevailing notion in the web development community that WYSIWYG HTML editors are an inherently bad idea. The logic seems to go something like: every time I edit my web page in a WYSIWYG editor, the experience is a bad one, therefore the concept of WYSIWYG HTML editors is flawed from the get-go; real designers only ever edit raw HTML. (Though I might point out that I have yet to see or read of a single example of a WYSIWYG editor creating terrible HTML code in a very long time, at least when it comes to fairly simple HTML pages, which most blog pages are. But I'm getting ahead of myself.)

Comments like the following also make it sound like if I'm not editing raw text, I'm just a big pansy-ass wuss:

"I suspect most of you are at least a bit HTML savvy and prefer the use of monospace type and a HTML editor anyway. But for those who are getting weak in the knees at the thought of having to type your own HTML relax."

Now, I'm not a web developer by any stretch of the imagination, but my experience with WYSIWYG editors — even web-based ones — has been largely positive. And, though I'm fairly comfortable looking at HTML code (and actually enjoy looking at other types of code), I never, ever want to edit it if I can at all avoid it. It's a completely unnecessary distraction from what I'm here to do: write. I'd much rather work on something that more closely resembles the finished product and not have it cluttered up with code. It's not that I'm scared of the code, it's that I'm annoyed by it.

For my personal web pages I have always used Dreamweaver. And while the user experience offered by that app is not always the most intuitive or Mac-like, it's always far preferable to me than using a text editor. For my blog pages — which are all formatted exactly the same way as per the Blogger style sheets I've set up — I use the Blogger-supplied online WYSIWYG editor. As much as I like the idea of working on my blog offline, I do not use MarsEdit or any other such client. And the reason is because of their lack of WYSIWYG.


John Gruber also supports the use of MarsEdit and its ilk:

"My best argument for using MarsEdit (or any desktop weblog editor) instead of a web-based interface is that it’s like using a desktop email client instead of webmail."

That's a great argument, except that it's a bit flawed: A desktop email client adds features and ease-of-use to the email experience. MarsEdit, on the other hand, removes a major feature that, for me anyway, greatly hinders ease-of use. It's far less aggravating to me to use a web-based WYSIWYG editor than it is to use a desktop-based code editor. To follow Gruber's analogy, using MarsEdit is like using a desktop mail client that only shows you the code in which your email is written. MarsEdit hinders ease-of-use by making me look at code when I really don't need to. All I need are some very simple markup commands and basic text editing. I really can't see any reason not to use WYSIWYG, particularly when it comes to editing blogs.

But this is not to completely disparage MarsEdit. That's not my intention at all. It sounds like a great product, really, and MarsEdit's author, Daniel Jalkut even acknowledges the need for WYSIWYG in his product and is planning it for a future release. Awesome. I may even buy and use MarsEdit when that day comes.

My point is that the WYSIWYG HTML editor is a great idea that someone needs to get on and do right. I believe its time has come. Over the past few years I've watched a series of HTML editors hit the market. The latest are either completely template-based — like Apple's iWeb, which lacks any ability to examine the code when it's necessary to do so, which is a big problem — or completely code-based — like, well, all the others. In between is a gaping chasm. The giant WYSIWYG hole. CSS editors, too, seem to be plagued by this lack of WYSIWYG. So I always find myself using Dreamweaver in the end, for lack of a better replacement. I suspect I'm not alone.

Again, I can't help wondering if there's a faulty rationale at work here. Do software authors think that, because their WYSIWYG editor experiences have been bad ones, the basic idea is also bad? Or entirely too difficult to build? Or unprofitable? Because I think that, in the same way that beautiful, affordable image editors are springing up to challenge Adobe's dominance with Photoshop, WYSIWYG HTML editors could have great appeal. I've been marginally on the lookout for one for years, and I write web pages only occasionally. And the best I've found, frankly, is Dreamweaver, which is good but not great, and very expensive.

Or is it possible that it's just machismo? (God, I hope not. Is there anything worse than macho geeks?) It is possible that developers think that WYSIWYG just isn't cool? That real web developers would scoff at such a product? Seriously, why is it that Coda, an absolutely beautiful app that does, like, everything under the sun, lacks the basic WYSIWYG found in all web-based editors? (Yes, I would totally buy Coda if it had WYSIWYG. Without a doubt.)

Guys, all I can say is, you're missing a big opportunity here.

Labels: Applications, Interface, Internet, TheBlog

I recently wondered aloud about the benefits of MacFUSE-supplied ssh access in a web development environment. A reader asked for a follow-up in the comments to that post, so I thought I'd just do a quickie today.

After writing the article, I tried out MacFUSE and the sshfs extension to that bundle. This combo facilitates the mounting of ssh-enabled computers directly on the Mac OS Desktop via a bundled GUI app, foregoing the need for an FTP client application. It was our hope that this would provide a more intuitive and user-friendly experience for our web developers. Unfortunately, in my experience there were bugs: the ssh filesystems often hung or had trouble mounting, often requiring a logout or restart to get things back to normal. (Mind you, this was over a month ago, in Mac OS X 10.4.something-or-other and God-knows-what version of MacFUSE and sshfs.) Also, from a user-simplification standpoint I felt that adding yet another application to the mix (the sshfs GUI app for mounting shares) didn't really do all that much to simplify things. In fact, in some ways, it complicated matters as it is not standard practice anywhere as yet.

That said, I really like the idea of mounting any sort of network share in the Finder. It's what's done in every aspect of our filesharing lives except web development, for some reason (that reason mainly being that Apple, inexplicably, still has not implemented this capability into the Finder.) As I mentioned in the original article, there are styles of development that take place outside the lab that are inherently different from what can happen inside a lab. The use of MAMP, for instance, is not friendly to a shared, multi-user environment, but is perfectly suited to a lone user on a single computer. So, again, I wonder aloud, do we provide a different way of working inside the lab than outside? A completely different workflow?

Ultimately, my answer will mostly be yes, I think. We provide it. We provide it right alongside the sorts of workflows that are common in the industry today. We provide both. We show students. We show teachers. And hopefully, someday, down the line, this will become the standard way of developing for the web. Until then we leave the old ways in place; they are not mutually exclusive.

My concern with MacFUSE and sshfs right now is stability. Because the product requires kernel extensions, and because I saw bugs in my limited testing, I am reluctant to put this on our machines. I can, however, use NFS from within our lab to provide a testing ground for the same sort of behavior that MacFUSE provides (i.e. ssh servers on the Desktop). And this will actually fit in nicely with the way we mount other shares in the lab as well (more nicely than the sshfs GUI, in particular). I will most likely implement this over the summer, however, as there's not enough time in the semester for it to really have much impact. Also, things will probably change a bit with the arrival of Leopard to the lab, and I don't see much point in making folks learn it twice.

Again, external development can be handled differently. So I may recommend, for advanced users, the use of MacFUSE outside the lab if they really end up digging the Desktop web development experience.

That's my take at this point on MacFUSE and web development. Hope it's useful to someone.

Labels: Applications, Internet, Lab, Server

I recently had a problem with iCal syncing to my iPhone: Calendars would sync fine from the Mac to the iPhone, but any event entered on the phone would not sync to the Mac. Moreover, calendars deleted from iCal on the Mac — calendars that no longer existed — would still be available for syncing in iTunes. Clearly there was a problem with cached data of some sort, somewhere. But where?

After a lot of trial and error, and hunting around — I tried resetting iTunes preferences, iCal preferences, and anything else that might present an easy fix — I finally figured out where all this data gets mashed up. There are two folders in your home account that are responsible for syncing the databases between your iPhone and your Mac. The first one, as far as I can tell, just contains a backup of your iPhone data. It is:
~/Library/Application Support/MobileSync

The second is where all the syncing action happens:
~/Library/Application Support/SyncServices

To fix my problem, I renamed these two folders. They'll get recreated the next time you sync your iPhone and you can keep these in case anything goes wrong. Then start up iTunes and reset all the items under the Info tab for your iPhone. (Fortunately, items under the other tabs seem to have been left alone, at least in my case. YMMV.) I still couldn't see my calendars in iTunes at this point, but I went ahead and just hit the Sync button. And it worked.

Everything now appears properly in iTunes. New calendars show up; deleted ones disappear. And syncing calendars between my iPhone and my Mac works perfectly now.

UPDATE:
Reader Ferdinand points out that Apple strongly discourages the removal of the SyncServices folder. Instead they recommend resetting your SyncServices with the instructions in this article for Mac OS X 10.5 or this one for 10.4. I'm quite happy I didn't have any problems, but if you need to mess with your sync services, I strongly recommend following Apple's advice over my own.

Labels: Applications, iPhone

So I really like Leopard. It's nifty, but not without it's problems. I thought I'd take a minute to post some of the issues I've had with the new OS.

So far I've only had a few complaints. Actually, my initial experiences were quite positive. I did an Archive and Install, preserving user and network settings, on my work machine, a Quad-Core Intel Xeon tower. I left all my old preferences in place and used my old home account data. All this went off almost completely without a hitch. The only snag, oddly, was my Final Cut Pro Studio suite, which needed to be re-serialized. Beyond that, smooth sailing.

Upgrade Woes
That upgrade went so well I decided to do the same to my aging PowerMac 2.7 GHz G5, and for the first time since I bought it that machine felt slow. Dog slow. Problematically slow. This was cause for concern. But what finally convinced me that there were major problems was what Leopard did to my iPhone. Oh, the horror!

Addresses
On the first iPhone sync with Leopard, all my addresses got completely borked. Each address was there, yet the name field was blank and there was a lot of information that didn't make the transfer. Fortunately I had a backup, and I was able to get back up and running. Oddly, the second sync worked perfectly, and only the latest contact info on my phone was lost.

Photos
Importing photos from the iPhone to iPhoto was also problematic on the upgraded Mac. The import took an extremely long time, and the imported photos suffered from strange color shifts and banding. They were unusable.

At this point I decided to do a fresh install. This worked much better, and my computer has been running much faster and handling iPhone syncs much more reliably. As part of the fresh install process, I also started with a fresh home account, which may have helped as well. But this was not the only source of problems, as I verified their existence on a clean account as well. Still, better safe than sorry, I figure.

In any case, for whatever reason, older hardware seems to like a fresh install. Things have been working reliably now for a few weeks. I'm happy.

AFP and MPD
My other beef with Leopard has to do with AFP mounts in the Finder. The way the Mac OS has always dealt with such mounts in the past is that when you mount a shared drive, you authenticate as a user with access to the resource and the drive mounts as though the authenticated user had mounted it, even if that user is different that the one who's logged in. So, for example, I could be logged in as SystemsBoy, but authenticate to a server as JimminyCricket. The server will show me the available shares for JimminyCricket, not SystemsBoy, even if they have different access privileges to that server. If I unmount the share, I can then reconnect to the server, this time authenticating as SystemsBoy, and then I see the shares available to SystemsBoy. This is actually more useful than it sounds. I have numerous identities that I use on my network. This allows me, for instance, to be logged into a machine as a non-admin user, but still connect to a server as an admin user and have admin access to those resources.

In my initial experiences with Leopard, however, the behavior had changed in a way that was potentially sucky. In Leopard, when I'd connect to a share I'd authenticate as a user, just as in the past. And the share treated me like the authenticated user, just as in the past. But once authentication had taken place, Leopard remembered the user credentials even after ejecting the mount. At this point, when attempting to re-log in as a different user, the Finder would refuse to forget the previous login identity and authentication would be bypassed. The server would simply remount as the originally logged in user.

This behavior could be a convenience for users who only use a single identity on client and server. But for those of us with MPD (that's Multiple Personality Disorder, smart guy) it's a real problem. We'd now find ourselves unable change our login identity on a server without a reboot, or until some period of time has expired. Crap!

Now, I have to say, this was happening to me without fail a few weeks ago, and it was really annoying. But now, for some odd reason, the behavior seems to have reverted back to it's old self, asking for authentication each time I request a server. It's really quite strange. I know this was a problem, because I noted it in my log of Leopard issues, but I'll be damned if I can reproduce it today. I suppose it's something to watch out for, but I'm glad to see that it seems to have cured itself. In any case, clearly there are bugs in Leopard, however inconsistent and occasional they might be.

~/Library
Leopard is a bit of a hard ass when it comes to your Library folder. The Library folder is where all the user's settings are stored, and Leopard takes steps to insure that it's always there. In fact, it disallows you from renaming or moving the folder. Try to rename it and it simply won't highlight; try to move it and you can only copy. This is both a blessing and a curse, I suppose. I mean, from an admin standpoint, I never really have to worry again about users removing their ~/Library folders. But then again, I never really did anyway. Conversely, it requires a trip to the Terminal to move a user's Library folder and test any problems therein, which is a fairly common troubleshooting step. I guess we break even here, but I think I preferred the old way of doing things. It just made my life easier.

Uh... So far that's it. Compared to my Tiger Beefs from a couple years back, that's nothin'. Hell, compared to any new software release that's frickin' amazing.

I'll say it again: Leopard is a pretty damn sweet release.

UPDATE:
I continue to have AFP problems on my Intel machine. They're different from those detailed above, but no less annoying. Earlier, I attempted to connect to a server and the process hung. I had to force quit the Finder to get out of it. And just a few minutes ago I connected to a server and copied a group of files over to my local system using a "command-c" copy, only to be denied for permissions reasons. Dragging and dropping the same batch of folders worked properly. And now, after ejecting and reconnecting to the same share, both styles of copying the same, exact folder work just fine. So clearly there are some AFP bugs that need to be worked out in Leopard. Nothing life-threatening, but surely annoying.

Labels: Applications, iPhone, Leopard, MacOSX

It seems I only have time for these brief posts. Tons in the pipe; time for none. Life must be... I dunno... Good or somethin'...

Anyway, I just updated my iPhone to the latest 1.1.3 firmware. You know, the one with all the goodies. It's pretty damn hot, I must say. The most useful thing will be the ability to send text to multiple folks. But the faux GPS is pretty damn cool too.

The other thing I updated was my iTunes, wherein I discovered this little nugget:


Looks like you can finally drag and drop music right into your iPhone and create iPhone-specific playlists — ones that live right on the phone and nowhere else. At this point I'm so used to the old way of doing things that I'm not sure what to do with this feature. But something tells me this new found freedom will be a boon at some point in the very near future.

Just as soon as I have some time to use it.

Labels: Applications, Hardware, iPhone

I'm not a web programmer by any means. But a component of the department I work in deals with the web from an artistic standpoint, and a subset of that group does, in fact, do programming. We have web programming classes.

Recently, one of the teachers of one of those classes made the charge that our approach to web programming is old and outmoded. Whether this is true or not is not really the issue. I've been looking for new ways to think about the systems end of that workflow because, well, that's my job, and because it's an inherently interesting challenge to me. How can we make our web development environment more user-friendly?

One general suggestion has been to make the experience more "OS-like." And one step in this direction is to have the web server mount on the Desktop, allowing the developer to work on her site as if it were local. That is, rather than firing up one of the popular SFTP clients and transferring files back and forth from the local machine to the server, the developer could mount her site — or actually, the share her site lives on — directly on the local filesystem. I have two options here: MacFUSE and NFS. I'm testing both currently. So far I've had a couple minor hiccups with MacFUSE's sshfs.app, but it looks to be a fairly smart and user-friendly implementation that web developers here might benefit from. And the NFS approach would work well also, though only from inside the network.

I'm curious what other Lab Admins are doing with regards to web development in their environments. How have you facilitated ease-of-use for a process that's inherently complicated? Or have you? Also, I'm curious if anyone is using MacFUSE — specifically the sshfs component — and what experiences you might have had with it, either positive or negative.

If any of you fine readers have any thoughts on this I would really love to hear them. I've been querying students, staff and faculty for ideas, but haven't come up with much. Maybe things here are perfect, but somehow I doubt it. And, as always, I really just want to make things better.

Please sound off in the comments if you're so inclined.

Labels: Applications, Internet, Lab, Server

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

Labels: Applications, Leopard, MacOSX, Tiger

It's not a difference you'd probably ever really notice, but Leopard's standard menus now use color to create the dark gray text you see throughout the interface (though not in the menubar).


I'm not sure the reason for the change — perhaps to add a warmth and a softness to the text.

Labels: Applications, Leopard, MacOSX

The founding article for this blog — indeed, the very reason for TASB's existence — was a little post called "Tiger Beefs" in which I ranted for a few thousand words about everything I disliked about Tiger. It's been over two years since that faithful first post, and Apple has just released the follow-up to Tiger, Mac OS X 10.5, codenamed Leopard. Please note the absence of the word "beef" from today's title. So far, I have to say, I'm quite pleased — and certainly not deeply irritated — by this latest OS iteration.

Right off the bat I want to point you to the best and most thorough review of Leopard. Every time a new cat is born, John Siracusa not only reviews many of the new features, but goes deep into the depths of the OS to tell us geeks what's really changed and what it means for the future of the platform. It should be required reading for anyone seriously interested in Mac OS X changes.

Also, I want to point you to Apple's infamous list of new features. It's pretty comprehensive for the surface features, and even touches on some of the things I'll deal with here. And speaking of, my particular perspective on Leopard will be less about productivity features (though there will be some of that, to be sure) and more about Leopard from an administration and maintenance standpoint. So, let's get started!

Time Machine
The most highly touted new feature in Leopard — and rightly so — is Time Machine, which automatically makes backups of your data to any external hard drive (or even, I'm told, partition). The whole idea behind Time Machine is that it's so simple, and requires so little thought, that anyone can — and, more importantly, will — use it. It's backups for the masses. And while Time Machine is really made for the end-user, the fact that such a beast now exists as part of the OS is a huge boon to SysAdmins.


I maintain a backup system for all staff members in my department. Anyone who's ever had to deal with such a system knows what a pain it is to implement and maintain. In the old days, we used to back up to tape using Retrospect. But as data storage became increasingly large, and tape increasingly expensive, the system grew unwieldy. An unwieldy system, as you surely know, is not reliable. A few years ago (in fact, with the introduction of Mac OS X, come to think of it) we moved to the free, scriptable, and very reliable rsync (we use the RsyncX version). This allows us to back up over the network to a large RAID drive. But still, the scripts require occasional maintenance, staff must be sure to leave their computers on. There are numerous points of failure. And most inconvenient of all, if a staff member does lose data, they have to come to me to retrieve it, which is inconvenient for both them and me.

Time Machine removes that last step from the equation. Time Machine puts the end-user in control, not just of their current data, but of their backups as well. Now, if a staff member accidentally throws away a file, or makes changes they don't like to a document, or whatever, they simply activate Time Machine and roll back. No freak-outs. No calls to the SysAdmin. No worries. Time Machine is frickin' beautiful.

I will continue to make backups to the RAID with rsync for the foreseeable future. It doesn't hurt to have an extra backup, and, Hell, the system's already in place. But I've also bought all staff a firewire drive specifically for Time Machine as well.


One thing to note about Time Machine: It is geared towards the idea of backing up everything. Like in Spotlight, you can add exclusions to Time Machine, but the default is to back up all your data. A fellow SysAdmin complained that he needed the ability to select what would be backed up, not what wouldn't, if this were to be useful in a production environment. Yes, my friend, but this is not made for production. It's made for people. So the default is, back up everything. What could be simpler?

The Finder
I won't spend too much time on the Finder. In a nutshell, I'm mostly happy, though I'm a bit peeved that the first thing I felt the need to do was hack that ugly-ass Dock.


Seriously. Ouch. I can see liking it on first glance. I mean it is shiny. I know people like shiny. But damn is it intrusive, and not the least bit of an increase in functionality. Yikes! What were they thinking?


There are a few awesome new touches in the Finder, though. Quick Look is probably my favorite. Hitting the spacebar to view a preview of a document is a great productivity boon. Students in the art department where I work will love it for presentations as well. It's beautiful, useful and extremely well-implemented. I only wish it were more key-command-able. (Or maybe we'll discover that it is.)


Speaking of key-commands, the Desktop now has a presence and key-command in the "Go" menu (it's command-shift-d). Sweet!


Also, a long-standing (read: never solved) problem with Tiger's inspector, wherein the inspector would not properly update file ownerships, has been fixed.

I also rather like the look of the new Finder. I'm pleased as punch that there's finally a window standard, and that it's not brushed metal. While I'd probably prefer a lighter shade of gray, and apps in the background to be darker rather than switching to a lighter shade (dark recedes; light comes forward, at least that's what they always told us in art school), the current iteration is really quite nice. The Sidebar is also, in my opinion, more efficient than it once was. And Cover Flow in the Finder might even prove useful at some point.

Other nice touches:

• Clicking on a file name only highlights the file's name, not its extension, thus making file renaming a lot quicker and easier.
  
  
• Drop shadows are larger and darker and generally more dramatic, making windows easier to discern.
• Drop shadows are also now included in screen captures of individual windows.
• File sharing, which is now possible on a per-folder basis (hooray!), can be activated and configured right from the Inspector.

One oddity: the Finder seems to be a bit more fascistic about what you can and can't do with your data. In fact, it disallows trashing key folders in your home account. I was unable to trash, or even rename my Library folder from the Finder. This might be great for the home user. But it could slightly complicate troubleshooting from an admin standpoint. Not a big deal, but I'm not crazy about the trend towards over-management of user data. It's fine for Time Machine. Not so sure about the Finder.


Still, that's a lot of good and very little bad. Overall, the Finder's a big win for me.

Disk Utility
Probably the best thing about Leopard is that there is so much good stuff for SysAdmins. Each OS upgrade has brought us a couple goodies, but Leopard is chock full of them, and the goodies are so... Uh... Good...

First off, Leopard now handles broken disks more gracefully. Attach a damaged external firewire drive, for instance, and if it's mountable, Leopard will mount it and allow you to copy any data that might be salvageable. This actually happened to me in the beta days, and Leopard provided successful, albeit partial, disk recovery where Tiger simply refused to even mount the damaged drive. That's a pretty sweet improvement that no one but SysAdmins are likely to see. Kudos to Apple's Disk Utility team for that one!


Another huge advancement in Disk Utility is the ability to re-partition a drive without wiping it, within limits, of course. Actually, it might be more accurate to say that Disk Utility allows partitioning — or splitting — of partitions. Let's say you have two partitions. But you want to turn that into three. In Tiger and before you had to erase the entire drive and repartition. In Leopard, you can cut one of your two partitions in half (or quarters, or whatever). Leopard will even indicate the free portion of the disk and cut it at the right point. It's pretty damn cool, and something I've been wanting for a long time. For forever, really. I've already used it in the beta, and it seems to work great. Cool!


The one caveat to this dynamic partitioning is that the disk must be formatted using the GUID partition map, which Apple has adopted for the move to Intel. It's GUID that makes all this possible. The old style Apple partition map won't allow non-destructive partitioning.


The final touch in Disk Utility — and actually, this appears to be true through much of the new OS — is that the wording of dialog boxes and information panels has been made much clearer. This should do a lot to make scary disk operations a bit less scary.


Directory Utility
The application formerly known as Directory Access gets some love in Leopard too. Now called Directory Utility, the application does more with less. It's simple, four-tab interface still allows the configuration of services, but there's just a lot less to configure. The only services left now are Active Directory, BSD Flat File and NIS, LDAPv3, and Local. Gone are the services that were never really configurable in the first place, save for turning them on and off.


But Directory Utility allows for the configuration of Directory Servers now in a separate panel, and this is where you'll most likely set up your Open Directory server (though the option still exists in the list of services as it always did). Setup is super simple: check the type, and enter the name. That's it!

Directory Utility now also has a panel for configuring NFS mounts. This is also really easy to use. Simply type the path to your NFS server, and type in the mount point. Directory Utility will verify that the server is functioning and then, when you hit apply, it will mount it. Neat-O!

NetInfo (RIP)
NFS mounts were once handled in an obscure admin utility called NetInfo Manager. NetInfo Manager is now dead. Leopard has moved all of its arcane functionality into other more GUI-friendly apps. Directory Utility handles NFS mounts. The Finder and Sharing Prefs handle per-folder file sharing (which was once the domain of a little app called SharePoints, which configured properties in NetInfo). And home account location can now be configured by using the Accounts Preference Pane and control-clicking the account in question, then choosing "Advanced" and selecting the appropriate options. It's true, I can't think of too many more reasons to go to NetInfo Manager.

But wait... How do I activate root?

AutoFS
autofs is the new automounter daemon in Leopard, and boy is it cool. I've watched with envy for years as my Linux counterparts dynamically mounted NFS shares — or folders within NFS shares — as they get called by the OS. I realize that autofs does a great deal of good for hangs caused by network dependencies, but what I'm most excited about is the dynamic nature of autofs. Prior to Leopard we used automount, which I simply could never coax into doing what autofs does out of the box. With automount, we basically just hard-mounted our NFS server at /home at every boot. With autofs, however, we can specify a wildcard in our map file. What that allows us to do is to never keep the entire NFS server mounted, ever, ever. Instead, when the needed share is requested, autofs mounts the portion of it that was requested.

Perhaps an example is in order. Currently, our NFS server gets mounted in its entirety at /home on every client in the lab. This happens using an arcane Startup Item that contains a truly Byzantine script that I made. It's horrible. Not only does it require this crazy-ass script, it only happens at boot or when automount is specifically restarted. It also requires (for reasons I can't recall) a series of symlinks to land in the /home folder properly. And, worst of all, it keeps the entire home account server mounted over the network on every client all the time. Yuck!

By contrast, autofs requires no such Startup Item. You simply edit one tiny text file (/etc/auto_home, if you're interested) and you're done. Not only are you done, though, but the entire process is now dynamic. No reboot required. In fact nothing happens. The home account server doesn't mount... Until it's called! That's right. No home account server is mounted until joe_user comes and logs in. When that happens, autofs springs to life and mounts the user's home account. And here's the other thing: it only mounts the user's home account, not every folder on the share. This is a huge savings in terms of network overhead. It's also much easier for me to maintain and manage. For me, a working autofs is a huge, huge deal, and it's the thing I'm most pleased about. SysAdmins doing any kind of NFS home account mounting will totally understand where I'm coming from here, I'm sure. This is fantastic. My job just got easier, and my network and Mac systems just got a helluva lot more efficient. Awesome!

Other Notables
There's a whole other list of new features that should make SysAdmins and even regular folk pretty happy. Here are my faves, in no particular order:

• Preferences and applications (i.e. Sharing, etc.) that can be applied to specific users now list network users and groups.
  
  
• Login, remote login (SSH), and file sharing are all now configurable on a per-user/group basis.
  
  
• The firewall is now configurable on a per-application basis.
• There is now a built-in guest account that gets deleted at logout.
• Software Update now logs you out for certain updates where your presence might cause problems.
  
  
  
• Software Update now remembers what it's downloaded and will use that if you postpone an update, rather than having to re-download it.
• iCal event entry doesn't suck as bad now, and is reminiscent of Google's method of contextual calendar entry.
• Dictionary now includes Wikipedia and can easily toggle the three views (dictionary, thesaurus and encyclopedia) or view them all at the same time.
• Spotlight works well now, like it always should have.
• Spaces might actually be useful as well!
• Screen Sharing! For free! Cool!
  

So, that pretty much covers my initial impressions of Leopard. We'll be holding off on installing it in the lab until I can run the majority of major applications (currently, AfterEffects is listed as not working, and that's a deal breaker). Until then, I will run it on my test machine.

And happily. Leopard has been extremely stable and reliable so far, and I must admit I really rather like it. I was never a big fan of Tiger, actually. I found everything "cool" about it to be buggy or annoying. Spotlight sucked, Dashboard was stupid, and there were all manner of problems, and few features to recommend it over Panther, at least not from a SysAdmin standpoint. Leopard, on the other hand, is completely the opposite. There are tons of new, useful features for both users and admins alike. So far, I'm very happy with this release.

Nice job, Apple people!

Labels: Applications, Lab, Leopard, Systems