Non-UNIX Changes
On Sat, 20 May 2000 00:02:15 BST, the world broke into rejoicing as
Adam Sampson <azz@gnu.org> said:
> On Tue, May 16, 2000 at 08:23:43PM +0200, Tomasz Wegrzanowski wrote:
> > Hurd is not only a kernel/OS. IT is also a place where UNIX design
> > mistakes are fixed o be used wider.
>
> ... which is something I'd like to see being done more. [This should be
> sufficient advance warning that whatever follows is likely to be mildly
> incoherent. It's late at night and I've had a long week, so bear with me.]
Fair enough!
> Not that Unix has any particular problems with what it's designed to do. But
> we could certainly make use of a slightly wider viewpoint; most of the new
> work being done in the free OS world at the moment seems to be cloning what
> the commercial Unices or Windows can do.
Agreed, and I'd also agree that almost all of the "flaming" that takes
place vis-a-vis both Linux and Windows comes from the same standpoint
of assuming that there are Two True Operating Systems, UNIX and Windows,
and One of Them Shall Win The Day.
Which certainly ignores all the other possible systems to learn from.
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 think that the real problem is that there isn't much documentation or
> chance to experiment with other OSs. The typical free OS developer (like me)
> has probably used a couple of versions of Unix (or clones), Windows, and
> that's about it. In many cases, this is because we have the opportunity to
> use anything else; 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. There's also little available documentation about any of
> these systems (multicians.org being a rare exception---well worth a visit).
Plan 9 is runnable on a *86 box, so I can't fully agree with that one,
and there's actually a fair bit of availability of VMS info.
To be specific, for VMS:
<DT><A HREF=
"http://home.earthlink.net/~djesys/vms/hobbyist/multia.html";> DJE
Systems OpenVMS Hobbyist Multia Support Page</A>
<DT><A HREF= "http://www.montagar.com/hobbyist/";> OpenVMS Hobbyist
Program Homepage</A>
<DT><A HREF="http://www.decus.org/";>DECUS - A Compaq Users Group</A>
<DT><A HREF="http://www.openvms.digital.com/"; >Compaq.com - Enterprise
Computing - OpenVMS Systems</A>
Is it "GNU"? Certainly not. But if someone is interested in collecting
information, it's certainly not going to be difficult to find running
systems. I suspect that one could put together a MicroVAX system with
"hobbyist" licensing of VMS for a few hundred dollars.
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."
> The Unix bias here does tend to limit the sort of ideas we come up with. For
> instance: one of the easily-available bits of documentation about ITS is a
> paper about what ITS called "PCLSRing", which pretty much blew me away when
> I first read it. Under Unix-like systems, if a system call gets interrupted,
> it will return an error code, so it's necessary to write programs that are
> capable of restarting failed system calls. Under ITS, when a system call was
> interrupted, ITS would modify the arguments to the call so that it would
> continue where it left off, and reset the PC so that the call would be
> executed again with the new arguments when the interrupt handler returned.
> It makes userspace code much simpler. But there's no way that that would
> ever get implemented in any of the existing free OSs, because it's
> completely different to Unix.
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.
> Take a look at some point at some of the features that RMS was thinking of
> back in 1985 in the GNU manifesto. Although many of them have been
> implemented in the GNU tools or in other free software (such as long
> filenames, journalling, filename completion and terminal independance),
> there are a few interesting ones that, while available in the early 80s,
> aren't common today: such as file version numbers.
Part of what 'broke' was that people were so excited about having
Linux around, and have so focused on getting it to cope well with
networking, that relatively little effort has gone into filesystem
work.
Of late, several journalling-related projects have popped up, with
ext3 and ReiserFS as the most notable.
Hopefully the learning that takes place in building a community that
knows how to _build_ filesystems can lead to some extensions, doing
_new things_ about filesystems.
> What this means is to have versioning built into the filesystem, rather than
> done as seperate programs (a la RCS). This was available under ITS. The
> commercial version-control system ClearCase does this (by using a custom
> FS); you can see the most recent version of a file by using its filename
> ("foo"), or previous versions by using "foo@@/version". (The @@ directories
> don't appear in directory listings, by the way.) This would be very nice to
> have in a free OS, particularly for config files and similar; a Hurd server
> which allowed you to apply versioning transparently over an existing
> filesystem would be a sensible implementation.
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." That way
the filesystem might support some structuring within the file.
Trivial would be fixed-size records, rather like the way VMS and MVS
have supported.
Supporting some form of hierarchical data store could provide further
value (or at least a cool idea that might prove horrid in practice);
with the "Oh, it's the Web! It's the Web!" mania going on, would it
not be neat if the filesystem could support structured data so that you
could read through files and find them preparsed?
> Another idea would be combining the debugger and shell. This would mean that
> when a program segfaults (like w3m just has on me), I would be in the
> debugger immediately, and could find out what was wrong and fix it.
> (LISP and Smalltalk systems often do this, and Hurd's suspend-on-crash
> server has similar functionality.)
>
> This is just one example; I'm sure there are plenty of other features in
> "forgotten" OSs which would be useful to us. So, essentially, my plea is
> that if you've got any information about interesting (or not-so-interesting)
> things in other OSs, then try to make it available to others to pick ideas
> from.
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.
--
This login session: $13.99
cbbrowne@ntlug.org - <http://www.ntlug.org/~cbbrowne/lsf.html>
Reply to: