[unios] Re: UniOS Definition & Direction

[Anders Petersson]

From: Anders Petersson <anders.petersson@mbox320.swipnet.se>

At 1999-01-07 , you wrote:
>From: Pat Wendorf <beholder@ican.net>
>
>> > Premise #1 - What UniOS IS
>> >    UniOS "standard" is _only_ the specific binary format that the
>> > objects are stored in, and the backwards compatible, well defined,
>> > hardware abstracted objects and drivers that the system is promised to
>> > have on each platform to allow cross platform development.  Essentially,
>> > this is all that we are creating... A new, simple, portable, flexible
>> > yet well defined standard for application development.
>>
>> So UniOS is going to be some sort of standards body?
>> Replace POSIX?
>
>I wanted to shy away from creating any standards and be completely based
on work already
>done, however this seems like a better (only) way of doing things.

I see mOS as the foundation (including maybe a few basic standards) to the
UniOS project. UniOS also encompasses auxiliary (but necessary) standards
and implementations.

>> > Premise #2 - What UniOS ISN'T
>> >    UniOS "standard", is _not_ the boot loader, the configuration
>> > methods, the IPC, the memory manager, the language, object
>> > interaction/sharing/ordering,

I agree. Especially the view of languages is different from Tunes.

>> > the script format,
>>
>> I may disagree on this. Language Oriented Subsystems may still
>> have some value.
>
>So maybe the script format should closely follow the object format (except
in plain
>text), and be part of the UniOS "standard" definition?  After thinking
about it, I may
>have to agree on this.

The script language should not strictly be a part of mOS, but *should* be a
UniOS standard.

>A singular first release with the absolute basics to get things rolling,
and then people
>can do what they want with the system.  This includes any outside project
customizations,
>and distributions.

This lays far ahead in time.

>> > Premise #4 - What UniOS MIGHT BE
>> >    If we end up with a fragmented UniOS Project, and if every fragment
>> > follows #1, all systems would be application level compatible.
>>
>> Very likely. Computers are used in so many diverse ways, a true
>> 'Universal Operating System' is _very_ unlikely to work.
>> But a standard . . .
>
>What I mean is that the object format remains the same across all
implementations.  How
>the system looks/acts, is a totally different matter.  If we end up with
so much
>disagreeance on low level implementation, then we may have to compromise
on having
>different running models.  My hope however is to make all the potential
variations into a
>whole, and have something that can watch the system and determine how it
is used, and
>automatically (or manually), plug in the right system components.

I agree. Compatibility between different flavours is important.

>> > I feel it's time to start working on some standards.

That is not what I feel. How likely is it that a handful of random people
come together, talk for a couple of months, and then creates the best OS
ever? We're not even clear over the design yet.
Our time will come. Eventually.

>> It will have to be broken down into specific catagories of
>> standardization. It would be best to start at the programing
>> level [APIs] and work our way down.
>
>I was thinking to start on the object format first, then move on to the
hardware abstract
>objects/drivers.  If we vote on the necessity of a kernel, then we will
work out the
>kernel API, otherwise we determine which functions go into the system
abstract.

NO VOTE! If we reason about it, we will discover if it's needed or not.
These are technical issues, not beliefs.

And please, don't rush ahead. If you do, you will miss the careful design
that we *need* to be able to succeed. If an OS of this kind was easy to do,
why are there so few of them, if any at all? Not because the system
designers weren't quick enough, at least. Rather the contrary.

>> > We have, in the
>> > last few months discussed almost every advantage and disadvantage to
>> > every known OS model, and have come to some important, well informed,
>> > logical conclusions. I'd like to state the two that I think everyone was
>> > not be able to choose between, and possibly force a decision out of
>> > everyone, or at least improvement of the document:
>> >
>> >
http://members.unios.com/proposed_final_layout.html

Neither of the models presented on that page are enough detailed or 100%
correct. They won't do for "final models".

>> > If anyone disagrees with these concepts, speak up.

I disagree with 1) your eagerness for votes, and 2) your haste.

>> Maybe the project should be divided into a cooperating 'Standards Research
>> Group'
>> and an 'Implemention Reasearch Group'. What do you think?
>
>Until the standards group is done, the implementation group would not be
able to do
>anything, so I'd rather if all members worked on the same ideas at the
same time.  That
>way we can all participate.

I agree with Pat. The standards are needed for implementation - they cannot
"cooperate" in their respective development.

binEng



------------------------------------------------------------------------
To unsubscribe from this mailing list, or to change your subscription
to digest, go to the ONElist web site, at http://www.onelist.com and
select the User Center link from the menu bar on the left.
------------------------------------------------------------------------
UniOS Group
http://members.xoom.com/unios