Extraordinarily designed OSs

[PeterX]

In this thread I would suggest to name OSs with extra-ordinary design (meaning not the look and feel but the technical design decisions).

I would like to start with these:

- Genode: Security kind of "inherited" from "instances" and given fine grained to other "instances".

- Phantom OS: Data persistance (meaning everything is stored non-volatile).

If anyone has a favorite OS with some unique technical design, he/she might name it here *Looking at eekee...*

Greetings
Peter

[eekee]

Hahaha! I was just thinking, "I've been considering both of those design features," and then saw my name at the bottom of the post. Thanks Peter!

I'm... hoping to have a lot of extraordinary features in Kaph, but I'm not clear on how many of them will fit in. I also still need to get more familiar with Forth and/or Plain English Programming. I've been writing Forth, getting practice, but I clearly still have a long way to go there. I have fewer ideas I want to try in PEP, mostly because it's non-interactive. My next step is to get Forth working on a bare machine, port my stuff over from my tablet, and carry on coding to get practice and see how various ideas could be fitted in. Once I've got some working ideas, I'll probably scrap it all and start again. I mean I'll refactor the design to produce a clean implementation between versions 1 and 2 or 0 and 1 or something.

I have had some ideas for persistence of main memory, but that's really the easy part. Swap, mmap (if always file-backed), and Forth blocks all offer natural methods for persisting whatever is written to them. Dealing with drivers being reset is another matter. I think with some devices (screen, mouse, ...) the OS can readily give the impression they were up all along, but with network... well, programs shouldn't assume the network is reliable anyway. It's all the same issues as "suspend to disk" really. It shouldn't be a problem if the OS is designed for this. More annoying might be memory leaks and other cruft from programs and the OS never being restarted. Those faults need to be cleaned up individually. But, do you know what? As I write this out, none of the points seem too big to handle.

That one line about Genode describes something I've considered. It's possible in Plan 9: a process can build a new, limited namespace, then rfork(RFNOMNT) to lock it in. listen (the inetd-equivalent) has a limited ability to do this. The shell can do it too with rfork m, which could be used by having listen start wrapper scripts to limit the namespace before running the actual server. (That's normal anyway.) httpd does its own listening and can source a file to control its namespace. But enough about Plan 9. I really liked the approach when I was last thinking about it. I'll no-doubt think of it again when I have some features to secure... now I've made a note! Thanks for the reminder.

I once considered hierarchal scheduling as an anti-DoS measure, but that would make more sense for a game or virtual world where you don't want one player's scripts taking CPU time from other players' scripts. Each user would get their own script timeslice, each of the user's objects its own timeslice within that, then each script within an object would get a share of the object's timeslice. It might be nice on multi-user OS servers too, but I don't think it's applicable to protecting a web server from DDoS.

I would like to deconstruct the whole idea of applications. (Smol bombshell there. ) I want components for users to assemble rather than applications which stand apart from the system. From some perspectives it can be hard to see how to do this, but when block text editing in Forth, I have a bunch of different commands all apply to the current block. Some are part of the editor; designed by its author. Some I've made to go with the editor. Some I've made to not use any editor features, only the variable which identifies the block last listed. (The editor calls list.) And one, move, is part of standard Forth quite apart from any text editing. I sometimes use pad which is a scratch space provided in the standard for strings and other things, but mostly I use my own x-block; it's like pad but much bigger. But how to design a good set of app/gui components for users to assemble into applications is another story! There will be some trial and error in that, just like the rest of the system.

[moonchild]

I have had some ideas for persistence of main memory, but that's really the easy part. Swap, mmap (if always file-backed), and Forth blocks all offer natural methods for persisting whatever is written to them.

It's not necessarily that easy.

Consider crash tolerance in the face of synchronization as one problem. Say process A requests some token from process B, and process B sends the token. Then there's a crash. Process B's state was synced after sending the token, and process A's before receipt. So now, process B remembers giving away the token, but process A doesn't remember receiving it. Process A says ‘can I have a token’ and process B says ‘??? no, I already gave you a token’.

Obviously this is a bit of a contrived example, and there are a number of simple solutions; but the point is that it's not easy to make something like that completely transparent to user code. And if you do make it transparent then you may have to make other compromises like rolling back state that you could otherwise have kept.

memory leaks and other cruft from programs and the OS never being restarted

Erlang deals with this well.

I would like to deconstruct the whole idea of applications. (Smol bombshell there. ;) ) I want components for users to assemble rather than applications which stand apart from the system. From some perspectives it can be hard to see how to do this, but when block text editing in Forth, I have a bunch of different commands all apply to the current block. Some are part of the editor; designed by its author. Some I've made to go with the editor. Some I've made to not use any editor features, only the variable which identifies the block last listed. (The editor calls list.) And one, move, is part of standard Forth quite apart from any text editing. I sometimes use pad which is a scratch space provided in the standard for strings and other things, but mostly I use my own x-block; it's like pad but much bigger. But how to design a good set of app/gui components for users to assemble into applications is another story!

Recommend taking a look at arcan.

IMO the traditional gui paradigm is super broken. I wrote a bit about this on reddit a few months ago.

[Schol-R-LEA]

I've mentioned Synthesis a number of times before, as something I have an interest in trying to recreate to see if the benefits of run-time code synthesis, quajects, pre-computing IPC, fine-grained thread scheduling, etc., translate well on modern processors. I even tried getting in touch with Dr. Massalin and Dr. Pu about it, and got some helpful advice from the latter (I couldn't reach the former), who basically said that the papers should have sufficient information about the task, but that the original code won't be published even now as it wouldn't be of value to someone working on different hardware.

He also mentioned some later papers on related topics that he recommended reading, which I am planning to do soon.

I don't know if it would really be practical as more than an academic exercise, but it is still of interest, I think.

I should note that the system was originally on a unique hardware platform call the Qua! Machine, which used a pair of Motorola 68030 CPUs. It was also ported to a Sun NeWS workstation, which was also a dual-processor 68030 system. All the system code was in assembly, using a homebrew macro assembler, and involved heavy use of the macros for templating the generated code sections. The dissertation points out that much of it could have been re-written in C given a more modern compiler than was available for the M68K when the project was begun, though the main feature of it - quajects and other executable data structures - couldn't be.

References
An Overview of The Synthesis Operating System
Synthesis Kernel, a white paper covering the major concepts
Synthesis: An Efficient Implementation of Fundamental Operating System Services (1992) (Massalin's doctoral dissertation). Reproduced in HTML here
Quick summary of the dissertation
Reimplementing the Synthesis Kernel on the Sony NeWS Workstation
PPP's article on Synthesis OS
"It’s Time for a Modern Synthesis Kernel", a white paper by Prof. John Regehr

[Schol-R-LEA]

I would like to deconstruct the whole idea of applications. (Smol bombshell there. ) I want components for users to assemble rather than applications which stand apart from the system. From some perspectives it can be hard to see how to do this, but when block text editing in Forth, I have a bunch of different commands all apply to the current block. Some are part of the editor; designed by its author. Some I've made to go with the editor. Some I've made to not use any editor features, only the variable which identifies the block last listed. (The editor calls list.) And one, move, is part of standard Forth quite apart from any text editing. I sometimes use pad which is a scratch space provided in the standard for strings and other things, but mostly I use my own x-block; it's like pad but much bigger. But how to design a good set of app/gui components for users to assemble into applications is another story!

Recommend taking a look at arcan.

I will look into this myself, as I have similar ideas about how applications could be destructured; my idea is to have toolsets or functions and objects which could be composed to create 'tool frameworks' which would be used in lieu of fixed applications.

I should mention the Oberon Operating System's 'Live Text User Interface' (actually a GUI which allowed code snippets to be selected and run, or pinned to windows to form menus), which tried to bridge the gap between CLI and GUI without needing a specialized macro recorder or scripting tool.

[bzt]

Good examples! Here's a few more:

VMS, general purpose OS though, but the most extraordinary designed (first 32 bit (in 1977), first with virtual addresses, first network distributed, first speech synth, first in many many many things)
Alto the very first OS with a GUI, quite extraordinary
JunOS specially designed for VPNs and firewalls and other network based stuff.
IOS (not the Apple's one) designed for high performance package routing (and has IPSec instead of VPN, and some firewall features in ASA, but that's pretty bad, better forget it)
FreeRTR a hobby OS designed for routing and virtualization (that page is served by FreeRTR )
KasperskyOS an OS specifically designed for anti-virus appliances
Singularity a research OS without MMU (single address space, abandoned)
Contiki an extremely low resource requirement OS (runs on 64K) for 8-bit processors with networking and GUI
FreeRTOS for real time scheduling tasks on microcontrollers
SanOS an extremely small OS to do one thing: run a single java server application

I'm not sure if all these are "extraordinary", but they aren't general purpose OSes, they are designed for a very specific task. And if Linux distributions also counts, the list is almost endless. A bit outdated, but has some interesting links and good reading: research OSes.

Cheers,
bzt

[moonchild]

I'm not sure if all these are "extraordinary", but they aren't general purpose OSes, they are designed for a very specific task

Another cool one along similar lines is sel4. Microkernel; fast; capabilities; and completely formally verified to boot!

[Schol-R-LEA]

You could also mention the various persistent-memory OSes and those which use capabilities (with several overlapping those categories):

• GNOSIS, which is the first in a series of OSes, most of which I'll list here
• KeyKOS
• EROS
• CapROS
• CoyoteOS
• seL4 (already mentioned by moonchild)
• Genode (already mentioned by PeterX)

While they are relatively mainstream, I would expect someone to consider some of the unusual aspects of both Plan 9 and Inferno to be worth considering.

[linguofreak]

Good examples! Here's a few more:

VMS, general purpose OS though, but the most extraordinary designed (first 32 bit (in 1977), first with virtual addresses, first network distributed, first speech synth, first in many many many things)[/url].

Nope, the Atlas supervisor has it beat for virtual addressing by 15 years, and systems like MTS and CP/CMS on the IBM 360 model 67 have it beat by about 10.

[Schol-R-LEA]

As I mentioned previously, I contacted Calton Pu regarding the Synthesis OS kernel design, and one thing he pointed out to me were two later papers of his regarding how to apply program specialization via partial evaluation to a more conventional Unixoid kernel design (with one case study using HP-UX, specifically). Those papers would likely be of interest to a wider audience than the Synthesis papers themselves, but I wasn't aware of them until he mentioned them so they seem to have mostly been ignored until now.

Optimistic Incremental Specialization: Streamlining a Commercial Operating System

and

Specialization Tools and Techniques for Systematic Optimization of System Software

A significant comment of his, which he repeated to me more than once, was that "our main lessons [from this later work were]: (1) The specialization of code is the (relatively) easy and fun part; (2) the real challenge is in the guarding of invariants used in specialization", so I am giving some consideration to that latter part especially.

[Korona]

Are there any modern OSes (= not DOS etc.) that do not use a capability-based design for resource access?

Systems like Linux (+ other UNIX-likes) and Windows all use capabilities (UNIX calls them file descriptors, while Windows calls them handles but they are essentially the same: process-private tokens to grant avcess to a resource).

In contrast to that, our web works quite differently: all resources have global names (namely, URLs) and access is managed though cryptography. Are there any OSes where all resources have global (and not process-private) names? How do they manage access?

[moonchild]

Are there any modern OSes (= not DOS etc.) that do not use a capability-based design for resource access?

Systems like Linux (+ other UNIX-likes) and Windows all use capabilities (UNIX calls them file descriptors, while Windows calls them handles but they are essentially the same: process-private tokens to grant avcess to a resource).

A file descriptor is not exactly a capability.

It has limited granularity; you can't share a file descriptor with another process. Nor can you limit access to it, having created it; for instance, you can't start with an fd that represents rw access to some object, and then later limit it to ro access.

[Korona]

Granularity is not a defining feature of capabilities, the defining feature is their process-private ownership model.

Furthermore, both of what you describe is actually possible on modern UNIX like OSes. You can share FDs by sending them over UNIX sockets (which is even defined by POSIX and not a system-specific extension). This is used frequently to pass memory without copying, e.g. by X11 in DRI mode or by Wayland. To restrict access further, you can open /proc/<pid>/fd/<fd> on Linux in read-only mode. Other OSes have similar features.

Regarding the granularity of access: that necessarily depends on the resource in question. If we keep the example of DRM (i.e., the Linux kernel's GPU interface), Linux has three different granularities (which are not managed through rw flags but rather through the FD itself): allowing everything (e.g., video modeset), allowing everything but modeset (for display servers that are on an inactive virtual terminal), and offscreen rendering only. (For VR, there is a patch set that adds per-monitor modesetting as another granularity of access; I do not know if it's already merged or not).

What I am interested in are OSes that do not have process-private resource addressing at all - all designs that I can find use capabilities in some form.

As a side remark, I do not really understand where the sentiment that UNIX FDs are not capabilities stems from. The EROS essay (which was already mentioned in this thread) on capabilities from 20 years ago lists UNIX FDs an example for capabilities that are implemented in the wild. Historically, the first capability based systems were developed concurrently with UNIX, hence the naming is different (and UNIX FDs obviously use "file" not "object" or "resource" in their wording) but it's exactly the same concept.

[void]

You could also mention the various persistent-memory OSes and those which use capabilities (with several overlapping those categories):

• GNOSIS, which is the first in a series of OSes, most of which I'll list here
• KeyKOS
• EROS
• CapROS
• CoyoteOS
• seL4 (already mentioned by moonchild)
• Genode (already mentioned by PeterX)

While they are relatively mainstream, I would expect someone to consider some of the unusual aspects of both Plan 9 and Inferno to be worth considering.

Has anyone on this forum implemented an OS inspired by these?

[rdos]

So, a handle is a capability? I had no idea.

I use handles that are per process for basically everything, and they are typed. Unlike unix, you cannot use a handle for a socket or any other non-file object with the file API, rather handles have their unique associated API functions. Handles cannot be shared between processes, but the underlying kernel object potentially can be. I don't have general read/write permissions, and I don't have general read/write functions either. Some objects, like a specific file, can be opened by multiple processes at the same time (using different handles) while others are exclusive. When a process terminates, all its handles will be automatically freed. I currently have 36 different handle types.

For many handle types, I have C++ classes that encapsulate the handle and export the API functions as methods.

The standard C handles are separate and can be connected to a sub-set of the OS handles.