I downloaded the much-hyped new mod_rails today, and while trying to install the Apache module that forms the “secret sauce”, was presented with the following warning:
You seem to be running MacOS X. Testers have reported that the default Apache installation, as provided by MacOS X, is broken. Passenger seems to crash for unknown reasons on OS X's default Apache installation.
Here’s a little tip: the most widely-distributed Apache build on any UNIX-like platform is, by definition, not “broken.” Your module is broken, and trying to blame Apple for your inability to deal with alternate build configurations isn’t helpful.
Wow. That’s pretty dumb.
mod_rails looks interesting, but something about Phusion just seems a bit April Fools-ish. I’m curious to see what happens with the vaporware that is “Ruby Enterprise Edition.”
Hi lennon.
We’re sorry that you had to see the warning. We fully realize that it’s not a nice thing to tell users. But please try to understand it from our point of view. We struggled with this problem for several days. OS X’s default Apache just continued to spew out errors that we couldn’t explain at all. On the other hand, Apache installed from MacPorts or from plain source worked like a charmed, as did Apache on all the other platforms (FreeBSD, Ubuntu, Debian, Gentoo, RedHat, etc).
So we were in a predicament:
1. We could postpone the release by another month, in an attempt to solve the problem ourselves. This could possibly mean that we have to neglect other important development matters in favor of this one. Since MacOS X isn’t our primary development platform, we would have had to put significant man power into this.
2. We could display a warning which tells people to install Apache from MacPorts. If the community finds out that OS X’s Apache isn’t broken after all, and finds out the cause of the problem, then it could be fixed in a later release.
Pretty much all of our beta testers agreed that 2 is a better option. For example, Pratik “lifo” Naik, a Ruby on Rails core developer who helped us with beta testing (who also happens to be a Mac user), performed a Google search and found out that lots and lots of people were having problems installing Apache modules onto OS X’s default Apache. He concluded that OS X’s Apache must be somehow broken. We carefully weighted the pros and cons of both options, and agreed that option 2 is better.
We hope for your understanding on this matter. That said, things have progressed since the initial release. Thanks to the help of the community, the cause of the problem was found, and the problem has been fixed in Passenger version 1.0.2, which will be released soon. We sincerely hope that you would give Passenger/mod_rails a second chance.
With kind regards,
Hongli Lai
- phusion.nl
Dear Sam Livingston-Gray,
Thank you for your feedback regarding Ruby Enterprise Edition. We can ensure you that Ruby Enterprise Edition is not vaporware, just like Passenger/mod_rails isn’t vaporware. There are two reasons why Ruby Enterprise Edition hasn’t been released yet:
1. Releasing Passenger took quite a lot of energy from us. We had 12-hour work days, because we were determined to polish Passenger as much as possible before the first public release.
2. We have recently made significant improvements in Ruby Enterprise Edition. We have decided that it would be better if these improvements were incorporated into the first public release. So we’re going for the extra mile, and we’re currently putting a lot of energy into making sure that Ruby Enterprise Edition’s first public release will be stable, easy to use, easy to install and well-documented. It is not our intention to release alpha/beta-quality software.
We will release Ruby Enterprise Edition as soon as we can. We kindly ask for your understanding on this matter.
With kind regards,
Hongli Lai
- phusion.nl
Hongli,
I think you sort of missed the point of my post. I wasn’t faulting you for having compatibility issues with the Apple builds of Apache. The issue was with the assignment of blame on Apple, rather than yourselves, in the message. By describing their Apache build as “broken,” rather than simply saying that *your module* was incompatible, you implied that Apple had somehow failed to properly engineer their system, while your own code was above reproach.
For the record, I’ve probably supported at least a half-dozen different third-party (i.e., not from apache.org) Apache modules in production, and never had a problem building or running them if they used the standard apxs/APR toolchain. I know that Passenger is substantially written in C++, which isn’t exactly the best-supported extension language for Apache, but your choice to use C++ (with all the ABI, linker, and library bloat issues it brings) was your own.
Hi lennon.
At the time, we observing these:
1. Passenger works on Linux (about 6 distros, both 32-bit and 64-bit).
2. Passenger works on FreeBSD.
3. Passenger works on OS X, that is, the MacPorts one *and* the source compiled one.
4. The only Apache on which Passenger did not work, was the default one bundled with OS X.
5. A quick Google search revealed that a lot of people were having problems with installing modules on OS X’s default Apache, and these problems may or may not be the same as the one that Passenger experiences.
Given all these points, and especially (4) and (5), we don’t think that “OS X’s Apache seems to be broken, unless proven otherwise” is a very unreasonable thing to think. All our OS X beta testers are certainly of the opinion that it’s Apple’s fault, and we have put these opinions in the warning message (i.e. it says “Testers have reported [...] is broken.”, and not something along the lines of “It is broken.”).
As for C++: the problem was not caused by C++. The problem would have occurred even if Passenger had been written in C.
With kind regards,
Hongli Lai
- phusion.nl
Hi lennon.
Passenger 1.0.3 has been released yesterday. MacOS X’s default Apache is now fully supported.