[TUHS] Unix stories

[Steve Nickolas]

On Mon, 2 Jan 2017, Nick Downing wrote:

> What I want to do is go back to a REALLY SIMPLE unbloated system,
> which is why I am very interested in 2.11BSD (you probably saw my
> earlier posts about the 2.11BSD system and potential port to Z180 and
> so on). And then I want to define the ONE TRUE WAY(TM) of doing each
> thing. But before I do this I want to go right back to basics and look
> at the object model used in the operating system itself. For instance
> the stuff like the oft (open file table), inode table, the filesystem
> table (I mean Sun VFS which isn't in 2.11BSD AFAIK but eventually
> should be), the device table and so on. And also the user-visible
> objects like files, sockets etc which map to kernel objects.
>
> So once I have sorted all this out and created an object model that
> the kernel can use efficiently, with compiler support (like C++
> without the bloat, like java with internal pointers and ability to get
> at the bits and bytes of your objects, like C without all the void *
> stuff and with automatic handling of stuff like vtables), and
> converted the kernel and all drivers to use it, then I think I will
> have an object model that is useful in practice. So my idea then is to
> export it to userlevel, so that userland programs can be rewritten
> into this new C-like object oriented language and calls like: count =
> read(fd, buf, size) would change to: count = fd.read(buf, size) since
> kernel objects are objects. There would also be a compatibility layer
> that allows you to keep a table of integer fds and their kernel
> objects in userspace for porting.
>
> After this I would start to look at popular libraries like the C
> library or the X-Window system, and convert them to use the new object
> model, while also providing the compatibility layer as I did for the
> kernel interface. Ultimately the result would be a bit like Java, but
> using all the familiar Unix objects and familiar Unix calling
> conventions (such as argument passing by reference or malloc/memcpy
> stuff that Java can't do). Also without any header files or
> boilerplate of any description, which is one of my pet peeves with
> Java, C, C++ etc.
>
> I really think that the solution to bloat is to go through and rewrite
> everything to do things in a more standardized way with more reuse.
> Also I think that the massive amount of bloat arises to some extent
> because the environment lends itself to writing non maintainable code
> (for example you have to write loads of boilerplate and synchronize
> function definitions in various places, which discourages you from
> changing a function definition even if that's the right thing to do in
> a situation). So there's always the temptation to add another
> compatibility layer rather than dealing with the bloat. Rewriting
> things in a much more minimal and maintainable style is the answer.
>
> Another reason for bloat is that authors have to support millions of
> slightly different systems. My idea is to totally standardize it, like
> POSIX but much more drastically so. Think about Java, it defines a
> strict virtual machine so there's nothing to change when you port your
> code to another platform. I haven't totally decided how to handle
> word-size issues in this context, but I am sure there is a way.

This vaguely reminds me of an idea I had a couple years ago, but never 
mentioned because I thought it might be perceived as daft.

I had the idea of writing a virtual machine specifically tailored to 
running C code, with a virtual operating system similar to Unix.  On the 
surface it would probably feel like running Unix under an emulator, but 
the design would probably be a bit less baroque, because everything would 
be designed to work together cleanly.

Like the mutant child of Unix and UCSD Pascal, I suppose.

-uso.