rPath Solutions Stage Talk and BOF

The rPath talk was given by Michael Johnson, who is a key developer at rPath. He is very passionate and excited about Conary, and wants everyone who wants to to use it. Conary (pronounced CON-A(IR)-E), is a pretty decent packaging system. Its major improvement over RPM, and in the BOF talk later in the afternoon, he explained how rPath looked at various packaging systems when designing conary.

The slides will be available on http://people.rpath.com/~johnsonm/ when he gets a chance to upload them. Conary does a lot of things auto-magically (such as grabbing the source, and its relatively easy to upgrade packages by simply changing the version number). An example of how Foresight is easily managed, and how they provided the latest Gnome so quickly after its release, were all attributed to Conary.

Conary in general, seems to be decent, and definately worth a look. However, Conary does have a fairly high resource utilization during updates. Ken VanDine indicated it was significant, Michael Johnson said you "would notice it". Conary does most of its work up front, hence the heavy resource utilization, the bigger the update, the longer it'll take. While they did address this issue, they try to quickly gloss over it and move on. While its not a big deal for a desktop solution such as Foresight, it would be a significant draw back for an appliance or server.

In the solutions stage talk, Michael Johnson seemed to directly contradict rPath CEO Billy Marshall's take on JeOS. In the talk, he called it Just Enough OS, enough Operating System to get the task done. Not a packaging solution, but just enough OS! In fact there was no mention of a packaging architecture at all!! In fact, Michael made far more sense that their CEO ever has in his blog. He went on to explain that No OS is really "Forget the OS", how conary makes things so the focus is on the appliance / application rather than the OS. In other words, the developer / user needs not concern themselves with the OS.

This makes far more sense than the "OS is dead", "long live the hypervisor" stuff their CEO spews out. It was nice to see rPath make the same case we've been making for years before they opened up shop - minimal OS (so you're not running things you don't need - security / resources), pushing the idea of enough stuff to let the box do its job, and that shell access isn't really necessary. Even the development approach is somewhat similar to the way AppStacks are built, essentially rMake is very similar to our IBE / RBE method, we just have different approaches for getting the software on there (conary vs subversion / compile), and different delivery methods.

After getting schooled in conary by rPath's finest engineers, I think conary is a good developer tool, and even a good package management system over RPM / DEB. However, the upgrade resource usage, the fact that upgrades are done on the appliance live (if rollbacks are a reverse upgrade, upgrades can take a lot of resources and some time, then rollbacks are likely to have the same problem), and the less secure delivery methods, still make conary a bad choice for server appliances (at least over AppOS).