Re: Non-UNIX Changes
On Sat, May 20, 2000 at 04:31:57PM -0500, Christopher Browne wrote:
> Were Windows to win the day, it would be a pretty terrible day. But
> if "all systems were UNIX," I'm not sure it would be a utopia that we
> would have...
I'd go as far to say that it would be just as bad: "the limits of my
language are the limits of my world" and all that. Upon rereading it, I
realise that my previous post could instead have read something like:
I'm scared about useful knowledge from other OSs being lost.
> > [...] most of the other environments---such as ITS, Multics,
> > TOPS-10, TENEX, VM, VMS, Genera, NeXTStep, Plan 9 etc.---will only run on
> > expensive, obsolete or difficult-to-emulate hardware, and the software is
> > rarely available.
> Plan 9 is runnable on a *86 box, so I can't fully agree with that one,
You can get disk images for a demo setup from plan9.att.com, which
apparently includes compilers and the window system. I actually downloaded
this last year; however, I couldn't find a machine in my collection that I
could actually get it to work on. To be fair, you'd probably have more luck
with a more modern machine than the various 486s I had available at that
point! The full (source?) distribution is also rather expensive.
As well as the other suggestions that people have made for the list of
interesting OSs to try, I should probably add AmigaOS (I was an Amiga user
for something like six years, so I'm not quite sure how I forgot it!),
Inferno (Plan 9's successor) and Nemesis
(http://www.cl.cam.ac.uk/Research/SRG/netos/nemesis/, or thereabouts; a very
neat "media" OS which runs on x86 and ARM hardware).
> To be specific, for VMS: [...]
> "http://home.earthlink.net/~djesys/vms/hobbyist/multia.html";
> "http://www.montagar.com/hobbyist/
> "http://www.decus.org/";
> "http://www.openvms.digital.com/";
Excellent. I've got some heavy reading to do. :)
> I suspect that one could put together a MicroVAX system with "hobbyist"
> licensing of VMS for a few hundred dollars.
Bob Supnik's minicomputer/mainframe emulator, simh, emulates various systems
including the PDP-{1,4,7,8,9,11,15}, Nova and IBM 1401. The PDP-11 emulation
is complete enough to run UNIX V7 and RT-11, so presumably an older version
of VMS would work on it. I think it's on Freshmeat.
There's a PDP-10 emulator around as well, e10, but it's nothing like
finished.
> I'd think that GCOS, the MIT Exokernel, SPIN, and EROS should also be
> on the list of "OSes that things might be learned from."
Definitely; the Exokernel looks very neat, particularly from a
"partitioning" (a la IBM LPARs or VMWare) point of view.
> I saw something on that; I have to confess I don't "get it." It may be
> important, but I'm not really fully seeing the importance.
I was just using it as an example, but I'll happily explain, because I think
it's pretty neat:
Suppose your app is doing
read(file, buf, length);
and has read "count" bytes when it receives a signal. Under Unix, the signal
handler is called, and once that's done, the read will return immediately
with the EINTR error code.
If PCLSRing was implemented, when the interrupt was received, the OS would
modify the PC and stack so that when the interrupt handler returned,
read(file, buf + count, length - count);
will be executed and then the program will continue as before. This could be
done for most of ITS's system calls. I recently ran across this problem
while writing a program that needed to simultaneously accept TCP connections
and restart dying child processes; the accept() call returned with an error
whenever the program recevied a SIGCHLD.
> Another thing that could be worth having in the filesystem might be a
> return to "record-oriented" files. That is, having some semantics that
> go beyond the UNIX notion of a file being a "bag of bytes."
Interesting. Obviously, this could be emulated at the libc level, but for
performance increases for databases and the like, it would be necessary to
build this into the filesystem. (Presumably this is why Oracle and similar
databases have the ability to work with a raw device rather than using a
filesystem.)
> Supporting some form of hierarchical data store could provide further
> value (or at least a cool idea that might prove horrid in practice);
I'm not sure what advantage this would offer over a userspace (well, you
know what I mean---applicationspace?) implementation; are you thinking of
something like the Windows Registry here?
> Unix System V provided a "message queueing" scheme for IPC; having
> this become _pervasive_ is where QNX got a lot of its power. I'm not
> sure how well Mach supports the notion.
How is the QNX IPC stuff different from communication between servers under
Mach? What could we learn from it? (Oh, for a _really_ free QNX... sigh...)
--
Adam Sampson
azz@gnu.org
Reply to: