86 Comments »

RSS feed for comments on this post.

Pages: [1] 2 » Show All

1. 1

   Well stated. I’m a Ruby on Rails developer myself, and tried deploying on Dreamhost in the early days. It worked, but I can’t say that it was a pleasant experience, and eventually I decided that it’s just not worth it to mess with Rails unless you have root. VPS services are gaining ground here.

   Rails deployment has been a sore spot for a long time, so maybe after all the ruckus that Zed Shaw has stirred up, someone will seize the opportunity to replace his fame and ask, “Why do we need to proxy to this Mongrel thing again?” and either a) improve fcgi support in Rails, or b) made mod_ruby into something formidable for Pete’s sake.

   Comment by Brent — January 7, 2008 #

2. 2

   How true it is. We recently moved a project from rails to .net mostly for deployment issues and the lead developer happens to be a better .net coder. And the next version of a certain high profile extremely high performance rails app has been written with almost all custom c code and php.

   Comment by Thomas Aylott — January 7, 2008 #

3. 3

   As the one who maintains the Rails packages here, I have to agree with Dallas. It’s a PITA. Adjusting the Rails gems to Debian packaging often feelings like pounding square pegs through round holes.

   Plus there is the recent frustration with the framework files that had to be altered just so people could freeze their rails. If we had just one server to maintain it wouldn’t be that big of a deal, but on a larger scale it’s a pain. It also seemed like a very dumb bug introduced into something that should just work.

   Comment by Terri@DreamHost — January 7, 2008 #

4. 4

   PHP and the likes are CGI-style application “frameworks”, and as such they of course do not require much resources.

   However, on the other side of the fence, with actual *application servers* (such as RoR, TurboGears (which I use), TomCat, …), by definition you cannot be lightweight — there has to be an application server running in the background.

   The best way is to use a proxy setup, which you now have, *except* for the fact that you cannot proxy it at the root of your domain…

   +- 0 to DreamHost. :/

   Comment by Mikael Jansson — January 7, 2008 #

5. 5

   But most of the time, I don’t want to run an “application server” or framework or anything like that. I want to type some code into a file and run it. I sometimes get frustrated with PHP and start investigating alternatives, but when I see all the nonsense I have to go through to get a Django or Rails app running, I give up.

   I personally hope ECMAScript 4 catches on on the server side… I love its syntax. However, whatever language that wants to make it big is going to need PHP’s stability and it-just-works-ness if it’s going to catch on at anywhere near the same level.

   Comment by Albright — January 8, 2008 #

6. 6

   Too true, Dallas. I’m glad to hear that Dreamhost is aware, and grateful to hear that communicated.

   I have two Rails sites running on Dreamhost and each has been an incredible pain to deploy. All supposed time-saving that comes with using a framework like Rails was very quickly nullified when deployment and maintenance was factored in.

   Comment by Alex — January 8, 2008 #

7. 7

   My $0.02 on this issue:

   1) I used to be pretty animate about my Dreamhost citizenship. But now I’m mostly done with Dreamhost exactly because of the Rails deployment issues I ran into. While Dreamhost is great for hobbyists, career programmers should probably subscribe to a VPS.

   2) That said, let’s not expect Rails to fill the same role that PHP does. Rails is providing a place in the marketplace for alpha-geeks who are constantly pursuing the bleeding edge. This is why API constantly breaks backwards incompatibility. Compare that to PHP 4 still running on the majority of the web servers these days, despite the maintainers warning of deprecation for some time.

   Comment by Robin Hoode — January 8, 2008 #

8. 8

   I would like to mention that there’s a clear difference between a programming language (which PHP is) and a framework (which is Rails). Of course you can do all type of web applications just with Ruby, without a framework, and it’s gonna be fast (well, sort of). But your development process will be slower because you don’t have ActiveRecord and all the other cool things Rails offers.

   I’m happy that Dreamhost supports Rails but I have to second Robin’s statement, if your really wanna run a Rails application in production, use a VPS.

   Comment by Christoph — January 8, 2008 #

9. 9

   Christoph, let’s be real here; how many people out there are really building Ruby web apps without Rails? (Or Ruby apps at all, for that matter?) Is such a thing even possible on DreamHost? And I’m not saying that as a Ruby hater; I actually think it’s quite a pleasant, if occasionally overly-cute (”string” * 3 = “stringstringstring”), scripting language. I’m just tired of the glassy-eyed Rails fanboys trying to complicate my life with “The Rails Way” — these people make even the most religious of us Mac freaks look normal in comparison.

   Yes, I’m well aware of PHP’s weaknesses, but until something else comes along that has the same level of it-just-works-ability, I’ll stick with it, both for work and pleasure.

   Comment by Albright — January 8, 2008 #

10. 10

    I think that most people do not care about the difference between application servers and cgi style frameworks, but it is a very important difference that they have to deal with anyway. I mean how many people request tomcat or custom java servers from dreamhost shared hosting?

    I also think many people are forgetting eruby, which is exactly what most people probably want. It lets you use ruby code just like php code. The only problem is that everything is instantiated every request, so just like with php, you gotta lazy load everything (which is very possible).

    I don’t think rails needs to change it’s deployment model too much (it is meant for vps’s with monit running and stuff like that and I love it), but other frameworks in different styles will fill those other gaps.

    I would love a eruby framework that lazy loads database stuff and lets me use haml. I suppose I should get started on coding that up.

    Comment by Nathan — January 8, 2008 #

11. 11

    Albrigt, how many people are building apps with PHP without any framework? I did it and I don’t use a full fledged framework for simple websites (eRuby does a pretty good job here). I’m aware that Rails is complicated to deploy (at least for the first time) and it’s slower than other solutions.

    Comment by Christoph — January 8, 2008 #

12. 12

    I like PHP it makes me smile and feel like oooo free as a birdddddddddddddddd.

    Comment by Jimminy Cricket Esq. — January 8, 2008 #

13. 13

    Christoph, I’m not sure if your question is rhetorical, but if so, then people are building sites without a framework all the time — or, at least, nothing as rigid or feature-packed as Rails. I recently started doing a lot of coding in Drupal, but even that isn’t something I’d call a framework — it doesn’t have database structures. Rails-like frameworks exist in PHP, but few people use them.

    I’d never heard of this “eRuby” before. I’ll look into it.

    Comment by Albright — January 8, 2008 #

14. 14

    Meh, I’d be happy with mongrel at DreamHost. I really like the service and all, but I need to do more and more rails work and I’m afraid I’ll have to switch away to another hosting solution because of that. :o(

    Comment by Samo — January 8, 2008 #

15. 15

    This blog post just goes to confirm my worst fears. Anyone who works with Rails knows it can be hard to get it running and keep it running. With that in mind, I’d expect a host with the size and resources of a DreamHost to be actively trying to solve the problem though instead of crying about it on their blog. There are plenty of people who are working their asses off to make Rails work better and faster (cough http://rubini.us/ cough), and some other high profile hosts like Engine Yard (disclaimer: I’m also an EY customer) are backing these initiatives.

    Now, I don’t expect DreamHost to have an EngineYard-like level of support, especially when you consider the cost differential and the scope differential of the two companies. What I do expect is for DreamHost to pick a horse already. Either support Rails properly in your basic plans, or jump ship and make it pay to play. If it’s going to be on the “invite only” PS plans, then so be it. At least we’ll know rather than sitting around refreshing my RSS reader to see if DH is supporting Mongrel yet.

    Comment by Bob Sherron — January 9, 2008 #

16. 16

    >> “we are working on additional support for it to be tied in with our DreamHost PS plans”

    I would absolutely love the idea of offering additionally selected software support for Dreamhost PS.

    Such as: NGINX web server, memcache RAM caching, and PHP APC for PHP bytecode acceleration.

    Comment by Frank B. — January 9, 2008 #

17. 17

    It might come across as elitist, but just about anyone who contributes to rails or releases open source ruby projects, will at least have a VPS in their pocket if not many dedicated servers.

    Getting Rails to work in shared environments like DreamHost is waaaay low on the totempole for the ruby/rails contributors.

    I think it’s up to you guys to fight the good fight on this one.

    IMHO, rails is such a customized beast that it would not work will intermixing with other DreamHost apps (PHP, etc).

    It almost needs its own custom control panel:
    * subversion URL to checkout from
    * # of mongrels to use
    * ngix tweaking
    * etc
    .. with the ability to SSH in and tweak additionally.

    Comment by Shanti Braford — January 9, 2008 #

18. 18

    I was a longtime Dreamhost customer as well, but it was this problem with Rails that finally got me to move on to something else.

    I ended up putting a Mac mini in a data center and it has been great. All the benefits of a dedicated server, but a much lower price. (I ended up going with Macminicolo.net…$35/mo)

    Perhaps someday I’ll look at Dreamhost again.

    Comment by Peter — January 9, 2008 #

19. 19

    Too many things come to mind about this post. For one thing, why? Why does Rails needs to be like PHP? Besides that you are comparing a language with a framework I personally just don’t see a good reason why RoR should be like PHP. At all. I can see how it would make your life easier but I’m not sure what it will really gain for everybody.

    Second, you might want to check your facts. In Zed’s rant he states that DHH’s app _had_ a large problem with restarts. again, had. Your statements say that it _has_.

    “Zed Shaw mentions in his rant that even the Ruby on Rails application run by DHH (the guy who wrote Rails!) _has_ regular issues and needs restarts several times a day.” (emphasis added)

    Third, have you even tried running Litespeed? Even the free version has great, out-of-the-box support for running Rails apps. And if you are willing to pay for the Enterprise version it even has support for hosting companies like yours. Are you willing to spend the money/time and try it?

    I’m sorry but this whole article, although it points sove valid arguments, leaves me with a lemony, whiny taste in my mouth.

    Comment by Adrian Madrid — January 9, 2008 #

20. 20

    I think the main sticking point has been touched on by a few commenters but not made explicit. We all hear the “Rails is a framework, PHP is a language” chorus, but the real point is that PHP is a language the way ColdFusion is a language, i.e., very explicitly targeted to web applications. Ruby, Python, Perl, et. al. are not. Sure, you can do shell scripting and console apps in PHP if you’re sufficient masochistic, but the damn thing’s been designed from the start to run in the context of a web server.

    The problem in practice is that the things that would make Rails less of a PITA to deploy for a shared hosting provider aren’t really things about Rails. They’re things about running web applications written in Ruby. Rails doesn’t play nicely with Apache because Rails doesn’t play nicely with mod_ruby because mod_ruby has lousy threading support (or something like that). The logical answer here for a shared hosting provider is “fix mod_ruby so it becomes a viable way for one Apache server to run multiple Rails applications,” but that’s not something that’s actually up to the Rails core team. They don’t have anything to do with mod_ruby (or for that matter, Apache).

    Having said all this, I really haven’t looked into whether this is even feasible, but I think expecting shared host providers to radically change their environment to work with Rails isn’t too rational. (The only Rails app I’m running now is Instiki, which is just stunningly execrable in terms of resource use). I know folks in the Python world have been actively trying to make deployment of systems like Django easier, particularly with mod_wsgi, which IIRC is explicitly designed to be shared-host friendly.

    Comment by Watts — January 9, 2008 #

21. 21

    Hey Dallas, here’s an idea: Why don’t YOU guys make it happen? I know that sounds backward, but stick with me here..

    If you invested the engineering time to figure out why exactly Rails is difficult to deploy on your environment, and you can create patches and get them accepted, how much do you stand to gain? There are TONS of people who’d be using Rails if they could affordably deploy to a host like DreamHost, and you could capitalize on it.

    That, or just let us set up a damn proxy to the root of our domains (for private servers). How hard is that?

    Comment by Joseph — January 9, 2008 #

22. 22

    I guess the question really to ask is, what do you get from rails that is so awesome that you really need to use it? The interesting ideas that it has posed have already been copied successfully in other platforms. ActiveRecord? Really? Hmm I like to write my own SQL, its really not that hard. It seems like all these people making RoR sites all all trying to just make the same kind of site anyways, seems like if RoR was so hot there would be one defacto package everyone uses. But since Rails has performance anxiety (like when I got married, thank goodness for beers) no one can actually create a killer app for it yet.

    There are so many more interesting problems on the web to solve then creating more frameworks.

    Comment by kenrick — January 9, 2008 #

23. 23

    One reason why PHP so easily runs on shared hosting is the company behind it: Zend’s business model is directly tied to the popularity and broad install base of PHP.

    37signals, on the other hand, has its own business model that doesn’t depend on the promotion of Rails as a platform. Instead they make apps that use Rails. RoR is free and open-source not so that it will be widely-adopted and make them rich, but so that the framework itself can get better, which in turn contributes to the quality of 37signals’s own apps.

    (Don’t misunderstand: I’m not trying to argue that one approach is better than the other.)

    For this reason, 37signals has little incentive to make their framework more portable. I’m sure they will accept any “drop-in” optimizations submitted as patches, but only someone with an incentive to get Rails working in a shared hosting environment would try to write those patches in the first place. And anyone who’s already sold on Rails is likely working on a VPS, or a dedicated server, or is just messing around on their local machine.

    Plus, as you’ve mentioned, a lot of that work needs to be done on a lower level than Rails itself. Ruby is goddamned slow. (Luckily, smart people are working on this. YARV, Rubinius, JRuby, et cetera.)

    I agree that the answer from you got from the community (”just use lighty + SCGI”) was quite stupid. The “smart” answer, on the other hand, would’ve acknowledged that what you were trying to do was Really Hard, and might’ve even suggested that the effort would not have been worth it.

    Comment by Andrew Dupont — January 9, 2008 #

24. 24

    Ruby/Rails definitely seems to be trickier to implement, but the guys at hostingrails.com seem to have Rails apps in a shared environment pretty nailed down… Performance has been great.

    Comment by Clay Preheim — January 9, 2008 #

25. 25

    That all seems like a bunch of whining to me…”If only someone with a lot of resources and a financial stake in shared hosting would do some work in making this free open source software work better on shared hosting!” (followed by a large stream of Dreamhost customers talking about leaving Dreamhost because of it’s inability to successfully run Rails under its shared hosting plans).

    The whole deal with open source software is that if you need it to do something it doesn’t already do, you put in the work to make it happen. I’d wager that nearly everyone who’s ever contributed to Rails deploys on their own servers / hosted virtual machines. If Dreamhost has a lot to gain from Rails working well under shared hosting, and they know a lot about the real world requirements of their shared hosting customers, they should do the work to make it so, not wait for people with no financial interest and no hands-on knowledge to do the work for them for free.

    And they certainly shouldn’t be spreading FUD about Rails (by taking advantage of the fragile emotional state of one of its most productive contributors) to cover up their own lack of effort.

    Comment by Greg — January 9, 2008 #

26. 26

    Well said. I’d love to be able to write a Rails app, but I can’t run it on my shared host. Unlike PHP where I can just upload a few files and go.

    Comment by Bryce — January 9, 2008 #

27. 27

    As already pointed out in comments, this issue is not specific to Rails, or to Ruby. The same problems apply to any complex web-app (like Django or TurboGears, and probably some of the larger PHP-based frameworks too) that has a large amount of set-up overhead. By running a separate app process you amortize the setup costs across large numbers of requests.

    This is a more complex model than a simple CGI or mod_whatever, but it’s a straighforward engineering problem and there’s no reason it shouldn’t be workable. (I’ve dealt with exactly these sorts of IPC issues in native OS X apps.) Not to impugn anyone, but a lot of web development is done with duct tape extension cords and not engineered very well — to the point where a fairly simple but efficient web server like Mongrel gets idolized a some kind of mysterious alien technology.

    FastCGI is a terrible protocol; it’s far too complicated for what it does. SCGI (developed by some smart people in the Python community) does the same task in a much simpler way, so I’m sure it’s more reliable. Has Dreamhost tried using mod_scgi to bridge Apache to Rails?

    I would also look at whatever daemon Dreamhost is using that kills off processes that run for more than a few seconds. I can’t even run “gem install” anymore without the command getting the axe before it can download anything. This is definitely going to screw up FastCGI processes, which by their very design need to stay running long enough to handle many requests.

    It sounds like both sides here (DH and the Rails devs) are to blame. I’m pissed off at this, as I’ve done my time with PHP, a nasty little pidgin C that lends itself to unmaintainable spaghetti code, and I’d really like to use a real framework like Rails or TurboGears, but I can’t because none of these work on DH. Please just make it work, guys. This is not rocket science.

    Comment by Jens Alfke — January 9, 2008 #

28. 28

    Adrian:
    I’m pretty sure anyone who knows enough to understand the original blog post is well aware of the differences between a language and a framework. The reason why Rails should be more like PHP is because PHP is both easy to implement on web servers and easy to start hacking away in. Rails is neither. That eRuby thing looked promising, but it sort of missed the point of the “Be more like PHP!” cry — the ability to mix code and HTML is *not* why PHP is popular, and it’s actaully quite dumb in my opinion. (I generally try to avoid it when I can, using Smarty.)

    Watts:
    What makes you think writing CLI apps in PHP is painful? Toss in your shebang line, get your arguments out of $argv and go to town — I can’t imagine how it could be easier.

    kenrick:
    What I want from a language like Ruby (not necessarily a framework of any sort like Rails) is to get away from PHP’s inconsistant and sometimes painful syntax. I’m also a fan of the “everything is an object” paradigm. PHP is a lawn mower — incredibly functional and useful but not very pretty and capable of making quite a mess.

    Comment by Albright — January 9, 2008 #

29. 29

    The real issue is that hobbyist developers want to use Rails because “its the cool new thing”, and then want to deploy their website built in Rails on their shared hosting package because it’s just a hobbyist site, and they can’t afford the (now tiny!) cost of dropping it onto a VPS.

    That’s not to dismiss the hobbyist developers! I’m a hobbyist developer when I’m not a professional one, and I know that if what I want can be achieved by “chucking a few PHP files on my host and BOOM”, then that’s what I’ll do. I’m not insane enough to fire up a full application stack just to enable some forms or have some funky AJAX requests.

    Rails (and Symfony, and Django) are APPLICATION FRAMEWORKS. They are the complete opposite of PHP and its ilk, though both can be used to achieve the others target.

    PHP is designed to allow you to take a flat website and add processing power to it. It starts with a site, and then adds fun.

    Rails etc are designed to allow you to build a full-featured application, and deploy it on the web. BaseCamp isn’t a website, it’s an application. Building BaseCamp in PHP is possible, just as creating a website in Rails is possible, but you’re using the wrong tools if you do it that way.

    Should DH support Rails in a shared environment? I can think of no good reason why, and frankly this is all a lot of hot air about nothing. If your customers are clamouring for something, that doesn’t mean they understand what they’re clamouring for.

    Comment by Hostile Monkey — January 9, 2008 #

30. 30

    Oh, and one final thought - Rails is not “a better PHP”, and neither does it want to be.

    PHP5 is a step towards “a better PHP”, and I hope PHP6 finally brings a mature language. Rails and PHP can happily co-exist in your toolbox, neither one being “better” than the other. A screwdriver and a power-drill kinda look the same, and kinda work the same, but you can’t replace one with the other, and the do different jobs.

    Let’s just move along, learn both, and be happy, eh?

    Comment by Hostile Monkey — January 9, 2008 #

31. 31

    Surprised no one has mentioned Merb… I really don’t see any reason to use rails any longer, it is bloated and slow… Merb, using datamapper, on the other hand is quite fast and powering all my latest apps…

    Comment by Jon Hoyt — January 9, 2008 #

32. 32

    Albright:

    You want people to change Rails into something more like PHP: easier to work with more servers and easier to start hacking. But you want other people to do the work for you. Why? What is the benefit for DHH and the core group of developers behind Rails? In every open source project there is an itch to scratch that starts it all. In RoR it was an actual application that started it. Now there are people that don’t quite like how RoR is implemented and have started plenty of Ruby servers (Thin, EVMA, ServerSide) and web frameworks (Merb, Sinatra, Halcyon, etc.) each with it’s own take on how to develop web applications. So if you need an easier way to deploy in multiple web servers go ahead and build it. Fork it if you can’t get it into trunk. Who’s stopping you? I am personally tired of people wanting other people to do their work for them for free. Specially when people only tell you what they want and not even a hint of how or offering time/money.

    Comment by Adrian Madrid — January 9, 2008 #

33. 33

    Rails is all marketing. It’s a joke. It doesn’t perform, and the world surrounding it (As Zed’s awesome article pointed out) is totally a crock of immature and inexperienced pretentious developers who think they rule the world.

    Rails = Marketing. Now that it’s so big it can’t keep up with itself.

    Comment by Michael — January 9, 2008 #

34. 34

    It may interest you to learn that the Ruby on Rails Podcast site is actually run off shared hosting…Dreamhost to be specific.

    Every public-facing page is page cached (written to disk as static HTML pages) and I’ve had very few problems.

    All my mission-critical sites, are hosted on a VPS at RailsMachine, but Dreamhost works fine for simple sites that can be fully page cached.

    Comment by Geoffrey Grosenbach — January 9, 2008 #

35. 35

    @Albright: EcmaScript IS catching on on the server! See appjet.com and helma.org, both excellent uses of server-side EcmaScript.

    Comment by Aaron — January 9, 2008 #

36. 36

    The only proper solution would be to have ruby itself do what RoR is supposed to do - build web apps.

    Comment by she — January 9, 2008 #

37. 37

    Stop using FastCGI. Switch to mongrel and all the stability problems go away like magic. Wooo.

    Can’t believe you guys still haven’t got this right.

    Comment by Steven — January 9, 2008 #

38. 38

    i really don’t understan what the problem with rails and shared hosting is all about, i never ever had a problem with it

    i am using a simple and cheap vps-setup (http://www.hosteurope.de/produkte/VPS-Linux) and it took me less time than reading this post here to figure out how to set up some mongrels behind a apache

    i am wondering what could be easier than mongrel… wouldn’t it be easier for you to write own some paragraphs for your users how to setup up and monitor mongrels than writing lengthy rants

    Comment by res — January 9, 2008 #

39. 39

    Rails seems easy at first sight, but trust me, it’s not a framework for idiots. It has a very steep learning curve. And it’s a very new technology ! So for fuck’s sake, stop comparing it with PHP ! Don’t expect your same kind of setups to support Rails properly and make extra monkey. I suggest you better keep your focus on PHP n00b, else you might end up losing many customers.

    Comment by Pratik — January 10, 2008 #

40. 40

    I can’t imagine this sort of rant would be useful in gaining new users, helping existing ones, or finding people to solve your issues.

    Wouldn’t time be better spend working on solutions to your problems instead of demanding them from the community?

    Comment by Adam Bair — January 10, 2008 #

41. 41

    And btw, if you knew a tad about rails, you would understand why everyone should FREEZE the rails version their app is using. And you wouldn’t have ranted about backward compatibility. That point was really stupid :)

    Comment by Pratik — January 10, 2008 #

42. 42

    Often surprised by the amount of horror stories you hear about rails deployment. In fact is quite simple, safe from the fact that most shared hosting environments have innate limitations making you to go trough a set of non-standard web forms instead of having the full power of shell (root). This is the main problem.

    There are two main ways of deploying: Mongrel & FCGI. The *sole* advantage of Mongrel is that it can be paired with Apache’s proxy module and the former is a stable implementation. While in case of FCGI the Apache pair is weak and buggy (note that not rails rather the Apache module). There is no major speed difference between Mongrel and FCGI, infact if there is a difference at all then it is FCGI being faster due to a more compressed protocol by a slight ignorable edge.

    Most of my setups use FCGI & Lighttpd, a rock solid combination. I can assure you that restarts are not that common as Zed’s misinterpreted and *out of context* DHH quote would lead you to believe.

    If you are in shared host then you can even have FCGI & Lighttpd bellow an Apache proxy. Or just use Mongrel if Apache is a must. The steps to create a working setup are predictable, reproducible => programmable. What is the big deal? There is no reason why the Dreamhost would not have a simple form where you specify:

    * domain to where the rails app should listen
    * upload a DB dump you would want the app to be initialized

    Automated gerbils would do the setup, and deploy a blank “Hello Rails” application. Then you would receive a mail telling you that it is all set up, with an attachment containing the Capistrano deploy.rb file specially crafted for this project.

    Perhaps even better you could have just a dreamhost_deploy gem that you’ll install for yourself then run in your project’s top directory and does this entirely for you. The first shared host that does this will get lot of business. Should not be too difficult to program.

    Comment by Dee Zsombor — January 10, 2008 #

43. 43

    The ‘backwards compatibility’ comment is very valid.

    Anyone picking up a book on Rails won’t be able to work through most of the first examples listed if they’ve installed 2.0.2

    These kind of issues raise the cost of entry and put people off.

    Comment by mtkd — January 10, 2008 #

44. 44

    DHH himself replied to this (http://www.loudthinking.com/posts/21-the-deal-with-shared-hosts)

    He is spot on. He and most of the Rails contributors DON’T need shared hosting. So it means that they need people who need to tackle the problem. It is an OPEN SOURCE project remember? Contributions anyone? It is always easier to rant and rant and do absolutely nothing and feel good about yourself, right?

    Dreamhost, on the other hand, MAKES MONEY out of Rails. So good luck to them if they think this kind of rant will motivate any NON-PROFIT contributor to help them.

    That said, I use Railsplayground WITH FastCGI. It is not perfect, but they are WAY more supportive.

    Neither Ruby nor Rails is a commercial product. If people are using them, that’s because they feel it helps them. So help back now. Or, go for a VPS solutions and DIY. Slicehost might be good.

    Comment by AkitaOnRails — January 10, 2008 #

45. 45

    I never tried dreamhost, but I tried running my business on rails, and hoo boy! I spent most of my time wrestling with deployment issues.

    And in those days (don’t go there much anymore) most people just overlooked it. If DHH doesn’t talk about it, then it’s not an issue, regardless of how much it is needed in the real world.

    When DHH says FUCK YOU! he really means it, and so does the rest of the sychophants on the core team. That is not just a joke line.

    Sorry to say. I have moved my business back to PHP, because you know what I realized, when the ruby on rails people wanted their mundane stuff to be served without problems, they used PHP forums or blog software or whatever. Last I checked the main ruby on rails site was running on PHP!

    Comment by MItchell Gross — January 10, 2008 #

46. 46

    Does this mean Dreamhost has upgrade to Rails 2?

    Comment by rick — January 10, 2008 #

47. 47

    There are many people (and DHH himself) here who say that there is no motivation for the core rails team to get Rails work better on shared hosts. As someone who loved rails until he tried to deploy his first production app I can say this is a very short-sighted view.

    Lets look at some usage scenarios: Rails is intended to take the pain out of building simple data driven sites, the majority of sites built on the internet are low traffic. Most of these sites cannot afford or justify a dedicated server per site - its a ludicrous proposition.

    If DHH truly wishes Rails to be the simple and easy to use language that it proclaims to be and wants it to spread further (it _is_ still small after all) then he needs to spend more time on this matter. Its true that this shouldn’t be all on his head, Shared hosts need to get involved too but posts like this are necessary to raise the profile of this issue to where it should be: The Top of the pile.

    Comment by T M — January 10, 2008 #

48. 48

    There is a Ruby on Rails clone in PHP named Akelos (http://akelos.org) for those of you who want to have the best of both worlds right now. Rails functionality with the ease of PHP deployment and scaling.

    It even supports ruby-like syntax on views!.

    The sad thing is that the amount of other Rails-wannabe PHP frameworks is making the a lot of noise that makes Akelos to remain little known.

    Here you have a side to side comparison (http://www-users.mat.uni.torun.pl/~tomahawk/summary.php) where PHP frameworks are compared to Rails.

    Keep it simple for your small projects you host on Dreamhost and avoid Rails when possible on shared environments where PHP excels.

    Comment by Rubén — January 10, 2008 #

49. 49

    How does your experience with other major web programming frameworks such as Django or Turbogears compare to that with Rails?

    Comment by Mark — January 10, 2008 #

50. 50

    My God, DHH sounds just as arrogant as a KDE developer. DreamHost doesn’t make money from Rails, they make money from hosting. No one cares what the f’in developers use; it’s the average Joe user, trying to implement Rails, who suffers because DHH can’t be bothered to make Rails work on commodity platforms. Thus, widespread acceptance goes in the toilet. I’m beginning to think Zed was right about Rails, despite his lack of tact.

    At least Open Source is always entertaining.

    Comment by Michael Brutsch — January 10, 2008 #

Pages: [1] 2 » Show All

Leave a comment