OSDev.org

VMS is the most extraordinary. Mainly because this is the operating system that I am most familiar with. It was far ahead of its time, most people who use VMS do not want anything else. There are stories of old VAX servers in production which are up for more than a decade.

Also with VMS you would love money more, there is $ everywhere .
--Thomas

Hey!

It seems I land a year too late^^, I would like to mention 2 other entries to these thread

• Sculpt OS [1] which comes from the Genode OS framework that has already been mentioned
  Qubes OS "A reasonably secure operating system" [2] That I use daily (and post this message from )

Sculpt OS is a "component based general purpose operating system" and is developed with Genode. To be more precise, Genode itself is not an OS but a framework that allows you to build component-based OS/scenarios on top of different kernels, hypervisors.
Sculpt gives the maximum control to the user, and let you add/remove components at runtime [3]. Here is the "Sculpt for Early Adopter" [4] article that gives a good architectural overview of Sculpt and what's possible to do with the framework. Sculpt also supports virtualization, so you can gracefully transition to a safer future

The framework features strong isolation between components. Each component has a strict view/access to only resources it really needs. e.g. each component receives a fixed physical ram quota, if it requires more, a component will need to emit a resource request to its parent component, the parent may or may not satisfy that request by providing more physical ram taken up on its own quota.
This applies for any resources accessible on the system, and for other services' consumption as well. Thus, it is quite easy to determinate the exact resource(s) and component(s) dependency for any component in the system, device drivers included (as they are components).

Speaking of device drivers, the framework provides an impressive Linux device driver environment, where unmodified Linux device drivers can run as a component on Genode. DDE for OpenBSD, iPxe and rumpkernel are also featured.

Qubes is a general purpose single-user OS [5]. It relies on the Xen hypervisor project to allow creation and management of isolated compartments called "qubes". Each qube runs its own operating system inside a VM. A qube is therefore more heavyweight than the lightweight components that Genode provides.
For example, you can separate banking from personal work. Thus, if your personal qube get compromised, it does not affect the others.

Conceptionally, Genode and Qubes have a lot in common. However, their approach differs. Qubes is a more top-down approach, being that their building-blocks are VMs on top of Xen. Xen+Linux support a wide range of hardware. Genode is a more clean-slate buttom-up approach. In my view Genode does a lot of things right. It's very likely that we will see a combination between Qubes and Genode one day.

I hope you'll find it interesting!

Cheers
-vania

[1] https://genode.org/documentation/articles/sculpt-21-03
[2] https://www.qubes-os.org/
[3] https://genode.org/about/2020-09-16-sculpt.png
[4] https://genode.org/documentation/articles/sculpt-ea
[5] https://www.qubes-os.org/intro/

I can't believe it's been a year since I posted in this thread. It doesn't feel like so long at all, although I think the way I express myself has changed in that time. Come to think of it, the way I think about development has changed a lot over the past few years.


Hi Vania! Your post interested me. However, I'm not at all convinced of the security of systems based on virtual machines. I really don't see how they'd be any more than a temporary inconvenience to crackers. I recall 9front's lead dev not seeing how they'd offer more isolation than processes, and I could quote some very strong language from OpenBSD's lead dev. I think it's interesting to look at processes. By design, there's nothing they can do without the operating system's support, yet there are oversights in design and implementation and oversights in implementation, and sometimes we blow holes right through good security practice for reasons of performance or convenience. (I have a story about WebGL on Intel hardware. :s ) It's all the same with VMs.

Last year, moonchild wrote:

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.

Right, thanks. Robust message-passing is certainly going to be interesting. I don't think that's too contrived; the window for the crash is very narrow but could happen. (It's like a race condition in that way.) It's also interesting in that the lost token may represent part of a finite resource. I think process B should not consider the token to be in use until process A acknowledges receipt. If A never acknowledges, then the token and the resource it represents should be considered for reuse. Of course, A should absolutely not use the token before it's sent an acknowledgement.

Oh wait... *sigh* Let's say there's a single-use resource, so there's only 1 token which B can give out to 1 process at a time. A requests it, B grants it, but before A can acknowledge, C requests it. Because the token hasn't been acknowledged, it's up for reuse, but then, when A acknowledges it, B has to accept or reject the acknowledgement. Is that the final necessary part of the process or could it get worse? I've run out of brain cells for now. I'm not sure I can just say it'll work with cooperative multitasking... I suspect a system crash could reorder process execution... Right! I'm quitting before I get a headache. I still haven't written my reply to Vania.

moonchild wrote:

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

Erlang deals with this well.

One for the list of languages to learn. Does it have a notion of garbage-collecting threads? I think Go does, and I vaguely remember Erlang coming up in a Go discussion or two.

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. [snip] 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.

Thanks! It's definitely on my list to look at later. I really will have to get around to learning Lua. It shouldn't be hard at all after the languages I've learned in the last few years.

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

I have different responses to different parts of that. Analog input is particularly important to picking items from a list because it can go straight to the item you want as soon as you see it. Getting the text highlight to the right place is something I find disruptive; it's distracting. On a nicer note, I agree with lumping terminal multiplexers under window management. I'm finding digital input for text editing okay with some caveats; it must be simpler than VI and preferably written by myself so I know exactly what each command does, but I still find the mouse easier for editing prose. It's the same issue as with lists: the mouse pointer can go exactly where I'm looking without any particular thought. I guess that might not be the same for everyone.