5 ms·

Passenger (mod_rails) released

33 points by zapnap 19y ago

zapnap 19y ago
Article links to screencast. gem install passenger should pull down passenger-1.0.1. taking a look...
deleted 19y ago
[deleted]
deleted 19y ago
[deleted]
- dzohrob 19y ago
  am i reading this wrong? "In addition to the GNU General Public License v2 licensing terms, we explicitly grand [sic] you the permission to run any application on top of Passenger, regardless of the application's own licensing terms. The application will not be bound to the terms of the GPL in any way. That is, the GPL only applies to Passenger itself, and not to applications that are run through Passenger."
  - davidw 19y ago
    Err... no, I typed too quickly. Still, I really don't see the point of GPL'ing it under version two with that clause unless they think that it will mean hosting providers have to feed their changes back...
    - prototype 19y ago
      Well, that's kind of the whole point David... and yes, we do think that. Kind regards, Hongli Lai Ninh Bui Phusion.nl
      - davidw 19y ago
        Perhaps something like the Affero GPL would have been more appropriate in that case? Maybe you have access to better legal advice than I do, but my reading of the GPL is that if you're not redistributing it, you're not required to give back your modifications, and I'm not sure that running mod_rails on your own servers counts as redistribution. Perhaps you're simply aiming to stop people from selling binary-only versions, but that doesn't seem like nearly as likely a scenario as some hosting provider boasting of a mod_rails with extra secret sauce that they're not sharing. I'm not a license zealot, and think they all have their places, but I should also say a word or two in favor of the BSD/Apache style licenses: in the Apache Software Foundation, we don't rely on licenses to "keep people in line" (in terms of proprietary forks), but a strong, diverse community that has the potential to outdevelop anyone who tries to make a proprietary fork. They realize that if they fork, they're going to fall behind the community driven version, which is moving faster. Of course, that's not possible in all cases, but I think that a potentially important project like mod_rails certainly has a good shot at attracting that kind of community. You guys probably know more about the people in the rails hosting market than I do though, so maybe your fears are based on a concrete threat.
  - DocSavage 19y ago
    Sounds like they are just clarifying an aspect of GPL that comes up frequently in FAQ. People wouldn't be distributing Passenger code with their application. They're just using it, like many developers use Linux but don't have applications on Linux bound by Linux's GPL license.
tptacek 19y ago
The answer to this is probably obvious, but, can someone sell my on why I want mod_rails? What's wrong with the tag-team app server / web server architecture?
- DocSavage 19y ago
  You're probably not the target audience. It's meant to ease deployment so it's more like PHP in a LAMP setup. In the author's words (http://www.modrails.com http://www.modrails.com), here are the main features: - Deployment is only a matter of uploading application files. No Ruby on Rails-specific server configuration required! - Built on the industry standard Apache web server. - Allows Ruby on Rails applications to use about 33% less memory, when used in combination with Ruby Enterprise Edition (optional). - Zero maintenance. No port management, server process monitoring or stale file cleanup required. Errors are automatically recovered whenever possible. - Designed for performance, stability and security. Passenger should never crash Apache even in case of crashing Rails applications. - Well-documented, for both system administrators and developers!
- rob 19y ago
  Not everyone wants to manage both a front-end server and six little mongrels running around just to run an app.
DocSavage 19y ago
Here's the root link to mod_rails website: http://www.modrails.com/ http://www.modrails.com/
petercooper 19y ago
And if you want to do the same-ish thing with similarly little configuration (indeed, less) with any framework (not just Rails) or even with a non-Ruby language, check out SwitchPipe: http://switchpipe.org/ http://switchpipe.org/
rantfoil 19y ago
Setting up apache proxy + mongrels, while not impossible, is also not brain-dead easy. Also, in virtual private server scenarios RAM may be a hot commodity (slicehost, for instance) -- so in theory this should help you run more rails sites with less RAM, since you won't have to spin up individual mongrel clusters for each domain.
thomasswift 19y ago
this is huge, although i think this needed to come out earlier. rails deployment has already been generally pegged as 'hard' or a 'pain'. I have gotten use to getting a rails app coded fast then getting ready to spend some time deploying.
- petercooper 19y ago
  Do note that this is not the first attempt at this, however it looks. My own system (I say "my" loosely, it's public domain and open source) SwitchPipe: http://switchpipe.org/ http://switchpipe.org/ is already in widespread usage, but its focus is a little different.
  - thomasswift 19y ago
    That is why i said it seems a little late. I remember stabbing my eyes out when i first got into rails once i tried deploying stuff, back in the fastcgi/lighttpd days. btw, switchpipe is going to rule the world in a few months, the support for all the other frameworks looks awesome.
    - petercooper 19y ago
      To be fair, fastcgi wasn't /too/ bad IF you actually had it running well at least once g and that varied incredibly from machine to machine, alas. It did use a similar underlying mechanism to most of these other alternatives, just in a rather messy way. I don't think SwitchPipe will rule anything, but perhaps once it's up on Github (instead of SVN) and I release the next version, more baby steps can be made. I'd love to make it even more simple somehow, and perhaps port it to a much faster base (probably Python).
      - thomasswift 19y ago
        fair enough :)
      - davidw 19y ago
        Yeah, I've had good luck with mod_fcgid, actually. I don't have that much traffic, but I like the fact that the software takes care of setting up and tearing down new instances of the application server, rather than having to take a wild guess at how many mongrel instances might be needed per virtual host. This is something that mod_rails also promises to do well.
tlrobinson 19y ago
1. What's with the rails community's obsession with naming things names related to trains? What's wrong with "mod_rails"? 2. "touch tmp/restart.txt" seems like an odd way to signal a restart of your app... what's the reason behind this?
- there 19y ago
  for web hosting providers only giving ftp/sftp access, there's really no other way to signal a restart than to upload another file. you have no control over the processes and using some web-based administration too complex.
hopeless 19y ago
Just noticed that the "Passenger blog":http://izumi.plan99.net/blog/index.php/2008/04/11/phusion-passenger-mod_rails-public-release-heck-it%e2%80%99s-about-time/ http://izumi.plan99.net/blog/index.php/2008/04/11/phusion-pa... mentions that Dreamhost has been beta testing Passenger. If thats true, and Dreamhost rolls it out (soon!), then Rails is going to become as ubiquitous as PHP for hobby-coders that don't enjoy playing sysadmins. I'm probably one of them.
fendale 19y ago
This is great news good to see it! What I have been wondering is what happens to the memory footprint? It says somewhere on the site it is reduced by 33% - is that a typical reduction? Also, if this is like mod_perl, deployment wasn't really as simple as it seemed. The general advice on mod_perl was to proxy requests from your front end 'static' webserver to the mod_perl one, because each apache process had to effectively run a Perl interpreter, giving them a big memory footprint. You don't want to use your expensive mod_perl/ruby processes to serve images etc. I also think there are other advantages to running expensive processes behind a proxy (I may be wrong on this one), but I think that slow clients tend to tied up the front end process as it streams the data to them. If you have appServer -> proxy -> slow client, the app server sends the data to the proxy at LAN speed, freeing it to serve another request, and the proxy ties up a process streaming the data to the client. I am not trying to criticize, I am interested in whether they solved these problems (if they even are problems anymore) and how.

33 points by zapnap 19y ago

zapnap 19y ago

Article links to screencast. gem install passenger should pull down passenger-1.0.1. taking a look...

deleted 19y ago

[deleted]

deleted 19y ago

[deleted]

dzohrob 19y ago
am i reading this wrong? "In addition to the GNU General Public License v2 licensing terms, we explicitly grand [sic] you the permission to run any application on top of Passenger, regardless of the application's own licensing terms. The application will not be bound to the terms of the GPL in any way. That is, the GPL only applies to Passenger itself, and not to applications that are run through Passenger."
- davidw 19y ago
  Err... no, I typed too quickly. Still, I really don't see the point of GPL'ing it under version two with that clause unless they think that it will mean hosting providers have to feed their changes back...
  - prototype 19y ago
    Well, that's kind of the whole point David... and yes, we do think that. Kind regards, Hongli Lai Ninh Bui Phusion.nl
    - davidw 19y ago
      Perhaps something like the Affero GPL would have been more appropriate in that case? Maybe you have access to better legal advice than I do, but my reading of the GPL is that if you're not redistributing it, you're not required to give back your modifications, and I'm not sure that running mod_rails on your own servers counts as redistribution. Perhaps you're simply aiming to stop people from selling binary-only versions, but that doesn't seem like nearly as likely a scenario as some hosting provider boasting of a mod_rails with extra secret sauce that they're not sharing. I'm not a license zealot, and think they all have their places, but I should also say a word or two in favor of the BSD/Apache style licenses: in the Apache Software Foundation, we don't rely on licenses to "keep people in line" (in terms of proprietary forks), but a strong, diverse community that has the potential to outdevelop anyone who tries to make a proprietary fork. They realize that if they fork, they're going to fall behind the community driven version, which is moving faster. Of course, that's not possible in all cases, but I think that a potentially important project like mod_rails certainly has a good shot at attracting that kind of community. You guys probably know more about the people in the rails hosting market than I do though, so maybe your fears are based on a concrete threat.
- DocSavage 19y ago
  Sounds like they are just clarifying an aspect of GPL that comes up frequently in FAQ. People wouldn't be distributing Passenger code with their application. They're just using it, like many developers use Linux but don't have applications on Linux bound by Linux's GPL license.

tptacek 19y ago

The answer to this is probably obvious, but, can someone sell my on why I want mod_rails? What's wrong with the tag-team app server / web server architecture?

DocSavage 19y ago
You're probably not the target audience. It's meant to ease deployment so it's more like PHP in a LAMP setup. In the author's words (http://www.modrails.com http://www.modrails.com), here are the main features: - Deployment is only a matter of uploading application files. No Ruby on Rails-specific server configuration required! - Built on the industry standard Apache web server. - Allows Ruby on Rails applications to use about 33% less memory, when used in combination with Ruby Enterprise Edition (optional). - Zero maintenance. No port management, server process monitoring or stale file cleanup required. Errors are automatically recovered whenever possible. - Designed for performance, stability and security. Passenger should never crash Apache even in case of crashing Rails applications. - Well-documented, for both system administrators and developers!
rob 19y ago
Not everyone wants to manage both a front-end server and six little mongrels running around just to run an app.

DocSavage 19y ago

Here's the root link to mod_rails website: http://www.modrails.com/ http://www.modrails.com/

petercooper 19y ago

And if you want to do the same-ish thing with similarly little configuration (indeed, less) with any framework (not just Rails) or even with a non-Ruby language, check out SwitchPipe: http://switchpipe.org/ http://switchpipe.org/

rantfoil 19y ago

Setting up apache proxy + mongrels, while not impossible, is also not brain-dead easy. Also, in virtual private server scenarios RAM may be a hot commodity (slicehost, for instance) -- so in theory this should help you run more rails sites with less RAM, since you won't have to spin up individual mongrel clusters for each domain.

thomasswift 19y ago

this is huge, although i think this needed to come out earlier. rails deployment has already been generally pegged as 'hard' or a 'pain'. I have gotten use to getting a rails app coded fast then getting ready to spend some time deploying.

petercooper 19y ago
Do note that this is not the first attempt at this, however it looks. My own system (I say "my" loosely, it's public domain and open source) SwitchPipe: http://switchpipe.org/ http://switchpipe.org/ is already in widespread usage, but its focus is a little different.
- thomasswift 19y ago
  That is why i said it seems a little late. I remember stabbing my eyes out when i first got into rails once i tried deploying stuff, back in the fastcgi/lighttpd days. btw, switchpipe is going to rule the world in a few months, the support for all the other frameworks looks awesome.
  - petercooper 19y ago
    To be fair, fastcgi wasn't /too/ bad IF you actually had it running well at least once g and that varied incredibly from machine to machine, alas. It did use a similar underlying mechanism to most of these other alternatives, just in a rather messy way. I don't think SwitchPipe will rule anything, but perhaps once it's up on Github (instead of SVN) and I release the next version, more baby steps can be made. I'd love to make it even more simple somehow, and perhaps port it to a much faster base (probably Python).
    - thomasswift 19y ago
      fair enough :)
    - davidw 19y ago
      Yeah, I've had good luck with mod_fcgid, actually. I don't have that much traffic, but I like the fact that the software takes care of setting up and tearing down new instances of the application server, rather than having to take a wild guess at how many mongrel instances might be needed per virtual host. This is something that mod_rails also promises to do well.

tlrobinson 19y ago

1. What's with the rails community's obsession with naming things names related to trains? What's wrong with "mod_rails"? 2. "touch tmp/restart.txt" seems like an odd way to signal a restart of your app... what's the reason behind this?

there 19y ago
for web hosting providers only giving ftp/sftp access, there's really no other way to signal a restart than to upload another file. you have no control over the processes and using some web-based administration too complex.

hopeless 19y ago

Just noticed that the "Passenger blog":http://izumi.plan99.net/blog/index.php/2008/04/11/phusion-passenger-mod_rails-public-release-heck-it%e2%80%99s-about-time/ http://izumi.plan99.net/blog/index.php/2008/04/11/phusion-pa... mentions that Dreamhost has been beta testing Passenger. If thats true, and Dreamhost rolls it out (soon!), then Rails is going to become as ubiquitous as PHP for hobby-coders that don't enjoy playing sysadmins. I'm probably one of them.

fendale 19y ago

This is great news good to see it! What I have been wondering is what happens to the memory footprint? It says somewhere on the site it is reduced by 33% - is that a typical reduction? Also, if this is like mod_perl, deployment wasn't really as simple as it seemed. The general advice on mod_perl was to proxy requests from your front end 'static' webserver to the mod_perl one, because each apache process had to effectively run a Perl interpreter, giving them a big memory footprint. You don't want to use your expensive mod_perl/ruby processes to serve images etc. I also think there are other advantages to running expensive processes behind a proxy (I may be wrong on this one), but I think that slow clients tend to tied up the front end process as it streams the data to them. If you have appServer -> proxy -> slow client, the app server sends the data to the proxy at LAN speed, freeing it to serve another request, and the proxy ties up a process streaming the data to the client. I am not trying to criticize, I am interested in whether they solved these problems (if they even are problems anymore) and how.