Re: Ada OS

["I. Levashew" <octagram@bluebottle.com>]

Paul wrote:

> OpenBSD values security, correctness and standardization, all of which I 
> see in Ada.

Well, security is currently something fashionable. Nobody wants to be 
the one not concious about security. But Ada isn't being mentioned more 
often. I had impression that it's a good show business to be 
security-concious. Cyclone, Fortify Source, Singularity. Cyclone 
pretends to fill "an empty niche". Fortify Source makes money on finding 
security issues in a source code, but without any reference to Ada. And 
Singularity pretends to be "absolutely secure" OS, mostly in modified 
.NET with tiny pieces in ... guess what? "verified C++ source code". 
Microsoft .NET implementation had critical vulnerabilities like any 
other OS component. How can one believe that "this time they'll maid 
something real".


In these circumstances one argument remains unbeaten: programs must not 
do bad things not because they were not allowed to do them. Most people 
forget one simple thing: virtually no any developer ever wrote

if Shell_Codes.Argument_Is_Shell_Code(Argument) then
    Shell_Codes.Run_Shell_Code(Argument);
end if;

in their programs. Security measures such as SELinux, chroot, 
Capabilities, etc. can only be secondary layers of prevention, not the 
primary one.

Returning to the original topic, there are many independent decisions to 
be maid when designing OS distro. OK, let's write everything we can in 
Ada. What's next? Currently there are many identified problems in modern 
OSes. One of them is extremelly high complexity of OS. Good example is 
Windows. After using it for a long time you are losing control over it. 
Different programs can alter some OS files, registry keys. Three years 
past installation it can be difficult to remember all the changes maid 
to the system. The only good way to backup such a system -- to dump the 
whole system partition. Next generation OS must be managed in a 
functional way. One property of a function is exploited here: it's 
deterministic. It must produce the same results wherever and whenever it 
was invoked. It must be simple to build up any program for any 
architecture with any configure options. Building crosscompilers, 
managing compilation process must be done via underlying subsystem. Nix 
package management is far from being perfect. But it is aimed right. In 
Nix OS functional way of doing things is also applied to system 
configuration, not just package management. If one could express the 
whole system with set of expressions in a functional language, it'll be 
easy to backup the whole system, manage multiple identical(or not so 
identical) workstations and servers and add a new ones. Ideally, without 
long hours of installation process. Thouthands of files present in 
modern OSes would be just cache of functional expression computation 
results. And provided that functions are really deterministic one can 
allow workstations to exchange their cached expressions.

SELinux is about managing rights in a functional way.

As you can see, both Nix and SELinux have nothing to do with Ada. These 
are independent design choices. And there are many other independent 
design decisions to be maid. Fortunatelly, there was enough time to 
identify common problems.

IIUC, Nix and SELinux are not currently integrated. I think their 
combination can be good step towards next-generation OS. Like SEBSD, 
SEDarwin are SELinux way of managing rights applied to BSD and Darwin, 
let's call it Senix. Sounds good, no?

God in the details. Each detail matters. That's why next-generation OS 
must be written in Ada, but it's neither the least nor the most 
meaningful detail.

IMHO.