Comments from an rPath engineer...

Comments from an rPath engineer...

Thank you for this thoughtful look at rBuilder! I'll first make clear that I'm speaking on my own behalf and not as a representative of rPath, but I hope these comments are interesting and/or useful. I apologize in advance for my typically lengthy comment...

First of all, I'd like to say in particular that I think your last paragraph is spot on; we can get rid of pain regarding distribution incompatibility by making it possible to manage the whole stack intentionally. We're definitely not against compatibility between distributions. We are providing services and technology to help enable building LSB4si, and we have tried to avoid inventing new wheels when existing ones work fine. At the same time, we enable users to escape a requirement to hold to high-level compatibility; we've moved the interface lower and simpler from the developer perspective -- kernel syscall compatibility (for example, deploying on EC2) or even hypervisor compatibility (deploying on one of the many supported hypervisors).

We made rBuilder Online available as a service before we made rBuilder Appliance available for sale as a product. Recently, we have been focusing our efforts on adding some new features to rBuilder Online, so there has been some recent buzz about those new features. This is a platform that's been around and in use for several years now.

Openfiler is clearly one of the commonly-used software appliances built with rBuilder Online. However, rather than use the rPath Appliance Platform Agent (rAPA), the Conary update features were included within the pre-existing Openfiler web console. Most of the appliances do use rAPA, it's just not required and Openfiler has chosen a different path. That's fine by us.

For users interested in rAPA, I'd like to point out that any reader can try out, at no cost, a sample appliance using rAPA, and demonstrating putting custom "branding" on the appliance, by following a tour available at our web site which launches a sample appliance in EC2.

We commonly use hard drive and filesystem images (a standard feature of rBuilder Online) with KVM. Obviously, you can use qemu-img convert if you would prefer to use one of the roughly ten other image types supported by qemu (depending on how you count...) My most common use of KVM for testing involves populating qcow sparse hard drive images with "appliance ISO" CD/DVD images. These use anaconda to lay down the contents of a pre-installed tar image and then configure it, which is extremely fast; most of the time is spent in configuration, not software installation.

Regarding making source code available, that was definitely a design goal of Conary. I personally think that at least the spirit of GPL compliance isn't just about the source code being available, it's also about being able to use it. For that reason, we don't merely strongly associate binaries in a repository with the exact source used to produce the binaries. We also include the exact version of every other package required to build the package, which means in practice that we specify all the bits that need to be on the disk in order to actually build the same thing again. Furthermore, we provide as open source software and ourselves use a build tool that automates this process. We allow project owners to create complete mirrors of their software repositories (source code and binaries both), as well.

I'd like to point out that rBuilder Online is open to more than only open source or free software. Anything that is freely redistributable is allowed (whatever is accordance with our terms of service) so if you have binaries you wish to make available to the whole world without restriction, the fact that they are binaries does not per se prevent you from putting them on rBuilder Online. (With regard to source code -- a source package can contain binaries; you are not required to post your source code to post your binaries. Our source code management enables license compliance, it does not enforce source redistribution willy-nilly.)

Lastly, I'd like to mention to any reader that finds this technology intriguing, we hang out on the #conary channel on the Freenode IRC network. We're happy to answer questions.