[unios] Pre-Grad looking for info

[Pat Wendorf]

Anders Petersson wrote:

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

Defiantly not yet.  Soon maybe, if we continue progressing.

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

Agreed, with a redefined method of programming hardware (hardware abstraction a
la UniOS), we'd need to design something from scratch for the final product.

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

Should be completely transparent in all respects.  I can't see having an OS that
can't run in another environment.  It's contrary to the beliefs of the project.
Implementation neutral is the most flexible way.


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

It's very easy :)  It's used in industry as a Rapid Application Development
tool.  Which means that it can be used to make no-so-optimized applications that
"do the job", in short time (vs. something like C/C++).  I'm using Java to
implement the CGI back-end of the UniOS page (it's coming along, I have the
MemberBase program 1/2 done).  It's not real fast, but it will work.

> 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 think this is a great idea!  I guess we could start with the hardware object
defined in the "Hardware Abstracts" document, and actually program in a virtual
system.  Once we find out what we want, we could port this system to our own
format.  I think essentially we're gonna have to start with the basic API
(methods and properties) of each of the objects.  The first object that would be
necessary, I think, would be the system object (agreed?).  I'm not sure if we
have reached consensus on the basic functionality of each object, other than
what I have defined (vaguely) in the document.  I guess I'll just send another
post, after this one, rehashing the system object, and maybe some solid
definitions.

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

I agree with that, and there is only a BASIC set of ABSOLUTELY standardized
(abstracted) system interfaces, that MUST go with every implementation...
otherwise we would not have a cross platform system...  Yes, I agree that more
device objects can be added, that was not an issue.  But I have to say, I can't
imagine what kind of chaos it would create to let the implementers of the system
decide what to name the Keyboard object, and it's methods... 9/10 times each
programmer would come up with something different!

What I propose is not a locked standard of objects, rather just a set of objects
that come with ALL UniOS system, that can be used by ALL programmers, ensuring
their program will work on all implementations.  Simple things like the System
Object, The Display Object, The Storage Object, etc... Each of these examples
will have the same defined methods on all systems.  Each of the objects CAN
access other objects to achieve the results, so long as the desired effect is
achieved somehow, and it ends up looking and acting the same as it did on any
other implementation.  I can't object to an object called "Voodoo2 3D Graphics
Accelerator", however it should(must) be able to be interfaced (not forced to
be) with a generic object like "3D Video".  Kinda like a Direct3D or OpenGL type
thing.  But if the programmer wishes, he/she can program the "Voodoo2" object
directly...  just wouldn't make much sense, for portability reasons :)

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

They just have a good way of describing it :) ...  And I am a member! :)

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

Well, said :)  A better explanation than my own.

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

Let the Kernel Die!  Long live persistent objects!  (and pray that this kind of
system will work ;)

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