As of right now (Tue Jun 17 11:09:13 PDT 2008), the “Ruby Enterprise Edition” download page contains the following little gem (green rounded boxes are my own addition, of course):

(In case there are problems with the image for anyone, the gist is that they list a download link as being for “All operating systems”, with a footnote that specifies that Windows and Mac OS X aren’t supported.)

I’m not trying to be a jerk about this, really. Hell, truth be told, I think it’s kind of great that they’re focusing on Linux instead of OS X or Windows — I’ve been a Linux user for a long time, and I certainly prefer it by a wide margin for production servers.

But c’mon, guys. “All operating systems” most decidedly does include Windows and Mac OS X. I think you’re doing good work, but you seem to be consistently over-selling the portability and generality of your solutions.

Hannah received her Master’s in Urban and Regional Planning yesterday from PSU. She’ll be starting work as a bicycle & pedestrian planner at Alta Planning & Design in a week or so, but for right now, we’re both enjoying the bit of downtime that comes with the end of the school year.

…and every bit of it is tightly coupled to the iPhone and its restrictive platform lock-down. This makes Microsoft’s attempts to push IE-specific browser extensions looks downright innocuous.

No wonder the music labels and Hollywood studios consider Apple a threat: they’re out-maneuvering them at every turn, and their customers thank them for it. The same evil that gets MS roundly condemned from here to Slashdot is accepted with a smile because the hardware is just so damn sexy.

Oh well. I guess I’ll just hang out in my un-sexy computing ghetto. Having been a Linux user since the days when Slackware was the big dog, I’ve certainly gotten used to being a second-class citizen when it comes to any sort of commercial development.

The parents, in particular, seemed to have basically given up on their kids being able to find work, due to the classic “you need experience to get experience” Catch-22. I personally found myself desperately wanting to yell back at them to stop whining, and start helping their kids out with something other than rides to the mall.

Going to school absolutely does not prepare kids for the workforce. Nothing short of work prepares people for work. There is an endemic assumption right now that the only reasonable course for a young person is through the K-12 system, then straight on to college, perhaps with a brief detour into a volunteering stint along the way to help pad the college application. This track produces exactly the kind of clueless, over-privileged 22-year-old that Baby Boomer managers love to complain about.

Admittedly, my own perspective on this is a bit skewed, compared even to a lot of my coworkers and friends. I started working in the summers when I was 14, and year-round by the time I was 16. My first job was running a summer reading program at the local county library branch, and I locked it in before the interview even started by being the only applicant to show up wearing a tie, resumé in hand. I continued working for the year I was in college, and have been supporting myself (and other people as well, occasionally) since I was 18.

Not every one of those jobs has been pleasant — packing boxes for shipping at a Mailboxes, Etc. during the Christmas season, for example, or making salads at a pizza shop — but I’ve learned something useful from each and every customer, project, and boss. 

Of course, no parent would want to listen to the advice of a college dropout who has no kids of his own, right? Obviously, college and a pure white-collar background are the only real path to success.

#include <stdio.h>
#include <signal.h>

/* Total idle timeout before sending signal to parent */
#define TIMEOUT 120

/* Verbose debugging output */
#define VERBOSE 1

static unsigned int idle_time = 0;

static void sig_handler(int sig) {
  switch(sig) {
  case SIGALRM:
    idle_time += 1;
    break;
  case SIGUSR1:
    idle_time = 0;
    break;
  }
}

int main(int argc, char **argv) {
  pid_t parent = (pid_t) 0;
  int remaining;

  parent = getppid();
#if VERBOSE
  pid_t my_pid = getpid();
  fprintf(stderr,
          “[%d] Waiting %d seconds to kill PID %d…\n”,
          (int) my_pid, TIMEOUT, (int) parent);
#endif

  signal(SIGUSR1, sig_handler);
  signal(SIGALRM, sig_handler);

  while(1) {
    alarm(1);
    remaining = TIMEOUT - idle_time;
    if (remaining <= 0) {
      kill(parent, SIGINT);
#if VERBOSE
      fprintf(stderr, “Boom!\n”);
#endif
      break;
    } else {
      pause();
#if VERBOSE
      if (remaining % 10 == 0) {
        fprintf(stderr, ”  (reaper) %d seconds remaining\n”, remaining);
      }
#endif
    }
  }

  return 0;
}

The specific project has involved writing a couple of plugin modules for lighttpd, which has also proven to be relatively painless. The API docs are pretty solid, and none of the bundled modules are larger than a thousand lines of code or so. (Compare that to, say, mod_dav.c in the Apache 2.2 distribution, which is 3-4x larger, and requires a half-dozen additional support files.) It actually only took about four hours to bang out the first module, and I’m proud to say it happily hooked itself into the server without the usual first-run segfaults I’ve come to expect from C code that’s using unfamiliar APIs.

Let me say this upfront: I have a lot of respect for the guys over at Gemstone. They have some serious pedigree in the Smalltalk world, and they’ve done a good job of spinning that expertise into continuing business in the heavy-duty enterprise space. Ruby and Smalltalk obviously have a lot in common at the language level, so I can see the appeal of building a next-gen Ruby runtime atop a stable, tested Smalltalk VM.

However, I think that there are a couple of red flags worth noting here. First, as quite effectively laid out by Charles Nutter of the JRuby team, executing Ruby code in a mode fully-compatible with MRI is very much not the same thing as being able to run some programs written in Ruby syntax. The surface syntax of a language is only a small part of its overall semantics, and evaluation is much more complicated than parsing.

Avi and the Gemstone team are very bright cookies, and I don’t doubt that they’ll eventually be able to hit whatever level of Ruby compatibility they set out to achieve. If that means running Rails, I have little doubt they’ll be able to run Rails. If that means 100% compliance with the growing corpus of Ruby specs being developed by the other runtime projects, I have little doubt they’ll hit that milestone, too. There may be some impact on performance, but overall, I would be shocked if a solid, mature JIT-able VM like Gemstone’s wasn’t running circles around MRI.

Regardless, I personally am still unlikely to use MagLev in a more than cursory fashion, or recommend its use to others. I’ve worked in teams whose core product was dependent on the availability — permission, even — of a proprietary tools vendor[1]. Smalltalk and Common Lisp toolchains (the latter being the arena in which I have more direct experience) have both had this problem for decades: the best implementations are closed-source, costly, (to the tune of several thousand dollars per developer, plus hefty runtime royalties and/or deployment licenses[2]) and tend to encourage platform lock-in with all kind of alluring features like fast, large-scale object stores that are 100% incompatible with any other language or development tools.

In my opinion, proprietary runtime stacks are also pretty much incompatible with open source, at least in the sense of “anyone being able to contribute to the project.” While the core language features may be portable between MagLev, MRI, JRuby, Rubinius, IronRuby, FooRuby, RubyOnAStick, et. al., the object database API most definitely will not be.

As a language geek, I’m definitely curious to see where these guys can take MagLev. Personally, though, I would have been a lot more excited to see Ruby on the Squeak VM or GNU Smalltalk, if the point was simply to show what Smalltalk runtimes can bring to the table for Ruby programmers. By tying the first Ruby-on-Smalltalk implementation to a proprietary toolchain, Avi & Co. may have doomed it to occupying the same edge niche that Smalltalk and Common Lisp vendors have been forced into for the last 30 years.

(Edit: Avi himself has now weighed in with a brief recap of the presentation, including some clarification of the release and licensing plans. I don’t necessarily think that anything he said really argues to the points I make here, but it’s worth a read.)

I can feel myself getting stronger already, and I know that more of my energy will return once my body has done a bit more healing from the surgery, but that doesn’t make it less frustrating right now. It’s a busy time of year, both for me and for my friends and family, and I don’t want to make it worse for anyone (myself included) by needing to be chaufferred everywhere.

The big upside is that I’ve already lost at least five pounds, and expect that to be followed by another ten or so in the coming weeks. Not being able to cook anything elaborate or walk to my favorite nearby restaurants has cut my food intake considerably, and every step on the crutches is basically requires an ab-crunch and a half-curl of both biceps. Cutting basically all alcohol consumption doesn’t hurt on that front, either.