On Thu, 8 Aug 2002, Alan Grimes wrote:

> Squeak should _NOT_ use X, as that would be redundant and wasteful. I
> beleive that recient kernels have a "framebuffer" device of some sort.
> Development should focus on using these.

The only complications to using the framebuffer directly are the cursor
(since we have to draw it ourselves) and reading the mouse.  The first is
just code and the second is not too difficult on (linux) kernels with the
new input layer (if your /dev/mouse is a link to /dev/input/mice then
reading the mouse is almost as easy as reading the terminal keyboard).  
On kernels without the input layer gpm can be used to do protocol
transation from the hardware mouse to something more easily digested by
portable software (cf, the "-t" and "-R" options).

If anyone is serious about using the framebuffer directly to do something
interesting with Squeak then I'm prepared to spend a couple of hours
adding support for it.

> It should not be terribly difficult to support these provided that
> squeak can launch system-level processes using the same methods init
> does.

A regular fork() and exec() should be all that's required (assuming you
don't care about forking respawning processes like getty -- although a
little expedient wait()ing via OSProcess could provide much of what init
does on behalf of these "system" processes).  The clever stuff then
generally happens in the subprocess.

> On a squeak system that seeks to be a step on an evolution to pure
> squeak, extranious software must be keept to the absolute minimum. 

Maybe the most useful clever thing done by a process spawned from init is
setting up a tty for interactive use (this involves much more than just
opening /dev/whatever, writing "login: " and waiting for a response) which
is usually the domain of getty.  If you wanted to run without getty yet
retain the possibility of forking an editor (or mail reader or whatever)
then the PseudoTTY plugin already does enough to make running interactive
processes from Squeak (in the absence of getty and friends) a reality.  
(I haven't tried it but the PTY plugin probably already does most of the
setup that programs like /bin/login require in order to work happily too,
although I'm not sure how interesting it would be to log in to a "bare
bones" kernel+Squeak system -- maybe to run ifconfig when everything
breaks? ;)  Things like inetd should "just work" if fork()ed from a
Squeak-pretending-to-be-init (assuming the config files and demons are in
the right places).

Ian