I am so liking this pattern:
Archive for June, 2008
I suppose I’ll probably get jumped on again for this, but I just couldn’t resist pointing out how weird it is.
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.
Everyone’s going to be having a love-fest this week over the new 3rd-party apps being developed for the iPhone. They’ve got streaming media, location-based services, bidirectional news and blogging tools, and full 3D-accelerated games.
…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.
I was listening to OPB on the radio last week, and their morning call-in show Think Out Loud was hosting a discussion on teenagers in the workforce. They had an employment economist who worked for the state of Oregon, an 18-year-old just starting in the workforce, and a variety of parents and teens contribute to the discussion, but I was struck by a weird sort of defeatist tone beneath the entire conversation.
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; }
I’ve been spending a fair bit of time writing C this week, and have to admit that I’m enjoying it more than I expected to. After spending most of the last 3-4 months fighting tooth-and-nail against Rails’ inclination to completely own every data source in my application, as well as trying to make big, memory-hungry web app server processes behave well under load, it’s been refreshing to strip things back to basics, and see my old friends char* and errno.
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.
There’s been a lot of breathless blog coverage of MagLev, the new Ruby-on-a-Smalltalk-VM implementation from Avi Bryant (of Seaside and DabbleDB fame) and the Smalltalk wizards at Gemstone. They did a demo a RailsConf 2008 which showed insane performance gains over MRI, (like 10x to 100x, depending on the micro-benchmark chosen) and since the OOBMS is baked-in, they got to casually toss around numbers like “17 Petabytes.”
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.)
1) My primary contribution to the last such team I worked on was actually porting the entire project from , a proprietary version of Lisp distributed by Franz, to CLisp, an open-source (but much slower) alternative. This was only possible, though, because the system used only a fairly portable subset of the overall Allegro CL runtime, and avoided any dependencies on their proprietary extensions to the language, including their very-nifty object database.
2) While I would like to be more precise about the price of licensing Gemstone/S, or any of Gemstone’s products, I’ve been unable to find any prices listed on their website.
Recent Comments