I’m trying to update CS5 using Adobe Application Manager, and I’m getting the following errors… (read more »)

Firesheep is a Firefox extension that allows users to steal login cookies on popular websites, which allows the user to login as you if you are browsing on the same network. It was release last week and has already forced sites like Facebook to issue statements addressing security. I downloaded it just now to test it out, and ran it while I logged into Facebook, Gmail, Amazon, Twitter, and other sites I frequent often. Here’s what Firesheep sniffed out:

Firesheep can login to a lot of the sites I use

Double clicking on an avatar or account in the sidebar immediately opened a browser session as me, logged into the website shown. Anyone running Firesheep on an open network can sniff out and login as anyone on the network who is actively using the websites Firesheep knows about. (read more »)

I hooked my MacBook Pro to a Panasonic 58″ 3D plasma display today and fed it a 3D video in the form of side-by-side video content. The good news is that the display showed a perfectly good 3D image when told to expect side-by-side content (yay!). However, there was a problem with my stereo 3D video: for some reason, all of the 3D content was pushed way back past the stereo window. The only way this would happen is if the left and right video content were diverged; upon closer inspection, it was obvious that this was the case. (read more »)

There are 4 Macs in my house. I use two of them for work and one as a server and media center for the occasional video or TV show (the last Mac is Pam’s). All of my media is stored on a NAS box that supports just about every protocol out there, and since every computer in the house is a Mac, I use AFP to connect to it. A few weeks ago, the Mac Mini that acts as the media center and server started slowing down. All Finder actions were sluggish, and opening folders started to take a few seconds (even on local disk). Opening folders and files on the NAS box (connected via AFP) suffered the most, and the Finder would sometimes take 30 seconds or more to return. Sometimes, files in networked folders would never show up, leaving folder windows empty (and spinning). Obviously, streaming video files from the network became impossible to do.

Meanwhile, access to the networked files from all of the other Macs in my house was as snappy as ever. In fact, I started copying files from the NAS to the Mac Mini by mounting both volumes from a third machine and copying between them (using AFP) — terrible, I know.

On a whim, I unmounted all networked volumes on the Mac Mini and re-connected using SMB. Problem solved — everything is now as fast as it used to be. Why is it that 3 machines (Mac Pro, Macbook Pro, iMac; all running Mac OS X 10.6.4) connect just fine to my NAS box using AFP, but one (Mac Mini Server running Mac OS X 10.6.4 Server) must be connected via Samba for suitable performance?

I’ll suspect that I’ll never know.

Tonight, I tried copying a Parallels 6 virtual machine from one machine to another. I was greeted with the message, “The virtual machine cannot be used because its files are corrupted.” OK, maybe there was a problem with copying over the network. I copied again, and received the same error. There is no option to actually try to recover the VM; the only options are to “remove” or cancel.

There is an easy fix: you simply have to remove the virtual machine from your list of VMs and re-add it. The easiest way to do this is to click “Remove” when the error message presents itself and double-click on the VM again. Parallels then asks you (correctly) whether the VM was moved or copied, and starts up without errors.

Nice error handling, guys.

Karel the Robot keychain gift at CS198 reunion

On August 13, 2010, Professor Eric Roberts and Mehran Sahami, Associate Chair of the Department of Computer Science, sent the Stanford CS198 alumn list an email inviting them to a reunion of undergratuate section leaders, TAs and program coordinators — the first such reunion in 40 years of teaching introductory CS106 classes. (read more »)

For an email client, I use Mac OS X’s Mail.app, which I’m perfectly happy with (in conjunction with Mail Act-On, which I find to be indispensable). To access my various email accounts, I use both POP and IMAP; each offers me something the other does not. (read more »)

I just returned from a trip to the Bahamas, where I shot and posted a bunch of 3D underwater video encoded for viewing with red/cyan anaglyph 3D glasses. When I arrived at home, I opened one of the 3D videos on my calibrated 30″ Dell 3008WFP LCD (connected to a Mac Pro)… and discovered that I could not see any 3D effect. It was quite strange because I could see the 3D effect perfectly when I streamed the same videos from my Vimeo page (on the same machine/display), and everything looks good when played from my MacBook Pro (even when it is attached to an external monitor). I even tried playing the videos back on my 50″ plasma display, and the 3D was fine.

What I discovered is that if you have a properly calibrated video card / monitor, you may not be able see anaglyph 3D-encoded images and video correctly. When trying to render colors “correctly,” ColorSync can change the colors enough to destroy the effect. (read more »)

I’m a big fan of CrashPlan, which is sort of like a platform-agnostic Time Machine with full internet support (minus the pretty star field graphics). I use it to continuously monitor and back up two machines (Mac Pro and MacBook Pro), and when I’m travelling, but MacBook Pro continues to back new files up — to a machine in my closet — through the internet.

I have CrashPlan+ licenses for the two machines I back up. CrashPlan+ doesn’t exist anymore, but it seems to give me some of the features of CrashPlan Pro like compression, encryption, and real-time monitoring of file changes.

Now, for the bad news: CrashPlan works really well when I have one machine backing up to another, but fails miserably when I have two machines backing up one machine. My MacBook Pro always backs up perfectly to the destination, but my Mac Pro stops after some time (usually works until I stop the initial backup, at which point it never starts up again).

I’ve tried:

• starting and stopping the CrashPlan engine
• setting each instance of CrashPlan to a different port
• reinstalling CrashPlan
• reinstalling the OS
• following directions sent from CrashPlan support (multiple times)

Each time, CrashPlan support says that it “must be a network issue,” but can’t figure out why it’s not working. I think it might be because I’m backing up multiple terabytes.

A few days ago, I realized that I was being stupid because I’m backing up my Mac Pro to a NAS volume that is mounted on the server. The server isn’t even necessary for my Mac Pro backup, since the 55-lb machine never leaves the house! So I’m now pointing my CrashPlan backup directly at the volume on the NAS box. The MacBook Pro is still happily backing up via the server.

I hope it works.

I recently acquired a Fuji FinePix REAL 3D W3 point & shoot camera, which is the only (proper) 3D point & shoot camera on the market (Mark Blum showed me the W1, its predecessor, some time ago). The camera stores still images in MPO format, which is essentially two JPGs, thumbnails and metadata crammed into a single file. It stores video files in a stacked AVI format called 3D-AVI.

New file formats are always challenging to deal with, especially if you’re on a Mac. Fuji ships the camera with its FinePix software, and after installing it, I realized that it has no 3D support because the Mac version is two major revisions behind the Windows version!

I went online looking around for MPO and 3D-AVI support for the Mac. Things aren’t looking so good. (read more »)

I’ve been using ReadyNAS products since they were still being sold by Infrant, but it wasn’t until the latest iteration that they became incredible performers. The Netgear ReadyNAS Pro has 6 SATA drive bays and funcations as just about every kind of server one could want (for a home office, that is).

My first ReadyNAS Pro has 7.89 TB accessible (1 disk redundancy), and is being used as a backup volume for 4 separate machines. SuperDuper! clones volumes to disk images hosted on the NAS, and it also serves as a Crashplan repository (through a Mac Mini running Mac OS X Server). The NAS also hosts all of my media (e.g. videos, music, installer disk images), serving media through shared volumes and various media servers (like UPnP to a Playstation 3). (read more »)

After some light prodding from Jauder, I set out to optimize my Mac OS X 10.6.4 (Snow Leopard) network settings. There is a lot of information out there about how you might optimize a Mac OS X network, but I couldn’t actually find any benchmarks. (read more »)

12 hyperthreaded cores!

My new 12-core Mac Pro is almost ready (it’s been copying files from my other machine for nearly 24 hours now). I re-ran a MPEG Streamclip vs. Compressor test and was pleased to discover Compressor is now insanely fast because it can be configured to use all of the cores. MPEG Streamclip doesn’t seem to multithread properly to use all 24 virtual cores when only batching up a few clips. I set it to 4 instances, and combined processor usage was around 270% (out of 2400%). Running the Compressor job against a local QuickCluster resulted in CPU usage illustrated in the screenshot above.

SSD installed on 6th internal SATA port, Mac Pro (July 2010) 12-core

In 2007, I stuffed 6 drives into my Mac Pro. Over the years, I replaced 2 of the 1TB drives with SSDs (an Intel 160GB X25-M and a SuperTalent 64GB for swap) and 4 of them with 2TB drives, but I’ve now been using some sort of 6-drive setup for 3 years with great results. I’ve finally replaced my aging Mac Pro with a new one; as usual, subtle changes inside the Mac Pro case have made things more complicated. (read more »)

I’ve been testing iSCSI performance for the past few days using an iSCSI volume on a ReadyNAS Pro (a 6-bay dual-gigabit NAS box). I’ve got the ReadyNAS Pro configured with 6 drives (of varying capacities between 1TB and 2TB each), and am running a dedicated gigabit line between the 2nd port on my Mac Pro and the 2nd port on the ReadyNAS Pro (bypassing routers/switches altogether). This is the preferred method for connecting to iSCSI targets.

Read speed is as expected, ramping up until it maxes out at around 102 MB/s (megabytes) for large block sizes. Write speed, however, was all over the place. The iSCSI target would time out for periods in which there was no traffic going over the network, resulting in inconsistent performance. Running the benchmark multiple times resulted in totally different write results.

Note that this is a real world test scenario. I have 5 machines connected at all times to the ReadyNAS Pro and have Crashplan backing data up to it constantly, as well as multiple cron jobs rsyncing data from web servers. This may be why write performance is so inconsistent, and provides a good argument for using a dedicated iSCSI box for primary storage.

One of my biggest complaints in earlier versions of Mac OS X (pre-Snow Leopard) was the dreaded network timeout. For example, if I was working on a notebook computer while connected to a networked volume, I could cause a multi-minute timeout (SPOD) for ~2 minutes simply by putting my computer to sleep, disconnecting my network connection, and resuming my session. Eventually, Mac OS would time out and unmount the inaccessible volume, but during that time my machine would be locked up.

When Mac OS 10.6 (Snow Leopard) came out it seemed to fix this problem, but lately, I’ve been experiencing similar network timeouts in Mac OS X 10.6.4 (Snow Leopard). I can reproduce it by doing the following, with 2 machines:

Machine A connected to network via hard-wired ethernet. Machine B connected to network via WiFi.

1. On machine A, mount a volume on machine B via AFP
2. Disconnect from WiFi network on machine B (and disable WiFi)
3. Connect machine B to router via hard-wired ethernet (it gets a different IP address via DHCP)

Machine A will then time out for at least 1-2 minutes (SPOD). When timeout expires, the shared volume is unmounted and my machine becomes responsive again.

Anyone have a fix?

I’ve been cursing AVCHD ever since it started showing up in camcorders and still cameras that shoot video. I don’t really understand why it exists. Although its file and folder specification claims to be compatible with Blu-ray, it doesn’t seem likely that the majority of casual video shooters will choose to archive video content from cameras directly onto Blu-ray discs, and AVCHD’s awkward multiple-folder storage structure makes it extremely difficult to work with in video editing workflows.

Some cameras save video directly to MP4 files or have the option to do so (everyone video person I know loves this). But on many cameras (e.g. Sony Cybershot TX7) the highest-quality video format is AVCHD-only. Frustrating! (read more »)

I’ve been intrigued by iSCSI for some time now. I currently have a ReadyNAS Pro with 6.5TB of usable, redundant storage space. Today, I created a 20GB iSCSI volume on the ReadyNAS Pro and used globalSAN to initiate a connection from my Mac Pro (partitioned and formatted using HFS+ Journaled). I copied 10GB of Canon 5D Mark II RAW files to the volume and imported the images into a Lightroom library (stored on my local file system).

After using the library for a little while, I have concluded that I cannot tell the difference in speed between storing my images locally and on an iSCSI volume on the ReadyNAS Pro. In theory, I could store my entire RAW image archive on the NAS box and work off of the network.

There are two issues stopping me from going with this set up:

1. I’d have to set up an additional NAS box to back up the working NAS box. I’m too paranoid to be comfortable with storing files on only one machine, even if it uses a RAID.

2. The ReadyNAS’ maximum iSCSI volume size is 2TB. I don’t like managing multiple volumes, and would rather have a single large volume.

At the moment, my Mac Pro contains two 4TB data volumes plus SSD boot and swap disks. Crashplan continuously backs up my data volume to the NAS, and each night, the data volume is automatically synchronized to the local backup volume (that’s three copies, locally).

Since I’m about to exceed the capacity of my current (local) 4TB data partition, I may end up just changing my RAID configuration to a single 8TB stripe, which would be backed up to my NAS box over gigabit (traditional share — not iSCSI). Having good backups makes me feel secure using a 4-disk stripe, and since I’m starting to do more video work, the local speed boost would be useful.

In any case, it’s good to know that iSCSI is an option for the future — it’s certainly less expensive and complicated than setting up a SAN over Fibre Channel (which I’m wired for). When the ReadyNAS supports >2TB iSCSI volumes, I may go that route.

I recently expanded my ReadyNAS Pro to 6.422 terabytes! It took 2 days because I had to add the two 2TB disks one by one, but it’s finally (almost) done.

Now, dare I convert the data volume on my main machine from 4TB to 8TB? At the moment I have two 2-disk striped volumes that are 4TB each. One backs up to the other every night, which provides peace of mind (along with ReadyNAS backup, that’s 3 spinning copies of important data in-house). I could stripe the four 2TB drives in my main machine into a 8TB volume, but I’d have to upgrade the ReadyNAS again to provide enough local backup space.

The other solution is to wait for bigger drives to come out, but I only have 100GB left on my main data volume — I’m cutting it close. I could also investigate using iSCSI and dual-gigabit LACP…

Today, I went through one of my old Aperture libraries and fixed some of the corrupted image entries. This post addresses the specific case of referenced files in Aperture spontaneously pointing themselves at other images on the disk. In my case, I opened up an old library from 2 years ago, and 61 images spontaneously pointed themselves at images I took just a couple months ago.

I didn’t have time to manipulate the SQLite database directly, so I had to re-import the corrupted images manually. (read more »)