SqueakSystem

A walkthrough of how you'd install the hypothetical Squeak system. A few notes:


 * This is at the lowest level, clearly; higher level is possible, even trivial, but this is the most illustrative
 * Squeak is a graphical environment, but for familiarity I'm sticking with command-line. I'm using Ruby-style syntax, for the same reason.
 * The important properties of Squeak I'm pretending exist are:
 * It's a VM, not just an interpreter
 * It's late-binding, meaning that modifications to the code take effect immediately

So, let's get started!

You have a SqueakSystem installer in your hand; it's a CD, USB drive, whatever. You stick it in the computer and boot. It autoloads.

Underneath it all, there's still a Linux kernel. When Linux (meaning Ubuntu GNU/Linux) boots, the kernel loads into memory, and then it immediately launches a process,, with PID 0. This process is responsible for launching the system.

SqueakSystem works something like that, but instead of launching, it launches a Squeak virtual machine. This is a language virtual machine, not entirely unlike Java, for example. Inside the Squeak VM, some hook runs--some function/method which will do some basic initialization.

Soon, you arrive at a prompt:

Interesting. This is kind of what you'd expect, if you were installing, say, Gentoo. In that case it'd be a bash prompt. What is it in this case? It's an interpreter prompt. If you want to see a Ruby equivalent, try  in Linux. You can try some stuff out:

So it's a full language shell, with some libraries attached. If you really wanted, you could program yourself a simple OS here and now, but you don't really want to do that, do you?

So, instead, you want to pull a system from the Internet. To start with, you need to get connected. Luckily, this installer VM has come with a basic networking library built in.

This looks just like some sort of command-line tool, and so it is. It's just that you're running the code directly.

Alright, now we want to start installing some useful stuff. First, we're running on an in-memory VM right now; we want to actually install, right? We need to be able to store stuff on the hard drive, right?

We may have the option of using ext3 or ext4 or BtrFS or whatever, but we can go meta. Somebody coded up a pretty decent LVM-style tool, which we want to use.

It's not included in the install VM, though, so we'll have to grab it. Where Debian and Ubuntu have, we have a similar tool which deals directly with source code. Let's call it. We'll use it to grab the storage manager.

Okay, neat, we've grabbed it...now what? Well, let's ask it.

Okay, nice, we've got some storage available, let's use it.

Now we've copied the running system onto this array of disks that StorageManager found for you. If you restart the system now, you'll end up right back where you are now. But where we are kinda sucks, let's spruce it up a bit.

So you were briefly in bash, or a bash-like shell. It was running inside the VM. While there, you used  (actually just a frontend for SourceManager) to install vim. Bash can be used for familiarity, but we don't really wanna use it right now. You can use it later.

You can install more stuff now; maybe an X server? But that has dependencies and stuff. And you don't want to fetch your whole system package by package, do you? So let's jump the gun and install a meta-project. In fact, a meta-meta-project.

So this takes an hour or two, of course. Eventually, it merges code from all kinds of sources. It is not, you should note, installing binary packages; it's actually going to the source projects and grabbing the source code. That source code is being merged into your running system.

So far, you may be raising an eyebrow; you can already do all this stuff. It just seems more complicated. Why would you want to add the extra VM into the mix? Seems crazy, right?

What the hell...busted code! And hey, we can see where the problem is. That's better than a segfault and memory dump, right?

So what do we do about it?

The code pops up, ready to edit.

Consider, now, what would be required if you set out to fix X, currently. You try to boot it, and get a segfault. What then?


 * 1) You download the source code (already non-trivial!)
 * 2) Unpack somewhere, poke through it a bit
 * 3) Check out the core dump, try to figure out what went wrong
 * 4) Once you've located the problem (hopefully), make some changes to the code
 * 5) Compile
 * 6) Move the files into the correct location (or anyway, set up the environment; can be difficult, especially with something as large and integral as X)
 * 7) Try to start X, probably crash.  Repeat steps 3 through 7.

I've never even attempted that. Here's what I do when X crashes: give up. Or, fiddle with configurations, hardware...anything but code. The code is for the developers to deal with, not little old me.

Compare and contrast with what is possible in SqueakSystem:


 * 1) Edit the class--this is not the on-disk code which will be compiled into the executable that will eventually run, this is the running code, residing in memory
 * 2) Try to spot the problem (note that you should be able to check the values in each variable, and look up the stack at who called this method--all available in a core dump, sort of, but not nearly so handy; here, we can poke around in a snapshot of the system when it crashed)
 * 3) Save your changes, and resume execution
 * 4) If you fixed the problem, execution will resume where it left off; otherwise, repeat steps 2 and 3 as necessary

You fix the problem, and X finishes booting. Neat. Now you're running something that looks like Gnome. But, in the process of telling me about the crazy coding you had to do to get X to work, you get annoyed because...well, you can't make out my buddy icon. So you middle-click on it (or something) and select "edit code". This brings you to the Jabber window code, where you add an event for clicks on the buddy icon; this resizes the icon to be twice as big. Toggles the size, actually.

You tell me you did that. "Neat," I say, "Can you send that to me?"

You send that to me, and on my end, I pull your changes:

Immediately after performing this fetch, I click on the buddy icon in the window. It grows.

"Hey, that's kinda useful," I tell you, "You should push it."

"Hmm, I guess," you say.

Somewhere in the world, a couple of Jabber developers just got a message saying:

They check it quickly with a diff, then:

The next time people around the world using the JabberClient devel branch update their Jabber clients (with something like ), their buddy icon will be resizeable with a click.

Now consider: You decide one day to make JabberClient send all messages to one specially-defined master client, which will log all conversations. Oh, shit, you did that wrong...revert. No harm done.

Try again a few days later, with your new knowledge, and hey, that's pretty cool. Push changes.

A few days later, I have the same functionality. Oh, and also, some dude in Albania modified it so that there's a button in any Jabber chat window to fetch 100 lines of past conversation from the central repo.

Major changes are full-on branches; you might start working one day, and instead of pushing to jabberclient.org, you publish your own URL for people to try out your version. Over time, a few people start collaborating with you. Eventually, you might merge it back with JabberClient. Or, maybe not.

Then we play a game of OpenTTD (or SqueakTTD, whatever). Midway through, you get annoyed because the buses keep taking the wrong road. So, you middle-click on one of them, open up their routing method, and...

You get pissed off for the last damn time that 'Quit' appears in the 'Buddies' menu in Pidgin...

You get sick of searching for "Format Character" in OpenOffice...

You wish that RhythmBox's pop-up display also displayed the next song in the queue...

Hey, would it be possible for Rhythmbox to control mpd...?

So, there's the core part of the vision: Wikipedia + Linux, with the help of git or some other distributed version control system. By that I mean:


 * 1) It's software, and it's the software running your system, but
 * 2) It's easy to modify, anybody can do it, changes are immediate, and spread quickly

That's vital! To see why I think so, read The LinusPedia to see how different Wikipedia might have looked. It might have been relatively static, slow-moving, small. Relative to Wikipedia, I mean--it might have been competitive with Britannica. But Wikipedia doesn't compete with Britannica. It's not slowly eclipsing it as the superior encyclopedia. Instead, in a handful of years, it rendered old encyclopedias obsolete. Linux is to Windows what an Audi is to a Ford...or anyway, well, there's huge differences in how they're built, and one is way more flexible, but in the end, they're still both cars. Wikipedia is a jet plane to Britannica's car. "We can get to Winnipeg in a day, la dee da...HOLY FUCK I CAN GET TO THE OTHER SIDE OF THE WORLD IN HOURS!"

It seems to me that the possibility exists, in software, for really dramatic, paradigm-shifting change (heh). Your system could be improved in a crazy exponential way, instead of the current incremental approach.

Heh, and a generation could be left in the dust. Things could possibly change so damn fast, once the ball gets rolling...

The 3d is extra. It's not the key part. Or, well, maybe it's orthogonal. Here, I suppose, is the thing: you don't need 3d to get this easy-edit, easy-share part of the system, which is really maybe the more radical of the two changes. On the other hand, you do need this before you can get to the 3d.

Why is that? I think the problems involved in moving to 3d are too big for a company to solve. Jesus, imagine try to imagine Microsoft moving to a 3d, WoW-style desktop! It'd be a terrible nightmare!

It's been tried. Second Life tried it, and they did pretty well. It was game-like, but you could program! ...Of course, you were limited to their in-game scripting language, which was designed to build toys. Oh, and they charged you for the privilege.

Think about that a minute! A 3d 'metaverse' (or whatever), in which toys could be created, change, evolve...but the world they were in was basically static, only changing when the developers (all ten of them, or whatever) got around to it.

So, if you have a system like the one I talk about above, and you turn that on a 3d world, you can multiply creativity by, er, the numbers of users you have.

What's the best interface for a 3D world? Desktop-and-windows style? Something different? Well, how about we try all of them and see (instead of having a three-person brainstorming session and then hard-coding it)?

And, well, I believe, deep down, that 3d (if done right, through massive, Wikipedia-sized levels of effort) would be a huge step ahead. If I imagine that all the software I want already existed, I can tell a really cool story about how you'd go about a day's work in Cobalt--especially if you happened to be, say, a grad student (international collaboration on projects you're coding in the world you're moving around in?).