<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
On 2009-04-10 22:44, <a class="moz-txt-link-abbreviated" href="mailto:jecel@merlintec.com">jecel@merlintec.com</a> wrote:
<blockquote cite="mid:5543122a$5bb86eaf$621c96c7$@com" type="cite"><font
style="font-family: Verdana,Arial,Helvetica,sans-serif; font-size: 10pt;"><font
face="Tahoma, Arial, Sans-Serif" size="2">Michael van der Gulik wrote
on Wednesday, April 08, 2009 9:39 PM<br>
</font><span style="font-family: Tahoma; font-weight: bold;">> </span>On
4/9/09, Jecel Assumpcao Jr <jecel@merlintec.com> wrote:<br>
> > My proposal is to use a separate system image and a user
image. You<br>
> > can't allow full access without also allowing accidents, but
a little<br>
> > structure goes a long way towards eliminating the latter. I
described<br>
> > this in a post to the SqueakNOS list:<br>
> <br>
> ...so you'd have one acting as the operating system, and one
acting as<br>
> the application?<br>
<br>
</jecel@merlintec.com>
<div>Exactly, though I see no reason not to allow many application
images at the same time. That would make using both Sophie and Scratch
in a machine with no underlying OS more practical, for example.</div>
<div><br>
</div>
<div>For the operating system image, I would actually have two: an
emergencySystem.image which would boot up initially and then look for a
currentSystem.image to which it would transfer execution after setting
up a watchdog timer. If the currentSystem.image is not found or it
fails to execute well enough to disable the timer (resulting in a
reboot) then the emergencySystem.image would execute all by itself and
present the user with enough resources to restore the machine to a
usable state.</div>
<div><br>
</div>
<div>The currentSystem would be a far smaller image (I imagine less
than 1MB) and wouldn't have any GUI or stuff like that. It would do all
of the low level stuff for the application images and would normally be
safe from anything that happens in these images. But it should be
possible to mess around the currentSystem.image from inside one of the
application images running remote tools (see Spoon). This would require
a series of steps on the user's part and would not normally happen by
accident. This is a reasonable balance between full freedom and safety,
in my opinion.</div>
<div><br>
</div>
<div>Note that practically everything I have described above already
exists - it is mostly a matter of gathering the parts into a coherent
system.</div>
</font></blockquote>
What lack is the last 20% of the work which takes 90% of the time and
is 5% as interesting as the rest of the system ;-)<br>
<br>
The SqueakNOS on XO need work on the TCP stuff to ease communication to
the rest of the world.<br>
I think image saving needs work as well, so changes to the system is
kept current.<br>
I like the idea of using different images for different apps, but that
need work to make it appear seamless.<br>
<br>
Karl<br>
<br>
<br>
</body>
</html>