This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Discovering Smalltalk
Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml
Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general.
Ted Neward takes a look at Smalltalk, and likes what he sees - with a few questions:
And suddenly I wonder, Is this the source of all that XP goodness that the Smalltalk community gushes on about? If we had the ability to "load" a JVM or CLI instance into a frozen image, and ship that, say as a 24-48 MB "image" file, think about the possibilities--less startup time (I would think, since this could be a more or less memory-mapped image), plus I could conceivably give my customer an ability to "freeze" an image if a bug hits, and email or FTP the image with the bug in it to me for diagnostics. No more having to recreate the problem! It's all right there, for me to load, inspect variables, and so on.
The worry comes here:
Then again, there's security questions--what stops an attacker from mangling an image and injecting some rotten stuff? Is the image format well-known and easily subversible? If I started using Smalltalk as a back-end HTTP-processing agent, is there weird buffer-overruns or command-injections that could corrupt the image somehow?
There's no way to do a buffer overrun - in .NET speak, Smalltalk is a managed environment - immune to that kind of thing. As to command insertion - you can't load code from a remote location unless the server is set up to do that sort of thing. I have this server set up to load code from a known (server side) directory for patching, but I have to have permissions to place code there in the first place - and the directory is not in the web directory side of things, so it's inaccessible from there.
More generally, and image is just byte code - it's somewhat like a big JAR file, but with the ability to extend and override any code you want/need to. I do live updates whenever I have new code - without taking down the server. The nifty thing is this: If I load in a new version of a class, all the existing instances get updated - i.e., if I added/removed an attribute (instance variable), then all the instances added/removed it as well. That's what makes live updates feasible. The site that hosts this server is running VisualWorks (part of Cincom Smalltalk), and the only attacks I've suffered have been the kinds that all bloggers suffer - comment and referer spam :)
Now one more thing - as to bugs? There have been a few times I've had to debug the server - in which case I've started it up with a GUI, using X over ssh. And then I've debugged the actual problem in the live server as it was handling load. If I wanted to do that with less fuss, I could set up the remote debugging tools that use Opentalk - which I intend to do, when I get a few spare minutes :).
Previous Topic
