Re: Ada Operating System

["Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org>]

"James Ross" <rem.jr@rem.webross.com> wrote in message
news:6c55au8m539tmegu6u7rpli47ik51ssvrm@4ax.com...
>
> I agree that such a "shoot yourself in the foot" mode should be a big
> inconvenience or you would have people using that mode to solve common
> problems.  I.e. logging in as root on UNIX to do the stuff you have to
> do. This mode should be for disaster recovery only and avoided
> completely under any other conditions.  A version of the OS could be
> compiled specifically for developing the OS itself that could switch
> easily between the modes **IF** that were necessary, I am not to sure
> that it would be.
>
Yeah, that's my point. Most of the time it isn't necessary or desirable to
run in a mode that is either realtime or has direct access to the hardware.
I could imagine that three tiers of operation for the OS might exist. One is
"Normal" mode in which it works pretty much like a standard workstation OS.
THe next is "Realtime" mode in which you can create processes that utilize
otherwise undesirable scheduling algorithms. And the third might be
"Glorified Program Loader" mode in which the OS might provide things like
device drivers and interrupt handlers, but otherwise, you've got complete
control of the machine. Getting into anything but "Normal" mode should not
be easy or accidental.


> One idea that came to mind is that during an install by the Admin a
> key would be given to him.  Something equivalent of an OEM key for a
> MS product. (aren't those a pain?).  Only on a cold reboot and with
> that key would he be able to enter the unsafe mode.  That key would be
> stored on the system encrypted using industrial strength encryption to
> make it very difficult for hackers to break it even if they did get
> passed the other security protecting where it is stored.
>
That's one way. The exact hows and whens are a matter of design, but just
simply making it something that doesn't happen just because you've got
privileges is what's important.


>
> You could come up with an Open Source License that stipulated that you
> can use it for free but you can't publicly distribute it.  Also, any
> changes made to the OS code base must be given back to the project.
> Then maintain a single distribution point of releases.  Anyone wanting
> to make sure they got the "secure" version would then make sure they
> got it from that single distributor. This would definitely avoid the
> distribution plethora like you have with Linux.
> JR
>
Well regardless of license and distribution, it comes down to a question of
what sort of promises are you willing to make about a large body of code.
Most folks would say "Without any warranty... but we believe it is A Good
Thing" which amounts to nothing more than marketing because it has no teeth.
I personally wouldn't want to put my business and other assets on the line
over a body of code that I can't control. I *might* be willing to stand
behind a specific executable that I built and rigorously tested, but if I
hand out the source code with it and allow you to recompile it, all bets are
off.

MDC


--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com