When you're pushing a way up a climb, going 12kp/h or whatever you're managing, panting and aching, it's humbling to think about how quickly your typical professional cyclist can manage the same thing. Of course, it's their job, and (and I mean this in admiration) they're basically mutant superheroes as well.

We had a reminder of that at the top of the Stelvio when, as a group of us were standing there patting ourselves on the back for getting to the top, a group of riders in Quick Step gear came up over the top so fast they knocked us all back on our heels.

We all went silent for a moment, and I know what I was thinking: wow, no matter how long I do this, no matter how many mountains I climb, no matter how much weight I drop, no matter how many intervals I do, I'll never even approach that. And they weren't even pros, as far as I know. Really amazing.

Controlled Falling

It's not just ascending that's challenging, though; descending is quite difficult as well. You need to control your speed, pick just the right line through the turn, brake at the right time, keep your weight on the right pedal, with your body lined up right with the bike... and everything, as you whip around the corner, is precariously balanced on a 1" strip of rubber against often broken pavement.

And the people who are good at this—I mean really good—are incredibly, unbelievably, going-70-mp/h-down-a-scary-grade-and-whipping-around-corners fast. And they're doing this on a road that's shared between cars, bicycles, motorcycles, walkers, buses... but even on a closed road, it's hard to believe that they're doing what they're doing.

I'm not a terrible descender, and I find it fun, but again: totally different league. And so, we picked our way down the 48-plus hairpin turns, brakes squealing, hitting pretty high speeds and hoping that nothing would go wrong so early in the trip.

Thrilling, nerve-wracking and successful, I'm pleased to say, and we met for lunch in a town at the bottom.

The total: about three hours of sweating up. About 20 minutes of heart-in-your-throat wooshing down.

A ride to our next hotel, the Hotel Hanswirt (a really fantastic hotel in Rablá), eat-work-sleep-eat and we're off again.

Passo Paladi & Passo Mendola—51 miles, 5402 feet of climbing

The third day was beautiful, sunny and hot from the get-go. Feeling kind of happy that the Stelvio was done, I went out faster than I should have and Paladi, an 11 mile HC climb averaging about 7.4%, decided to teach me a slow, painful, sweaty lesson.

Every climb has a personality. The Stelvio was hard but varied, with a lot of switchbacks and beautiful scenery. Our legs were fresh. We were ready to test ourselves. But for me, at least, Paladi was a slog. There were very few turns. The sun beat down, making the high humidity even more oppressive, and any shade was few and far between. Getting up to the top was a confidence-sapping, nearly two hour Mom-are-we-there-yet struggle.

But it got done.

Passo Mendola, despite being Cat 2, was comparatively easy and dispatched pretty quickly: a relief. Lunch, followed by a fun, fast, twisty descent towards Bolzano, brought us to the city's incredible bike trail system.

I don't think I've ever been to a city quite as friendly to bicycles as Bolzano, something I didn't notice when I first arrived for my brief stay before the trip started. There are a huge number of extensively used bike paths. No cars are allowed in the middle of town, which is a pedestrian mall, surrounded by beautiful scenery.

It's really a lovely town... and, after the typical dinner-work-sleep-work-eat-pack ritual, we left it all too soon for what was scheduled to be our biggest climbing day yet.

My original plan was to blog about the Maratona dles Dolomites, and the week leading up to it, while it was happening. It'd been a while since I'd written things with any regularity, and it seemed to be a good way to get started again.

Foolish me.

Given the length and intensity of the cycling, and the amount of work I had to catch up on in the morning and evening, there was just no real way for me to execute that plan while still getting a few hours of sleep every night. And I definitely needed sleep.

So, plan B was to tweet occasionally and write things up after-the-fact.

Welcome to Plan B

As I wrote before, I'd tried to train as much as I could during the months before the event, both with and without friends (the great group of enthusiastic and knowlegeable folks at Ride Studio Café in Lexington). I'd configured and packed up a fantastic titanium bike from Seven Cycles, a great Axiom SL with couplers that fit me perfectly and could break down into two pieces. This allowed it to be packed in a small case, the Co-Motion Co-Pilot about the size of a wheel and less than a foot deep (26"x26"x10") - easily checking as regular luggage and, with handle and wheels, rolled onto planes and trains and through the streets of Italy as needed.

Honestly, if you're doing any kind of serious cycle-touring, a great bike with couplers and this case is a fantastic way to go. I can't speak too enthusiastically about either the bike or the case.

I booked things so I arrived in Bolzano a day before the main group (relatively late at night due to the flights), and stayed a night at the Stadt Hotel Città, who were kind enough to feed me when I came down to dinner a bit late after catching up with the support email that'd come in during my travels.

The next morning, I met the host of the FredCast, David Bernstein, during breakfast: it was great to put a face to the voice, and as he wrote in his own blog, we were both quite worried about the first real day coming up, climbing the Stelvio. (David blogged his impressions of the trip in far more detail than I'm going to, and he took a lot of great pictures - you can find his posts and pictures here.)

Warm-up Day—15.2 miles, 810 feet of climbing

Our guides, Enrico and Massimo (both great people and cyclists) were at breakfast, and we met with a number of the other people on the trip as we headed out to the shuttle that would take us to Glorenza, a great village, and our first hotel, the Hotel Post Glorenza, a beautiful and comfortable way to begin our tour.

The morning brought bicycle assembly (which took less time than expected) and a short ride to shake out the legs and highlight/resolve any mechanical problems. Three of us (not including the guides) had brought our own bikes, and one of them was a Seven Axiom, which was great to see.

The first ride was short, including a brief extra loop up the approach to the Stelvio, and it was fun talking, getting to know and riding with the others on this adventure. A delicious dinner and restless sleep later, our adventure began in earnest.

Passo Stelvio (The King)—61 miles, 6495 feet of climbing

It's hard to describe how incredibly different the riding in Europe is compared to what I'm used to. On my normal rides, we might have 2000 feet of altitude gain, but that's often done a few hundred feet at a time. Elevations rarely go over 1000 feet, and a typical climb takes 10 minutes or so.

Compare that to the Stelvio, which was around 13 miles and over 5000 feet of elevation gain, averaging well over 7%. A real HC climb (well, category 1 in Italy, since there's no HC).

Never done anything like that before. And, frankly, I had no idea how to pace myself. I don't know what my zones are, don't train with power, and rarely use my heart monitor thingy (which wasn't working anyway) so, well, I just tried to stay in a comfortable-but-not-relaxed zone. There was a lot of climbing to come, and it didn't make sense to hit everything hard.

And, well... it was tiring but fun! The scenery was beautiful, the company pleasant, the bike worked well and before I knew it I was confronting the famous figure of Fausto Coppi.

I remember thinking it was absolutely crazy to have us climb this particular climb so early in the trip, but now I completely understand why: if we could do this (and we proved we could), there was nothing coming up that we could not do. It was a huge confidence boost to get up (and down) this famous climb, and I think we all felt that, after all the pre-trip doubts, we were actually ready for what was to come.

And there was a lot to come.

For SuperDuper! users, I'll cut quickly to the chase here: we should be releasing an update this weekend that resolves the few issues that inevitably arise when a new update comes out. Thanks for your patience as we worked through the issues, and thanks to the users who helped us by running special test versions to ensure we had the problems fixed.

This is a bit of a stressful time to be releasing an update, as I mentioned before: I'm in Italy, training for the Maratona dles Dolomites, which happens tomorrow.

My schedule has been kind of crazy, as everyone suddenly remembers they have to back up before a major OS release (and given the minor issues we've been dealing with): I get up around 5-6am, answer as much email as I can before 7:30am, join the group for breakfast and route review, pack (we were moving to different lodging every day before today), get on the bike, ride over mountain passes until evening, shower, answer email until 7:30pm, eat, and then work from 9-10pm until sometime after 1am.

And repeat.

Our total activity so far, pre-Maratona: 210 miles of cycling over about 18 hours and 31 minutes, with 26,813 feet of climbing. Tomorrow's event will add up to 85 more miles and 14,000 feet of climbing over a long day with thousands of other cyclists from all over the world, for a trip total of around 295 miles and more than 30,000 feet of up.

Now, for many people (and you know who you are) that's really not that much. But this is the first time I've done anything quite this strenuous, and combined with a full day of work it's been mentally and physically exhausting. But I knew what I was in for when I signed up: the riding's been well planned, guided and supported, and SuperDuper users have (for the most part) been pretty understanding, so thanks!

With that, on to more detailed information about the update. Assuming final confirmation tests go OK, it should come out today (Saturday). Full information about the update is in the release notes, but I wanted to highlight a few items here.

First, we've fixed the problem with Tiger (10.4) where most AppleScript-based actions didn't work, including scheduling and post-copy actions like Shutdown and Restart. As soon as we determined this was a problem, we turned off auto-updating for 10.4 users.

This problem was due to a misconfigured build script that compiled our dictionary for 10.5 and later rather than 10.4 and later.

It's getting harder and harder for us to maintain compatibility with Tiger, and doing so is preventing us from using the new APIs introduced in Leopard, so I expect that we'll continue with our policy of supporting two OS versions back with new releases of SD! when Lion comes out. We'll still provide support for Tiger users, of course, but new versions will not be compatible as we move forward.

Many Leopard users found that the v2.6.3 was generating errors with their system log, asl logs or some other 'active' files. As above, as soon as we received a few similar reports of this problem, we turned off auto-updating for 10.5 users until we could run down the problem.

It turned out that some new, more aggressive post-copy error checking was a bit too aggressive on 10.5, and when users had very active system logging (due to various system errors that were getting written multiple times a second), a failure to verify file size (etc) information post-copy caused us to raise an I/O error for the file.

We've loosened up our check a bit here to avoid this problem, while still doing additional verification to catch more problems under all OS versions.

So there you go: auto-update will be turned back on for 10.4 and later sometime today, and you'll be able to enjoy improved operation while I enjoy a rest day off the bike.

As always, thanks for your emails, support requests, registrations and comments!

There's a certain way I like to release a version of SuperDuper, or any application, really. It goes something like this:

1. We plan a healthy mix of fixes, tweaks and features.
2. Those new features are designed and implemented.
3. Once we've put them through a bunch of internal testing, we recruit a mix of old and new testers to put things through the "customer wringer".
4. The fix/test cycle is repeated as many times as is necessary to ensure that we're meeting our quality standards, that new features are working as desired and satisfying the needs we'd identified during their design, etc.
5. During the last few testing cycles, I usually start telling the story of the release (which, at that point, we're pretty sure we're nearly done with), highlighting some of the more interesting elements.
6. Finally, we freeze the release and, with any luck, we release shortly after the release candidate is OK'ed by internal and external tests.

And I highlight all this because the whole "telling stories" part of our next release is going to be much shorter than usual, and we'll be doing other things a bit differently as well.

Ring One–Personal

As anyone who follows me on Twitter is aware, I've been doing a lot of cycling over the past few years (and tweeting about it in a rather boring way, sorry). After a cycling trip to Italy last fall, and based on a suggestion by one of the guides, I decided to train for (and participate in) the Maratona dles Dolomites.

So, for the last six months or so—in sun, snow and rain—I've been riding and training (well, trying to train) for this huge, 9500-participant Grand Fondo. In one day, we'll be riding about 85 miles and over 7 big passes, with 14,000 feet of climbing. It's the first time I've ever tried anything this...crazy. Ready or not (mostly not), on July 2nd, I'm headed to Italy for the race, which happens on the 10th.

Those ten hard-date days were running through my head when the 2011 WWDC keynote was broadcast earlier this year.

Ring Two—Professional

As the various rumor sites could tell you, it's always hard to know when Apple is going to do things. But given that WWDC was likely going to be all about 10.7, and last year's WWDC was about iOS, it seemed a reasonably safe bet that the release of 10.7 would be well after this year's WWDC.

Well that was a bad bet.

Apple announced that Lion will be coming out "in July". In other words, the release window opens tomorrow (I'm posting this on June 30th). Given the current state of things, our current 2.6.2 release of SuperDuper is not Lion compatible. Specifically, we know we have two issues of significance under Lion:

• Deprecated command-line tool The "disktool" command was deprecated and effectively removed, and we rely on that for a number of things, including refreshing disk mounts when a copy starts, and automounting during a scheduled copy.
• Updater crashes Our automatic updater crashes under Lion, which makes it hard for Lion users to update (although they can download from our site and install manually).

With that in mind, also remember that Apple is going to be releasing this through the App Store. That means that there's no delay between an "RTM" build (which we can test against) and when you get the GM: it'll get declared RTM, someone will push a button somewhere and BAM! it's GM, and in the App Store.

Add to that the fact that I'll be gone nearly half of July. Which means, if Lion comes out in the first half of the month, as it very well could, and probably will...I think you can see where this is going.

Ring Three–Where the Rubber Meets the Road

Well, perhaps not where you think. We're not going to be late with Lion compatibility, unless something really crazy unusual happens between now and when Lion hits your Mac.

What it does mean is that some of the more interesting things we were going to put in this update will be postponed until later, and we're going to have to put this out with "initial" Lion compatibility, as much as I hate doing that.

So here's the plan: we're going to release version 2.6.3 of SuperDuper! in the next few days (probably on July 1st). This version has a lot of small things in it, some of which will significantly improve the user experience. Examples include:

• Initial Lion compatibility As I've explained, Lion is not out, so we can't promise that we'll be compatible with it when it is released. But SuperDuper 2.6.3 works well with the test version of Lion that we have now, and should work fine when the Big Button is pressed.
• Better scheduling A small change that should help a lot of users. Right now, it's too easy for a user to accidentally create multiple schedules. In the new version, the "Schedule..." button brings up an existing schedule for the source/destination drive pair if there is one (which is what most users expect it to do). Users can still create another schedule for the same pair of drives by Option+clicking Schedule. (I could write an entire post about this one change, and hopefully will be able to in the future, since it's one of the major errors I made in SD!'s quickly-reworked-after-the-original-disaster schedule design.)
• Improved volume failure detection If the destination volume vanishes during the copy, we detect the failure and stop the copy more reliably than before. This should avoid cases where the destination drive's mount point converts to a folder and files are copied to a "hidden" location (/Volumes) on the startup volume.
• Antivirus compatibility improvements We've tried to work around some incompatibilities with NAV that would cause intermittent issues for users that had that installed.
• Better support submission We've had an integrated email support submitter for a long time, but it relied on the NSMessaging framework, which has been deprecated. So, we've moved to a "direct submit" model. You shouldn't see any differences locally, but it'll work in more situations, regardless of your email client. (The downside is that we can't 'automatically reply' to one of these messages, which means a lot more work for me...)
• Expanded automount/ejection We now allow internal drives to be ejected, so they can participate in automatic mounting when scheduling, and can be selected as an ejectable volume after a copy.
• Various other improvements, fixes and tweaks We've touched pretty much every area of SuperDuper! in some subtle (and some not so subtle) ways, with more to come.

Thanks for Coming—Visit the Midway!

So there you go: we'll soon have SuperDuper! v2.6.3 available. You should endeavor to upgrade to the new release before you upgrade to Lion.

I hope you like the new release! If you're interested, follow me on Twitter where I'll be posting about the Grand Fondo a bit, and will be posting updates about SuperDuper! as necessary.

Support during these two weeks will be a bit slower than usual, because I'll be riding during the day, and only able to post at night. Apologies in advance if support feels less "spectacularly fast" during these two weeks: I'll do my best to respond as quickly as I can.

Thanks, as always, for using SuperDuper: we couldn't do any of this without you, and we'll continue to do our best to make SuperDuper an application worthy of your praise and personal recommendations.

The What

Ever been confronted by a Spinning Pinwheel of Death on launch of SuperDuper! on Snow Leopard and, while waiting for it to stop doing that, raised your hands to the sky and cursed me and the ground I walk on?

Hey, me too (without the self-cursing—kids, remember, if you curse yourself you'll grow hair on your soul)! But (and here's the important part) it's not unique to SuperDuper!. You'll also see this when you do a File > Open, File > Save As, and many other actions. It's not just a delay due to drive spin-up, and there's a fix!

The Why

I can't pretend to totally understand why this happens, so please don't ask, but it seems that the dyld cache (if you don't know what that is, read it as "stuff deep inside OS X") gets in some sort of weird state, and that state is often seen, up in userland, as these annoying, inexplicable SPOD delays.

Might be best to think "damnable munchkins" is the real reason why. Or circuit ants. Or blame the iPhone 4's antenna: it's Mark Papermaster: he's taking the blame for everything else and, at this point, probably wouldn't mind.

The First Fix (for Users Uncomfortable with Terminal)

The easiest way to fix this is to power off your Mac, hold down the Shift key, keep it down and power back on. Keep Shift down all the way to the desktop. This starts your Mac, more slowly, in Safe Boot, which automatically rebuilds this cache (among other things).

When you're totally logged in and running, try running SuperDuper! or your other app that was slow with File > Open. You'll note that it's quite fast.

Now, restart your Mac normally. And—check that out—it's still fast! Yay!

The Second Fix (for the Terminal Savvy User, or the Bold and Brave)

If you're comfortable with Terminal, you can do this without the Safe Boot restart:

1. Open Terminal.

2. Copy the following to the clipboard:

   sudo update_dyld_shared_cache -force

3. Paste that into Terminal.

4. Press Return at the end.
5. When prompted, enter your password (it'll be invisible) and press Return.
6. When it's completed and the prompt returns, quit Terminal and restart your Mac.

Poof! Problem solved.

In Sum

Hopefully this worked for you, and was useful. Enjoy your faster Mac, and stop cursing me!

So, I don't usually put general how-tos up here at Shirt Pocket Watch, but since I found this more than a bit frustrating and hard to diagnose, I thought someone else out there would benefit from what I found.

For years my Macs haven't gone to sleep on their own. I honestly don't know why, but there must be some application that's active enough to stop the sleep timer and prevent energy saver from doing its thing.

Annoying, but I'm pretty used to using Cmd+Opt+Eject to put the Mac to sleep. But recently, my Mac recently started waking unexpectedly—basically, I'd put it to sleep and whenever I'd go back (after an hour or so), it'd be awake, screen off.

I hate wasting power like that (not to mention the "fake" presence in AIM or whatever), so I spent some time diagnosing what was wrong.

It seems that the new Bonjour "Proxy" support implemented in Airport Extreme devices requires the proxy to be 'refreshed' on occasion by the proxied Mac. So, every hour, your Mac wakes itself without turning on the screen, updates the proxy, and then goes back to sleep.

Mine hadn't been doing that, but I recently reset my Energy Saver preferences to their defaults, and that turned on "Wake for network access". When that setting is on, this behavior takes hold. And if you Mac doesn't go to sleep on its own (for whatever reason), it stays on after the first wake.

So, in summary, it's a barely Documented Feature with surprising and unexpected behavior. Turning Wake for network access off in the Energy Saver preference pane resolves the issue.

It's been in test for quite a while, and we're happy to say that SuperDuper! v2.6.2 has been released!

I understated the speed improvements we've measured in the press release and collateral, but we really are seeing 3x improvements in-house, which is pretty great. We'll see how it works for you.

Anyway: I hope you enjoy the new version as much as we enjoy being able to provide it to you.

Just a quick post to let you know how things are going with SuperDuper! and the upcoming v2.6.2 (no release date yet, so don't ask—hence this post). So far, we've:

• Implemented a fix for the problem where we don't preserve compression under Snow Leopard
• Ensured that extra data is no longer copied with back-to-back Smart Updates (as expected, a side-effect of the compression issue)
• Resolved the various other issues mentioned in the last post (although we haven't come up with a fix for the scheduling/settings issue yet)

These fixes have been in external testing for over a week, and the feedback has been excellent so far.

Since we hate releasing updates that have nothing but "fixes" in them, in addition to the above, we've made some changes that significantly speed up the speed of copying, with both Smart Updates and full copies.

In our internal tests, confirmed by our external testers, copying under Leopard and Snow Leopard (with larger data sets) is up to (wait for it) three times faster, especially with fast destination devices.

Needless to say, both of these changes involved "cracking open the cloner", which requires significantly more testing than a tweak to the UI or some "simple" changes to higher level aspects of the copying process, but progress is very good and we're looking forward to getting this into your hands as soon as we (and our external testers) are satisfied with it.

Note that I'll be at C4 this weekend, so support might be a bit slower than usual from Friday until Monday. If you're at C4 too, say Hi!

Well, a week has gone by, and 2.6.1 has been downloaded and run by an awful lot of you. It seems to be working well, too—which isn't to say it's perfect so, once again, no unicorn.

Here's what we're working on right now.

Individual file compression under Snow Leopard is not maintained on the backup

This kind of caught us by surprise, frankly. When we checked our copy results, we found that the sizes of files were the same on source and destination, and assumed the files were, indeed, being copied with compression.

Nothing like an assumption to make one feel like an ass. Or an umption. Whatever.

Anyway, what's happening is the OS is hiding the compression from us... and we didn't realize it. For the nerdly among us, here's some terminal commands and output that you'll find interesting:

$ ls -l /Applications/iCal.app/Contents/MacOS/
-rwxr-xr-x  1 root  wheel  9123088 Jul 16 03:42 iCal
$ cp /Applications/iCal.app/Contents/MacOS/iCal ~/iCal
$ ls -la ~/iCal 
-rwxr-xr-x  1 taiko  taiko  9123088 Sep  4 17:16 /Users/taiko/iCal

OK! So, I copied a file, and as you can see, the size of the file is the same when I started and ended: 9123088. This is what you'd see with SuperDuper!, too (except with the ownership and stuff preserved). So, everything's cool, right?

Well, no. At a lower, block level:

$ du /Applications/iCal.app/Contents/MacOS/iCal 
6776 /Applications/iCal.app/Contents/MacOS/iCal
$ du ~/iCal 
17824 /Users/taiko/iCal

Well, look at that: iCal, despite being copied with a system tool, is now nearly 3x the size in blocks after being copied, but the same size at a high level.

Great.

Needless to say, that's why we got confused. The sizes were the same. But they weren't... and you could only tell by looking at the amount of space the files took on the drive, not the file's size.

Note that cp, tar, Finder, etc all behave the same way with this: the file ends up getting expanded. The only one that acts differently, when given special parameters, is ditto, and that's likely because it's used by the installer (which puts these files on the drive in the first place).

We've got a good handle on this, and we're in the process of modifying SuperDuper! to retain the compression in the next update.

Some files get recopied every backup

We're aware that some files (specifically, files in /Applications, /System and /Library) are being recopied each time you back up, which significantly slows down repeated Smart Updates.

Our initial investigation has shown that while we thought this was related to prebinding, this is actually related to the compression issue, above. Specifically, compressed files, when they expand during copying, compare differently with flags and with certain time fields.

We didn't catch this because our confirmation tests didn't use compressed files. We did know that we were recopying files, but due to the fact that the end result was fine, and Snow Leopard shipped four weeks earlier than we expected, we just didn't have time to investigate the problem fully, especially since fixing it would involve the most critical and most time consuming to test part of SuperDuper!—something that we'd frozen many weeks before.

In other words, considering the issue was basically one of performance, we thought it was better to get the update out day-and-date with this known issue, than hold it back for the week or so it would take to investigate and fix (and then however long it took to test, based on what we had to change).

This should also be fixed in the next update.

Slower performance

We've had some reports of slower performance in the new version, which is more than a little weird, since the base-level copy calls are the same. Part of that is due to the re-copying, above, but we're looking into it further to see if there has been a regression, and if so we'll fix it as soon as we confirm and find the cause.

People aren't recreating their schedules

This version of SuperDuper! requires that people recreate their schedules due to some problems reading in parts of the old settings files. Many users aren't doing this, so we're trying to improve our error handling to detect and force the schedule to be recreated, rather than just asking people to do so.

UTF8 encoded URLs in AppleScript bite me again

So I'm an idiot. I can't tell you how many times I've attacked this specific problem in AppleScript, but I blew it again in the schedule driver in some cases, so drive names with some unusual characters (accents, etc) won't always run when scheduled.

Again.

I've already fixed this problem and it should be in the next update. It's been tested with both regular Unicode characters (e.g. ) and composed sequences (e.g. é). Note, though, that I haven't managed to get AppleScript to work with a drive named using the Alpha character (α) with backup-on-mount (reported by Glenn—thanks), because Finder fails when I try to use that character in a built-up path. Anyone who's awesome with this stuff in AppleScript please contact me if you have any ideas, because I'm fresh out.

Japanese users and backslashes

Back in the days of Panther, there was a weird bug where backslashes () didn't work in AppleScripts, because they were confused with the Yen symbol when you were in Japanese language mode.

That was supposedly fixed in the compiler back then... but in Snow Leopard, the problem seems to be back (it works properly in the Script Editor but not in the command-line compiler osascript), and I used some backslashes in the updated schedule driver. That's been fixed as well—thanks to Tohru for reporting the problem.

I think that just about covers the issues we're working on right now at a high priority... back to it.

Rather than taking the time to write a mildly amusing "we suck" press release that announces this day-after-the-big-release update, let me just say it fixes the stuff I mentioned in the last post, followed by ringing a dinner bell.

Come and get it!