[unios] Re: Priorities

[Anders Petersson]

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

At 15:00 1998-12-04 -0500, you wrote:
>From: Pat Wendorf <beholder@ican.net>
>
>> I do not think that an OS for everyone is impossible. But I, as the only
>> person here as it seems, have in mind that there *are* trade-offs.
>
>There will be tradeoffs... but they may not be as serious as we may all
think.  I
>do agree with you here :)

Good... the tradeoffs could be minimized by having the system flexible...
as we plan to.

>> The examples you mention can well be fitted into the same OS, and I think
>> UniOS should do it all. In principle I'm not against the OS for everyone...
>> but if giving speed as high priority as Pieter wants, you are making it
>> extremely hard for yourself.
>
>I think what pieter and Diemian (Disuke) were saying, was that if you
design the
>system well, the speed will just fall into place, without any conscious
thought...
>Good design promotes speed. We do not have to sacrifice on our
design/flexablity
>ideals.

Let's hope that is the way.

>> Actually, I'm not very fond of the term 'hardware abstraction'. Why not
>> simply call it 'drivers'? We still know what we mean... and it's shorter to
>> type.
>
>Drivers is fine if you want it shortened.  However I think there is a
fundamental
>difference between them, so I gave them another name.  Drivers also have set
>methods of interaction, but don't mirror the hardware on multiple levels.

Our construction is very different from the traditional approach, yes...
but they still resembles drivers most of all. I'd prefer to call them that.
If I do, you know what I mean.

>> What you think is a good system depends on what characteristics you are
>> looking for. That is what I was trying to say, and I guess it's most of all
>> a fact, not some personal opinion.
>
>Yep.  We haven't yet defined what a good system means to all of us...
"good" is
>kinda abstract... lets define what a good system consists of ASAP.  I
think this
>will reduce the arguments we are having... (not that they're really
arguments...
>just strong ideals :)

When designing the system, we can't do so with our personal view of a good
system, but with the view of the target users, what the users wants. And
our users are... that's right - everybody. So, what is important for users
in general? All features we've mentioned. We're back at square one.

>> Of course speed has to be thought of. When the system comes to the final
>> user. However (you knew I'd say that, not? :) ), if speed is to be the
>> second most prioritied feature, you are not looking for a generic system,
>> but some critical industrial system.
>
>Embedded... PLC... whatever you wanna call it... I'm sure some other
people can
>make those systems better than we can.

Yes... but then we go away from the 'OS for everyone', aren't we? I feel a
little divided about the 'everyone' target...

>By giving speed higher priority than generic solutions, you are effectively
>
>> defeating your own goal; an OS for everyone. We need generic solutions. The
>> opposite is solutions for specific situations and environments. Maybe the
>> importance of generic solutions becomes more self-evident now?
>
>I think you should write a semi-document in the list, so we can all
understand
>what generic means... I understand from our constant mails, but others might
>not...

That is a good idea. I'll look over my presentation to Beholder and post it
here.

>> For critical uses, a flexible system can be customized to improve speed,
>> like by disabling the multitasker and shutting down daemons and such...
>
>My thoughts from the beginning....

Yes, I admit the idea was yours... but now it's ours! :)

>> Performace a big issue because of compability? I can't see why.
>
>I don't think I do anymore either... the entire purpose of a generic
system is to
>allow a generic interface and programming... not a generic methods of
>processing... I don't think anyone said we had to have a fixed processing
style...
>that went out of style with Unix :)
>
>However, I do believe we can provide different processing styles within
the same
>product...  We only have to make the very basic interface, and the codified
>program distribution methods universal... the rest is up the the
>implementation....

I don't understand the term 'processing style'... could you please explain?

>Hot swap kernels, processing and memory managers...  does anyone see why this
>would not work?  Does this not satisfy the requirements of a Universal
Operating
>system?  Does it constrain the user/programmer?

What we should look at first is: Is there really a need for this? If there
is, is the gain in proportion to the cost? If the answer to any of these
questions is no, then we don't need to bother about it.

>For example, I've worked in Home/Corporate/Industrial computing
environments...
>(hence the project organization).  It's not an equal distribution of
experience,
>as I have not worked in the corporation as long as I have worked in
industry or
>home computing...  This makes me opinionated in certain directions.... the
ones I
>know best :)

I've got a wide experience in home environments... and very limited
corporate experience. That's not a even distribution... and it makes me
less aware of industrial needs. But I'm sure you tell me whenever I'm
missing something...

>----------------------------------------------------------
>I'd like to say this to all of you now:  If at any point the group does
not feel
>like the project is going in the proper direction, or will not fulfill the
>requirements of the ideas presented, and this is somehow my own fault, I
will give
>the leadership position to any one of you who feels they can bring the
project to
>it's full potential.  HOWEVER: The person who goes to this position, must
be voted
>in unanimously by all other members.  That person will get control of all
>resources associated with the project, including the Web page, Mailing
List, and
>membership control.
>--------------------------------------------------------

There's absolutely no thought about that... and there will probably never
be either.
Other from that, the procedure sounds reasonable.


------------------------------------------------------------------------
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