From: Dmitry A. Kazakov on
On Wed, 13 Jan 2010 10:09:58 +0100, Georg Bauhaus wrote:

> Dmitry A. Kazakov schrieb:
>> The problem is that we followed the wrong path for too long. All these
>> standards (XML to name one) are based on these flawed untyped file - "don't
>> care about the contents" model. There could be no return, maybe.
> The name "Don't care about the operations" model of file systems seems
> adequate because virtually all contemporary file systems and
> archive formats offer file type indication (via extended
> attributes).

Oh yes, it is a shoe carton with a big fat label on it: "Mercedes". Look,
it is not the label, but the operations, which make the thing what it is. A
shoe carton is a carton no matter how you name it. A file is an object with
the operations getc, putc, period. Mercedes is an object with the
operations drive etc.

Dmitry A. Kazakov
From: Martin on
On Jan 13, 3:38 am, Leslie <jlturr...(a)> wrote:
> Shark8 wrote:
> > On Jan 12, 2:41 am, "Dmitry A. Kazakov"
> > <mail...(a)> wrote:
> >> On Mon, 11 Jan 2010 17:13:55 -0800 (PST), Shark8 wrote:
> >> > Anyway, I was wondering if anybody here would be interested
> >> > in such a project.
> >> If that will be a really new OS (not a UNIX clone), OO,
> >> portable, distributed etc, for interesting platforms like
> >> this:
> >> why not?
> >> --
> >> Regards,
> >> Dmitry A. Kazakov
> > You know that was a frustrating / discouraging thing to hear
> > almost everybody I talked to about wanting to write an OS say
> > something along the lines of "Why don't you just download the
> > sourcecode for Linux?"... I'm sorry folks, but I don't want to
> > be the OS equivalent of a 'script-kiddie'.
> > One thing I find very annoying about the Unix/Linux mentality
> > is the "everything is a file" philosophy... coupled with the
> > C/C++-ism of simply assuming that a file read/write went well
> > and you're asking for trouble. {Yes, I know that you CAN check
> > to see if writing is successful or not in C/C++, but it goes
> > against most C/C++ programmer's sense of terseness/'beauty'...
> > the same one that makes no check on array-bounds.} </Rant>
>         If possible, also, it would be nice to get away from the "root
> can do anything" paradigm, and its associated inherited
> privileges (crash a root-capable process and steal its
> privileges).  It would be nice to see something more like the
> explicit privilege design used by CP in IBM's VM operating
> systems.
>         As a side note, does anyone here remember the Intel iAPX432
> processor, designed to execute Ada programs (almost) directly?
> Leslie

Nope...but I wish we'd gone for the Ericsson D80A processor (with Ada
(83) runtime in firmware) and not the Motorola 68040! We'd used the
D80 and the D80E which were fantastic processors, not sure why the
decision went the way it did...great support from Ericsson back then

-- Martin
From: Lucretia on
On Jan 12, 1:13 am, Shark8 <onewingedsh...(a)> wrote:
> I was wondering if there would be any interest in coding up an OS in
> Ada. I don't mean taking an existing codebase and rewriting/converting
> it to Ada, but implementing it from the ground up. It's been a bit of
> a "for later" project for me to write an OS, although I did begin to
> write one in Turbo Pascal which got to the point of being able to
> recognize user-commands & (based on those commands) change the screen
> resolution. {And all using less than ten lines of inline assembly!}
> As time went on the project went on the back-burner and "later" never
> really came around, but in that meantime I was finishing up my degree
> in CS and came across Ada in my senior-level programming languages
> class. The design of Ada impressed me a lot and so I got myself
> Barnes's Ada 2005 book and started teaching myself. (So, in reality
> I'm pretty new to Ada, but I do come from a Pascal background and like
> the idea of having my compiler check things for correctness.)
> Anyway, I was wondering if anybody here would be interested in such a
> project.

Me too, I wrote a "hello world" kernel in Ada ages ago and posted it
up onto my blog site: - it's a tad slow though
so will be moving my site over to a new one when I get around to it :D

I'll also be getting back to the OS (when I get around to it :D).

From: Ad Buijsen on
Leslie wrote:

> If possible, also, it would be nice to get away from the "root
> can do anything" paradigm, and its associated inherited
> privileges (crash a root-capable process and steal its
> privileges). It would be nice to see something more like the
> explicit privilege design used by CP in IBM's VM operating
> systems.

A capability-based OS, like Coyotos, perhaps?

The latest version of Genode (announced in this group) supports
components programmed in SPARK; this allows a gentle entry to building
an OS by piecemeal replacement of servers, and possibly even the

Ad Buijsen
From: Shark8 on
> > Interact with other systems? You know, you might want to sometimes
> > move your "persistent objects" to another machine.
> Marshaling? In terms of ADT it is assignment. Create a local object of the
> type. Assign the remote object to it. Done.
> Provided you have the assignment defined.

What happens when the network is disrupted in the middle of an
assignment though? Is the assignment atomic? If it's a large store of
data is it resumable, or does having a large file on a flaky server
doom you to never being able to retrieve the data?

> > Did I mention that you might want to move you whole hard drive to
> > another machine as well? :-)
> Did you try? What happens with a NTFS drive in a Linux system? Can you
> mount it as an ext4?

Ah, here you're confusing "is a" and "has a" because the drive itself
is NOT a file_system, but it may have one [or a part of one]. You can
think of the file system as a format-for-the-data. So, like some
people have done with compression/encryption and made an abstract base
to derive from we can do the same with file-systems.

> This is not a question of objects or raw blocks. If the OS recognizes the
> pluggable component, there is no problem,

Nope. The OS can detect a perfect & compatible drive and yet be
mystified by its contents because it doesn't understand how to read
it. If the drive is a dictionary, the entries are the particular files/
directories/objects thereon, but it is pretty useless to give someone
a dictionary in a language they can't read.

> if it does not there is a
> problem. Nothing prevents a portable design of persistent storage.

You are correct. And that is what a file-system IS. The design of [a
method] for persistent storage.

> Note that the file system itself is built on a layer of blocks and sectors.
> So if your argument worked, there would be no need for a file system. We
> would still read sectors and count drive heads...

Oh please don't say that the best way to reference disk-data is by
(sector, block) direct access... I'd prefer to have my hardware a
little more intelligent than that, and have my CPU available for
things other than calculating location-offsets.

> > There is a reason why none of the pure-OO-OS-let's-do-it-correctly
> > ever really took off.
> Yes. There are many reasons. For all there is no consistently designed
> OOPL, Ada included.

Ada is one of the most consistently designed languages I've come
across {LISP is another}, so if your argument is valid it should be
more doable in such language[s] than in other languages.

> Without MI, MD, tagged tasks, there is no chance to get
> it right.

If by MI you mean multiple inheritance I think the Java/Delphi/Ada2005
interfaces handle that pretty well.
If MD is multiple dispatch then we're talking about something that
simply explodes combinatorically-speaking: Say we have a multi-
dispatch procedure with two dispatching parameters [Letter and
Number], ok? Now, if we have two versions of each of those in the
classes we get something like:

Now let's say we extend our families of letters and numbers by a
single item we get the following:


And each of these instances must be defined because we have no way to
restrict invalid combinations, and if we don't restrict invalid
combinations we quickly run into huge data-sets that are [mostly]
worthless. If multi-dispatch were sorting it's somewhat akin to having
bubble-sort be your only method of sorting. We don't have efficient/
proper techniques for dealing with it.

> In long
> term perspective we sooner or later will be forced to use computing
> resources more efficiently.

Indeed, I completely agree. Which is actually the reason I named my OS
after the Commodore; if we could have the same 'wow' level of
effectiveness & efficiency given current hardware as they did then, I
believe that we would have normal-people absolutely astounded at what
their computer could do.