Multithreaded

I just bought a Drobo to make use of a bunch of old drives I have lying around. I’m a big fan of redundant storage systems but my recent experiences of using an Apple RAID card in my MacPro have been less than satisfactory. The performance was not as good as I’d expected, it takes ages for raid arrays to initialize and I was getting a lot of problems with the system not coming out of sleep so I decided to ditch that.

I ordered the Drobo from Expansys on Thursday and it arrived on Monday. Today I pulled it out of the box and set it up. Firstly, the unboxing is quite a nice experience in itself, comparable to opening an Apple product. The all-black interior of the box, complete with black foam and a good quality black fabric bag on the Drobo itself, all lend an air of quality to the experience. There is a bit, three-step, getting started guide on the cardboard cover and all the cables and accessories are laid out in a separate tray.

So what of the device itself? The unit is smaller than I was expecting, just large enough to take four drives. It has nicely rounded corners and a very solid feel without beeing excessively heave. The front panel is held on by magnets and is removed with a gentle pull to reveal the drive slots. These have spring-loaded flaps on them and inserting drives is simply a matter of sliding them in until they click under the restraining clips. The Drobo takes any combination of SATA1 and SATA2 3.5″ drives. I put in a 750G, two 500Gs and a 250G.

The Resource CD has tools for both OS X and Windows. I was installing on a Mac which was just a matter of running the installer program for the Drobo Dashboard. The Dashboard provides several useful views of the device configuration from the overview:

to the more detailed status:

Following installation, the software offered to upgrade itself to the latest version, which it did with no fuss. Then it asked me to plug in the Drobo USB cable and it set it all up automatically, only pausing to ask if I wanted FAT or Mac OS Extended format. Within about two minutes I was up and running with 1.1TB of free space, all fully redundant spread across the 2TB of drives (1.8TB actually usable). This is far more impressive than the half-hour or more it usually takes to fully initialize a RAID array.

All in all, I’m very impressed with the device and the setup. The next test is how well it performs. Clearly the USB 2.0 connection will be a limiting factor here, but I’ll keep an eye on it to see how it goes.

Update:
Mind you, given this announcement, perhaps my timing for buying one was not so great.

Just been listening to the March 14th newscast from the JavaPosse where they spend a lot of, very interesting, time talking about the new SDK on the iPhone and the apparent restrictions in the terms and conditions which prevent people from distributing apps which run on a VM. This would mean that developers could not distribute Java applications which required the VM to be present to run. They discuss a lot of interesting points, and speculate a lot on the motivations, sinister or otherwise, of Apple in deciding to limit developers. Obviously, not being Apple, they’re not able to draw a lot of definite conclusions.

I’d like to offer a different perspective on this issue. As developers, we see the iPhone as a development platform with huge potential. Since the moment it was released, I’ve been wanting to have other apps running on it. It makes a great connected device and it’s easy to compare it with other, open, platforms such as the Nokia N800. However, I believe Apple did not create the iPhone, and are not looking at it, as a device for developers. This is a consumer device, first and foremost. Apple’s priority at all times is that someone who has bough an iPhone, as a consumer, should get the best possible experience all of the time and if that means that developers are left frustrated then so be it.

I think that the directive against VM-based apps it based on this principle. Apple do not want people to come browsing the software on the iPhone store, seeing something they like and then being told they need to download one or more other components in order to get it to run. Or worse, downloading (and perhaps paying for) an app only to find it won’t run because they didn’t know that they needed to download (and possibly pay for) another component before it would run. Supporting this in the iPhone store would mean dealing with dependencies between components and then you get into all the problems of version handling - what happens if I have the Java 5 runtime installed but another app needs Java 6?

Looking at my experience of using a Nokia N800, it was great that it is a very open device and that there are lots of third-party apps for it, but my experience of installing those apps was often frustrating as I needed to locate libraries that those apps depended on and download them separately. Even as a programmer I found it very annoying and tedious. I can well see that Apple to not want that to be the experience of the average user who expects things to just work.

In fact, I would not be surprised if Apple did not take “it just works” as their yardstick for deciding how and when to open up aspects of the iPhone. As the JavaPosse discussed, the delay in releasing the SDK was probably not down to not wanting people to develop for the iPhone, but rather taking the time to ensure that the experience the developers have is a great one which probably meant considerable cleanup of the libraries and tools between the launch of the phone and the release of the SDK. For iPhone users they are going to be even more stringent in applying that principle.

Of course, another aspect of that is that they would want all apps on the iPhone to be as consistent as possible in their look and behaviour. The first part of that is the visual component library which means getting people to use the native SDK as much as possible. The second part is the UI guidelines, but Apple developers are usually pretty good at sticking to those. I have used Java apps on Symbian 60 phones and generally they look and behave very differently from the native S60 apps which can cause a lot of confusion and just be downright annoying sometimes. Again, a situation Apple would love to avoid on the iPhone.

In conclusion, I think that if you take a step back from your developer viewpoint and look at the iPhone SDK and software distribution system from the point of view of a consumer then Apple’s behaviour seems a lot more understandable and a lot less sinister.

This is just awe-inspiring (for any self-respecting geek, that is)