This sounds good... (Fwd: Re: A Linux OS done in Corba.)

Alexander Bostrom d96-abo@nada.kth.se
Tue, 30 Dec 1997 10:32:00 +0200


I found this in on UseNet. Any criticism or praise, anyone?


From: mikesw@dhp.com (M Sweger)
Newsgroups: comp.os.linux.misc,comp.os.linux.development.apps,comp.os.linux.advocacy
Subject: Re: A Linux OS done in Corba.
Followup-To: comp.os.linux.misc,comp.os.linux.development.apps,comp.os.linux.advocacy
Date: 29 Dec 1997 12:53:14 GMT
Organization: DataHaven Project, Inc (http://www.dhp.com)
Lines: 177
Message-ID: <6886fq$77n$1@stronghold.dhp.com>
References: <67e7sh$bcf$1@stronghold.dhp.com> <m2sorm3dix.fsf@jolietjake.com> <87afdnedm7.fsf@mars.mds.rmit.edu.au>
Reply-To: mikesw@whiterose.net
Xref: news.kth.se comp.os.linux.misc:232567 comp.os.linux.development.apps:46813 comp.os.linux.advocacy:160573




Marcelo Cantos (marcelo@mds.rmit.edu.au) wrote:
: Jarek Luberek <jarek@swipnet.se> writes:

: > Omegaman wrote:
: > 
: > > mikesw@dhp.com (M Sweger) writes:
: > >
: > > > ... why not an OS such as Linux. Corba provides network
: > > > connectivity, a simple processing management and data
: > 
: > As far as I know, Corba does not provide anything. Corba defines
: > interfaces. It is up to anybody to implement them (right?).

: As an experienced engineer once told me in my electrical engineering
: days, interface are the key to successful engineering.  The
: quintessential task of the engineer is to make A work together with B
: to achieve C (let the scientists worry about making A and B work in
: their own right).  That is what Corba is about, and it is neither a
: trivial nor an easy undertaking.

: > Although, Corba is interesting. A free (BSD-licence) implementation
: > would do tons of good for the industry as a whole. Go Corba I'd say.

: My real concern is the size of the task.  Linux had a head start on
: two counts: 1) it started from minix, not from scratch, 2) it had a
: preexisting paradigm to target, unix.  It simply had to perform an
: already well defined function (allbeit a complex one).  To reimplement
: Linux using an ORB at its core without any change in functionality
: would be pointless in the short term (Linux works now, why change
: it?), and to change Linux to be something more (by virtue of the extra
: power, Corba provides) would leave us without a well defined goal.

: Having said this, I don't wish to imply that such an enterprise is
: futile, (on the contrary, if it can be pulled off it has the potential
: to completely remodel the computing landscape).  I simply wish to
: point out that one can very easily underestimate the difficulty of the
: task.

: A possible route would be to replace the kernel with a functionally
: identical ORB-based kernel (ie: the "pointless" first option I state
: above) as a proof of concept.  Then move on to explore what Linux/ORB
: can do.  I personally like the idea of providing dosemu and wine as
: Corba OS objects.  These projects might find it easier to bind into a
: more generic micro-kernel with ORB functionality than into the current
: Linux kernel (pure speculation, I realise).


: Cheers,
: Marcelo

Hello,

I too am an Electrical Engineer by training. However, I was taught
that the purpose of engineering is to improve upon what has already been
done due to the application of new ideas and concepts and build upon
what has already been done. For one to state that why change ( or redo
and improve) upon what already works is limiting. If everyone takes this
position then we would still be in the stone age riding around in horse
drawn wagons ( why develop a car when the wagon ain't broke) or develop
a faster computer when the old one was just as fast; or develop a free
unix OS (with improvements) when there are plenty of outdated and 
slow to change commercial products that are out there. I think everyone
gets the point now! We develop and repackage old concepts in the hopes
of achieving something better: besides if the commercial companies did
it, then the free clones will eventually imitate it anyway.


True, the ORB needs alot of underlying OS provided functionality
such as network support and scheduling. However, alot of the OS utilities
can be rewritten as objects on the Corba Orb for easier maintenance and
portability and be less tied to the OS directly. There is nothing stopping
me from writing an object(s) that imitate network protocol stacks and
utilities that are presently done by the OS and bypass the underlying
network functionality that the present day ORB relies on. I.E. I could
develop an FTP uitility written using objects on the ORB similar to having
an object that serves as my ODBC object providing connectivity to some other
application or system. I could develop a telnet utiltity to bypass the
OS and it's network stacks. I could write a Novell netware protocol
stack to reside on the ORB because it isn't supplied as part of the OS
or is to hard to write without a complete understanding of the internals
of an OS I didn't write or have the source to. Another example, is ESIOP
which is part of the Corba Orb. ESIOP is a set of objects that allows
me to commmunicate with dissimilar networks that aren't TCP/IP such as
SNA. So, now that I've rewritten all my OS network support to be objects
on the ORB ( off course the current ORB architecture would have to be
modified to utilize these objects) I have elminated part of the functionality
of the OS.

What, else does an OS do for me? It does scheduling of my 
application processes through well known techniques. WEll, i could write
various different scheme of kernel scheduling as objects on the ORB. Currently,
the ORB doesn't rely on the OS to perform scheduling of object execution.
An application written with objects must have an object that controls the
order and sequencing of the objects. Moreover, the Corba ORB provides
time service ORB objects that can be used to schedule events that control
the sequencing of the application objects. Right now, the kernel only
provides one type of scheduling technique that is selected based on design
tradeoffs when designing the kernel. However, different applications
existing on the ORB can have a set of different scheduling methods available
for selection instead of one. Hence, I can tailor a scheduling scheme to
a specific application and because I can have mulitple applications running
simultaneously, I can have multiple scheduling techniques running simultaneously
to maximize the performance of each applications. So, I'm not stuck with
one type of scheduling implementation; I can have a set of scheduling
implementations (even the text book ones) that maximize the performance of
my application. 

What else does an OS have besides communications, utilities and
scheduling? It has a storage mechanism based on a filesystem. Currently,
the ORB has POS (Persistent Object service) which just stores the data
in the object into a permanent storage mechanism such as a DBMS (more
prefereably an ODBMS). Even the entire executable (from what I've read)
can be stored). The ODBMS is supposedly very quick in retrieving and
searching for objects and allows you to do queries based on grouping
of objects thru hierachies (similar to a join) and have different views
on your set of objects. (Note: I'm pretty ignorant on ODBMS' still)
Well, doesn't this look like a filesystem to you? A file is an object
since a file may be 1) TEXT 2) data 3) binary programs 4) graphics etc
. I even can have multiple copies of the same object/file since ODBMS'
allow for versioning. Nested objects in ODBMS' could be similar to
a directory structure (the picture isn't to clear this early in the morn).
So if a do subclassing of these different objects, I can bring very
quickly together the parts needed to create an application. Look at
OpenDOC by Apple. The whole application comes together as a set of
different objects under one parent object. Alot of DBMS vendors are
rewriting their entire DBMS engine (querying, retrieving etc) on top
of the Corba model as objects. Hence their, legacy DBMS application
is now a set of objects. Netscape has rewritten their Web server as
a set of objects residing on the Corba Orb. By doing this, it leads
to easier s/w maintenance.

In the beginning, the internet created Netscape and it was good.
When Netscape came into being, it was the first time that alot of
disparate applications residing out on the internet could be integrated
into one product. I.E. text, pictures, sound, movies etc. For easy
maintenance the concept of pluggins was devised with applications such
as word processors being activated via viewers. Hence, the browser
became the central focus of the desktop - not the OS. The browser
itself can be totally a set of pluggins ( perhaps object applications)
that reside on top of the ORB supplied now by NETSCAPE for the browser
on the desktop. Hence, the browser itself can be just a shell without
alot of pluggin objects that do specific things even doing the html
parsing. What scared Msoft to death ( and they should be) is that even
the OS such as DOS could be a pluggin. Meaning that instead of the
browser residing on top of DOS, that DOS is just another object within
the browser whereby when needed, an application requiring some DOS
capability would send data and commands to the DOS object. Therefore,
the browser controls the desktop: not the OS. Msoft just became obsolete!
So what did MSOFT do? Well they changed gears and are coming out with
windows 98 that makes the browser the center of the desktop with tight
integration with the OS (making you rely on them). How, to get around
this dependency is another story. So! if I can make DOS a pluggin/object
within or on top of a Corba ORB for DOS why not do the same for any
OS such as LINUX or UNIX in general. Yes, it can be done! The technology
exists! It's just a matter of convincing and changing peoples old mind-sets
to the possiblity of a new concept. That new concept and its vast
potential capability is enormous! Even the major companies (760 of them)
saw the hand writing on the wall and realized that if we don't join
the band wagon, somebody else will do it and kick us in the ass by
making us obsolete just like MSoft was - or is - being made obsolete. :))

Well, hopefully this answer the questions as to why. It sure is
better than seeing alot of duplicate projects being done as free s/w.
I.E. just how many different telnet, ftp and editor programs can the free
UNIX write that are imitations before people move onto greater challenges?
I can only use one of each at a time not the multitudes.


Just my IMHO.



--
Mike,
mikesw@whiterose.net

-- Alex (Really tired of this Window95 crap.)