Ruby on Rails on unofficial Chrome OS

update: I thought this Chrome OS distribution was THE google distro. I was wrong. It’s just someone who used SUSE Studio to make a customized version of Open SUSE around the Chromium theme. With the site being on a google site and the code on a google code repository, I thought this was it, but no.. this distro is totally unrelated to google.

Chrome OS is by now just a bit more than a curiosity. In the meanwhile, you can go and download a non-official distribution mimicking what it could be, but be warned, all you are going to get is an Open Suse distribution with Chromium installed and a blue theme with a cute logo. Hopefully the real ChromeOS will be much lighter and more user-friendly.

Starting the virtual appliance from VirtualBox is easy. You create a new virtual media with the virtual media manager and then a virtual machine using this new media. That should be it. If you leave the default options (64MB) you’ll end up with a really slow boot. I set the base memory to 512K and things are much better.

What will you find in this distribution apart from Chromium? Zip, Zero, Null.. or if you are into ruby, nil.

Truth is, this distribution is a bit too rough around the edges (when it comes to internationalization, even if it ask you for the keyboard settings, it will just ignore them), but being a SUSE, you can install whatever you want. The only thing you’ll need is the root password. Since I’m such a hacker it took me almost no time to realize the root password was “root” (my other options being “sergei”, “larry” and “640Koughttobeenough”.

Once you have root access, you can use Yast for installing anything you might need. Just for fun I installed ruby, rubygems and sqlite3 via Yast, and then rails using gem. I had to run a gem update –system so I could use rails 2.3.4 and I generated a scaffold to see if everything was fine. Well, it was :)

ruby on rails running on google chrome os

Well, even if it was utterly useless, at least I found a cool way of making customized SUSE distros in an easy way ;)

Advertisement

Multiple rubygems versions, GEM_HOME and GEM_PATH

Installing rubygems is failrly easy and it’s great to have a package manager so you can forget about manually installing and upgrading the components you use. After installing a gem, you can require it from any ruby script and use it hassle-free. Well, given your ruby interpreter can find it.

When you install rubygems, a lot of default configuration is done behind the scenes. If you must see to believe, you can run

gem environment

do you believe me now?

Unless you are on windows, you have probably experienced already that gems can get installed in different locations. If using a superuser account, the global configuration will be used, but with a regular account gems install under your home directory.

If you are not careful about how you install your gems, or if you are using rake gems:install from regular accounts, you might end up installing the same version of a gem twice. That’s not only WET (not DRY, bear with me here) but it eats up your poor HD.

Things can get a lot worse than that. Suppose you are working with both JRuby and Ruby MRI. When you use rubygems from JRuby, it will try to use a different gem location by default. So, depending on how you are installing gems, you could have up to three different copies of exactly the same version.

And if you are on ubuntu and you upgrade from an old version of rubygems to the latest one —you will have to if you install Rails 2.3.4; if you are having problems you can read right here how to update it— you might be surprised that your gems are being installed *again*. The reason is under older versions the default location was “/var/lib/gems” and the latest one defaults to “/usr/lib/ruby/gems”.

Well, four different copies of ActiveRecord 2.3.4 are three and a half more copies than I wanted, mind you.

So.. how can we stop this gem install frenzy? Easy. Don’t use the defaults. Each of your installations is using default values, but they can be easily overridden with command line parameters or much more conveniently with environment variables.

Remember the title of this post? Can you see anything there that would make a good candidate for environment variables? That’s right, all the rubygems versions honor the GEM_HOME and GEM_PATH variables, so if they are set they will be used.

Depending on your OS, you can set these variables in different places. I’m on ubuntu and a bit lazy, so I chose the easiest, which is by adding this to my .bashrc file.

export GEM_HOME=/var/lib/gems/1.8
export GEM_PATH=/var/lib/gems/1.8

And now, no matter what I’m using: Ruby MRI, JRuby, or the latest rubygems, my already installed gems will be used, and the new ones will be put in the same place.

Saving the world is a hard job, but someone has to do it.