Great concept, terrible implementation

I’ve mentioned rPath before, as it is the basis for OpenFiler, and other appliances. Now with the mad headlong rush into the misty vapors of cloud computing, they are rebranding as a cloud appliance provider. Their concept is great. Create a functional software appliance, run it everywhere. Thats not what i am going to complain about. Its about the implementation. [rant mode full on] Its always about the implementation. As the implementation is the thing that drives support.

Ok. So you have this brand spanking new OpenFiler distro. It is based upon rPath. You install it on your new hardware. Only to discover, no driver for some aspect. No problem. You are proficient at pulling down drivers, and building them. So you pull down the driver. And you try to build it. Ok, oversight. No compiler. No problem though, as surely, without a doubt, there is a compiler overlay bit, that allows you to do something as esoteric as building a driver you need. Right? Right? If you are on rPath, the answer is an unequivocal “no”. Lets take the case I am dealing with right now. OpenFiler ships with an older driver for a RAID card. We need to update it. It is crashing for the customers, and this is a known problem, with a known solution. You update the driver. Solves the problem. Can you do this on rPath (which OpenFiler is now built upon)? No. You cannot. Read that carefully. You cannot. Its not that you are not allowed to. You, in the truest sense of the words, lack the ability. This is not a slam at OpenFiler. It is a reasonable product for what it does. That you cannot update it, is not OpenFiler’s fault, its the thing under OpenFiler that prevents this. It would be to rPaths credit, if they created a “BUILD DRIVERS HERE” image, which allowed you to, curiously enough, BUILD DRIVERS HERE and import them over to the appliance. Remarkable concept. Because, otherwise …. … anything based upon rPath is effectively unsupportable in the face of driver updates, security updates, etc. Sure sure sure… its an appliance. Its a black box. Who wants to update a black box? Maybe a customer who has a known problem, with a known solution? Is this possible? Yes? Yes? Yes yes … conary update (don’t get me started on conary … I see so many supposedly better mousetraps built to solve largely non-existent problems … ) will let you … … update whatever is in the latest repository. But if your driver isn’t there, you are SOL. Your choices are stark. First, you can, as is suggested in the OpenFiler fora, simply downgrade to supported hardware. Second, you can abandon OpenFiler (and rPath). I’d really like that third option. Download the BUILD DRIVERS HERE appliance. I just pulled down the devimage appliance, and hopefully it or the app2app will provide what we need TO BUILD THE DRIVERS. Either that, or I could simply pull the right source, find the identical gcc version, build that somewhere else, and then build the driver against this. At least they haven’t taken away ssh (yet). [end of rant] The concept behind rPath is very good. Its the implementation that is lacking. The JeOS and other initiatives, where you don’t actually have to give up your tool chain if you need it (e.g. you can pull it in) is a better implementation. Then again, rPath demonstrated that, unlike Redhat, you really really don’t need such a huge install radius on your systems. Your installation radius as a function of how wide your dependency trees are. If you want to do network boots, or similar things, smaller is better. Appliances? Smaller is better. This is the concept behind the modular Linux that was being pushed some years ago. It is a good/correct approach. Crippling the install so that you cannot fix a problem in the field forcing the customer into a different solution? No so much a good idea. (yeah, in case you didn’t sense it, I am annoyed by this)