This is a long one; a lot has happened since the last update.
The offer arrived, and I accepted. As of tomorrow, I end a 54-week unemployment (setting aside occasional consulting work in the interim) and start work as a Senior Systems Administrator with the Chicago Board of Trade. Tomorrow will be purely orientation with Human Resources and a bunch of other new hires, and Tuesday should start the real acclimation. I just wanna play with the E15k...:-)
Proving once again that I find stability boring, I jumped into the Red Hat Rawhide GNOME RPMs after taking a look at the latest GARNOME. Yay, transparent panels. ;-) On a more serious note, a few little quirks that were annoying me are fixed (Rawhide currently sports a mixture of 2.1.3, 2.1.4, and 2.1.5 GNOME packages), although I'm now having some trouble with icon theming for Nautilus (all objects, unless they have a specific Nautilus handler or a custom icon, are being displayed with the default blank-page icon).
This is the working name of a little side project I've been playing with, in an attempt to really dig into Python in more than a superficial manner. At this point, despite doing very little, it's probably one of the heavier users of python's restricted execution environment (which, I might add, I've had very little luck tracking down usage examples for at all, beyond the most basic uses of rexec and Bastion). The basic gist of the project is in the spirit of an LPmud (see LDMud, MudOS, and DGD for example implementations), but using Python as the embedded language rather than LPC (actually, the server itself is also implemented in Python). No, I'm not interested in writing a MUD (although that will prove to be a good basic proof of concept); the idea is to build a general object environment that can run relatively untrusted code (obviously, this is heavily dependant on the implementation of Python's restricted execution mode), much like the LPmud environment. Think in terms of a lightweight application server, and you have a good general idea.
The basics are in place at this point; clear communication channels between the "server" (kernel) and the contained environment ("mudlib", for lack of better terminology) are enshrined in a pair of objects that marshal access back and forth. I need to flesh out the kernel interface quite a bit, but the basics are there. The last remaining piece before it's ready to show off is communication between mudlib objects; Python doesn't provide easy methods for access control between objects, assuming that all code running is essentially trusted, which isn't true in this kind of application. So all object-to-object communication will be marshalled through the kernel object, which will "cleanse" what gets passed back and forth, using the equivilent of Bastion objects for everything; using this mechanism, I should be able to implement private and static members pretty easily.
Since I'm going to be commuting again, driving on a spare tire just won't do. Two new front tires now adorn my car (rated higher than what I had previously; it's always nice to upgrade), and the stalling problem I was having with boost levels over 10 psi has been fixed with new spark plugs. After extensive road testing ;-) I'd say the car is more than ready for daily commuting again.
Haven't had much time to work on SubWiki lately. I saw that gstein did a little bit of obvious cleanup of some stuff I checked in that should have been done before I checked it in. ;-) Hopefully, once I start taking the train to work, I'll have a little time in the morning and evening to get back to playing with it (although the Portal project has been sucking up a lot of my free hacking time, if only because it's been a whole lot of fun reexamining LPC-related stuff again). I fired off a few more patches for Subversion related to the SWIG bindings, and even had a chance to pop off a simple autoconf patch for Galeon. Whee!
That's it for now. Time for bed; going to be a busy day tomorrow.