While I agree that RoR is pretty damned hard to use in a shared environment, I'll point out that it is definitely possible. It took Jamie a couple of weeks to get it all spinning...but Virtualmin can spawn mongrels, configure load balancing in Apache, and still keep it all running as the user (making it safe for shared hosting environments). Several of our customers have it deployed...and while the load of the RoR stack is significantly higher than PHP (or Perl/Python) under mod_fcgid, it can be done safely.
Rails really exposes the overselling that occurs in most shared hosting environments. Though this isn't by any means praise for Rails, it does explain why a company that with massively popular shared hosting might be annoyed by it.
I don't mean this as an indictment of Dreamhost. I recall when I first started experimenting with Rails (years ago, pre-1.0 IIRC), Textdrive somehow had this reputation of being "the Rails host." This was probably a combination of the Textdrive folks giving some early sponsorship to Rails while having one of the more customizable shared hosting environments available. Anyway, imagine my surprise when I found that one could not reliably deploy a Rails app of any substance (even apps developed by Rails core members) on TxD's shared hosting because they kept killing the processes due to memory overages! Though it's understandable from a business perspective why there are process (and, more generally, resource limits) for shared hosting, it's also an absolute disgrace for a hosting company to imply that one can run Rails on its shared hosting when their policies preclude it and then all but call customers cheap for not wanting to upgrade to a $150/month plan just to run a basic app.
I don't know that that's an entirely fair assessment of TextDrive (and not just because they're a customer of Virtualmin). They were pioneers in running Rails in a shared environment...and the Rails development community is hostile to shared hosting (perhaps because, like RoR exposing "overselling" in the hosting industry, shared hosting exposes the extreme resource usage of most RoR deployments). So, it has always been an uphill battle, and until you've actually had to fight that battle, it's hard to imagine just how ornery it is. That it took them a few months to work out all of the issues shouldn't be damning evidence against them. It was untrod and undocumented territory, and the fact that two years later most hosts still don't offer it ought to be enough evidence that the hosts that can offer it safely are above average in their technical savvy (or Virtualmin customers...).
The 'problem', as it were, with Rails is that it occupies a fairly large chunk of memory. It does a lot for you, but that comes at a bit of a cost in terms of memory usage.
Really, this should be a mea culpa, but instead it's a rant. Dreamhost was too ambitious in trying to offer Rails hosting given their legacy infrastructure. And now they're punting.
So why did they support RoR to begin with? "Ruby on Rails seemed to really fit in with our company philosophy and we thought our existing customer base would love it." Okay guys, so what have you learned here?
