Response at a distance

Let me start by saying that this will be my last post on this subject.

For some reason, Pratik Naik, the poster of the original Twitter message chose to respond to my post on my blog via the Phusion blog. Ninh Bui of Phusion has asked the discussion to be taken elsewhere, so here we are.

Count me as shocked at the angry and non-linear response to what I felt was a neutral response to the original Twitter message.

@Tom : It’s you who need to put down your weapons when *YOU* felt the need to reply to my simple twits (where there was no mention of you/your employees/your comany ) with a gigantic blog post.

What you say here, Pratik, is not entirely true, as Engine Yard is a host that “doesn’t let you use Passenger”. Basically you’re now saying that Engine Yard was collateral damage to an attack not aimed directly at us. Of course, collateral damage is unavoidable when you make statements of the sort you made. Perhaps you should aim more carefully in the future to avoid such confusion.

When you have to reply to me saying “PEOPLE spreading FUD about passenger”, the shoe must fit. Even your employee had to make a direct personal attack, which is a shame.

Actually, I didn’t respond to that, but I certainly did reference it. I’m unaware of any of our employees making a direct personal attack, but will take you at your word and apologize for that employee here and now. We certainly don’t condone such behavior, though know full well that in a company full of young technical people, mistakes will be made.

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.

Please don’t put words in my mouth. As stated in my post, I was replying directly to you. There *are* valid reasons to not support Passenger, and I outlined a few of them. I also explained that there were very valuable and useful aspects of Passenger and most especially, Ruby Enterprise Edition. I think that I explained those reasons fairly clearly.

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 )

Thanks for pointing out that mod_rubinius is not where it should be. I’m checking into that. Of course, since most of the code was written before the virtual machine was rewritten in C++, the code isn’t highly valuable at this point. :-(

It’s rather unfortunate, to be sure, that we needed to reduce the size of the Rubinius team here at Engine Yard. We still maintain two full time people working on that project, which we consider to be very important to the community. Some might think it’s impolite to bring this up, but since we have already discussed this in public, I will not hold it against you.

I am confused, however, how this is relevant to the issue at hand. Perhaps you could enlighten me?

** 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.

Are you surprised that there are contacts made, and discussions had, that don’t come to fruition?

Again, I’m at a total loss as to how this is relevant to the discussion.

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.

Well, stating it in ALL CAPS doesn’t make it any more true. What does the word constantly mean to you?

In fact, Ezra endorsed Passenger, with a few caveats! Is Ezra not allowed to state an opinion, and suggest that Passenger is currently state of the art for a historically problematic issue of hosting small sites? Was it true at that time that Ruby Enterprise Edition wasn’t stable on 64 bit systems, which we use exclusively here at Engine Yard?

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.

I’ve looked at those statements again and again and fail to see how they’re contradictory. I said that you can reduce these disadvantages, but I did not say you could eliminate them. Ezra said that nginx “beats apache’s ass” which, I must admit, lacks technical rigor, yet the two statements simply do not contradict each other.

When you start putting Apache/nginx and “Scaling” in the same sentence, you’re just trolling/spreading FUD.

Really? Why is that? Would it be FUD to say “Apache and nginx scale equally well”? Both words in the same sentence, but no FUD involved at all. Now I’m being ridiculous to make a couple of points. Ezra’s statement was clearly an opinion. To make it more than an opinion, benchmarks would be required. Additionally, there are many ways that nginx could “beat apache’s ass” (memory and CPU usage, for instance) that would not indicate that Apache couldn’t scale. Directly to the point, Ezra did not say that Apache doesn’t scale.

What seems clear to me, in the end, is that you have an issue with Engine Yard. I’d *love* to understand what that issue is. Because, at this point, you’re now suggesting that we’re FUDing Apache, which is well off the original subject of Passenger.

We’re a Ruby and Rails application deployment company. We sponsor several open source projects. We host several hundred Ruby on Rails websites, and work 24x7x365 to see that the needs of our customers are met. We’re working hard and employing a lot of hard working Rubyists to make Ruby application deployment a no brainer for current and future Ruby and Rails application owners. We have exciting new projects coming soon that will make deployment easier and simpler than ever before.

It’s clear that you also take an interest in Ruby and Rails application deployment.

Do we have to agree on what stack is ideal to be friends? I, for one, hope not.


About this entry