[unios] Pre-Grad looking for info

[Pat Wendorf]

I received some mail a few days back from someone looking for
information for his thesis paper, I'll post the messages and the
replies in this mail.  Maybe someone will have more information
for him.

BTW:  I changed the UniOS page (where most people find ut) so
that all questions about the project, from now on, get sent to
the mailing list.


I'm sorry for how long this message is...

---------------------------------------------------------------------------------------------------

Hi!

I was browsing through the UniOS pages and stumbled across
the paper about the database file system.
You don't state what kind of database you see as a file system,
do you have any special kind in mind or...?

You also say that a database FS would be slow, but aren't
database
implementations slow because they are (often) built on top
of current FS which adds an extra layer of abstraction which
could be removed. Also by using OO databases (the most natural
choice IMO) you get fast "file" (object) traversal.

The reason I am interested in the UniOS project is that I
am writing a graduate thesis at the University of Iceland
about an OS design which eliminates (or at least minimizes)
the need of a central kernel.
I am also interested in incorporating object technology into
OSes at the lowest level.

My notion is that file systems are not necessary. Objects
should be made persistent automatically, without the user
(or programmer) knowing how or where it is persistent, as
long as he (the user) can access it again in a predefined way.
What do you think?

Regards,
Gummi Haf

--
------------------------------------------------------------
Gudmundur Hafsteinsson                         gudmhaf@hi.is
Student in Computer Engineering at The University of Iceland
------------------------------------------------------------

---------------------------------------------------------------------------------------------------

Gudmundur Hafsteinsson wrote:

> Hi!
>
> I was browsing through the UniOS pages and stumbled across
> the paper about the database file system.
> You don't state what kind of database you see as a file system,

> do you have any special kind in mind or...?

That's a good question :)  I was thinking of having a low level
implementation of a popular commercial database, but that would
draw
away from the Open Source aspect of the project.  The only
solution
left is to write it from scratch, and hope we know enough about
database design to handle it (which I have doubts :).

Actually, our current idea's on the matter are that a low level
FS is
necessary for facilitating booting the system, while the database

that stores all the objects (files and associated data), will be
stored as a massive file on this low level FS.  We would
implement
direct hardware access to the storage device, thus still allowing
the
fastest access possible (all we have to know is where the file is

physically stored, and bypass the lower level FS altogether).  In

this way, we can also use existing FS's such as Fat16 or Ext2FS
to
store our OS (non-intrusive OS technology), and boot them similar
to
the Linux LOADLIN.EXE.

> You also say that a database FS would be slow, but aren't
database
> implementations slow because they are (often) built on top
> of current FS which adds an extra layer of abstraction which
> could be removed. Also by using OO databases (the most natural
> choice IMO) you get fast "file" (object) traversal.

Every DBMS I've ever seen has been very slow on I/O, but they
were
probably just bad examples (I hear the AS/400 DB2 is quite fast
because it uses direct hardware access).  And I agree that having

everything OO, we could focus on optimizing access for that.
However
UniOS as a concept is storage independent.  The Database FS is
only
an idea for the initial release.  UniOS by definition is actually

hardware independent also (it's more like and abstracted
description
of how programs should run, but solid enough to run them with a
lot
of flexibility and performance).

> The reason I am interested in the UniOS project is that I
> am writing a graduate thesis at the University of Iceland
> about an OS design which eliminates (or at least minimizes)
> the need of a central kernel.
> I am also interested in incorporating object technology into
> OSes at the lowest level.

Yes, that is very similar to our own research (if you can call it

that), we are looking into the concept of a hardware abstracted,
kernel less OS.  More or less, the objects reside in memory, and
just
"talk" to each other. It's my belief (and I'm heavily criticized
for
it by some), that there is a way to distribute and compile
hardware
independent objects, that are descriptions (see meta
programming), of
how a program should run.  These objects are loaded in memory and
the
system, which can be totally reflective (can see itself running
and
modify itself to fit the situation due to the lack of a static
kernel), and will compile them (on the fly, or precompiled) and
run
them as seemingly normal applications.  The whole key to the
UniOS
project is the idea of making the OS totally flexible while
running
(i.e.. you can plug-n-play every single component in the system,
and
every component can "talk" to every other component it has
security
access to).

> My notion is that file systems are not necessary. Objects
> should be made persistent automatically, without the user
> (or programmer) knowing how or where it is persistent, as
> long as he (the user) can access it again in a predefined way.
> What do you think?

This is another element of the project that is discussed
frequently.
Automatic persistence is a great idea, and along with it comes
the
idea of the bypassed boot sequence (ram image is stored on hard
drive
on shutdown, and on next boot up, everything is loaded back up
from
the image), but that's just a byproduct feature that can be
implemented if necessary.  We want to make it as seamless as
possible
to access objects.  I'd imagine the hardware objects and the
"kernel"
objects (scheduler, memory manager, ect.) that are in use most
often
would almost never leave the system memory, which would give us
as
much speed as a static kernel.

Actually when it comes down to it, semantically we are talking
about
a low level object-oriented database (a good place to start a
graduate thesis, simply because it's never been done :)

---------------------------------------------------------------------------------------------------

> That's a good question :)  I was thinking of having a low level

> implementation of a popular commercial database, but that would
draw
> away from the Open Source aspect of the project.  The only
solution
> left is to write it from scratch, and hope we know enough about

> database design to handle it (which I have doubts :).

Isn't there any Open Source DB?

> Actually, our current idea's on the matter are that a low level
FS is
> necessary for facilitating booting the system, while the
database
> that stores all the objects (files and associated data), will
be
> stored as a massive file on this low level FS.  We would
implement
> direct hardware access to the storage device, thus still
allowing the
> fastest access possible (all we have to know is where the file
is
> physically stored, and bypass the lower level FS altogether).
In
> this way, we can also use existing FS's such as Fat16 or Ext2FS
to
> store our OS (non-intrusive OS technology), and boot them
similar to
> the Linux LOADLIN.EXE.

Sounds a little bit like MS-DOS -> Win95 (I mean use old
technology to
implement a "new" one).
Why build on something you won't use? An FS is not necessary to
boot an OS.

> Every DBMS I've ever seen has been very slow on I/O, but they
were
> probably just bad examples (I hear the AS/400 DB2 is quite fast

> because it uses direct hardware access).  And I agree that
having
> everything OO, we could focus on optimizing access for that.
However
> UniOS as a concept is storage independent.  The Database FS is
only
> an idea for the initial release.  UniOS by definition is
actually
> hardware independent also (it's more like and abstracted
description
> of how programs should run, but solid enough to run them with a
lot
> of flexibility and performance).

It's good to be <put some word here, e.g. hardware, storage
etc.>-independent
but to be that you need a solid base to build on. When I was
looking at UniOS is seemed to me that the foundation is very
abstract. Have you decided how to implement these abstractions?
(I'm not talking about what hardware or implementation language
but more like what concept, I hope you see what I mean... I'm
not sure if I do myself ;)

> Yes, that is very similar to our own research (if you can call
it
> that), we are looking into the concept of a hardware
abstracted,
> kernel less OS.  More or less, the objects reside in memory,
and just
> "talk" to each other. It's my belief (and I'm heavily
criticized for
> it by some), that there is a way to distribute and compile
hardware
> independent objects, that are descriptions (see meta
programming), of
> how a program should run.  These objects are loaded in memory
and the
> system, which can be totally reflective (can see itself running
and
> modify itself to fit the situation due to the lack of a static
> kernel), and will compile them (on the fly, or precompiled) and
run
> them as seemingly normal applications.  The whole key to the
UniOS
> project is the idea of making the OS totally flexible while
running
> (i.e.. you can plug-n-play every single component in the
system, and
> every component can "talk" to every other component it has
security
> access to).

Meta programming is IMO too slow but may become feasible sometime
in
the near future, who knows. But the idea is great.
What kind of Inter-Object-Communication (IOC) mechanism do you
have in mind?

> Automatic persistence is a great idea, and along with it comes
the
> idea of the bypassed boot sequence (ram image is stored on hard
drive
> on shutdown, and on next boot up, everything is loaded back up
from
> the image), but that's just a byproduct feature that can be
> implemented if necessary.  We want to make it as seamless as
possible
> to access objects.  I'd imagine the hardware objects and the
"kernel"
> objects (scheduler, memory manager, ect.) that are in use most
often
> would almost never leave the system memory, which would give us
as
> much speed as a static kernel.

Very few OSes page their kernel, and a good OS should have a
small
memory footprint so it doesn't have to be paged (around 1-2 Mb is

acceptable). Take AmigaOS as an example (version 1.2), it was
implemented in 256 kb, with GUI and everything. Another example
is (as you know) QNX.

> Actually when it comes down to it, semantically we are talking
about
> a low level object-oriented database (a good place to start a
> graduate thesis, simply because it's never been done :)

In a certain way yes, but in a certain way no. An OODBMS must
have
a query language (like OQL, Object Query Language) but an OO
OS must not necessarily have one (it might be implmented as an
extra service). It's more like letting the OS disappear;
objects in the system are services available to other services
(objects) and there is no fundamental difference between a
file system and a word processor, except in the service they
offer.

Regards,
Gummi Haf

--
------------------------------------------------------------
Gudmundur Hafsteinsson                         gudmhaf@hi.is
Student in Computer Engineering at The University of Iceland
------------------------------------------------------------

---------------------------------------------------------------------------------------------------

Gudmundur Hafsteinsson wrote:

> > That's a good question :)  I was thinking of having a low
level
> > implementation of a popular commercial database, but that
would draw
> > away from the Open Source aspect of the project.  The only
solution
> > left is to write it from scratch, and hope we know enough
about
> > database design to handle it (which I have doubts :).
>
> Isn't there any Open Source DB?

Hmm... none that I can think of off hand.

> > Actually, our current idea's on the matter are that a low
level FS is
> > necessary for facilitating booting the system, while the
database
> > that stores all the objects (files and associated data), will
be
> > stored as a massive file on this low level FS.  We would
implement
> > direct hardware access to the storage device, thus still
allowing the
> > fastest access possible (all we have to know is where the
file is
> > physically stored, and bypass the lower level FS
altogether).  In
> > this way, we can also use existing FS's such as Fat16 or
Ext2FS to
> > store our OS (non-intrusive OS technology), and boot them
similar to
> > the Linux LOADLIN.EXE.
>
> Sounds a little bit like MS-DOS -> Win95 (I mean use old
technology to
> implement a "new" one).
> Why build on something you won't use? An FS is not necessary to
boot an OS.

This is for people who would be upgrading from Win9x type
systems. Once the OS is
in memory, it doesn't really matter if it has absolute control of
the whole hard
drive... just the portion that UniOS would need.

> > Every DBMS I've ever seen has been very slow on I/O, but they
were
> > probably just bad examples (I hear the AS/400 DB2 is quite
fast
> > because it uses direct hardware access).  And I agree that
having
> > everything OO, we could focus on optimizing access for that.
However
> > UniOS as a concept is storage independent.  The Database FS
is only
> > an idea for the initial release.  UniOS by definition is
actually
> > hardware independent also (it's more like and abstracted
description
> > of how programs should run, but solid enough to run them with
a lot
> > of flexibility and performance).
>
> It's good to be <put some word here, e.g. hardware, storage
etc.>-independent
> but to be that you need a solid base to build on. When I was
> looking at UniOS is seemed to me that the foundation is very
> abstract. Have you decided how to implement these abstractions?

Nope, that's what we are currently working on. If we had an idea
of HOW to do it,
we'd write up a plan, and be coding by now :)  UniOS, at this
point, IS very
abstract, even to those of us working on it.  Actually if you
notice the title of
the index page it says:  "UniOS - A Concept OS".  In other words,
we really have
no solid idea on which to implement this OS (actually most think
of it as a high
level abstracted design, rather than an OS).

If you have any ideas, they are more than welcome :)

> (I'm not talking about what hardware or implementation language

> but more like what concept, I hope you see what I mean... I'm
> not sure if I do myself ;)

The closest thing we have to that is the things we KNOW that need
to be there.
Such as:
1) Object orientation as the paradigm throughout the system
2) A hierarchical structure for implementing order and security
3) Multiuserability
4) Adaptive processing
5) Hardware independence for implementation and applications
6) Registered data types
7) The forced separation of configuration files (objects) , code
objects, and
data objects
8) Scriping/Programming as part of distribution
9) Filtering/Conversion of data types through filters as part of
OS
10) Standardized hardware abstracts distributed with every single
UniOS type
system

These are just some of the things we discuss in the mailing list
as a group.  HOW
to do all that is what we are always trying to figure out.

> > Yes, that is very similar to our own research (if you can
call it
> > that), we are looking into the concept of a hardware
abstracted,
> > kernel less OS.  More or less, the objects reside in memory,
and just
> > "talk" to each other. It's my belief (and I'm heavily
criticized for
> > it by some), that there is a way to distribute and compile
hardware
> > independent objects, that are descriptions (see meta
programming), of
> > how a program should run.  These objects are loaded in memory
and the
> > system, which can be totally reflective (can see itself
running and
> > modify itself to fit the situation due to the lack of a
static
> > kernel), and will compile them (on the fly, or precompiled)
and run
> > them as seemingly normal applications.  The whole key to the
UniOS
> > project is the idea of making the OS totally flexible while
running
> > (i.e.. you can plug-n-play every single component in the
system, and
> > every component can "talk" to every other component it has
security
> > access to).
>
> Meta programming is IMO too slow but may become feasible
sometime in
> the near future, who knows. But the idea is great.
> What kind of Inter-Object-Communication (IOC) mechanism do you
> have in mind?

This is another point of heated discussion (a while back) on the
mailing list.
We know of many different ways of how it can be done, so we
finally settled on
the fact that it will not be part of the final UniOS spec... more
or less it's
going to be implementation dependent.  Some architectures can do
some things
better than others, some ways of passing data are better than
others for certain
applications, so it will be up to the final designer to decide
"how and when".
With adaptive processing we could specify many different types,
and let the
compiler decide which way would be best (fastest/most
efficient).  IOC was not my
department :)  I'm more of the "big picture" guy.  If you'd like
to discuss it
more, you can sign up with the UniOS mailing list (I told them
about you, and
they wish to talk to you also :).  To sign up for the mailing
list, there is a
link on the index page of the web page, however I'm not entirely
sure if the
automated one works yet. If not there are instructions at the
bottom of the
page.  Our list is called "unios@tunes.org"

> > Automatic persistence is a great idea, and along with it
comes the
> > idea of the bypassed boot sequence (ram image is stored on
hard drive
> > on shutdown, and on next boot up, everything is loaded back
up from
> > the image), but that's just a byproduct feature that can be
> > implemented if necessary.  We want to make it as seamless as
possible
> > to access objects.  I'd imagine the hardware objects and the
"kernel"
> > objects (scheduler, memory manager, ect.) that are in use
most often
> > would almost never leave the system memory, which would give
us as
> > much speed as a static kernel.
>
> Very few OSes page their kernel, and a good OS should have a
small
> memory footprint so it doesn't have to be paged (around 1-2 Mb
is
> acceptable). Take AmigaOS as an example (version 1.2), it was
> implemented in 256 kb, with GUI and everything. Another example

> is (as you know) QNX.

QNX is awesome.  If they went FreeSource, that would be great for
all OS project
to draw code from.  They're generic enough to provide a potential
implementation
ground for UniOS.

> > Actually when it comes down to it, semantically we are
talking about
> > a low level object-oriented database (a good place to start a

> > graduate thesis, simply because it's never been done :)
>
> In a certain way yes, but in a certain way no. An OODBMS must
have
> a query language (like OQL, Object Query Language) but an OO
> OS must not necessarily have one (it might be implmented as an
> extra service). It's more like letting the OS disappear;
> objects in the system are services available to other services
> (objects) and there is no fundamental difference between a
> file system and a word processor, except in the service they
offer.

Yep, agreed :)

---------------------------------------------------------------------------------------------------



I truly apologize for the length of this message...

--
--------------------------------
 Pat Wendorf
 UniOS Group
 http://unios.dhs.org
 beholder@ican.net
 ICQ: 1503733
--------------------------------