[unios] BAck to the basics

[Anders Petersson]

>Let's get back to the basics of computing...
>And design an OS model form there. We are designeing new models
>which have beautiful features we don't need but lack the things we _do_
>need. That's not the way to go. Before thinking of some 'innovative' 
>model, that in the end is nothing more than existing stuff, we should
>think at how computing is organized. 

Which features we need and which we don't need is a relative question. Do
we _need_ computers at all? The goal is not to be able to *do* something,
but to do it *efficiently*, may it take whatever features are needed.

But yes, we need to touch the essence in computing, we need to reveal the
intentions in the operations.

>So, let's start with 100-years-old stuff such as the Turing model, and
>the Neumann model on which all modern computers are built. Let's start
>with the first diagram in every course on computers:
>
> INPUT -----> PROCESSING -----> OUTPUT

That's a representation of an intention all right, and a basic one too. You
wish to take the input and produce the output.

>When new models are designed in the UniOS group, this basic thing seems to
>be forgotten. We cannot avoid it however, because it's how the hardware of
>Turing/Neumann - computers is built. A Neumann computer is basically based
>on the idea that data and code are one : code can be seen as data and
>acted on as such. (code can be written etc.)

Well. I have not forgotten it, and mOS incorporates the idea, even if I
haven't described that yet. (There's more of mOS than what's written in the
"published" document, I hope you have been aware of that.)

>Some process acts on data and outputs other data: e.g. a graphics filter
>acts on some image data and outputs anotehr format, or a text processor
>read a data file and outputs the formatted text on screen.  
>
>Wether you use a functional or object-oriented system, this is the same.
>The problem with all new models is that we think far too much on how to
>make them beautifully object-oriented without regarding what functionality
>it should have. 

Depends on how you define "beautiful". I think of the term (in this
context) as a solution that elegantly and satisfactory reaches all stated
goals within the target problem domain.
With such a definition, you can hardly have a beautiful design that doesn't
look to functionality.

[snip]
>So, while unix follows a scheme
>like this:
>
> input file(object) ---> process ---> process ---> process ---> ouput data
>
>a system like this should be possible:
>
>                              ___|process|-->output
> input object --- |         |-| 
>                  | process |---|    
> input object --- |         |---| process|--->output 
>                              |            |->output
> input object ----------------|

You're right, the latter case (as well as the former) is not only possible
in reality, but maybe common too, and should really be possible.

>I hope I did make sone things clear...

You did speak out, but if it was your intention to really add something new
to the view of the flow of data or related issues (more than you sketched),
I think you'll have to elaborate, because in such case I didn't understand
the essence of what you wanted to say.

binEng