Ezra, as promised I’ve sent you a mail a few hours ago and am eagerly awaiting your response.

But it’s very apparent you weren’t replying to me, but you were replying to your customers justifying your position against the growing popularity of Passenger. And that’s fine. Just don’t pretend as if it’s all in a response to my twitter messages. My twit, clearly, was just a catalyst.

But forget all that. Let’s have a little history lesson, shall we :

** Feb 12 **
- Ezra Announces mod_rubinius http://brainspl.at/articles/2008/02/12/what-do-you-want-to-see-in-mod_rubinius.
- Comment #12 is EXACTLY what passenger is.
- And now mod_rubinius has been officially killed ? ( correct me if I’m wrong http://www.google.com/search?q=github+mod_rubinius )

** April 4 **
- Passenger is released to the public http://ninh.nl/blog/2008/04/04/the-moment-youve-probably-been-waiting-for-so-have-we
- If you notice the announcement, “Lastly, we’ve been approached by EngineYard..”. And we never heard about that ever again. Clearly, something went wrong there.

After that, you guys CONSTANTLY tried to ignore/sideline Passenger, by saying it’s suitable only for shared hosting/VPS. COMPLETELY BASELESS as pointed out 100 times before. That’s pure FUD.

Here’s an interesting part :

Tom says “Of course, you can reduce these disadvantages by cuting down a custom build and tweaking the included modules”
Ezra says “I think i;ve scaled a few ruby websites and I use nginx cuz is beats apache’s ass”

Clearly, those are contradictory statements and one of you doesn’t know what you’re talking about. Pick one. Period. When you start putting Apache/nginx and “Scaling” in the same sentence, you’re just trolling/spreading FUD.

To be 100% clear, my blog post was in response to the referenced Twitter post. It was my intention to explain why we’re not currently offering Passenger support by exposing the decidedly non-draconian reasons.

The reason is fairly simple: We see most of the advantage of Passenger to be simplified configuration, which we don’t need, and that comes at the expense of Apache -vs- Nginx. We like Nginx *a lot* and have over 30 support personnel and hundreds of customers running production environments, and thousands of lines of automation code written around our current stack.

As Ezra responded, we see the majority of benefit to our customers coming from Ruby Enterprise Edition, which as noted in my blog post, would not work for us until the very same day as my post. I also agree that we’d *love* to see a Passenger module for Nginx, and would consider supporting such a project.

It’s distressing to see commenters here suggesting that Passenger is somehow at odds with our business model, for instance, unless it simply means that our business model is to focus our attention on the stack that we best feel meets the needs of our customers. Our business model is very simple: provide what we feel is the best production environments available to host Ruby applications, and back up that stack 24x7x365 with support people. In order to do this, we must *not* support every possible combination of components, as that would drastically dilute the expertise that we can provide.

Finally, as for 32 bit -vs- 64 bit environments: Yes, 64 bit environments consume a lot more memory than 32 bit environments. This is the reason that we’re more focused on Ruby Enterprise Edition -vs- Passenger! 64 bit environments, when virtualized via Xen, have performance advantages compared to 32 bit environments. Additionally, the ability to run processes of greater than 2 GB of RAM has proven to be a very useful capability to have in our toolbox.

Trevor Turk: Ezra’s statements make it clear that we have spent time with Passenger. My post said that we did not have expertise in it, which is quite a different subject!

Egze: I’m sorry that you felt we were bashing Phusion’s products. I don’t believe there was anything in my post, or anything else from Engine Yard, that qualifies as bashing any of Phusion’s products, so I’m very sorry if it came across that way.

Riptie: please send me an email or call me at 866-518-9273 extension 201. I’d really like to understand how we’re underperforming your expectations on this issue. It’s tremendously import for me to understand, because I feel the path we’re taking is 100% in your best interests, but if you don’t agree, then I’m wrong.

I understand there are other factors involved and I don’t have any experience with Linux. But I know that you can easily compile kernel to support more than 4 GB of memory. So I’m just curious to know why 64 bit when you guys are SO concerned about memory usage.