OSDev.org

The Place to Start for Operating System Developers
It is currently Fri Feb 26, 2021 1:10 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 9 posts ] 
Author Message
 Post subject: Extraordinarily designed OSs
PostPosted: Sat Feb 13, 2021 11:46 am 
Offline
Member
Member
User avatar

Joined: Fri Nov 22, 2019 5:46 am
Posts: 567
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

_________________
https://wiki.osdev.org/User:PeterX


Top
 Profile  
 
 Post subject: Re: Extraordinarily designed OSs
PostPosted: Sun Feb 14, 2021 12:24 am 
Offline
Member
Member
User avatar

Joined: Mon May 22, 2017 5:56 am
Posts: 546
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! :D

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.

_________________
Kaph link pending. code pending. design pending. plans in a state of flux! everything pending! choice of language still up in the air! why is nothing coming together?!?


Top
 Profile  
 
 Post subject: Re: Extraordinarily designed OSs
PostPosted: Sun Feb 21, 2021 12:08 am 
Offline
Member
Member

Joined: Wed Apr 01, 2020 4:59 pm
Posts: 62
eekee wrote:
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.



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


Erlang deals with this well.


eekee wrote:
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.


Top
 Profile  
 
 Post subject: Re: Extraordinarily designed OSs
PostPosted: Sun Feb 21, 2021 11:39 am 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1724
Location: Athens, GA, USA
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

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
μή εἶναι βασιλικήν ἀτραπόν ἐπί γεωμετρίαν
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
 Post subject: Re: Extraordinarily designed OSs
PostPosted: Sun Feb 21, 2021 12:37 pm 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1724
Location: Athens, GA, USA
moonchild wrote:
eekee wrote:
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.

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
μή εἶναι βασιλικήν ἀτραπόν ἐπί γεωμετρίαν
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
 Post subject: Re: Extraordinarily designed OSs
PostPosted: Sun Feb 21, 2021 2:58 pm 
Offline
Member
Member
User avatar

Joined: Thu Oct 13, 2016 4:55 pm
Posts: 1269
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


Top
 Profile  
 
 Post subject: Re: Extraordinarily designed OSs
PostPosted: Sun Feb 21, 2021 3:45 pm 
Offline
Member
Member

Joined: Wed Apr 01, 2020 4:59 pm
Posts: 62
bzt wrote:
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!


Top
 Profile  
 
 Post subject: Re: Extraordinarily designed OSs
PostPosted: Sun Feb 21, 2021 4:08 pm 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1724
Location: Athens, GA, USA
You could also mention the various persistent-memory OSes and those which use capabilities (with several overlapping those categories):

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.

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
μή εἶναι βασιλικήν ἀτραπόν ἐπί γεωμετρίαν
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
 Post subject: Re: Extraordinarily designed OSs
PostPosted: Tue Feb 23, 2021 3:32 pm 
Offline
Member
Member

Joined: Wed Mar 09, 2011 3:55 am
Posts: 406
bzt wrote:
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group