Friday Jun 19, 2009

Typo in OpenSolaris RoR AMI on Amazon EC2

We released a new OpenSolaris Ruby on Rails image on Amazon EC2 last week.  This version is different from the previous one on OpenSolaris because not only does this AMI include the usual goodies, updates etc., this is also a Typo appliance. 

Want some marketing key words?

  • Optimized
  • Secure
  • Pre-configured, preinstalled, and very "appliancy"
  • Extremely monitorable

Since I'm not really a marketing guy, I just can't put words out there without feeling a primordial urge to explain myself.


The stack (Ruby, extensions, gems, web servers) is compiled with the latest compilers, optimal compiler flags based on performance studies, and Nginx is configured to have its temporary file store on a tmpfs mount.


Nothing runs as root, even for an instruction.  If you're wondering how Nginx can listen at port 80 without being started as root, the answer is easy - Solaris privileges:  root is not a user, rather it's a role.  So you can confer privileges (like listening on port 80) which are usually associated with root to other users (like the nginx user).  So this obviates the necessity for applications(like Nginx or Apache) to run as root even for the brief set of instructions needed to bind to a port.  The less instructions you run as root, the less your exposure.

Pre-configured, pre-installed, and very "appliancy".

The image contains a production ready configuration of Typo, which is the popular Rails blog engine(usage details are here[1]).  Its architecture: there are two Nginx workers.  Nginx listens at port 80 and is a fast web server which reduces the possibility of application bottlenecks.  In all likelihood, one cannot fully stress two Nginx workers in an EC2 instance (or even one, in my opinion) In addition, Nginx has a low memory footprint, so the benign effect of having two instances outweighs the overhead). 

The Rails servers are powered by Thin.  There are two instances that Nginx communicates with.  Rails is a CPU-intensive/low concurrency application that benefits from multiple instances.  The Thins are sized in anticipation of a single CPU so it may be wise to increase the number of Thin instances depending on the number of CPUs in the image.

MySQL is the database.  The three tiers are pre-configured.  Nginx communicates with Thin, and Thin communicates with the database.  Typo has its schema populated into the MySQL database, Rails and its dependencies are already installed.  The native gems, like MySQL and Thin have been compiled and configured correctly . . . and it "just works".  To use it start the instance, and log on to http://instance to begin setting up your web log.

SMF services exist for the Nginx, Thin, and MySQL components, and the dependencies between these services are also expressed in the manifests.

The catalog entry has information on where the service manifests are stored, and where the components are installed for one who wants further control.

Extremely monitorable

The AMI has DTrace support.  DTrace provides for a low overhead profiling with fine-grained control over which code is being profiled.  Please refer to Reference 2 below[2].

What's not in the AMI:  one needs a backup mechanism for their weblog entries, this is something that the AMI does not provide at this time. 

And that's it, please check out the AMI, and hope it is useful either in itself, as a starting point for an tiered architecture that can benefit from an SMF integration, and/or as a base Ruby on Rails AMI that can be used for building a private stack.




Wednesday Apr 29, 2009

SMF manifest for Nginx

Here's an SMF manifest for Nginx.  You'll need to tweak it for your location of Nginx.  You can create an nginx user and group to run the web server as(highly recommended), or tweak my script to run as root(please don't do this).

The steps?

  1. Download the SMF from here
  2. groupadd nginx
  3. useradd -d /export/home/nginx -g nginx nginx
  4. change all occurrances of "/usr/nginx/sbin/nginx" to point to where ever your nginx is installed.
  5. You may remove the -c option in the nginx invocation if you do not want to place your nginx config file in that directory(or just want to use the default one).
  6. next, import the SMF script.  svccfg import nginx.smf
  7. run svcs -vx to make sure everything went well. It should have, if you followed all the steps above.( else you'll be pointed to a log file for further debugging )
  8. You are set.
  9. Optional:  add service dependendies on the mysql and thin/mongrel services on your system since nginx probably won't be of much use if you don't have those running.

Monday Apr 27, 2009

Git is in OpenSolaris-dev.

I just noticed that git is available in the OpenSolaris dev repository.  No more compiling from source.  Very cool.  All the volunteer work done to spruce up FOSS support in the OSOL community is paying off. 

You can either get it by running "pkg image-update" on your OpenSolaris instance, or wait for the Ruby on Rails EC2 image which I'm creating right now, to get a preconfigured set of tools, gems, web servers etc.,

Friday Apr 17, 2009

To update Ruby, or any other application on OpenSolaris . . .

My recent post about updating Ruby on OpenSolaris can be summed up with the following steps:

(1) set the OpenSolaris developer repository as the package authority(pkg set-authority -O

(2) run "pkg image-update".

This raised questions about whether an image update was necessary just to update Ruby, which is a well behaved application with no direct ties to operating system internals.

The answer, quite simply, is a YES.  This applies to any application that is provided by  the main OpenSolaris (or dev) repositories, not just Ruby.  One can only update the application to a level of the package that is delivered on the build of the OS that one is running. 

Does that sound confusing?

 Lets say your OS level is 101 ( use "uname -a" to find that out).

root@domU-12-31-39-02-F5-56:/var/ruby/1.8/gem_home/bin# uname -a
SunOS domU-12-31-39-02-F5-56 5.11 snv_101b i86pc i386 i86xpv Solaris

Now lets look at an application installed on this machine (gmake, for example).  Use "pkg info" to get information about an installed package.

root@domU-12-31-39-02-F5-56:/var/ruby/1.8/gem_home/bin# pkg info SUNWgmake
          Name: SUNWgmake
       Summary: gmake - GNU make
      Category: Development/GNU
         State: Installed
       Version: 3.81
 Build Release: 5.11
        Branch: 0.101
Packaging Date: Wed Nov 19 22:11:01 2008
          Size: 696.26 kB
          FMRI: pkg:/SUNWgmake@3.81,5.11-0.101:20081119T221101Z

gmake 3.81 is installed, and this was built on build 101 of Solaris Nevada (build 101 is the value that corresponds to the "Branch" tag).

Now, what this means is that one will not be able to update gmake to a version higher than the one bundled with build 101 without running "pkg image-update".  In this case, that is gmake version 3.81.

Updating individual packages is possible with the IPS framework, and that means that non Sun packages can be updated.  The packages that are delivered by Sun, however, cannot be updated thus.  These packages are listed as dependencies for the meta-package called "entire". "entire" imposes the restriction on what build number a package could be updated to. 

The IPS team is working on loosening this (reboot required) restriction.   But until then, please point your pkg command to  (by uttering pkg set-authority -O ) and then say " pkg image-update ".

This will bring up Ruby 1.8.7p72 and Rubygems 1.3.1.  There is work happening to make Rails available too. stay tuned.

Tuesday Mar 24, 2009

installing ImageScience an art?

ImageScience is a pretty cool gem to use in your Rails application for Thumbnail generation.  It doesn't install correctly out of the box since ImageScience uses an incorrect default path for locating FreeImage. The Makefile shipped with FreeImage also does not build correctly on OpenSolaris.  So here's a way to make sure it works correctly first time if you are on OpenSolaris.

Step1:  Update your Ruby package.  We now package Ruby 1.8.7 p72 with OpenSolaris.  Here is a blog entry I wrote sometime ago on how to upgrade to 1.8.7p72 ->

Step2: Ensure that /usr/gnu/bin is prepended to your PATH environment variable. (or, just utter export PATH=/usr/gnu/bin:$PATH in bash).

Step3: Install the requisite OpenSolaris packages.

pfexec pkg install SUNWgmake

pfexec pkg install SUNWgnu-coreutils

The "pfexec" is there to give you enough privileges to install the packages.  If you run as root(which I do - and which is not recommended), then you don't need to use pfexec.

Step4: Build FreeImage. Download it from and unzip it.  The Makefile that ships with FreeImage does not build correctly on OpenSolaris, so here is a Makefile that does ->  .

Change directory into the exploded FreeImage source, and utter the following.

gmake -f Makefile.opensolaris

gmake -f Makefile.opensolaris install

Where Makefile.opensolaris is the OpenSolaris Makefile that you just downloaded.

Step5:  The rbconfig.rb file in your Ruby installation needs to be changed.  Edit this file(it's to be found in /usr/ruby/1.8/lib/ruby/1.8/i386-solaris2.11 )

Look for a line that goes thus:


 and replace it with


i.e., change the linker binary such that the GNU Linker is used by RubyInline(which is an ImageScience dependency).

This is a bug that will be fixed in build111.  So if you have a newer version, this bug might already have been fixed.

Step6: Now install ImageScience the usual way. 

gem install image_science

Step7: You should now be set.  But, just to make sure, run the ImageScience tests and make sure they pass.  Here is how to do that.

Edit $GEM_HOME/gems/image_science-1.1.3 test/test_image_science.rb (if you use the default gem home on OpenSolaris the file is to /var/ruby/1.8/gem_home/gems/image_science-1.1.3 test/test_image_science.rb ).

Add the following line to the beginning of the file.

 require 'rubygems'

Now test it by executing:

cd /var/ruby/1.8/gem_home/gems/image_science-1.1.3

(or cd $GEM_HOME/gems/image_science-1.1.3 if your gem home is different).

ruby test/test_image_science.rb

 Loaded suite test/test_image_science
Finished in 0.01314 seconds.

7 tests, 28 assertions, 0 failures, 0 errors

And thats all it takes to have a working ImageScience library.

Wednesday Feb 04, 2009

How does one update Ruby in OpenSolaris?

  The package manager UI(or it's command line alternative "pkg" ) in OpenSolaris is the right way to update installed programs.  However, in 2008.11 (and onward) one may find that the package manager does not show that updates are available.  This is because of how the package repositories for OpenSolaris are structured.

 The package manager by default uses the package repository at   This repository is frozen(this is not completely true, since we're allowed to put security patches into the release repository after it's been 'frozen', but new features and other bug fixes are not allowed here) at the time of an OpenSolaris release and is updated only when the next official release occurs.  The 6 + builds that occur before the next freeze(for the next release) are not reflected in this repository. 

 It's a pity - with OpenSolaris, you don't have to worry about build instabilities, crashes etc., given all the good quality assurance that's built into the system - so one might(and probably would) prefer to stay on the latest build without giving up on stability. 

 But have no fear, there is an option for such users - the dev repository.  Please set  as one of your repositories(in the package manger tool).  In fact, I also set it to be my primary repository.  This way you can stay up to date, without waiting for the next official release; the dev repository is updated with every build.  So expect an update every two weeks(approximately).

To update the installed Ruby, click on the "Update all" button - this will download a wad of packages to update your system with.  The update takes a while, but this happens in the background while you continue working.  For other programs you may be able to get away with updating only the concerned package.

Saturday Jun 07, 2008

On allocas

The alloca call is used when one would like to dynamically allocate memory within function scope. Such memory is reclaimed after the function call returns, hence obviating the necessity of explicitly freeing the memory.
On SPARC, alloca is a macro, defined in alloca.h.

     55 #if defined(__BUILTIN_VA_ARG_INCR) || \\
     56 	defined(__sparc) || defined(__i386) || defined(__amd64)
     57 #define	alloca(x)	__builtin_alloca(x)

The compiler, when it pre-processes a source file containing an alloca call, replaces it with a call to __builtin_alloca(invoking a "cc -P" generates pre-processed source code into a filename.i, in Sun Studio).

After the file is compiled, however, the allocas may not show up when DTrace is used to profile the application. This is because the compiler generates inline assembly for the __builtin_alloca call. This happens even if inlining is disabled using the "-xinline=" compiler option. All that the alloca implementation needs is to decrement the stack pointer by the number of bytes allocated by the alloca call, and the code to do this is generated by the compiler in place of the alloca call.(there is an exception to this simple algorithm, which is documented by Darryl)
For example,

     #include <stdio.h>
     #include <alloca.h>

     void main(void)
       void \* ptr = alloca(262144);

is compiled into an object, which on disassembly(which can be done using the er_src command with Sun Studio) looks like
Annotated disassembly
Source file: ./allocate.c
Object file: ./allocate
Load Object: ./allocate

     1. #include <stdio.h>
     2. #include <alloca.h>
     4. void main(void)
     5. {
        [5]    10b70:  save        %sp, -104, %sp
     6.   void \* ptr = alloca(262144);
        [6]    10b74:  sethi       %hi(0x40000), %o0
        [6]    10b78:  sub         %sp, %o0, %sp
        [6]    10b7c:  ret         
        [6]    10b80:  restore     %g0, 0, %g0
     7. }

The save and restore calls are made on entry and exit from main, they obtain a fresh set of registers for the main routine, using a SPARC hardware feature called register windows. The alloca call is broken into the sethi and sub instructions. sethi sets the most significant 22 bits of register o0 with the 22 most significant bits of the hex value 0x40000(which is what the %hi achieves). the sub call then subtracts 0x40000(or 262144 in decimal), which is stored in register o0, from the stack pointer(-xO4 optimization was used to compile this code).

The alloca code is inlined in the object, hence a call to alloca(or __builtin_alloca) will not show up through DTrace or nm(unless the code falls into the exception category mentioned above).

A good way to trace this is to use the collector(and analyzer) or SPOT.
It helps if the binary is compiled using "-g -xO4 -xbinopt=prepare". Using -g does not reduce performance if -xO4 or higher is used, and -xbinopt=prepare does not affect performance.

Monday Jun 02, 2008

Where's my Ruby?

OpenSolaris is different from Solaris Expresses(ie., the SXCE and SXDEs) in that most of the software that comprises this release is not distributed in the CD media(or image that can be downloaded from

There's just one CD, and rest of the packages that comprise OpenSolaris are hosted on, and available through the "/usr/bin/pkg" command.

Ruby is not on the base CD image, but to have a usable version of Ruby on OpenSolaris 2008.05 is very easy, just issue the following commands.

-bash-3.2#pkg install SUNWruby18


Completed 1/1 1546/1546 8.50/8.50


Install Phase 1844/1844

-bash-3.2# which ruby


-bash-3.2#pkg install SUNWgcc


Completed 4/4 2035/2035 88.13/88.13


Install Phase 2457/2457

-bash-3.2#cd /usr/ruby/1.8/lib/ruby/1.8/i386-solaris2.11

-bash-3.2#mv rbconfig.rb rbconfig.rb.orig


After this point, one is set to install Ruby applications with C extensions . . . like Mongrel or Thin.

Monday May 19, 2008

How to install Mongrel, Mysql, and Postgres gems in OpenSolaris Ruby -

Rubygems is the preferred package manager for Ruby, and Ruby packages are called gems. While most of the gems out there are written in Ruby, there are a few that have C or C++ code in them for performance(like Fastthread for Mongrel), or Features(like the MySQL connector for Ruby).
Such gems need a C/C++ compiler to successfully be installed. Apart from that, they also need an appropriately configured rbconfig.rb file in the Ruby installation.
The rbconfig.rb file is typically present in lib/ruby/site_ruby/1.8/rubygems.rb - on OpenSolaris, it is present as /usr/ruby/1.8/lib/ruby/site_ruby/1.8/rubygems.rb
The rbconfig.rb file contains, among other things, information about which compiler(ie., the location) was used to build Ruby, compiler flags, linker flags, path to the C++ compiler, location of ginstall etc.,
This is strictly not necessary for C applications, ie., you can install a native gem compiled with CompilerB on a version of Ruby that was compiled with CompilerA, but the advantage of having the build time compiler flags captured is that you can optimize the extensions just as the Ruby binary was optimized(and the folks who built Ruby for you hopefully have done some reasearch in this area).
On OpenSolaris, there's a bug by which some paths in the rbconfig.rb file actually point to a compiler location that was used by the build infrastructure, and this location is normally not present on the system.
This is a bug that is being fixed, and the right paths should work out of the box. Until that fix shows up in the repository, here's how to make sure your Ruby installation works well.

If you have Sun Studio installed on the machine, use this rbconfig.rb to use Studio(it assumes you've installed Studio into /opt/SUNWspro - which is where it goes into, by default).

If you prefer gcc, use this rbconfig.rb instead (it assumes gcc is in /usr/sfw/bin/gcc - which is a symlink from /usr/bin/gcc).

After you've replaced the original rbconfig.rb file, installing native gems should be easy.
If you used the gcc version, then all you have to do is utter "gem install mysql -- --with-mysql-dir=/usr/mysql/5.0", "gem install postgres", or "gem install mongrel" to install these packages.
Note that the "--with-mysql-dir" option is necessary. OpenSolaris has two versions of MySQL, the ancient version(4.x.y) is in the default link path, which you don't want to link to, MySQL 5.x.y is in /usr/mysql/5.0

Also, I assumed that Sun Studio is in it's default path of /opt/SUNWspro. The rbconfig.rb files are for Solaris running on an x86/x64 platform. If you're using SPARC, modify your file with appropriate values for INSTALL, CC, CFLAGS, CPPFLAGS, LDFLAGS, and CPP from my files.

Sunday May 11, 2008

Ruby 1.9 very first impression

Program: ruby -e 'require "benchmark"; p Benchmark.realtime { a=0;1000000.times {a = a + 1}; p a} '

On a machine running OpenSolaris on AMD Opteron. The timings are:

x64 Ruby 1.8.6: 1.31seconds
x64 Ruby 1.9: 0.198 seconds

I'll want to run programs that aren't as simplistic, of course, but still, wow! that's an 84% improvement for this loopy.

Wednesday Mar 26, 2008

DTrace support for Ruby

DTrace probe support is now into OpenSolaris - as of build 87. Siva, an engineer in my little Ruby team checked it into the free software gate last Tuesday night.

Pretty cool!

DTrace is a great way to profile Ruby programs without introducing much overhead into the program you're tracing. This is a real boon considering that overhead is a big problem with Ruby profilers today.

Also, you don't need to make _any_ changes to your Ruby programs in order to narrow your profile to a set of functions.

DTrace rocks.

Below is an example of how to use DTrace to profile Ruby programs. The program traces through method invocations in different classes, and indents nested invocations accordingly.

Here's the program:

[root@dn10 dtrace]$cat rb_funcalls.d 
#!/usr/sbin/dtrace -Zqs
 \* How do you invoke this script?
 \* Use dtrace -xbufsize=40m -Zqs rb_funcall.d -c "ruby my_arg1 my_arg2"
 \* Where "ruby" is DTrace enabled.

 \* Thread local variable to
 \* store the indentation level
 \* during/after a function call.
 self int indent;

    printf("Starting to trace\\n");

    \* To ensure that we capture function
    \* entries and returnes made by a thread
    \* in order.
    self->thread = 1;
    self->indent += 2;
    printf("%\*s", self->indent, " ");
    printf("=> %s->%s\\n", copyinstr(arg0), copyinstr(arg1)); 
   printf("%\*s", self->indent, " ");
   printf("<= %s->%s\\n", copyinstr(arg0), copyinstr(arg1));
   self->indent -= 2;

   printf("Finished tracing\\n"); 
[root@dn10 dtrace]$

There are a couple of ways to invoke this - either start a process through the DTrace command line, or attach to an existing Ruby process. We'll do the latter since our program is rather simple.

[root@dn10 dtrace]$cat /tmp/hello.rb
message ="Hello World")
puts message
[root@dn10 dtrace]$

On uttering the appropriate DTrace mantra, the following ensues:

[root@dn10 dtrace]$dtrace -xbufsize=40m -Zqs rb_funcalls.d  -c "ruby /tmp/hello.rb"
Starting to trace
Hello World
  => Class->new
    => String->initialize
    <= String->initialize
  <= Class->new
  => Object->puts
    => IO->write
    <= IO->write
    => IO->write
    <= IO->write
  <= Object->puts
Finished tracing

A few comments about the invocation and the scripts are in order here. You don't need a very high value of xbufsize for a small data set, it's just illustrative. You really need the -Z option because it ensures that DTrace doesn't bail out with complaints that it couldn't find the ruby\*:::function-return(and other) probes. DTrace would otherwise do that when dealing with application level probes.
Moving to the script, note that it address the probes as "ruby\*". This means that the selected probes in all Ruby processes running on your system will be activated and profiled, not just in the command you just invoked. If you don't like that, and instead want to trace a specific process, two changes are in order:
1. In the script, change "ruby\*" to "ruby$1"
2. when calling the script - use "dtrace -xbufsize=40m -Zqs rb_funcalls.d my_pid" . Where "my_pid" is the pid of the Ruby process you're interested in profiling.
You can obtain more data from the probes, such as the source file being interpreted, and the line number. Use arg2 and arg3. An example of how to use them is:

#!/usr/sbin/dtrace -Zqs

    printf("Class name: %s, Method name %s, Source file %s,  Line number %d\\n", copyinstr(arg0), copyinstr(arg1), copyinstr(arg2), arg3);

To invoke the above script, just utter "dtrace -xbufsize=40m -Zqs rb_fn_info.d", and assuming that you have a ruby process already running in your system - you'll begin to see data like the below.(else use the -c option to launch a command. Or use ruby$1 and a command line argument for the pid that you'd like to latch on to)
Class name: Proc, Method name call, Source file /usr/ruby/1.8/lib/ruby/1.8/irb/ruby-lex.rb,  Line number 207
Class name: IRB::Context, Method name prompting?, Source file /usr/ruby/1.8/lib/ruby/1.8/irb.rb,  Line number 115
Class name: IRB::Context, Method name verbose?, Source file /usr/ruby/1.8/lib/ruby/1.8/irb/context.rb,  Line number 156
Class name: NilClass, Method name nil?, Source file /usr/ruby/1.8/lib/ruby/1.8/irb/context.rb,  Line number 144
Class name: Object, Method name kind_of?, Source file /usr/ruby/1.8/lib/ruby/1.8/irb/context.rb,  Line number 145
Class name: IO, Method name tty?, Source file /usr/ruby/1.8/lib/ruby/1.8/irb/context.rb,  Line number 156
Class name: Object, Method name kind_of?, Source file /usr/ruby/1.8/lib/ruby/1.8/irb/context.rb,  Line number 156
Class name: Object, Method name kind_of?, Source file /usr/ruby/1.8/lib/ruby/1.8/irb/context.rb,  Line number 157
Class name: IRB::Irb, Method name prompt, Source file /usr/ruby/1.8/lib/ruby/1.8/irb.rb,  Line number 116
Class name: Object, Method name dup, Source file /usr/ruby/1.8/lib/ruby/1.8/irb.rb,  Line number 266
Class name: String, Method name initialize_copy, Source file /usr/ruby/1.8/lib/ruby/1.8/irb.rb,  Line number 266
Class name: String, Method name gsub!, Source file /usr/ruby/1.8/lib/ruby/1.8/irb.rb,  Line number 267
Class name: Object, Method name ===, Source file /usr/ruby/1.8/lib/ruby/1.8/irb.rb,  Line number 269
Class name: String, Method name ==, Source file /usr/ruby/1.8/lib/ruby/1.8/irb.rb,  Line number 269
Class name: Object, Method name ===, Source file /usr/ruby/1.8/lib/ruby/1.8/irb.rb,  Line number 269
Class name: String, Method name ==, Source file /usr/ruby/1.8/lib/ruby/1.8/irb.rb,  Line number 269

And that's all it takes to get dangerous. You can of course do a lot of fancy profiling with all these(and I'll save that for a different entry, since I've got to get to bed in time for an early morning phone call ;-)

Tuesday Mar 18, 2008

Doing The Right Thing, or Why Rails is not in OpenSolaris

If you haven't been watching the discussion on, the news is that Rails will not be integrated with OpenSolaris or Nevada.
ie., an installation of SXCE/SXDE/Nevada/Indiana will have Ruby installed, but Rails will not be available by default.

The recommended way to install Rails and other gems is by using the gem command - using the famous utterance "gem install rails --include-dependencies".
And that's it.

I think this is the right position for us to take. I think it's quite a brave one, and one that shows that we are truly working as a community now, at least in my corner of the universe.
Think about it . . . with other OSes drawing users away from Ruby's native packaging, in order to "do it their way" - what would the natural response from an operating system vendor be? To say "Let it be, a good solution already exists in Rubygems", or "hey, we want XYZ library delivered through our mechanism, irrespective of what the problems are"?

Rubygems is the chosen package manager for Ruby, and abiding by that decision helps Ruby users on Solaris - and people get that. We got a a lot of comments from our user community, as well as from the good folk at Twitter about Solaris packaging for Ruby gems in general - and nobody at Sun, after having heard the story, ever said, "you know, Debian has it, BSD has it, so we should do it too".

And that's a brave step to take.

Thanks to all the folk that provided comments, please keep them coming, and I'm proud of the folk at Sun, for working sincerely with the community.

Monday Nov 12, 2007

What's cool in Opensolaris build 78?

I can think of one thing ;-)

We putback Ruby into OpenSolaris build 78! Ruby 1.8.6 patchlevel 110, Rubygems 0.9.4, and Openssl, Curses, Readline, and Tcl/Tk extensions are enabled.

The directory layout for Ruby is per the ARC case. Ruby is in /usr/ruby/, it's linked from /usr/bin so as to be easy to locate - the man page is also appropriately linked.

Same for Rubygems, it's available though a link in /usr/bin - and the default gem repository happens to be /var/ruby/1.8/gem_home (ie., $GEM_HOME).

In the mean time, the wish list has is getting bigger n bigger . . .

\*\*\*\*\*\*\*\*\*  This mail is automatically generated  \*\*\*\*\*\*\*

Your putback for the following fix(es) is complete:

    6622810 Bring Ruby, Rubygems, and Extensions into OpenSolaris.

These fixes will be in release:


The gatekeeper will mark these bugids "fixed" and "integrated" in bugtraq
as soon as the gate has been delivered to the WOS.  However, you can mark
them "fixed" (but not "integrated") now if you wish.

        Your Friendly Gatekeepers


Saturday Oct 13, 2007

rubygems for opensolaris

Rubygems seems quite easy to put into OpenSolaris. It is a good candidate for /usr/ruby(with appropriate symbolic links from /usr/bin, of course). The gem repository needs to be outside the /usr hierarchy to allow the repository to be administered by users of sparse root zones. /var/ruby/1.8 looks like a good place for this.

The question of versioning model, compatibility, and how to distinguish a stable version from not, all had extemely pleasing answers for a ardent-compatibility-supporter like yours truly :-) thanks to Eric Hodel.(this is data that I was able to incorporate into my ARC case for Ruby). It also seems that Rubygems will have their own release cycles, independent of being included in the Ruby train.

When Rubygems installs a gem with an executable, for example Mongrel, it ties the runtime to the currently installed Ruby version. ie., It uses "#!/usr/ruby/1.8/bin/ruby". and thus, Mongrel will still invoke Ruby 1.8 even when the end user upgrades to ruby 1.9.(it would be cool if Rubygems used "#!/usr/bin/env ruby" instead of hardcoding . . .)
This makes it impossible to reuse the gem repository across different versions of Ruby installed on the same machine.
So a /var/ruby/x.y/gems directory will ensure that each Ruby version has it's own repository.

Should be easy to write a program to migrate gems between these, given the gem cache directory in Rubygems.

Rubygems tends to complain when when invoked after being configured with the non default gem repository directory. This seems like an RFE to me, since you tell the Rubygems installation program where your repository is, why doesn't it remember?

I know, I know, setting the GEM_HOME variable will solve that. But that takes time. Maybe just a few seconds more, but time that doesn't need to be wasted for this.

Friday Sep 14, 2007

Have ideas for what goes with Ruby/Rails in OpenSolaris?

If you are not interested in Ruby on Solaris, don't read further.

Else . . . help decide! You opinions and rationale are crucial to make OpenSolaris better!

What's your favorite Ruby extension or gem?
Write to the "Open Source applications on OpenSolaris" community at




« June 2016