Jaharmi’s Irreality renewable hyperlinks with 0% transfat since 1999

Geoff got me thinking about zsh last fall, and it’s on my mind again. I’m pondering a switch to it.

I’m still stuck on tcsh because it’s what I started with for my heavy interactive shell use. All my shell config files and knowledge reside in tcsh, because that’s what you used by default in Mac OS X 10.0. But, I dislike that the tcsh syntax is different than what I’m used to when it comes to shell scripting with bash. Bash is what I learned when I first took up scripting. Well, more to the point, I learned sh, and have grown a bit into using some bash-isms.

So I’m reading more about zsh, which means I’ll probably be firmly rooted in analysis paralysis for a while. But it looks good, and my chances in converting will improve if I can get my .tcshrc custom-tailoring moved over with reasonable ease.

In the meantime, here’s a search for zsh on Del.icio.us.

As Ian Ward Comfort notes on the MacEnterprise list, “it looks like a lot of people are going to have a problem” with Apple’s current Java runtime environment during the daylight savings time switch in March.

The most up-to-date shipping version of the JRE on Mac OS X Tiger responds the same way it did for Ian on my test system when running Sun’s tzupdater.jar tool:


$ date
Fri Feb 2 07:27:08 EST 2007
$ java -jar ./tzupdater.jar -t -v
java.home: /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home
java.vendor: Apple Computer, Inc.
java.version: 1.5.0_06
JRE time zone data version: tzdata2005m
There's no tzdata available for this Java runtime.


The tool from Sun will not update Apple’s JVM, unfortunately, even though it will tell you what version of the time zone data is installed. (For more info on Java and the 2007 changes, see Sun’s “US Daylight Savings Time Changes and the Java SE Platform” FAQ.)

What implications there might be for an out-of-date time zone file in the Java JVM…that, I don’t know. The sky is not necessarily falling.

But, the Apple JVM as of this moment evidently doesn’t include the daylight saving time changes first encoded in the Olson 2005n database—the JVM is older than 5.0_7, the first one Sun lists as including it, anyway—which means it apparently doesn’t incorporate the shift introduced by the Energy Policy Act of 2005. Of course, there is the possibility that the Apple JRE is different; it may tie into system time rather than rely on the JVM’s own facilities, and if you’re on Mac OS X 10.4.6 or later, that might mean everything is fine.

Hm.

Update 03/15/2007: Apple did patch this before DST 2007. However, I have heard of a subsequent last-minute Sun JRE update that I’m not sure is incorporated in Apple’s patch. However, it should be noted that after Apple’s Java patch, I do get the following output from Sun’s tool, indicating that the time zone data does exceed the problematic “tzdata2005r” version:


$ java -jar ./tzupdater.jar -t -v
java.home: /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home
java.vendor: Apple Computer, Inc.
java.version: 1.5.0_07
JRE time zone data version: tzdata2007a
There's no tzdata available for this Java runtime.


In listening to MacBreak Weekly 25, it hit me that the new 802.11n AirPort Extreme base station could very well be the first Apple home server. In some sense, it could compete against Windows Home Server (see a preview here), which was announced at CES.

Let’s think about backup, which is one of the neat features announced with WHS. We know that Mac OS X Leopard is supposed to include Time Machine. Time Machine is going to eat drive space; to keep your current data plus historical data—so you can go back and forth in time—you’ll need more storage than you have internal in most single-drive Macs. You can do this with a local drive or a network drive, although I’ve seen no public information on the requirements for network access. (Apple coyly says only, “Or back up to a Mac OS X server computer,” on the Leopard preview pages.) It could be a shared AFP volume or it could be a disk image on a network share—that information simply isn’t public yet so let’s not speculate.

We know that the AirPort Extreme base station has a USB 2.0 port for attaching a drive. The attached drive can be shared for Mac and Windows, according to Apple, which implies AFP and SMB/CIFS support. You can set up accounts and access controls. (Oh, by the way, it still offers printer sharing.)

It’s in providing the share points that AirPort Extreme could enable over-the-network Time Machine backups for one or more computers. That would compete with WHS.

There is suspicion that the base station could be running a similar embedded “OS X” to the iPhone. This could account for the file sharing, print sharing, accounts, and access controls features; these are already part of Mac OS X today.

Now, I’m going to extrapolate. Let’s assume one could hook up a USB 2.0 hub to the base station. That implies that you could connect several devices, possibly even multiple drives—whereas right now, Apple advertises only a single “USB 2.0 port for connecting a USB printer or USB external hard drive.” [My emphasis.] This might not be ideal if you don’t have a good, consumer-friendly way to manage that storage.

Enter a new volume format. What if ZFS ever comes to the “OS X” platform, as many hope it will in Leopard? Wouldn’t it make sense to connect multiple drives, bundle them into a ZFS storage pool to provide scaling and redundancy, and then share them out?

It’s at that completely hypothetical wishful-thinking point that the AirPort Extreme base station competes more capably as a home server against WHS and my new Infrant ReadyNAS NV+. The others both have on-the-fly expansion capabilities that are not advertised for the AirPort Extreme. Assuming you just need AFP or the ability to store a disk image—a big but reasonable “if” at this point—then a multi-drive ZFS-based AirPort Extreme network storage solution would be a grow-with you home server.

Note that Microsoft itself mentions WHS as being a good host for Time Machine backups in the preview I linked to above.

It’s too bad the LAN Ethernet ports on the AirPort Extreme are only 100 Mbit.

Hm, only time will tell how this will play out.

I wanted to determine how much space I’d save—and what the compression time tradeoff might be—to compress Mac OS X system images with gzip versus bzip2. Both are options in Mac OS X Tiger, but the bzip2 compression is new in that release (and thus not backward compatible with Panther and earlier). Given that Apple’s own disk imaging is the bedrock of almost all imaging solutions from Mac OS X, including those from third party computer management solutions providers, this information is valuable and widely applicable on the Mac platform.

If the time were the same but I saved some disk space, I’d count that as a win for one compression choice or the other. For significant space savings, I’d even sacrifice time to a longer conversion operation because disk image compression and ASR prep can be handled in the background during downtime or operational lulls. A Folder Action or launchd task might be ideal for that, and might even be a useful option if you are just archiving images.

The two disk image formats I tested are UDZO and UDBZ, as defined by the hdiutil command and its man page.

For an UDZO version of the image (gzip compression at level 9—or best),
I got the following results from hdiutil convert:

Elapsed Time: 1h 1m 50.751s
File size: 4226869141 bytes, Checksum: CRC32 $8CF3F127
Sectors processed: 20184610, 19980489 compressed
Speed: 2.6Mbytes/sec
Savings: 59.1%

I ran the hdiutil command with time (a handy utility if you haven’t used it), to get these figures:

real 61m52.133s
user 51m7.575s
sys 2m47.700s

For the same image converted to UDBZ (bzip2 compression):

Elapsed Time: 2h 16m 28.057s
File size: 3956667545 bytes, Checksum: CRC32 $8CF3F127
Sectors processed: 20184610, 19980489 compressed
Speed: 1.2Mbytes/sec
Savings: 61.7%

The time results for that were:

real 136m29.205s
user 106m1.832s
sys 8m30.739s

You may draw your own conclusions, as appropriate to the data and your situation. The source image was the same size, nearly 10 GB, which included Mac OS X Tiger and a suite of applications with a small number of user accounts. The source and converted files were both stored on an external FireWire 400 hard disk, and converted with a 1.5-GHz 12-inch PowerBook G4.

Although the ASR-prepped (i.e. asr --imagescan) gzip and bzip2 images were not that different in the end, the bzip2 version definitely came out smaller. It has in ever test I’ve ever run. However, it did take twice as long to create the image. So, if you’re strapped for disk space to collect your images and CPU time means less to you than storage (which is often the case for me, given that I have access to a lot of G4-class Mac hardware), I would consider bzip2. However, gzip at level 9 is perfectly acceptable (still providing almost 60% savings in this case), is faster to create, and has the benefit of working on older versions of Mac OS X, as well.

I should try gzip at other settings (like levels 1 and 6, for example), because you can’t choose level 9 in the Disk Utility interface; you must use the command line -imagekey flag. (You can get bzip2 from the GUI if you enable the hidden advanced disk image formats, but I still don’t see a way to choose a higher gzip level.)

The use of the defaults command in Mac OS X is something of a black art. For one thing, you need to delve into property lists to determine what property you want to change.

Therefore, I didn’t want to resort to it to set Safari’s “open safe downloads” preference, but it looks like that particular setting is regrettably not one that you can control with Workgroup Manager (or the Apple MCX schema for managed clients).

So, to make that settings change at the command line or through a script, you can use the following tips. (If you have to do something much more advanced with plists than this, you may want to consider using PlistBuddy, a propertly list manipulation tool which Apple includes in their installers.)

With defaults read, you can read the AutoOpenSafeDownloads property in the user’s domain:

% defaults read com.apple.Safari AutoOpenSafeDownloads

That will return 0 or 1, the former meaning the “off” or “no” and the latter meaning “on” or “yes.”

To turn AutoOpenSafeDownloads off, use the defaults write command with the -bool option at the command prompt:

% defaults write com.apple.Safari AutoOpenSafeDownloads -bool NO

To turn it on, change the boolean option to YES:

% defaults write com.apple.Safari AutoOpenSafeDownloads -bool YES

One of the most popular articles on this site since the Drupal transition is my discussion of MacHeist and MacSanta. I did take advantage of the MacHeist bundle right before I’d heard the announcement of MacSanta—perhaps proof that in promotional sales, timing is a key element.

So far, I’m pretty happy with the software that I got from MacHeist, and the price I paid for it, but it’s not exactly life-changing yet. I haven’t even downloaded and registered it all; I’m probably going to forget what I got soon. Still, I’m eagerly anticipating some upgrades to a few of the applications in the near term—FotoMagico 2 and iClip 4—and hope that they match the promise (and in the case of iClip 4, actually ship sometime). (I’ll probably get stuck paying upgrade fees for them, but that’s a tried and true Mac bundle tradition, too. Sometimes, a savvy software bundle shopper is just in the game to get the upgrade pricing for future versions.)

If I had bought software through MacSanta, I would have strongly considered the applications below, some of which I only discovered because of the promotion. Others are applications I’ve been following for a while but just haven’t gotten to the point where I want to buy a license. A few were just such late additions to the lineup that I really didn’t have time to think about it; there was just too much else going on leading up to Christmas. (I really wish the promotion had run from Black Friday or December 1, rather than starting so close to Christmas and ending on Christmas Day. Poor timing and the ever-changing lineup were just two problems with MacSanta.)

Here’s my list, not quite in priority order:

• a BBEdit upgrade, since I’m a little behind and I use it so much (plus, I just found out TextMate has poor support for InputMethods and thus doesn’t work with Spell Catcher X)
• CSSEdit
• Painter’s Picker and/or ColorSchemer Studio
• 1Password
• PTHPasteboard, even though I have iClip now—and especially if I’d known version 4 was coming, because running regexes on the clipboard would have been awesome
• DoubleTake
• Keyword Manager
• Tangerine!
• FlySketch, which is close to the quick drawing tool I’d like for annotating Web uploads

According to a post by Lance on the MacEnterprise.org mailing list, the .mcxlc file in the user's Mac OS X home directory is a lock file for managed client (i.e. Workgroup Manager or MCX) logons.

If the lock file is stale, he says, deleting it may help the user log in.

I was emboldened by success with Flock and the update to Drupal’s Pathauto module. Fresh from that minor yet important triumph, I figured it was time to try MarsEdit out again—because it really is my preferred blog API posting client (and the one I’ve paid for).

It turns out that the previous work I’d done to set up MarsEdit—combined with the Pathauto change and mixed with some magic during the intervening time—made all the difference. I’ve been able to post and re-post stories to my Drupal site. MarsEdit now works round-trip. It lets me create new stories, using Filtered HTML formatting and converting HTML entities. It allows me to tag stories with categories from my taxonomy. It also enables me to edit existing stories, presenting the current state of each in the CMS, as well as displaying a sorted list of the categories (and which ones are selected for a particular story). Thanks to the Pathauto module fix, new stories automatically get a title-derived URL. This is excellent!

For future reference, my server is set up so that the Drupal site is the default for the domain (i.e. you go to “http://www.site.tld/” and you immediately get the Drupal site with no additions to the URL). The blog settings that worked to post stories there included:

• Home URL: http://www.site.tld/
• Software: Movable Type
• RPC URL: Home URL + xmlrpc.php
• Blog ID: story

I believe the rest of my settings are defaults when you create a new blog definition in MarsEdit 1.1.

My last post was the first one I’ve posted with Flock, an upwardly-mobile special purpose Web browser.

I am quite surprised at how deftly it handled connecting with my Drupal site, allowing me to post a story with relative ease. It did so much better than I’ve managed to accomplish with MarsEdit, unfortunately—and that could be misconfiguration of MarsEdit, but the point is that I still haven’t hit on the right combination. In contrast, Flock asked for my Drupal site login information and URL, and from there, it automatically configured everything. (In other words, it performed the way that MarsEdit did when I was using it with my older Userland Manila site, but not with Drupal.)

Still, all is not perfect. While Flock correctly handled a complex posting task—including discovering all of my various taxonomy tags for categorization, letting me set multiple tags for a story, and handling various HTML entities such as typographer’s quotes and em dashes—the Drupal story did not get a human-readable URL assigned by the pathauto module. I think that’s probably more of a Drupal problem, something to do with the pathauto module, rather than a blog posting tool problem. MarsEdit posts exhibit the same result. (For what it’s worth, I’ve now posted this in the issue tracker for the Pathauto module.)

Also, Flock suffers from a user interface that feels derived from the Mozilla project. There’s just some odd happenings in the text editing fields, and I have yet to figure out if there are keyboard shortcuts for some of the editing toolbar buttons/functions.

On the plus side, there is a useful source view so you can check out the HTML source of your blog post. Since Drupal doesn’t need that formatting (since its Filtered HTML and Full HTML input methods will automatically wrap paragraphs, for example), it’s superfluous for my purposes, but still handy to see if you need to.

I also wish I could see the taxonomy tags right in the main editing window, or as a drawer. I don’t prefer MarsEdit presenting them in a drawer, but even that is preferable to Flock’s drop-down sheet, which is much more modal.

Wanting to find out exactly how long Tiger has been available, I tried out some date math in Python. The answer? It’s 618 days, as of today’s date.

Previously, I’ve done my date math in AppleScript, but Python is quicker for me now that I know what to do. I post this to help remind me how to do date math, because I’m very forgetful.


% python
Python 2.3.5 (#1, Mar 20 2005, 20:38:20)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from datetime import date
>>> a = date(2005, 4, 25)
>>> b = date.today()
>>> print b - a
618 days, 0:00:00
>>>