Re: For the AdaOS folks

["Warren W. Gay VE3WWG" <ve3wwg@NoSPAM.cogeco.ca>]

Randy Brukardt wrote:
> "Warren W. Gay VE3WWG" <ve3wwg@NoSpam.cogeco.ca> wrote in message
>>>But in our hypothetical OS each possible way of access will be
>>>represented
>>>by some safe system object. These objects, when properly designed will
>>>provide necessary administrative services.
>>
>>If you are a night watchman for a Mall, which situation makes it
>>easier to sleep at night when you've locked up and gone home?
>>
>>   1. A mall with one or two doors on the outside to be
>>      locked and checked.
>>   2. A mall with thousands of doors on the outside to be
>>      locked and checked.
>>
>>The answer is obvious. Sure, it is ok for other doors to exist
>>inside the mall (for each store), which can be locked, but it
>>only makes sense to choke the security at a minimal number
>>of points.
> 
> There are other requirements than security! 

Of course. Did I ever claim that this was the
only requirement?

> I think the fire dept. would be
> pretty unhappy with (1) - at least if you ever let anybody in. Same holds
> for OSes; you're going to need multiple ways to get things done; you can try
> to minimize the number of "doors", but its unlikely that you can get down to
> just one.

Yes, practical issues prevail, but to use a different example, I doubt that
banks would like the idea of buying vaults with more than one door.

I was illustrating a "general principle", and I stand by it as a principle.
Will there be exceptions to it? Probably and it depends on the specific
problem you are solving. Exceptions are generally understood to exist
when discussing general principles.

> BTW, I think Dmitry's grand vision is on the right track. The tough part (as
> always) is mapping that to something that still is practical. 

Exactly. We can all talk about grand visions until the cows come home,
but that doesn't get us anywhere. I don't have a problem with "vision",
but it needs to be discussed in the context of "how are we going
to accomplish it?"  Otherwise, it is a vision that will never be.

> Why shouldn't
> an Ada OS take advantage of Ada's features to provide persistence,
> synchronization, and the like? 

I'm not against these basic needs, and certainly not against Ada,
or Ada methods (this is the whole reason I embarked on this project).
But Ada BTW, is where some of the work belongs (for example Ada.Streams).
In the mean time, the project will have to at least consider alternatives
if portability becomes one of the goals (I am not sure that it must be).

> Sure, you'll have to go beyond that, too, but
> why not start with Ada's fine features in this area?

Randy, this is precisely the issue (going beyond that). How?  No
"how" is being offered in the present discussion. I am pretty
open minded about things that make sense to do, provided that
they _can_ be done (and provided that all of the extra work doesn't
fall to me.)

I can talk about a lot of pie-in-the-sky stuff too. But if we don't
ever take it beyond that, it will just become another empty project
on Source Forge. There are enough of those already.

In fact, the "registry" issue always seems to bring out strong
feelings. So I say, go off and SF a project to fix it the way
_you_ want it to work. It need not require a new O/S to prototype
So if someone wants to prove me wrong with a prototype - I
welcome the event!

As a side note, my little project will eventually be put up on
SF, so that others can meddle with or otherwise contribute to it,
if they want. But my suspicion is that a lot of hand waving will
disappear when it comes to actually implementing something. ;-)
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg