Over the years I have come a long way toward a close philosophical alignment with the Free Software movement. Yet I’ll shamefully admit that my two computers are an iMac running OS/X and a Acer running Windows 7. Of course, nearly all of my projects are undertaken in Linux virtual machines which I fire up in the host environment. I just didn’t want to cope with issues of finding drivers for the proprietary hardware of machines that were already “working”.

This week I took one more token step toward a free software stack, by migrating from proprietary-ol’ VMWare over into open-source VirtualBox. Although they use different virtual disk formats (VMDK vs. VDI) it is possible to convert between them using a free tool, just like this:

VBoxManage clonehd image.vmdk image.vdi --format VDI

Yet the format of the virtual disk file is a minor hurdle in the scheme of things. The real problem with switching from one virtualization system to another is that all the “virtual hardware” changes. You basically have a whole new video card, processor, BIOS, sound device, keyboard, ethernet interface—everything changes. There can be problems booting after the switch if the operating system tailored the installation for only the hardware you had at the moment you ran the setup.

Fortunately modern operating systems were designed to roll with such punches. Manufacturers and users alike will pull parts out of the computer and put new ones in. So there’s enough of a “lowest common denominator” lingo that even super-futuristic graphics cards can go into a 640×480 mode long enough to let you see the dialog boxes for installing a smarter driver designed for it. My Linux installs came through just fine.

But I keep a VM for Windows XP too, that I pull out in those circumstances when I need such a thing. Predictably…Windows had some esoteric trouble on VirtualBox with agp440.sys and intelppm.sys. A helpful article I found suggested to essentially delete them and it starts working. I did a little reading and agp440.sys is related to a deprecated standard called the Accelerated Graphics Port; it seems that removing it does not seem to prevent the Virtual Machine from having accelerated 3D services. intelppm.sys is related to power management and turns off the processor if the CPU is effectively idle, so it is likely superfluous to a virtual machine.

(Note: I did have to turn on the VirtualBox setting for enabling “‘IO APIC” to appease mup.sys but did not see the CPU utilization bug mentioned in Ticket #638. So I decided not to follow the convoluted process of using SysPrep to rewire things so that I could turn that check box off.)

So after a couple hours of tinkering, my Windows VM came up under VirtualBox…though it gave me a warning. My hardware had changed sufficiently that its “Genuine Windows” status was invalidated. It told me I would have to activate it again within 3 days.

“Or what?”, you may ask.

In this case the “or what” is “we won’t let you into your system”. You type in your password and it announces that you’ll be going into the activation process right now, else no soup for you. It didn’t even give me the 3 days it claimed; in the course of less than 24 hours it decided to jump me straight to OS death row.

(A long way to go, just to harass users of an operating system the company DOES NOT EVEN SELL ANYMORE.)

My one copy of XP is very old. The wily holographic disk has the orange license key sticker stuck directly on it. I’ve used it on several computers, all of which basically either died and got thrown away…or were formatted with Linux and given away to charitable causes sans any of my personal info. Yet I don’t know how many times I can push this magic “activate” button before it decides to say no. Plus I hadn’t even installed the VirtualBox tools that let Windows magically embrace things like integrating the mouse pointer with the host…what if I activated, then installed those, and it decided it was a new computer all over again?

As it happens, I restarted in Safe Mode and it decided to let me in. I installed the VirtualBox tools and rebooted and clicked “activate”. It let me activate (for now…at least while these activation servers happen to be around.) But this is another zen lesson about what it means for something to be Defective By Design. My small dependence on a few Windows tools and desire to assist people with problems (such as porting solutions to not need Windows) will hopefully be phased out before I should ever encounter another Genuine Windows Disadvantage!

This is the second of several articles I’m going to write about the REBOL programming language. To learn more about it, you can visit rebol.com. But my hope is to demystify some of its strengths and weaknesses in a way that their website currently does not, so if you read what I write first then it might help.

(Clear Warning: REBOL is not “free as in freedom” software, and no commitment has been laid out for how the commercial scaffolding which supports its development would be phased out. I know of no published statement that RT would not sue ORCA or other open-source efforts to implement the language. Until these issues are resolved, I consider it only an interesting thing to study and do *not* suggest its use in important projects. While REBOL may rebel against complexity, I think the rebellion for freedom is more fundamental—and the infrastructure we build on is too crucial to be left in the hands of one company that decides who may use a tool and how.)

REBOL’s advocates tout the language as a “rebellion against software complexity”. But what does that actually mean? Ruby and Python advocates ask how it differs from other modern interpreted languages. What they’ll get back usually boils down to “the interpreters for every other language, plus their libraries, plus the source code you feed into them, are too many bytes for what the end result achieves.”

I do poke a bit of fun of their obsession with size, by comparing it to Saturday Night Live’s “Tiny Elvis”. In the sketch, Nicholas Cage is shown dressed as a miniature Elvis who points to common household items and remarks about how “huge” they are:

  

Tiny Elvis: Hey, man.. look at that salt shaker, man. That is huge! Man, I’ll never be able to use all that salt, man. That is way too much!

Red: Yeah, that’s a big salt shaker, Elvis!

Tiny Elvis: Sure is huge, man.

Sonny: That’s hilarious, Elvis!

Red: Score another one for the Tiny E!

Tiny Elvis: Well, I’m just saying it’s a big salt shaker, that’s all.

Red: [ laughing ] There he goes again! That’s why he’s the Tiny E.

I’ve envisioned REBOL’s architect Carl Sassenrath miniaturized at a modern workstation. He’d be bemoaning the misapplication of the hardware, as “Tiny REBOL”:

Tiny REBOL: Whoa now. Look at that Firewire drive, 750 Gigabytes! I run in 750 Kilobytes. What would *I* ever do with all those bytes?

Fork: [ laughing ] Man, you’re going tonight, Tiny R!

Despite my friendly kidding, I agree that size can be a good barometer of when complexity has been managed well. It’s not the only indicator and shouldn’t be taken to extremes—such as by giving variables short (but unclear) names. Yet if a very small system can do what you’d think a much larger one would be needed for, it bears a closer look.

Plus, I do think REBOL can be rightfully called a revolution against most of today’s programming methods. In this article I’m going to try and tackle the philosophical basis for why I believe it.

(more…)