Describe your dream OS

[moonchild]

Fully integrated operating system and programming language. Like the lisp machines.

Completely transparent networking. Like plan9.

No file system. No need to distinguish between 'objects held in memory', 'objects held on disc', and 'objects referenced through the network from another computer'. Thus, serialization is redundant.

Very fine-grained permissions, on the level of threads. (A thread can create another thread with fewer permissions than itself, if it wants. It can also remove permissions from itself a la pledge/unveil.)

No 'user-mode'/'kernel-mode' distinction. Everything happens in ring 0. Everything except for kernel/drivers is written in the integrated programming language, which is safe. There is no such thing as a context-switch, so process switching is completely free (modulo cache miss, which is to be expected).

Running processes are completely transparent; their state can be freely inspected and modified. A process is just an object, as is a string-keyed btree (like a file system); row- or column- oriented structureset (like a row-based or columnar database); multidimensional array (spreadsheet)... All these objects can be nested arbitrarily within each other.

[eekee]

That's pretty-much what I want, or have wanted at some point, modulo my tendency to rebel against safe languages. :cyberpunk: Also, I like the elimination of distinction between objects in different stores, but may very well have a filesystem-like object index, if that makes sense. After failing at planning several times, I lowered my sights a bit, but I think I'll get most of the pieces in eventually.

[moonchild]

modulo my tendency to rebel against safe languages.

I find that interesting, because this is kind of at the centre of my vision. Without a runtime for the language, the introspection and integration kind of...don't work. Also, without runtime-enforced safety, you have to do traditional process separation for security, which seriously harms performance. (Unless you want to completely disregard security, which is a completely valid position.)

Also, I like the elimination of distinction between objects in different stores, but may very well have a filesystem-like object index, if that makes sense.

Yes. I plan something something similar. Every process gets its own 'namespace', but a namespace is just another object which has to reside somewhere. Think linux /proc, except all application-specific data is part of the app's 'proc'. So there's a root object of some sort (this part I'm not sure about yet; perhaps this can be configurable, so some people will have a hierarchical-fs type thing as root; others an array, or associative array, or database, or...—depends on personal preference). And then, before you can run a process, you have to give it somewhere to put its namespace. But you can also put other arbitrary data in the root (or subobjects thereof).

After failing at planning several times, I lowered my sights a bit, but I think I'll get most of the pieces in eventually.

Good luck! Incrementality is the way to do it.

[eekee]

modulo my tendency to rebel against safe languages.

I find that interesting, because this is kind of at the centre of my vision. Without a runtime for the language, the introspection and integration kind of...don't work. Also, without runtime-enforced safety, you have to do traditional process separation for security, which seriously harms performance. (Unless you want to completely disregard security, which is a completely valid position.)

I forgot, I have been thinking of jails for untrusted code. Forth words can be redefined so, for example, the pointer access words could be changed to restrict access to the process's data memory only, and I have an idea to simplify and speed that. I don't know where I'd get untrusted code, but it would also be useful for developing new code. Or I could set up the MMU and go to ring 3 for untrusted/new code only. The MMU would be better, it would give me an error on out-of-bounds access. Restricting pointer access with my idea is simpler to implement and works on anything, but results in bad addresses wrapping around. It's simply AND to limit the range and OR to add the offset - the fastest operations on any processor, I think. Trusted library code would be exempt. But I might be getting into too much detail for a dreams thread.

How to reference data is a huge subject. It's so big, I find I've developed an aversion to thinking about it. Schol-R-Lea has some interesting ideas when he's in a good mood.

After failing at planning several times, I lowered my sights a bit, but I think I'll get most of the pieces in eventually.

Good luck! Incrementality is the way to do it.

Thanks!