[naasking]

Looks like a traditional kernel, which I think is a shame. High-level language-based operating systems have a lot more flexibility to enforce fine-grained abstractions rather than a traditional OS's coarse-grained abstractions.

For instance, memory safety is process-level in a traditional OS, but object-level in a programming language. So paging logic doesn't make as much sense here, since it would require a lot of expensive runtime support to make every object lazily loaded, not to mention the expense of the bookkeeping overhead to track which objects should be paged out.

This encourages a more event-oriented architecture where programs provide the kernel with continuation when requesting services. For instance, something like C#'s async/await operating at the kernel process level would be one possible approach.

[amaneureka]

I strongly recommend you to build the kernel once and check output assembly file. which should answer lot of your doubts like extra overhead of object loading. It's not exactly same how you are interpreting. I tried very hard in order to optimize the output code.

[naasking]

Are you saying this is not a traditional operating system design utilizing the MMU for memory protection? If it is, then everything I said is accurate compared to software isolation in an OS like Midori. If not, then you should really point that out because it makes your project much more interesting!

[amaneureka]

Indeed it is utilizing MMU for memory protection. But no that is not the final objective of project.

[naasking]

Sure, your objective is a standard operating system, and that's a neat project. I'm just saying that a high-level language operating system provides many more opportunities for different kinds of trade-offs than found in typical commodity OSs. These aren't trade-offs you can make if you're going to support legacy code or traditional OS abstractions, without jumping through a lot of unnecessary hoops.

[nickpsecurity]

naasking is saying you could try different protection strategies since it's an experimental, clean-slate OS. User/kernel model protection is among the weakest models that only works with separation kernels such as seL4 or Muen. Tiny, tiny kernels. Let me give you examples of alternative, OS architectures and protection models to show what naasking likely meant by doing it different:

http://www-spin.cs.washington.edu/

Note: SPIN OS was written in safe Modula-3. Interesting thing about it was leveraging the language safety & a type-safe linker to allow code to be loaded into kernel for acceleration.

http://www.symbolics-dks.com/Genera-why-1.htm

Note: LISP machines were among most powerful machines ever created for developers. The language itself had code as data philosophy to change it at will. Runtimes had REPL, incremental compilation per function, AOT compilation, and live updates of code. Do a whole OS that way you get feature 7 along with debugging or linking ones on 8-12 page that no OS has today. I mean, single coolest thing your OS could do is allow debugging or updates of it in high-level code that somehow goes through compiler and right back into memory. The same HLL that users write the applications in.

http://www4.cs.fau.de/Projects/JX/

Note: The main paper on this page will tell you what this OS is about. The architecture tries to enforce POLA at a decent granularity with building blocks that are pretty easy to understand. Almost everything is safe. One thing worth copying is using different, garbage collectors for different apps or parts of OS.

https://en.wikipedia.org/wiki/MOSIX

http://encyclopedia.thefreedictionary.com/K42

Note: MOSIX was an OS I ran into when I studied supercomputers in the late 90's. The cool thing about it was how it turned a network of computers into a cluster that it automatically distributed jobs over. Treated them like one machine in a way that typically required low-level, message passing. K42 was IBM's attempt at building blocks for something similar using microkernels and hot-swappable components.

https://www.cs.vu.nl/pub/amoeba/amoeba.html

Note: Amoeba was a distributed, operating system. Each machine ran some code. The OS and apps were spread among them.

https://www.cs.ucsb.edu/~chris/teaching/cs290/doc/eros-sosp9...

Note: EROS was a capability-secure, microkernel OS with trusted networking and GUI stacks. Abandoned when Microsoft hired Shapiro. Capability model has strong properties for enforcing POLA but one must be clever to minimize overheads.

E language and capability model

https://www.combex.com/papers/index.html

Note: Embedding the capability model as constructs in the language, esp RPC's, can make for interesting abilities.

https://www.microsoft.com/en-us/research/publication/safe-to...

Note: Nucleus is literally stolen from a 70's-era mainframe that did same stuff along with Per Hansen. The idea is you wrap all the low-level stuff behind an interface that forces it used safely & consistently in above layers. Then, above stuff is easy to do in high-level language. The how of this has many possibilities. Safety enforced statically with type systems or Design-by-Contract (e.g Spec#); or dynamically with argument checks; or both.

[jstimpfle]

I'm super excited about the idea of removing the artificial boundaries between kernel and userspace. Equally, static and dynamic compilation.

Are there any technical or practical reasons why systems like Symbolics Genera are inferior to todays mainstream operating systems? Or do you think it's only social / economic processes that they weren't adopted?

[nickpsecurity]

It was economics like with most hardware of the time. Those were expensive, custom machines. The CISC and RIZC processors kept getting cheaper and faster to point that users, mostly wanting performance, were better off buying them. Genera itself eventually got hosted as an emulator or something on Alphas. Then Alphas bit the dust haha. Wait, it's not funny cuz PALcode was amazing.

Anyway, economics and market demand as usual. That's what killed it.