Re: Current state of Vsta?

mdingler@mindless.com writes:
>What's going on in the Vsta world? The web-site is
>pretty old and if I remember correctly, the majordomo
>said that development has stalled or something.
>
>So, what's planned, on what projects do you work?
>And (*shock*), may I help? ;)
>
>...Michael...

I see no one's answered, so I'll give it a try...

I think actually the hardest thing to do is to decide what to do, in
this case. :) Typically in a free operating system project a lot of
ork is done on porting various free unix-ish software to the new OS.
Of course we do have GCC and other utilities ported to VSTa. But I
don't think we want to build the whole OS that way. For example, it
was pretty much decided that we don't want X ported for the GUI,
because it doesn't fit well with the VSTa micro-ish philosophy, and
besides that, other free OS's like FreeBSD and Linux run it better.
In other words, we don't want to have the architecture compete
directly with what's already been done. POSIX compatibility is fine
(and very helpful, too), but I think VSTa is looking for something
new.

VSTa is definitely in need of a good SVGA graphics module that could
handle stuff like bitmaps, clipping, etc. The only catch is it would
have to run well as a user process. Perhaps a combination of a shared
library and a process would be best. The library could handle things
like off-screen bitmaps and other tasks that can run independently in
each process. When it comes time to actually display the graphics,
the library would send a request out to the video process, which would
serialize all of the requests and talk to the video hardware.

For upper level GUI stuff, I really don't know. Andy has talked about
running a language called Squeak to handle some of the higher-level
stuff. It sounds interesting. I think we're really in the market for
something new here. I'm imagining something that can go along with
VSTa's object-orientedness. I'm not talking about an object-oriented
GUI that means we define a C++ class called Button or some nonsense.
The objects I'm referring to here are the objects of the system; what
the user is trying to interact with. It's a different paradigm than
most user interfaces use. A VSTa process, I would imagine, would
interface with its GUI in a manner that's different from the way a
Windows app interacts with the Windows GUI. Instead of saying
something like "edit field #6 goes here", it would say "this object
has these attributes and it works with these objects like this." The
GUI process would work with the objects the user is using and what
the user is trying to do, and try to present it in a meaningful way.

It's a tall order, I know. But I'd really hate to see something like
COM/OLE that's a decently designed standard, technically, but which
turns out to be so utterly useless in practical use it's not even
funny. Or like QNX: a really slick lightweight OS that can pack a
convincing Windows 95 clone on a 1.44mb floppy, but doesn't go beyond
Windows' functionality.

In terms of the VSTa kernel: there are a couple of bugs to fix but
they aren't too serious. The biggest hole I see in the VSTa message
system--here's something to think about--is manifested in the telnetd
program in the KA9Q package. Here's what happens: when someone telnets
in, telnetd gets the connection and prepares to run login. But it
can't hand the raw TCP connection to login, because something has to
be there to run the telnet protocol. So instead it forks off and stays
behind to run a message loop that interprets the protocol. Then the
original process execs into "login //####" where #### is the port
number of the message loop that will run the protocol.

The problem is that that number is a public server number. Any process
can open that "//####" and connect to telnetd. A user could write a
process that hides in the background poking around at port numbers,
trying to run a fake login process that will record passwords. Etc.

The traditional ACL way of solving this, of course, is to require that
the client who opens "//####" has sys privileges, or whatever. That
certainly would work, but it doesn't sit well with me for two reasons:
first, it's not really the VSTa philsophy. Things that usually would
require administrator privileges in other OS's (for example, running
a file system) can be done by ordinary users in VSTa. There's nothing
about wanting to use a message loop to perform a private function that
requires superuser privileges. Second, this situation is bound to crop
up again, especially as process becomes more modularized. A method for
doing private-mode server invocations securely seems appropriate. Even
with the ACL pseudo-solution, it won't work in all cases: you couldn't
prevent two processes with the same ACL credentials from interfering
with each other.
Received on Sun Aug 8 16:13:44 1999