RAID is scary nowadays. What used to be considered a "must-have" for fast storage with redundancy, is now (with today's ever-larger drive densities) becoming a liability in the form of a ticking MTBF time bomb. Hardware RAID 5 in particular, which was an excellent solution in the days when 73GB enterprise hard drives were considered "large", now gives a very false impression of basic data safety when used with large 1TB+ drives. The topology itself is a liability, because in the event of a disk failure, the thrashing given to the other disks in the array during rebuild increases the likelihood of a second failure to statistically uncomfortable levels.
While in search for a properly state-of-the-art DIY storage solution for my company, I kept hearing about ZFS. The "magic silver bullet" B-tree file system, that self-heals silent corruption with end-to-end checksumming and manages disk devices directly for monolithic high-speed software RAID that is controller-independent. The one that eliminates the RAID5/6 write hole. The one that supports snapshotting and deduplication, that mixes its RAID metaphors within the same volume, that writes in variable-length stripes. The one that brings them all, and in the darkness binds them… no wait, that's a different movie.
Anyway, ZFS is supposed to be hot shit, and has a large contingent of cheerleaders in various corners of the enterprise systems world. It was the brainchild of the Fishworks team at Sun, whose collective accomplishments are too lengthy to discuss at present, but suffice to say they are generally considered legitimate badasses. ZFS was developed to be a key competitive advantage for Solaris in the enterprise storage space, and Sun was well on their way to hitting critical mass with sysadmin mindshare generally, which would have seen ZFS (and Solaris) in a great many environments where it may never have ventured previously. Unfortunately, after Oracle gobbled up Sun they immediately went to work screwing with OpenSolaris and the community development model in ways they shouldn't have, which I won't get into here. To make a long story short, there's now a completely community-built version based on Illumos, called OpenIndiana. I decided to use OpenIndiana as the basis for a high performance, low cost NAS server, and see how far I could go with it in terms of performance and stability on a budget.
Build an enterprise-grade NAS server using up-to-date hardware with at least 100 MB/s sustained reads and writes across the network, via NFS or SMB/CIFS. Both, if possible.
So, you have a Motorola Droid and you've been hearing about all sorts of interesting things that you can do with it, things that aren't necessarily "approved" by our friendly overlords at Verizon. Maybe you're thinking about installing that CyanogenMod thing you keep hearing so much about, but you don't know exactly where to look for guidance and you keep finding a bunch of junk info online that isn't particularly helpful. I hope this guide will help.
Most of the "guides" for rooting the Droid involve manually downgrading from 2.1 to the older 2.0.1 (including radio baseband downgrade), then rooting from within 2.0.1, then flashing a newer system and radio baseband to get back up to 2.1. This is silly, in my opinion. A much better method is to directly flash a rooted "stock" 2.1 image onto the phone with no baseband changes, and then install the alternative 2.1-based build of your choice in a smoothly automated fashion from within the rooted-stock 2.1. So, let's do that.
I have made a few useful notes on the Android system architecture and on CyanogenMod, which I've included at the end. If you're a person that thrives on in-depth "big picture" information, skip to the end and read those bits, then come back and proceed.
The Very Short Story of what we'll accomplish:
- Overwrite stock system with modified stock system using RSD Lite.
- Install modified su for full superuser (root) permissions using SPRecovery.
- Install Clockwork Recovery using RomManager.
- Install CyanogenMod in an automated fashion using RomManager and Clockwork Recovery.
- … steal underpants?
Without further ado… here is Porter's Guide for Root and CyanogenMod on the Motorola Droid.
I have a Sigma SD14 (Foveon sensor DSLR) that I like very much, for all its limitations. Some of you may remember that I had a lot of frustration with the system early on, because of some significant problems with the required workflow to convert the huge/complex X3F raw format into something that can be properly used by standard image editing tools. Well, Sigma has been refining and improving their conversion software constantly, with big improvements in each generation, and with the release of Sigma Photo Pro 4.0 I think they've finally matured it into something truly fantastic. It's what I consider "digital developing", to a level that's well beyond what is normally seen in the Canon and Nikon tools, or even in Adobe Camera Raw.
The new version is (finally) able to fully harness the wide dynamic range and huge color space of the Foveon X3F output and allow some really compelling photographic results from the sensor. It is also now capable of directly outputting full-gamut ProPhotoRGB colorspace images in several formats including 16-bit TIFF, which is fantastic if the next step is a ProPhoto native tool like Lightroom or PS CS4+. Take a look at an example of the kind of conversion control this thing can do, in this case using a very overexposed shot in hazy conditions…
Email to Sigma America
Dear Mr. @@@@,
Thanks for taking the time to speak with me today. As we discussed, I have made a few small discoveries since our original discussions several months ago, that may shed some light on the red channel overexposure that I have experienced in certain situations using my SD14. Rather than a capture problem in the camera, I have discovered that the issue may be related to the color-space conversion performed by the Sigma Photo Pro software during X3F import.
I have attached two versions of an image, one that illustrates the color issue that I have experienced in scenes that push the limits of the color space (gamut) used in the current Sigma Photo Pro 2.5 software. The difference between these images is obviously intended to represent a worst case scenario, so please don’t regard the “original” over-saturated image as the work of a talentless hack — it is purely for illustration purposes!
Click to read on –> More >
I’ve added a number of good Sigma and SD14-related links over in the right-hand column. Eventually I plan to grow this into a central resource for SD14 information, and mirror it to an appropriate domain name.
Give me a shout if you find something good that’s SD14-related on the web, and I’ll add it to the list!
As we discussed on the phone, I am writing to document my new SD14 camera’s unusual red saturation problem and provide raw X3F samples for your review.
Before I explain, here are the details of my particular unit and configuration:
serial no. [redacted]
firmware revision 1.07
Sigma 18-50mm F/2.8 EX Macro
serial no. [redacted]
Using Sigma Photo Pro 2.5 in Windows XP, using a color-corrected display (Spyder2Express calibrated).