Now, where was I?

A year has passed since I last worked on SecureSqueak. Babies do that to you. So now, I ask myself: what was I doing!?

It appears I was trying to set up a completely independent class hierarchy / object graph with no dependencies on Squeak's classes. In other words, my own Class, Metaclass, Object and so forth, all in a Namespaced environment rather than in the SystemDictionary (known colloquially as the "Smalltalk" global object).

This is trickier than it seems. All of the above need to live "in" a Package object. As an object, it is therefore an instance of the Package class, which has Class, Object and so forth as superclasses. So these (Class, Object, etc) all need to be made first... but then these classes in turn need to be in a Package (called "Kernel"). Thus, we have a chicken-and-egg problem. We need an instance of Package, which is an instance of a class inside itself (and further, compiled by a compiler which is in another instance of Package).

My solution is to file out the core packages using my current tools: Kernel, SourceCode, Compiler, Namespaces, NamespaceTools, etc. Then I do this:

1. File in (but do not compile) the Kernel package, using the existing compiler and a custom filing code.
2. Make the new Metaclass singularity by hand.
3. Compile the Kernel package using whatever compiler is available, using the new Metaclasses.
   
4. File in and compile all other dependencies using the resulting Kernel. These will all be discarded once the second kernel is built.
   
5. File in the Kernel source code again into a separate PackageSource, this time using the new Kernel (above) for the Object, Class etc classes.
   
6. Now, do a whole lot of "special case" handling on the new second Kernel, using and sacrificing bits from the first, to make the new Kernel completely self-contained. This is quite a complex step so I'll spare the details.
   

Thus is born a set of objects with no links whatsoever to any Class in the SystemDictionary.

SqueakOS the cheaters way

Cold boot to Squeak under 6 seconds? Possible. I haven't actually automated it yet, but it is possible as described below.

Tiny Core Linux is a mini Linux distribution that is, before boot, only two files. One is the Linux kernel. The other is the entire filesystem which is loaded into RAM. These two files are packaged up into a bootable .iso image for burning to a CD, although you can put them on any bootable medium and boot them using grub. You can put these files on an existing Linux partition on your hard disk, for example. The "tiny" version is 10MB and has a graphical interface and package manager! The "micro" version is 6MB and is only a command line. They boot really fast.

Now, the micro version can be used to run Squeak:

1. Boot it up using one of the "vga=" command line parameters to get a working framebuffer. You could use grub to persist this setting.
   
2. Get Squeak into the filesystem somehow. I used wget to fetch an image and the Linux VM from ftp://ftp.squeak.org/. A more permanent option would be mounting an existing filesystem.
   
3. Become root (sudo su) to run Squeak, or fix the permissions on /dev/input/mice.
4. Run squeak: "bin/squeak -vm-display-fbdev".

This is not quite as cool as SqueakNOS, but it is a practical, easy and stable way of running Squeak as if it were the OS with good hardware support and a filesystem.

Squeak vs Pharo

How does Squeak compare to Pharo?

Well, people will have different experiences. Some will find the features of Pharo appealing. Pharo comes with a huge range of developer tools: syntax highlighting, autocompletion, code refactoring tools and a whole lot of smaller enhancements that people might like.

Pharo looks nicer than Squeak. They've dared to change the menus around, in my opinion, for the better. They've taken a lot of inspiration ("blatently copied") from the Macintosh UI. They've also changed much of the interaction with the user, although the whole UI still freezes up whenever the image is doing something (please, learn to use multi-threading! It isn't hard!).

I've been living on Pharo for the last 6 months because I wanted to use and modify the NewCompiler. I've gone back to Squeak. Why? Pharo is too slow. I have a Celeron clocked at 1.7GHz. Pharo's debugger takes forever to appear when something goes wrong. The browser is very laggy to type into. The UI in general looks like a Porshe, but certainly doesn't perform like one.

The deal-breaker for me was that Pharo couldn't load a Monticello package I wrote. Pharo would freeze up, and alt-. would not recover it. Apparently this has been fixed in the later releases.

So I'm back in Squeak. It's still slow like Squeak is, but at least the debugger comes up in a reasonable amount of time.

Dammit, Nethack!

I have been a bit... distracted lately by a certain chaotic elven wizard with a penchant for Yendorian amulets. I'll be back into SecureSqueak shortly.

NewCompiler

I want to use the NewCompiler in SecureSqueak.

The main reason for this is that I want to use its IR ("intermediate representation") objects for moving code between images. The IR is effectively the bytecodes, but in object form, one object for one instruction, such that a final compilation step can be run on them to make CompiledMethods.

This is important in SecureSqueak as it makes implementing a "bytecode verifier" much easier. Instead of verifying the bytecodes for incorrect variable accesses, invalid jump destinations and so forth, we just get the kernel to run the last step of compilation itself. This makes it impossible (*ahem* less possible) for malicious bytecodes to be injected into SecureSqueak.

The rest of the compiler is completely optional. You merely need *something* that can generate the IR — it doesn't even need to be Smalltalk code.

The current NewCompiler maintainers use Pharo, so I'll be moving development over to that for now.

UGP / SecureSqueak 0.1 released

Download from here: http://sourceforge.net/projects/securesqueak/
Or watch the video: http://vimeo.com/6698843.

This is the first release of my "Unnamed Grand Project". It includes the SecureSqueak kernel (kind of), SiteBrowser, Subcanvas and the DPON object replication framework. Currently the "SecureSqueak kernel" is just the Squeak 3.10 kernel converted to use namespaces. Version 0.2 of UGP will start introducing security into it.

This release is for show and tell only; it barely works and isn't at all secure.

Subcanvas, with windows!

...and they actually work, too! The yellow parts are the borders; you can drag them around, and clicking on them brings them to the front.

The Subcanvas API is starting to prove that it really can work. The yellow bits are a subcanvas. Each of those contains a subcanvas with the window contents. The background is a subcanvas. The buttons (grey things with text) are subcanvases and will pop up a brand new window when you click on them.

Next up: choose better colours and make the test sites actually do something.