The BFC Computing Weblog

A Mac user might want to export his Keychain passwords and notes for several reasons - using a third-party password manager on Mac OS X, creating a time-resistant backup of passwords, printouts of passwords for the safe-deposit box or attorney, or switching to another operating system.

There's no easy way to do this. Keychain Access only allows you to export certificates, and Apple recommends backing up the Keychain database files, which accomplishes none of the above goals and promotes lock-in.

The keychain code is itself open source, but I couldn't find it compiled for another platform anywhere. I assume that enough of the OSX toolchain is required to make this infeasible, though likely not impossible. Still, it's not there.

Fortunately, I ran across an Applescript that uses Keychain Scripting to create a text file from a user's login Keychain. Unfortunately, it didn't do a bunch of things I thought were required for moving my passwords to a Linux machine, so here's the delta:

version 2009030201:

• handle all keychains
• handle all key types
• handle comments and descriptions
• handle errors
• trim dangling whitespace
• write to tab delimited format
• unlock all keychains first, so the mad tapping won't hit 'cancel'
• add username to filename
• replace carriage returns/newlines in text fields with spaces
• use unix line endings in output file

and some general code cleanup. I'm assuming the sample code is in the public domain and releasing this version under GPLv2+. Please improve this and comment here when you do or send changes back. If you own the original code and feel this is improperly licensed, let me know ASAP.

I've run this out of Script Editor - the advantage there is it's easy; the disadvantage is double-confirming every keychain access, one for Script Editor, one for Keychain Scripting. Terribly time consuming. I suspect if you compile this it'll eliminate the first half.

I've set this to open all the keychains first. Otherwise when hitting "allow, allow, allow" you might hit 'cancel' if it asks to unlock a keychain. If your keychain is big enough you might not get through the whole thing before the keychain unlock times out, so be careful.

Your minutes of tapping on the mouse button like a human waiting for a treat will be rewarded with a ~/Desktop/Passwords-yourusername file. It'll be easy to then process with other scripts, importable into databases or spreadsheets for further manipulation. I'll leave it up to you to be smart and not leave this password file sitting around in some unencrypted/unprotected location for any longer than absolutely necessary. If it gets stolen you're probably up a creek, right? So, be careful, only aim at what you intend to kill.

Download KeychainExport.

I've been using streaming video solutions more, since we pared back our satellite TV package at home and have been saving the Netflix allotment for the kids.

But streaming performance has been lacking for me. I've frequently experienced [buffering] and [recalculating bandwidth] messages, and having streams just stop dead and freeze up.

I wondered if Comcast might be playing games, since they have a history of doing so and this competes with one of their other products, so I decided to check out Google's tools that measure this possibility. Comcast is clean.

But the tools did help me find the actual cause: my TCP buffer receive size was set too low. Their network diagnostic tool revealed that 80% of the time my system was responsible for causing the delay, and only 20% of the time was the network at fault. After rejecting many forum suggestions I found as bizarre, I came across a decent O'Reilly article, which linked to an LBNL site with this recommended setting (for Mac OS X):

          sysctl -w net.inet.tcp.win_scale_factor=8
          sysctl -w kern.ipc.maxsockbuf=16777216
          sysctl -w net.inet.tcp.sendspace=8388608
          sysctl -w net.inet.tcp.recvspace=8388608
          

This increases the send and receive buffers to 8MB each and adjusts the kernel ipc buffer to accommodate. The first line is obsolete as of at least 10.4.11, which my video streaming system is on.

The last three lines above are a good way to test, and for permanence, create a file, /etc/sysctl.conf , with just the parameters, like this:

          kern.ipc.maxsockbuf=16777216
          net.inet.tcp.sendspace=8388608
          net.inet.tcp.recvspace=8388608
          

After setting that, my videos are all streaming without errors and the Google test shows that now the network is my delay 80% of the time and my client side none.

Recent OSX (10.5.x) and Linux (2.6.17) have TCP buffer autotuning which might, in some cases, make the above unnecessary. The Linux version only sets 4MB buffers, though, which may or may not be enough depending on your bandwidth delay product. Some experimentation may be in order, look up the proper variables for your kernel version, the above is only tested on xnu 8.11.1.

Apple's Snow Leopard (10.6) operating system is due out in the next quarter according to slides shown recently at the LISA conference. It adds a small handful of features but it's mainly an architecture, performance, and bugfix release. Leopard (10.5) is pretty buggy and Apple readily admits it's not what an OS should be. So they're coming out with an update less than a year and a half since the last one, which is by most counts what Leopard should have been. This isn't really disputed, even Apple's name isn't for a new cat, this is the one with all the 'marks cleaned off'.

OK, so it's great that Apple's getting everything squared away so quickly, right? Yeah, it is if you've got recent hardware.

But what if you have a computer that was purchased in, say, the first half of 2006? It's going to have a PowerPC processor in it, and Snow Leopard doesn't support PowerPC. OK, so then you can run Leopard, which does support PowerPC. But, wait, Leopard is buggy, that's why they're fixing it.

OK, so you can run Tiger (10.4). Well, no, if you're going to be connected to a network you'd be foolish to do that; Apple only issues security updates for the current and previous versions of its OS, and with 10.6, 10.4 will go by the wayside. Within months there will be public exploits for your 10.4 machine available and the time to your machine being compromised is just a roll of the dice.

"Wait," you may be saying, "my machine is less than three years old and it's now unsupported?" "It's still under AppleCare warranty and I can't even get security updates?"

Yep, and there we see the tactical brilliance behind splitting the Leopard and Snow Leopard releases - Apple gets to book its revenue early on a not-ready OS, beat Microsoft to the market, and save a ton of money really only supporting one majoor version of its operating system. So, this doesn't really work out well for you? Just buy a new Mac, they're probably not going to do this again in three more years. Right?

This may be a dangerous gamble for Apple in a recessionary economic period, so perhaps they'll do the right thing and simultaneously keep their customer base. If not, Ubuntu 8/PPC isn't eligible for a commercial support contract but it'll run on your Mac and its security updates will be current for another two years. At that point your machine will be five years old and you can keep it around with debian or netbsd or if we're coming out of the downturn get yourself a brand new machine. By then you'll be so used to Ubuntu you'll have broad purchase options.

From today’s new Macbook announcement:

11:01AM Q: Concern about the glossy screens. Are you going to offer another option?
          A: Steve: We're going all glass -- we won't offer another version. 
          Phil: You offset the reflection by the brightness, and consumers love it. One of the great things about a notebook is you can turn it however you want!

I’ve used a Mac laptop since 1992 as my primary machine and often find myself using it in situations where I can’t actually rearrange the furniture or move the windows (Phil apparently lives in an opaque bubble). So I’ve always ordered a Macbook Pro with a matte screen, because my brain simply can’t see through the glare. Some people can, my eyes don’t work that way.

Yeah, their marketing images actually
show the reflected keyboard

So, today marks the end of availability of new Macs I can use. Since OSX doesn’t run on other hardware (securely) this means I can’t plan on using OSX into the future. I’ll keep a machine around for media work in the short term, but it’s obvious I need to get as much of my work moved over to Linux as possible if I’m going to have hardware that’s current technology.

With Apple’s primary focus on the iPod/Phone market, its draconian tactics there, and its inability to deliver a stable next OS release this is merely the last straw (if it were the only problem I’d consider investing in custom coatings, etc.) Thanks, Apple, it’s been a fun 16 years.

Update: Not just me.

I’ve been writing a short note here after each minor release of Mac OS X 10.5, noting the major problems with it, and 10.5.5 is unfortunately no different. Today I applied it to my main machine’s Leopard install and tried two fairly simple operations:

• delete a partition with Disk Utility
• install Software Updates

The first totally messed up my drive’s partition table, resizing a supposedly untouched partition from 96 to 26 GB, rendering it unusable. The second, applying a half dozen software updates failed on the first attempt, and on the second attempt rendered the system unusable (LoginWindow would keep crashing and re-loading in an endless cycle).

So, I’m restoring my machine from backup now, and will stick with 10.4 (Tiger) until Leopard is as stable as Tiger.

Maybe 10.5.6 will be better, but as of now I’m still recommending clients stay on 10.4.11. A year into Leopard now, and it still has fundamental problems - that Apple has 10.6 (Snow Leopard) planned as a no-new-features release specifically to address architectural problems is a sure sign the issues run deep.

This will sync any attached iPods if iTunes is running:

          #!/bin/sh
          osascript <<_END_OF_UPDATE
          tell application "Finder"
                  set processList to get name of every process
                  if processList contains "iTunes" then
                          tell application "iTunes" to update (every source whose kind is iPod)
                  end if
          end tell
          _END_OF_UPDATE
          

It can be called from a cronjob to keep an iPod updated. iTunes ought to just do this automatically.

Fraser Speirs, former iPhone developer, had his application rejected by Apple on grounds that it might compete with iTunes. Unfortunately for Speirs and every other developer out there, you have no way of knowing if an app will be allowed by Apple until the last step in the development process, unless the app already exists in the Store. This raises the risk for investing in an iPhone app tremendously, meaning few businesses will make the investment, especially if their application is cutting edge. How would you like to invest $200K in an iPhone development project to have it turned back by a fickle screener?

But, I mean, who could have seen this coming in a completely closed and proprietary development environment?

Rule #3 of business - never have your business completely dependent on another business. A well-diversified, well-capitalized business might be able to take this risk, but the majority won’t. Android and Maemo are waiting.

If compiling transcode for macports has you stuck at ‘undefined symbols’ for _mpeg2convert_rgb24 , the problem is that configure isn’t finding the ports version of pkgconfig, so it can’t find the library’s symbols.

The right thing to do is to make transcode depend on pkgconfig, so the ports version gets installed for you. I submitted a patch for this a few weeks, back, and it just got accepted, so expect to see it in the wild in the near future.

Apple has pulled the popular iPhone application BoxOffice from its store without informing the author or responding to his queries.

Some have speculated that it might be at the behest of the data provider (Fandango) but the author clarified, "i'm in talks with fandango right now, and they're thrilled with my app".

Another possibility is that the terms of the iPhone SDK were violated by the publication of the source code for BoxOffice, which necessarily discloses parts of the iPhone API to third parties.

For those wondering if Apple was actually going to enforce the non-open-source aspect of its NDA, this may be the test case that will decide the issue.

Update 2008-10-13: This appears to have been a licensing issue with improper use of data from Rotten Tomatoes. Its owner (now Fox) contacted Apple and Apple 'fired first and didn't bother to ask questions'. Apparently through some back door channels and 10 days later the author was able to contact somebody inside Apple and get the issue resolved. By insisting on playing gatekeeper, Apple is going to take blow after blow on these kinds of problem, simply as a matter of percentages. The iPhone App Graveyard will track the drama.

After coming close to losing a few years' worth of the kids’ digital photos (I had a backup, thank you, rsnapshot, but when I only have one copy it’s close to being lost) I decided to find a good full-time backup hard drive for the wife’s computer. Hers is a Mac Mini running Leopard, and it has the Time Machine backup system (think exactly like rsnapshot, but with directory-level hard links as well). So, I wanted to find a drive that would be:

• Small
• Quiet
• Easy
• Big enough to handle backup of an 80GB drive
• Reliable
• Cost-effective

Now, there are several drives out there that have the capacity. Most are pretty big (physically), and many of them require an AC wall wart and have fans in them. That I didn’t want.

I usually just head over to Newegg and find a case and a drive and screw something together, but they didn’t have any that met the requirements. By this time I had decided that a Firewire bus-powered drive with a 2.5” 160GB drive would be perfect, and I finally found one at MacSales/OtherWorld Computing. These guys sponsor the open source project XPostFacto which lets you run OSX on hardware Apple has abandoned (so that you can connect to the Internet without being pwned). So, good guys, and they have the 160GB OWC Mercury On-The-Go Oxford911 FireWire 2.5” 5400RPM 8MB Cache Portable Storage Solution, which, while a mouthful, is just the right drive for Time Machine backups. I didn't think I'd buy another PATA drive, but the Oxford 911 chipset is really quite well-proven, a nice feature for a backup drive. The drive comes with a cable and a pleather case:

and a CD that contains some software for something I don't need (it would be a nice green move to be able to leave out pleather cases and CD's if they're just headed to the trash heap). I plugged the drive in, the Mac asked me if I wanted to use it for Time Machine, and a few clicks later the backups started running. Nicer interface than rsnapshot, for normal mortals anyway. Now after all that, there are two complaints. First, it's in a very nice lucite case. But the case doesn't have much in the way of markings on it. There's a 3-position switch on the back, and you have to refer to the user's manual pamphlet to figure out what it does. It's a switch for Bus Power/Off/AC Power. I made a label on my label maker so I could recycle the instructions. The second point isn't about the product but the marketing. The box exclaims, "Fits in your shirt pocket!". Here's how well that works:

This particular oxford (not 911) shirt of mine has bigger pockets than any others, and it just fits. When I hear a claim like that, I think of another 2.5" drive I have:

that can almost fit reasonably in a pocket. This isn't a shirt pocket drive - maybe cargo pants. Better to just call it a really nice drive.