Re: More VSTa info?

[Kevin Beauchamp <kbeaucha@gpu.srv.ualberta.ca> writes:]

>I posted the following to comp.os.misc and thought I would cc directly to
>you for your unique insights. This was prompted by your response to a
>request by someone for an OS meeting his list of requirements.

Greetings. Yes, I saw your posting, and since you hadn't mailed it to me I
assumed you wanted other people's opinions. Anyway, now that you've sent it
to me....

>1) Who is working on VSTa apart from Mr. Valencia?

About 6 really serious developers, and another dozen who send in bits and
pieces.

>2) How mature is the version available?

In reliability or features? In reliability, it is probably superior to an
early 386BSD release, but not up to a current FreeBSD release. In features,
it lacks many things which a "full" OS would obviously havee.

>3) How portable is this system?

Pretty portable, ports to 68k and SPARC are in progress.

>4) Is there a new windowing system forthcoming as well?
> (Reflecting on the systems that influenced the OS, I expect
> a fusion/hybrid of 8 1/2 and Photon!)

Correct on the windowing system, although I hadn't heard about Photon?

>5) How much emphasis will be placed on:
> a) Distributed systems? (Spring, Alpha, QNX)

Reasonably heavy, although I will note something about this below.

> b) Object orientation? (Chorus COOL, Clouds)

Much less.

>6) How does the message engine compare with Minix? QNX? MPI?

Far superior to Minix (1.1/1.2, I haven't looked at it since then). We use
the usual VM tricks. Comparable to QNX, although clearly their product is
far more finely tuned.

>7) Will the system stay publicly available? Future plans?

Yes, it'll always be copyleft. We're shooting now for better SCSI, a
windowing system, networking, followed by distributed services.

>8) Are device drivers and file systems demand loadable/unloadable?

Yes.

>9) Is the scheduler also a user task? (Workplace kernel)

No.

>10) Does the system distinguish between realtime and "batch"
> tasks?

Well, real-time and user-ish. It uses a hierarchical organization of
scheduling nodes for user tasks, where nodes at the same level below a given
node are scheduled "fair share" based on priority.

>As I understand it, part of the raison d'etre for VSTa is to provide
>the basis for an exploration of new concepts in OS design that
>is accessable to anyone interested. I am also interested in its
>potential to provide a basis for a new hardware paradigm emphasizing
>high-speed links for near-distributed system.

This doesn't sound necessarily incompatible, although there are many, many
ways to go on this. Our current plans are to bring up networking, and then
set things up so a server (which generally looks like a filesystem) can be
mounted over the net. With that running, we can experiment on how we might
make services available in a structured and consistent way.

Now the "gotcha": most of us are widely separated across the Internet. Most
likely, our focus is going to be on designs which map well to large latency
connections. If you were to work on the distributed aspects, you might find
some of us pushing the design in ways which maintain compatibility with
slower connections. On the other hand, almost everything you're likely to
be doing would work for both, and right now we don't have anybody actively
working in this area anyway.

                                                Regards,
                                                Andy
Received on Fri Aug 5 16:27:38 1994