Google Reader - following vs. reading the feed

Mahendra, who I will now be following, has written a great summary on using Google Reader. It was all familiar to me, but he cleared up a mystery for me ..

How I Live and Breathe Google Reader by @ScepticGeek

... Tip: By adding a person’s shared items to a folder in Reader, you can unfollow the person in Buzz if you wish, while continuing to see their Reader shares....

Aha! That explains it. Some of the people I most like to follow, like John Munro, had vanished from my Google Reader "Follow" section but their shared item feed remained in my GR Subscription section. I bet I accidentally clicked "unfollow" (surprisingly easy to do for me).

I just navigated to John's shared item feed as shown in GR and added him back to my follow section. (Oops! He's showing up as "08915834275668816438". Hope this gets fixed soon.)

Like Mahendra I'm abstaining from Buzz. Google Reader "People you follow" is much closer to what I want than Buzz.
--
My Google Reader Shared items (feed)

FCC iPhone speed tester: very slow upload in MSP

I tried the FCC iPhone Broadband speed app today.

I ran it once on WiFi and once on MSP 3G.

Houshold DSL speed: 5.5 mbps down, .75 mbps up

iPhone WiFi: 5.8 mpbs down, 0.71 mpbs up

iPhone 3G: 2 mpbs down, 0.08 mpbs up

The iPhone WiFi performance was limited by our home DSL speeds.

The 3G download performance was pretty good. The 3G upload performance, however, was really bad. It's comparable to a modem. AT&T's 3G upload is 4% of download performance. No wonder posting images to Facebook, or to Evernote, is so slow.

OS X Backup: Apple's Backup 3.x

[Update: This post has several updates, but in the end I rejected Backup 3 due to an unacceptable bug.]

I've been trying to figure out how to manage offsite backup now that Retrospect is a lost cause.

I'm using Time Machine/Time Capsule for onsite backup for all of our machines, and testing SuperDuper for an offsite backup of my main machine using an encrypted disk image to work around SDs lack of encryption. That leaves my laptop. Alas, OS X won't mount a networked encrypted sparsebundle image for SuperDuper to use, and I can't backup up my laptop data without encryption.

I can, however, backup just my key laptop iPhoto library to a share.

How to do that?

Well, turns out Apple Backup 3 still works - at least with Leopard. The current version is 3.1.2. Apple will update old versions, and if you're a current MobileMe subscriber it's still available. Free.

Might be just what I need for stuff that doesn't need encryption.

Testing now.

See also:

• Time Machine, Time Capsule and offsite backup
• Online backup – the security problem (it’s not the encryption)
• CrashPlan (or JungleDisk) instead of Retrospect 8?
• Freeing up Time Capsule space – and documentation for Time Machine and Time Capsule

Update 4/1/2010: I've now combined scheduled Backup with traveling. Yech. It's stuck on a backup schedule I can't edit and it can't complete. This app never got past beta testing.

Update 4/13/10: APPLE SAYS DON'T USE BACKUP. It doesn't really work with 10.5 or later. Thanks, Apple.

Update 4/14/10: Ok, now they release Backup 3.2. I'm getting whiplash here! Also, I came up with a workaround for the lack of encryption. I use Backup.app to put a backup of my iPhoto Library on my primary drive, that entire drive is backed up by SuperDuper to a local (USB drive) sparsebundle encrypted disk image. This means my current iPhoto library ends up with two local time machine backups, one local backup on my primary server, one local backup via SuperDuper on an external drive, and one remote backup. Five backups feels about right.

The major 3.2 change, besides presumed compatibility with 10.5 and beyond, is recycling. Most significantly, it "improves" restore reliability (kind of scary actually).

Update 4/17/10: I've given up on Backup. I believe it can cause an endless SPOD (spinning pizza of death) system hang when it's backing up to a network share and connectivity is lost (ex: laptop goes to sleep, hang on resume). That's an unacceptable bug.

Can't mount sparsebundle disk images over an AFP network

I can mount several types of OS X disk images from an AFP (TCP/IP) network share, or even from an iDisk (slow obviously), but not sparsebundle encrypted disk images. I can only mount those from a local drive.

This to be a limitation of both 10.5 and 10.6 (Leopard and Snow Leopard). I found a related Apple Discussion thread and an older 10.5 thread on NAS mounting.

I was trying to do this as a workaround for SuperDuper not supporting drive encryption. I had hoped to first backup locally to a sparsebundle encrypted image, then move the image to a shared drive which I hoped to then update over the WLAN. That way I could safely rotate my SD backups offsite.

This doesn't work. We really need SD to support encryption.

Two Problems with SuperDuper backup

I've not been having much luck with OS X backup. I really wanted Retrospect 8.x to work, but every rational voice I trust tells me to stay away from it. It must be terrible to be the responsible product manager.

Time Capsule/Time Machine works ok, but it's not suited for offsite rotation. Carrying around unencrypted data is not a great idea.

SuperDuper! is suitable for offsite rotation, but it has the same problem. Even though it can backup to an image, the image isn't encrypted. You can create an encrypted disk image and have SD do a daily "smart backup" to that; in my testing SD will load the backup on demand and even load the encrypted image (as long as the pw is stored in your local keychain).

There have been many requests for the author to add encryption but he's held off. I hope he'll come around eventually.

The other problem with SuperDuper backup is that you can't test it. The automatic smart reconciliation feature requires payment first. Even EMC provides a 1 month evaluation copy of Retrospect, but Shirt Packet doesn't allow us to test the key backup features of SuperDuper.

See also:

• Time Machine, Time Capsule and offsite backup
• Online backup – the security problem (it’s not the encryption)
• OS X Backup: Apple's Backup 3.x
• CrashPlan (or JungleDisk) instead of Retrospect 8?
• Retrospect 8 - no user guide?
• Freeing up Time Capsule space – and documentation for Time Machine and Time Capsule
• Airport Extreme: Firmware update, Time Capsule bugs, tips and fixes

--
My Google Reader Shared items (feed)

The OS X Snow Leopard "Connected As" MobileMe bug

In 10.6.2 I can replicate the same bug described here ...

OS 10.6 - how to change "connected as" default name - Mac-Forums.com

I have an imac & a macbook on my network. when I'm on my imac & i click on the sidebar to connect to my macbook, the same "connected as" name always comes up. i don't remember where this name came from (it's actually my mobileme email address) it's not a name i have listed under users who can share on my macbook. after connecting i have do disconnect then quickly click connect so i can enter in the username i want to use, if i don't then it automatically connects back under the name i don't want. i just want to reset the default "connect as" i guess I'm trying to say. i don't have this problem when connecting from my MacBook

It's a Snow Leopard bug. If you enable MobileMe Snow Leopard tries to authenticate with a remote machine using the MobileMe name instead of a username. I think it's some version of a directory service; in theory it probably lets you easily connect to a remote account with the same MobileMe credentials -- even if has a different username and password. It fails, however, if you try to connect to a share with a different associated MobileMe account.

When this bug hits you can't use the normal "Disconnect" or "Connect As" features. Editing the Keychain doesn't help. You can try clicking "Connect As" very quickly after Disconnecting and it might respond.

If you turn off MobileMe then you can connect and disconnect normally and the "Connect As" feature works. If you turn MobileMe back on the bug returns.

If you save files using this MobileMe authentication scheme on the remote share I think you may run into ugly permissions problems (such as 45,000 0 length files this evening on one failed write attempt).

See also: Gordon's Notes: Tech churn 2010: How do you share a family file?

Update: There's a Take Control book on permissions due out soon. The announcement blog post sounds ominous. I'm going to buy that book, I'll ask the author to check out this MobileMe bug too. Since Apple last updated their troubleshooting permissions document in 2008, and their screen shots go back to 10.2, the author has his hands full.

Update 3/11/2010: Given my recent experiences, I decided it was time to migrate Emiy's account to the new machine, and clean out the old accounts. I did a firewire migration and it went very quickly. After verification and testing I deleted her account on the old 10.5 iMac. On restart my old account on that machine had her user name, but all of my content. So the permissions were more than a bit screwed up over there. I deleted that account as well.

Why you shouldn't use OS X ACLs

The OS X file security mechanism (aka "permissions") was archaic eight years ago. Now it's the living dead.

The somewhat less decayed alternative is to use OS X Access Control Lists (ACLs). They are not widely used, though some geeks use them to share media collections among multiple machine accounts. (This kind of file sharing is not otherwise possible [1] without hacks that remind us that OS X is a dying desktop solution).

This, however, is not necessarily wise. This warning is embedded in Retrospect Professional 7.7 Mac OS Client preferences for ACL backup ...

Allow the Retrospect Client to examine Access Control Lists (ACLs) on Intel Macintoshes. This may cause Retrospect to freeze due to a defect in Apple's implementation of ACLs.

EMC's products are notoriously buggy, so I suspect "freezing" rather than, say, throwing an error message is an EMC bug. On the other digit, however, I believe them. This feels true based on my own experiences, and it confirms a hunch of mine that one should avoid ACLs. Of course this is a good general principle -- don't use features of operating systems and software that are not widely used. A corollary is that you shouldn't consider uncommonly used features when evaluating modern software -- they probably don't work.

[1] Last April Tidbits claimed iPhoto '09 does enable multi-user sharing. It is, however, still undocumented by Apple and thus risky. Even so, I might give it a cautious try once I happy with my 10.6 backup solutions. I'm not happy yet.