[unios] Re: Priorities

[Anders Petersson]

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

>From: Pat Wendorf <beholder@ican.net>
>
>> Pat's most recent list was:
>>
>> 1) Flexible
>> 2) Stable/Reliable
>> 3) Secure
>> 4) Fast
>> 5) User Friendly
>>
>> Anders wrote:
>> > Performance is the biggest hassle. I guess some effort has to be put
>> > into this.
>>
>> I think 4 and 5 should be switched.  The user (and programmer) is more
>> important than speed of the system.  If the program is not what you want,
>> or is not easy to understand, or is hard to maintain, then only the
>> original programmer will be in a position to appreciate the program being
>> fast.
>
>That has been bothering me.  User friendliness, as I understood it only
>applied to the User him/herself, not the developer.  But if you put it that
>way, it makes sense to make the system easy for developers also.  I have not
>posted the priorities yet, so there is still time to discuss them.

I was also thinking of "user" as the *final users* of the system, not
developers. I think these two groups are so different in their needs that
they should be separated from each other. The users could retain their
place, while developers get a higher rank.

>> Also, you may want to consider ease of use for programmers in addition to
>> users.  I don't know how you view the distinction in UniOS, but in TUNES
>> we strive to obliterate any difference.
>>
>> Pieter wrote:
>> > What about 'Stable' on 1 ??
>> Pat replied:
>> > I agree that stability is very important, but I don't know
>> > how we would focus on stability in the initial design.
>>
>> I agree with Pieter.  The system should NOT be able to disobey the user
>> and programmer. That is, it needs to conform to the specifications for
>> behavior laid out in the objects created, shared, and controlled by users.

Of course not, but that's not stability. That's security. Stability and
reliability to some degree comes as a product of security. Maybe we've
underestimated security?

>> That means no C-like inability to check array boundaries (for example).
>> You CAN focus on stability in the initial design: use strong type
>> checking, throughout the system.  This just means that operations are not
>> allowed to operate on values that don't make sense.  I am currently
>> developing a strong, integrated type system for TUNES, because I believe
>> it is the center of the system.  There will be no kernel, just this type
>> system.  All objects will take part in the type system (or they won't
>> exist).

Is the quality of the programmers' code really something system developers
can do anything about? How could it be?

Sounds like this type system provides the security, is that so? But what if
the binary code is altered - by mistake or on purpose? And can all
programming languages be used, or just one?

>> In TUNES we say stability and reliability are just by-products of security
>> (strong typechecking).  So when we say security we mean all three.

They are very much interrelated. But this strong typechecking idea is not
clear for me.

>When we say security, we are talking about the privacy/networked type more
>so.  Sorry for the confusion.

When *I* say security, I mean security among objects in general. This
should include all types of security (well, all related types).

>> So, my proposed revision of the priority list is:
>> 1. Security
>> 2. Flexibility
>> 3. Easy to Use/Program
>> 4. Fast

I've come to a different conclusion:

1. Generic design: (not priorited)
	* Security -> stability and reliability
	* Flexibility / Hardware indepencency
	* Consistence
2. Developer friendly
3. Fast
4. User friendly

Let me explain. This approach is somewhat different. As priority #1 I have
"generic design", which includes the listed features. They are not
prioritied, as they don't stand in opposition to each other and are very
much related. My version of the solution is mOS.

As for the order of the other priorities... 2-3 is because 2 really is a
issue for us and needs to be thought of from the start, while 3 (IMHO) can
be somewhat improved later on.
3-4: 4 isn't really our worry. User shells are not really part of the OS.
Not our primary concern, at least.
The flexibility slogan encourages us to let the final user systems to a
high degree be tailor-suited... not much of obligatory objects in the
system tree.

>I like the ideas you present, but I'd like to define some of the (possibly
>different) terms I use:
>
>Flexibility - The ability for the programmer/user to adapt the system to any
>possibly need, due to a flexible, and hopefully simple design. (Hence it
being
>in the #1 position - "Universal"Os)

The same as the first priority on my list - "Generic design".

>Stability - The need for the components that the system is composed of, to
not
>(be able) scrutinize the flow of run time code.  This does allow for
incorrect
>object usage (if binary is corrupted), as that is a logic bug, which should
>not take down the system.  As you say, this will probably involve a typecheck
>system.

_Compile-time_ typecheck?

>Security - The ability to maintain privacy in multi-user and networked
system.

I'd rather say: The feature that disallow inappropriate use of
system-visible objects.

>Fast - A measure of responsiveness to a given task (server processes, single
>user applications/games, etc.)

Why not a measure of the time spent on a certain task, in comparison to the
time spent on overhead?

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