ORG: Subjects

[luther (l.w.) stephens]

Greetings,

I do not know what mailer this is (I believe that it is tunes). So forward
this message through the appropriate mailers if I have failed to do so...

This project, this group, this initiative...

The last first. This initiative is THE step into our future. I beleive
that Mike is on to some things here that (coincidentally I have been 
mulling over in the back of my mind also) and are the future of computer
engineering.

This group. For this to work we need some structure both centralized and
decentralized. The centralized structures:

	1. Centralized communications. We need one remailer. Second we need
	   a topics moderator. Someone who will pick the current topic
 	   to discuss and only forward mail along those topics. We are currently
	   as a group suffering from brain diarrhea. That is we have too 
	   many good ideas oozing out of our brains. Lets agree to each
	   keep a record book that we can jot down our ideas in, so that we
	   can present those ideas in a concise and appropriate manner.
	   Also we need to take time to mull over peoples ideas so that
	   we can "work through them".

	2. We also need someone who will volunteer to be the central workbook
	   keeper. In other words they are willing to keep a central design
	   document that we submit our work to...

The decentralize structures:

	1. Eventually we need to form groups that are working on common pieces.
	   These groups must have team leaders, et cetera.

	2. We also need to have some formal processes to support our independent
	   work.

Sorry that the above is brief, but I am not a good process person, I just 
can identify what is missing. I beleive before we tackle any of the project
we need to tackle the above...

NOW ON TO THE IMPORTANT STUFF

I keep seeing in the discussions threads about low-level languages, high-level
languages, likeness (compatibility) to other OS (unix,dos,...). This is not
what we should be striving for or even worrying about! I have a firm belief
that Operating Systems are an ARCANE concept that is slowing down the progress
of both the development of software and hardware.

What we generally consider Operating System varies from the perspective that
you approach it from. For instance a true hacker views an operating system 
as the set of capabilities that schedule system resources (et al). The user
views the operating system as the way the computer "responds" to them. An
application views the operating system as the set of utilities that are 
available to it. So forth, et cetera... All but the first (the capabilitites
to schedule resources) are really "views". And indeed, the first is a fixed
view that we run into problems with as architectures change (try getting a
plain unix box to support a multi-proc machine).

Ideally what we should want is four layers (please use and interpret "layers"
loosely). These would be the device class layer, the system layer, the 
view management layer and the application layer. They would appear like

____________________________________________________________________________
|                                               |                           |
|          Application Layer                    |                           |
|                                               |                           |
-------------------------------------------------                           |
|                     |                                                     |
|                     |                 View Layer                          |
|                     |-----------------------------------------------------|
|                                               |                           |
|          System Layer                         |                           |
|                                               |                           |
-------------------------------------------------                           |
|                                                                           |
|                           Device Class Layer                              |
|---------------------------------------------------------------------------|

To analogize this with PIOS, the view layer would be the PIOS toolbox.

What do each of these layers represent?

Device Class Layer:
This is the layer of device specifications. In an O-O sense this is the set
of classes for each type of device that logically represent that device. The
device class layer would present a uniform interface (regardless of the device
to the rest of the world (everything up above).

Every physically piece of hardware should be modeled as a device. This includes
motherboards, processors, et cetera. Yes processors. Each class of devices
should (as stated above) present a uniform interface to the world. So all
motherboards and processors would look the same to the world above it. 
Optimazation of the device would be performed by the device class.

System Layer:
The system is the representative entity of what capabilities (physical) are 
available to the world (everything above it). The system schedules resources.
However, for this to be effective the system needs to be a highly evolvable
entity. This means that if you plug in second processor, then (without taking
the system down) you should be able to evolve the system.

View layer:
This is where we get Unixes, DOSes, et cetera. We can provide any view that we
like. The view layer is where the presentation of everything underneath it
is decided. Do we want to present ourselves as a Unix machine...? In fact
we can present any view or combination of views to the user that we would like.

This is also where a set of tools could reside. Tools that the application
could use to "build and manage" itself.

Application Layer:
I would rather call this User layer. Whether a user is an application or 
a physical person is regardless.

So what does all of this mean? First we don't need to worry about views
right now. We should design so that we can provide any literal view
of the system. Second languages are irrelevant (wait). We (as a group) need
to decide a general language to use to develop this, but we do not need
to constrain users of our system to use a specific language. In fact,
we should take a smalltalk like approach and allow for the parsing and 
definition of any language (little known secret of ST).

More to follow
_________________


I am sorry that this is quick, there is a lot more to this. In fact I am
writing a paper on this (but it will not be completed for a while).

I will follow up with more thoughts later.

Luther (Luke) Stephens