LinRails — Ruby On Rails For Linux

foobarf00 writes "LinRails is a binary package that includes Ruby-1.8.6, Rubygems-0.9.4, Rails 1.2.3, Mongrel 1.0.1, MySQL-5.0.41, ncurses-5.6, OpenSSL-0.9.8e, and zlib-1.2.3. Its goal is to make it easy to get a Ruby on Rails development environment running in no time. This initial 0.1 release doesn't have a Web server in the package; opinions are solicited as to which to include."

It does have a very good web server

[Fjan11]

> It includes Mongrel 1.01 [...]
>This initial 0.1 release doesn't have a Web server
Mongrel is a very good web server, especially for a development environment. (And the ruby package includes webbrick on top of that). Current 'best practice' deployments of RoR applications usually use a pack of Mongrels behind a load balancer (such as mod_proxy or Pound), and/or Apache or Nginx to serve static pages. If you want to completely mirror your production environment in your development/testing environment than including those would the logical choice.

Re:Why MySQL

[Xest]

MySQL just seems more common and I can't see that changing. Pretty much every web development book and site uses MySQL for database teachings so as people come into web development I'd argue it's just going to increase the MySQL user base even more.

For most people's web development needs MySQL just does what you need. Chances are if you need something MySQL doesn't have then you're already competent enough to not need a package like this and set it all up yourself anyway, this just makes it easier for those who are relatively new to web development to jump straight in.

I'm just about to start learning RoR myself and I just run my practice servers as VMs so for people like me, it's pretty easy to just setup a Linux VM, install a package like this and knuckle straight down with learning RoR. When I've got a decent understanding of it and am sure it's something I really do want to continue with I'll start to pay more attention to setting it up in a production environment and I'll start looking further into different databasing options and so forth.

Re:Apache?

[FooBarWidget]

Ruby on Rails cannot be run in Apache.

Yes, I was stunned when I found this out last year. If one wants to run RoR on Apache, then one has to use either mod_fastcgi (or mod_fcgi or whatever it was called; it'd run RoR as a FastCGI process) or mod_ruby. mod_ruby seems to be abandoned, and I have heard stories about excessive memory usage. mod_f(ast)cgi doesn't seem to work on Apache 2 at all.

So there are two ways to run RoR: either in Lighttpd (which has proper FastCGI support) or in Mongrel (a web server which can run RoR directly).

Re:Apache?

[Dark$ide]

> Ruby on Rails cannot be run in Apache. How do you arrive at that conclusion? I have RoR running in Apache. It needs some funky .htaccess stuff and I have a virt host defined for it.

# SetEnv RAILS_ENV development
ServerName rails
DocumentRoot /home/Dark$ide/ruby/myapp/public/
ErrorLog /home/Dark$ide/ruby/myapp/log/apache.log


Options ExecCGI FollowSymLinks
AddHandler cgi-script .cgi
AllowOverride all
Order allow,deny
Allow from all



Alias /ruby /home/Dark$ide/ruby/myapp/public

Options ExecCGI FollowSymLinks
AddHandler cgi-script .cgi
AllowOverride all
Order allow,deny
Allow from all

The .htaccess file in the public directory needs a quick tweak to match the Alias to get the rewrite rules working. Works well.

Re:Special Announcement

[foobarf00]

From their blog:

"We decided to this so that we can share the same development environment with all the team. If programmers have a different Linux distro/version, they will still share the same development environment. This prevents programmers to say "well, it works on mine" when there is a problem. Also if you have a Linux distro package, versions may change when a new Linux distro is released. Also if you want to upgrade to the latest and greatest you are at the mercy of the Linux distribution. We will try to always have the latest versions of each tool. This helps to solve those problems."

Why .exe's are better

[Krommenaas]

As a frustrated Windows user who would like to switch to Linux but can't get it to work, let me explain this to you:

1) in my experience a Windows .exe always works regardless of what Windows version I'm using, while a Linux package generally doesn't work on the Linux distro I'm trying.

2) if I'm given a link to a .exe that will fix my internet connection, it's rather obvious to me that I can download the .exe from another PC, put it on a USB key and run it on my own PC. however, if I get an apt-get line to help me fix my internet connection, I have absolutely no clue what to do with it.

Re:Why .exe's are better

[jack455]

At some point I installed Fedora Core 2 (now on 7), and the install was very smooth. I installed KDE and already knew how to use that from using the Knoppix Live CD.

Upon First Boot I immediately allowed Fedora to AutoUpdate, but then had trouble. Without a tutorial, I searched for and found software I wanted to install but I thought I had to compile from 'somepackage.tar.gz'. Oops. Seems silly to me now, but I didn't have anyone helping me. I knew I could go to forums, but didn't. I then found out about rpm's and how to install from the command line. Then I found out that 'yum' was better to use than 'rpm' for installing 'somepackage.rpm'. Weird, at first anyway. Eventually '#yum install yumex' got me a graphical software finder and installer. KMenu(like Start)---System---Yum Extender

But occasionally I want to install software from a CD or download 'somepackage.rpm'.

Instead of 'someprogram.exe' it's 'somepackage.rpm'. The one thing I had to learn wasn't so much how to do it, but what the commands meant.

For the same reason I decided to stop using Windows, I wasn't going to type su into a terminal without knowing why. But you can run Konsole from the "start" menu. Type $su; enter root's password; navigate to your Desktop folder or wherever 'somepackage.rpm' is; type #yum localinstall somepackage.rpm; type y for ok!

Not blazingly simple after all, but there's very little to understand.

Remember that intermediate, advanced, or experts on any OS(windows, mac or linux/unix) should all be telling you _not_ to download an exe and run it in order to fix an internet connection.

Re:Aptitude

[EsbenMoseHansen]

You fail to understand how people use software.

Take a common program, for instance. Say, Gnumeric. And you're running Ubuntu 6.06 -- the Long Term Support release.

So you are running a release that is made for one purpose: To not change and then complain that it doesn't change? Okaydokey. The rest of us just follows the automatic Ubuntu upgrades as times go by. Sure, sometimes we have to wait for 6 months before getting the latest .x release, but personally, I really don't care.

It sounds as if you want a stable core, with application repositories closely tracking the newest available? Sounds like a decent idea for a distro. Are you sure that there isn't just such a distrobution?

That's the problem. Repositories are just time-constrained cludges. People should be able to install cool new apps whenever they want, all in a single file, just like you buy a new CD from the shop and play it. Linux was getting there with Autopackage, but sadly that hasn't been taken up to any grand scale...

I don't know about autopackage, but klik [atekon.de] seems to offer what you want. I'm sure the klik team will appreciate your contributions, at least with testing. They seem to need some server reasources, too, the search seems very slow.

Personally, I prefer to be able to have new, fairly tested software without having to bother with the actual upgrades. But I am sure you actually enjoy hunting down the 10-50 apps you use and upgrade them as needed every now and then ;p

Re:Aptitude

[FooBarWidget]

"Great, so you download a .exe from some random website. You have no idea what's in it so you constantly run the risk of getting more spyware/adware/crap installed."
What if it's not "some random website"? What if you know that it's good software, but it isn't in any repository?

"Locate package foo. Download it, ensure dependencies are met"
Ensure that dependencies are met? Most people don't want to manually hunt down hundreds of dependencies.

"Alternatively download the source tarball and run ./configure && make && sudo make install. What's hard about that?"
Try explaining that to your mother and your grandmother. You'll find out what's so hard about that.

However, the fact that some software are not in repositories is just as much of a political/social problem as a technical one. It already starts with the question: DEB or RPM? What if I want to produce DEB but I'm using an RPM distro? If I produce a DEB, will it work on all Debian-based distros? (Answer is no, unfortunately.) If I produce an RPM will it work on all RPM-based distro? (No either). What about non-DEB non-RPM distros? Etc. Making an installer on Linux would hide the package format problem, but will not solve binary compatibility problems (FooApp needs libfoo.so.4 but AwesomeLinux only provides libfoo.so.5).