[unios] Pre-Grad looking for info

[Anders Petersson]

Welcome, Gudmundur.
You'll have to excuse that I take the opportunity to use this thread partly
for "inside" talk, we're not a totally homogene group (yet?).

>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.

I question that it is an existing dabase system we need. For a test system,
yes maybe, but a serious implementation needs to take advantage of the
special low-level circumstances. And - I don't think our model is defined
is such detail yet as to allow meaningful statements over the DB needed.

>> > 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.

Thanks to the modularity, these details do not affect the running system in
more than the speed may vary. When sharing the system with other OSes (as
is likely to most often be the case), simulating the native UniOS DB FS
inside a file in another FS should be resonable. However, there is no
problem in giving the DB FS and own partition - only the low-level FS
module would ever be affected.

>> > 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).

I have my own opinions, ideas and scenarios (most are yet undeveloped),
which I believe would bring UniOS a little closer to reality. Still much is
left, though, and time is sparse (especially now).
One reason why all this is as abstract as it is, is that we want more than
Just Another Stupid OS (tm). We want to truly improve computer systems, and
for that more abstraction take a key role. But yes, partly it's abstracted
because the concrete details simply aren't there yet.

We should construct a experimental system to see how our ideas look in
reality, to get a feel and deeper understanding of the concepts, which
probably would lead to improvements as well as giving us something to show
up for interested. It seems to me, as suggested by Pat, that Java should be
a suitable tool for this; it's interpreted, OO'ed, widely recognized and
easy to use. (Says one who haven't even used it :)
In Java, we could built a framework that would mimic a dynamic, running
UniOS system with its objects and interfaces, and see how some simple
applications could be made and interact and so on... I don't think this
could be done immediately, but it should IMHO be a short-hand goal, and
would bring us significantly forward. What do the rest of you say?

>> (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
Oh so true. And an absolute set of rules for the system, ruling all objects
(important!).
>2) A hierarchical structure for implementing order and security
IMHO more than that can be achieved by the hierarchic concept. Storage
distribution, processing power, and perhaps even user-defined properties.
>3) Multiuserability
By reducing users to just another object, this can be applied if wanted.
Most often it will.
>4) Adaptive processing
I don't see what you're thinking of here.
>5) Hardware independence for implementation and applications
Abstraction, with another word.
>6) Registered data types
...As part of the object rules. The importance of these rules can't be
overrated.
>7) The forced separation of configuration files (objects) , code
>objects, and
>data objects
This isn't really *forced*, but application programmers should be strongly
asked to take advantage of the built-in features of UniOS when writing
programs. As they themselves would benefit from this, it shouldn't be a
problem, and the separation mentioned would exist.
>8) Scriping/Programming as part of distribution
*Highly* wanted, but not really a requirement.
>9) Filtering/Conversion of data types through filters as part of
>OS
Again, made possible by the rules.
>10) Standardized hardware abstracts distributed with every single
>UniOS type
>system
Sorry, I have to object here. Standardized hardware abstracts would
decrease the potential of the OS. It would put much responsibility on us as
designers at development time, forcing us to try to make forecasts as to
what types of hardware devices may come. It would run against the principle
of leaving irrelevant decisions until run-time. Perhaps I've been too
unlear about this before.
My suggestion? It may seem very similar; still abstract interfaces, but
defined, treated and used just in the same way as other objects - no
difference at all, the same concept, the same implementation, everything.

>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).

You surely begin to sound like a member of TUNES, Pat. :)

>> 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"

As a general rule, objects can communicate with whatever interfaces they
can see. The details as to how communication is performed are yet to be
found out.

>> > 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.

There is no need to save the whole RAM to disk, there is not even needed a
concept for that (as Pat hints). Every single object live on persistent
storage, and is only cached in RAM to gain speed. That is, you define the
object to live on disk, but it doesn't have to be there all the time; the
important think is what you see. (Object actually can live directly in RAM
according to the device-independence principle, but such objects are
inherently volatile. Diskless terminals can therefor function with UniOS
too.) Anyway, on shutdown, you can just flush dirty data... /except/ for
some details like device drivers, etc.

>> 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.

I dunno... QNX is POSIX-compatible, something I'm always sceptic towards.
But as a group of limited resources, maybe we can't expect to be able to
tailorsuit everything.

>> > 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 :)

>From my point of view, a DB FS is not something to aim for; it is something
that may coincide to look much like what we're after, but it's not
automatically the goal. 

>> 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.

Bravo! That's just it. (Although I don't think we can let the OS disappear
in the meaning of avoiding a kernel...)

binEng