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.