From: usotsuki@buric.co (Steve Nickolas)
Subject: [TUHS] Unix stories
Date: Mon, 2 Jan 2017 01:01:32 -0500 (EST) [thread overview]
Message-ID: <alpine.BSF.2.02.1701020058230.83335@frieza.hoshinet.org> (raw)
In-Reply-To: <CAH1jEzbnqCPYDfOqmAE+N=4jFG4YoitUf=+w29FUOP7wGw6KXg@mail.gmail.com>
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.
next prev parent reply other threads:[~2017-01-02 6:01 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-01 5:00 Larry McVoy
2017-01-01 6:48 ` Nick Downing
2017-01-02 2:03 ` Steve Johnson
2017-01-02 2:42 ` Nick Downing
2017-01-02 6:01 ` Steve Nickolas [this message]
2017-01-02 6:21 ` Warren Toomey
2017-01-02 6:25 ` Nick Downing
2017-01-04 4:07 ` Steve Nickolas
2017-01-02 7:29 ` arnold
2017-01-02 22:52 ` Dave Horsfall
2017-01-02 22:56 ` Larry McVoy
2017-01-02 22:59 ` Ronald Natalie
2017-01-02 22:58 ` Ronald Natalie
2017-01-02 23:23 ` Tim Bradshaw
2017-01-03 0:49 ` Larry McVoy
2017-01-03 11:36 ` Joerg Schilling
2017-01-04 13:04 ` Steffen Nurpmeso
2017-01-04 14:07 ` Random832
2017-01-04 14:54 ` Ron Natalie
2017-01-04 15:59 ` Random832
2017-01-04 16:30 ` Steffen Nurpmeso
2017-01-04 16:32 ` Random832
2017-01-04 16:51 ` Steffen Nurpmeso
2017-01-04 16:54 ` Random832
2017-01-04 16:58 ` Ron Natalie
2017-01-04 17:38 ` Steffen Nurpmeso
2017-01-04 17:47 ` Steffen Nurpmeso
2017-01-04 18:51 ` Steve Johnson
2017-01-04 17:08 ` Steffen Nurpmeso
2017-01-04 16:22 ` Steffen Nurpmeso
2017-01-04 16:35 ` Random832
2017-01-04 17:03 ` Steffen Nurpmeso
2017-02-09 13:46 ` Steffen Nurpmeso
2017-02-09 14:55 ` Random832
2017-02-09 17:15 ` Steffen Nurpmeso
2017-01-01 13:11 ` Ron Natalie
2017-01-01 16:50 Noel Chiappa
2017-01-01 21:45 ` Nemo
2017-01-02 2:53 ` Wesley Parish
2017-01-02 14:30 Doug McIlroy
2017-01-02 18:36 ` Dan Cross
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.BSF.2.02.1701020058230.83335@frieza.hoshinet.org \
--to=usotsuki@buric.co \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).