Osnews runs a brief story about SqueakNOS.
Most comments are about how useless this project is, I guess they have not used Squeak ;-)
Karl
Karl Ramberg wrote:
[...] Most comments are about how useless this project is, I guess they have not used Squeak ;-)
Yeah, plenty of ignorance there. But that doesn't mean there aren't some real problems looming ahead. One of them was identified in this paper:
Yasuhiko Yokote, Fumio Teraoka, Atsushi Mitsuzawa, Nobuhisa Fujinami and Mario Tokoro, "The Muse Object Architecture: A New Operating System Structuring Concept", Sony CSL technical report SCSL-TR-91-002, also appeared in Operating Systems Review, Vol.25, No.2, April, 1991, February 1991.
http://www.sonycsl.co.jp/project/Apertos/techpaper.html (has a .ps.Z version of the paper - it is number 24)
The authors propose a new architecture for operating systems: reflective OSes. More interesting to us right now is that they review previous alternatives and talks about their problems. These are:
- layered structuring (THE, Multics) - hierarchical structuring (Cal, Pilot, Cedar, Choices) - policy/mechanism separation (HYDRA, ARTS) - collective kernel structuring (Chorus, MACH, V-Kernel) - object-based structuring (HYDRA, StarOS, Medusa, iMAX432, Eden, Amoeba, Clouds) - open operating system structuring (Pilot, Smalltalk-80, Cedar) - virtual machine structuring (VM370) - proxy structuring (SOS)
You might find it surprising that the authors didn't consider Smalltalk-80 to be an object-based OS, but I would have to agree with them. It was implemented in an object oriented language but there was no clear separation between system objects and application objects. Their main complaint against open OSes is the total lack of security. They agree that it gives you great powers (insert Spiderman quote here) but the risk of accidents is high and there is no way to deal with intentional attacks.
The same is true of the current design of SqueakNOS, of course. A single typo in a critical place or a user poking around where they shouldn't can bring the whole thing down. Certainly this is something most people would associate with MS DOS and stuff like that.
Though I am very much a fan of reflective OSes (my Neo Smalltalk design was previously called Self/R for this reason), I have a far simpler proposal that might make SqueakNOS more practical: instead of running an image and VM on the bare hardware we could run two images. The first one would be the "system image" and would include everything that SqueakNOS now has and what is being developed for it. The second would be the "user image" and could be any unmodified Squeak image at all. Since it was not modified, it expects to run on an OS and once in a while will invoke some primitive to communicate with it. The VM would then convert this to a message and send it to the system image (I am supposing a Hydra or Spoon style system) which would deal with it.
The advantage is that no code in the user image can ever crash the machine. Only the system image poses this risk, but only SqueakNOS developers should be messing with it. The system is still fully open since the system image can be accessed (but not by accident!) and all the usual Smalltalk resources are available for changing it.
It is easy to imagine generalizing this to multiple user images. Each one would be fully protected from the others though they could still communicate when needed.The system image might handle the frame buffer and allow the various user images to share it (and keyboard/mouse) in a controlled way. If some GUI locks up you just press some special key sequence and switch to another that is still working. You can kill the bad image if there is not a better alternative.
Obviously it would be nice to reduce the system image as much as possible. There is no need for it to play chess or be able to send emails. One advantage of sharing normal user images with other platforms is that you no longer have to SqueakNOSify the OLPC image, Sophie, Scratch,WebImage, etc.
With several images sharing the same RAM it would be nice to be able to store the common bits only once. But that is another story....
-- Jecel
squeaknos@lists.squeakfoundation.org