Words of Advice

[jecel@lsi.usp.br]

.. and bits of history:

I designed a LogoMachine back in 1983 (didn't finish it because
I moved on to better things) and have been doing "exotic OSes"
even since.

A key to success is to be able to separate reasonable suggestions
from plain nagging. An example of the latter is all those people
who kept complaining about the Macintosh when it came out
because it had no slots. When they released a machine with slots
(nicer ones than the PC had, I might add) none of those people
were interested - they just moved on to other complaints! So
the proper response is to pay close attention to potential and
current users, but simply point the nags to an alternative
solution: "sorry, we don't have that. Try the store down the
road..." Of course, this doesn't apply to LispOS until it is
actually defined.

Similar to plain nagging is the ephemeral requirements. It
can be fatal to ignore those, as I found out when I sensibly
answered "no! that is silly" when my partner asked "can you
write a Unix OS in Smalltalk?" The proper response is to say
"of course" (and maybe even prove it is possible) and assign
it to some future, unspecified release. *Then* you can ignore
it, and you will find that as time passes and things change
that people will simply forget about it. Remember how Win NT was
going to have DOS, Windows, OS/2 and Posix personalities all
running in the same kernel? So there are some things you have
to promise to survive, but there is no need to deliver (am
I becoming a politician??).

Here are some decisions I made for my OS that may, or may
not, be relevant for LispOS:

- There will be two versions - one will run directly on
  hardware (PCs, initially) and the other will run on top
  of existing OSes (Linux and Win32 are my first targets).
  Sharing the machine lowers performance a lot, but also
  greatly reduces the "cost" of people trying it out. If
  they don't try it (and take a good look at how many neat
  things out there most people, including you, have never
  tried) they will never adopt it.

- Backwards compatibility is simply too costly. If they
  ever want to run something from the old days, then they
  have to boot an old OS (they can run my system on top
  of that, side by side with their old app).

- "Snarfing" drivers and other parts from working systems
  is so tempting, but I won't do it. If the only things
  I can get working in the first releases are VGA video
  and IDE drives and you need something more exotic, then
  get an old OS and run my system on top of that. See the
  Apertos OS for how continuations for drivers make most
  existing code look ridiculous. And I intends to use
  inheritance to good effect for all those strange hardware.
  How would I do that if I import drivers as black boxes?

- When running on other OSes (some systems that already
  do this: Inferno, Oberon, Pick, Magic Cap) try to blend
  in. My idea is that a person might find a tictactoe.xyz
  file on the net and download it to his machine. He then
  finds he must also get a xyz.exe to run this (much like
  all those pages that keep telling you to get Acrobat
  Reader to see their PDF files). Now that everything is
  ready, just clicking on the tictactoe.xyz file (or
  whatever works on this system) will bring up a window
  with the game in it. There is a whole other OS now
  loaded on the machine, but there is no need for the user
  to worry about this. Clicking on another .xyz file will
  launch it much faster as the OS is already up (has
  "booted"). And bringing another .xyz from the net is
  now as simple as any other file type. xyz.exe looks
  like a native executable to the host OS, but it could
  also be a plugin for a web browser (see Dolphin Smalltalk
  for a great example of this).

- I use the host OS as a "hardware platform". No native
  widgets, no font managers, etc. I just need some space to
  blast pixels to - let my code do the rest. My system doesn't
  have files ( just a global persistent object store divided
  into soups of objects called regions), but the regions
  can be encapsulated inside the host OS's files (like the
  .xyz examples above). This conflicts with the "blend in"
  idea, but if care is taken in having visual preferences
  (see Smalltalk/X for an example of this) so the look and
  feel can be varied, then the applications can match others
  running beside it closely enough so users are satisfied.

- The GUI should stand out in a crowd so that someone going
  past a long row of PCs will double back and take a second
  look at one running my system (see
  http://www.lsi.usp.br/~jecel/next/merlin_menu.gif). This
  seems to conflict with having applications run in their
  own windows and feel part of the host OS. My idea is that
  any object can be directly mapped to an output screen
  (or window, in the case of an underlying OS) and the GUI
  is just another such object. BTW, mapping a regular application
  object to a whole hardware screen is great for kiosks and
  other embedded uses.

I hope this helps a little, and doesn't just add more noise
to this hyperactive list...
-- 
-----=============( Jecel Mattos de Assumpcao Jr )===========-----
http://www.lsi.usp.br/~jecel/merlin.html | mailto:jecel@lsi.usp.br