From mboxrd@z Thu Jan 1 00:00:00 1970 From: usotsuki@buric.co (Steve Nickolas) Date: Mon, 2 Jan 2017 01:01:32 -0500 (EST) Subject: [TUHS] Unix stories In-Reply-To: References: <5257291ca0a0e1d80c646cab730129d589c5d707@webmail.yaccman.com> Message-ID: 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.