Rails is not for fire-and-forget hosting!

in my position of Gentoo Ruby team member (and thus Ruby packager), I’d like to give a couple more insights regarding what Jürgen wrote about on the Diaspora topic. I guess I should be considered weighting slightly more than him not only because I dislike Python myself (which seems to be the base criticism moved to Jürgen) but also because I did work with Rails, and this very blog runs on Rails!

I have some personal grudges with Rails, but in general I don’t dislike the MVC approach they take. Unfortunately, while the theory is often pretty solid, the implementation leaves to be desired a lot. A framework that suggests doing agile “Test Driven Development” and fails its own tests is not something nice to look at. But that’s not the problem at this point.

The first problem sits at the way the Diaspora developers worked on the project; someone else already dissected some of the security issues (some, not all of them, do note); and it shows that whoever wrote the code wasn’t a huge expert of Rails to begin with. Beside the number of mistakes in security ideas, working on the older Rails 2 framework is, by itself, a bad idea; considering they are targeting a “later” release, working on the newer Rails 3 branch would have reduced the possible upgrade headaches in the future.

Here comes the biggest problem of all though: Rails is far from a fire-and-forget hosting framework; while PHP has had a long history of incompatibilities between versions I don’t think it ever reached the amount of incompatible versions between one release and the next. Basically, when you write an application with Rails, unless you rely only on the very basic architecture, there is an almost 100% chance that the application will only work with the current version of Rails; full version of it, so if you write it on 2.3.5 it might not work on 2.3.8. And Typo, that I use for this blog, still only work on 2.3.8, not 2.3.9!

To complicate the matter, the single-version-compatibility problem extends not only to Rails itself (which include its own helper gems, such as activerecord) but also to their dependencies, such as Rack, and to the other gems that the application might require. This is one thing that makes maintaining Ruby and Rails packages in a distribution such a hell. To “solve” this problem, Rails 3 mandates the use of Bundler, which, well, creates bundled libraries in every Rails application. Indeed this “solves” (or to be precise, hides) the problem of different versions of packages for different applications, but at the price of possibly leaving around older libraries for older applications.

One thing has to be told about Bundler at least: it should make it much easier to update an application running on Rails, as it takes care of keeping the dependencies at the right version, without causing all the dependency hell that was happening before. Unfortunately, the dependency hell is not the only thing that makes the upgrade of a Rails application (or, for what matters, any other web application) complicated; the other is migrating the database. Rails supposedly provides tools for migrating the databases in a clean way, but often enough they only work with a subset of the database drivers Rails comes with. This is supposed not to be a problem with the “NoSQL” databases, but I’m sincerely quite sceptic about those. Finally, there is the problem of customisations, even if it’s just themes, since they tend to embed enough Ruby logic to require full porting.

This brings us to two points: updating the dependencies of a Rails app only happens when updating the app and updating a Rails app is far from trivial. This easily translates to “updating a Rails app often enough happens only when the administrator is forced to”; newer version of the interpreter breaking the older application, new hosting, new protocol versions and so on so forth.

And if you am to tell me that Rails is pretty secure a framework, please note that there are at least six bugs in the GLSA Archive since 2006, which means an average of slightly over once an year. I can’t think of many security notices even coming for third party gems, and that makes it very difficult to assess their security status.

Up to now, I don’t think I have seen much of an interest for security-evaluating third party gems, as most of them don’t have so much known use (as far as I can tell, most of the Rails applications out there are developed as closed-source, proprietary web applications, not Free applications). Those who are actually used by more widely used applications such as Typo and Redmine probably undergo more scrutiny, but even those can be considered small fishes (WordPress, Trac, Drupal definitely look much meatier targets). With the coming of Diaspora, especially with its idea of “distributed social network” (see the related post for more details), these gems are likely to become an interesting target as well. Especially the eventually older versions that the Diaspora releases will be looking into.

Do I think a different language/framework would have worked better? Not sure sincerely; I don’t like PHP for many reasons, but I have been told that newer versions have much better frameworks than what we had around version 4.2 which is the last version I actively used. Since PHP is (even more than Ruby) designed to be used for web applications, one should suppose it has gained more and more features to make it difficult to make mistakes, even when that makes it more difficult to use it for general purposes. For what I’m concerned, I doubt Python would get much better results either.

Rails is, in my opinion, a pretty good framework if you actually maintain a web application; it’s not good if you write an application for somebody to use and leave it there. By its own definition, it’s “agile” development, but “agile development” require that you actually follow it. Do you think that the average “Diaspora enthusiast” is going to follow the Agile development cycle, or will just set up an instance and stop caring about updating it when it becomes too difficult?

It’s not a matter of language or framework, it’s a matter of architecture; in a project whose basic idea was to allow each user to maintain its own instance, the choice should have gone toward software that made it difficult to misuse, mismanage or keep out-of-date instances running. In this, they seem definitely to have failed.

Humoristic note of the day: if it proves that my concerns come true, and Diaspora become a vessel for more spam, I’ll be renaming that DiaSPAMora…