Hello! I am a human and I have concluded that all OSes suck for my needs!

Please pardon the truly awful page source. ;)

These features are organised in to lists until I decide to learn something newer than HTML 2.0

Kernel-level features:

• Microkernel/Type-1 hypervisor hybrid. For ease of fault-tolerance and sandboxing, as little as possible will be run in the privileged kernel. Hardware drivers will be "sandboxed" and run in their own "VM". Device access will be passed through to the hardware via the control micro kernelvisor. Security controls will be available, but only enforced by the micro-kernelvisor. The actual security "services" will be run in a sandboxed VM for fault-tolerance and isolation due to eventual breaches of security. The micro kernelvisor should do little more than act as a message bus switching messages between "VMs". The "hypervisor" which will run the message bus-kernel will only handle basic hardware initialisation and responding to messages sent to it via the message bus microkernel running in a privileged "VM".
• Privilege and resource separation No VM will be able to access the resources of another VM without it having permission to do so in its configuration. Invalid requests the VM lacks the privileges to will be denied. A subsystem for accessing devices of another VM will not be handled via the microkernel's message bus, they will instead be handled in a way similar to the Inter-User Communication Vehicle (IUCV) in IBM's VM operating system which will provide a direct message bus between the VMs it is attached to. Memory, hardware devices (hardware cannot directly be accessed via the vm-to-vm message bus. Direct hardware accesses will be tightly controlled by the VM that initialised them), and so forth can be shared via this vm-to-vm message bus. However, you can configure default privileges accessing all VMs to access say, the networking stack or USB hubs. Said USB hubs and networking interfaces would run in their own "VM"
• Hardware abstraction layer APIs for various driver subtypes will be provided. A basic SCSI, USB, or networking API for example would be created. Drivers for specific hardware merely hook in to these APIs and declare the features they support. Drivers can declare features not mentioned in the APIs. The APIs are to be limited and only provide basic sandboxing and message-passing procedures

Filesystem

• Record-based All files will be stored in records, records can vary in length. VM-to-vm communications can be performed by passing a "Record ID" to the main filesystem handler VM (although each VM is allowed its own virtual filesystem with its own filesystem manager providing its own security) instead of needing to access the data and pass the data over the bus with several layers of indirection.
• File versioning It will be possible to have different versions of files present seamlessly. This can be enabled on a per-volume basis. Imagine this as how FILES-11 on VMS and others does it: Modify FILE.TXT;1, FILE.TXT;1 still exists, but the changes are written to FILE.TXT;2. This versioning feature can be disabled/enabled on a per-directory basis. Filesystem/volume "snapshotting" as similar to in ZFS will be offered.
• Volume management A "disk" will be divided in to different volumes, these volumes can number between 1 and 65536. If more volumes are needed, it can be arranged. Different filesystems can be written to these volumes, or they can be used as a way of creating a hierarchy with differing quota, permission, versioning, and snappshotting settings. For example: /usr, /var/, and /users can all have different quota limits and maximum sizes. /usr and /users can have file versioning turned off if the default for the root volume is "on".
• Online resize Filesystems/volumes can be enlarged or shrunk at runtime. As always, online resize will not be recommended.
• "Cluster-aware"/Networkable Volumes/filesystems on other systems can be accessed via a direct network "channel" to the filesystem engine "VM" on a remote system facillitated by the networking stack "VM". A vm-to-vm message bus will be established between the storage and networking VMs in this situation. Controls will be handled by the security "VM".

Userland

• Shell A text-mode shell will be provided. This shell will borrow designs from various OSes. It will offer command completion a-la TENEX/TOPS-20 (press escape and a list of parameters for a command are provided.) Help can also be embedded in to this command completion system. The syntax will not be as terse as JCL or DCL, but not quite as...obtuse as the syntax to the Bourne shell(s)
• Inter-process communication Inter-process communication can be provided via a "pipes/output redirection" facillity or by using the microkernel message bus. Here's an example of the format of the IPC packet: {VM ID}{Process ID}{User ID}{Data}. A direct process-to-process messagebus can be created. This can be either within a "VM" or via a vm-to-vm message bus as an intermediate transport
• Administration Administration of the micro kernelvisor is done via a privileged VM with full access to the message bus and hypervisor configuration. This can be used to add/remove/delete VMs.
• STREAMS-compatible API A STREAMS-compatible API will be provided for use for whatever you can think to do with it. It will be used via the message bus for terminal handling and network listeners.

Security

• Role-based User accounts/access levels will be provided by configuring "roles". Each role can have specific devices its allowed to access, filesystems, VMs, commands, et cetera. One role can inherit the privileges of a role it is set to inherit said privileges from
• >Isolation VMs can be configured in various "types". The first type: cooperative. VMs in the cooperative state (if they are in the same "cooperative group") can share resources between them such as devices, roles, accounts, message buses, et cetera. The second type are: islands. VMs in the island state have resources dedicated to them and only them. They are completely cut off from the rest of the VMs. The privileged VM cannot even access "island" VMs. Their resources are strictly controlled so as to only the underlying drivers can access them (For example, a filesystem can be created for "island" VMs and only "island" VMs to use). Resources cannot be shared between VMs unless the security "server" is configured to permit said sharing of resources. When operating in an "island" state, separate private instances of the various subsystems (security, filesystem, networking) can be created running only within that VM. They are as isolated as they can possibly be

Fault handling/tolerance

• Graceful crash handling If a VM crashes, it will try to save what it is doing. This will be possible due to various critical functions running in separate VMs. For example: VM "A" crashes due to a process doing something funky. This kills VN "A" yet the filesystem "VM" safely sinks its filesystem. No I/O for the whole system is blocked, an error message is printed to the console/logging subsystem, and a VM restart is attempted (if enabled).
• One VM crashing doesn't crash everything In some less separated OSes, a bug in a driver can take down the entire system! Not in /my/ ideal OS! If the display driver hits an error, why should everything else die? The filesystem handling "vm"will stay running as will all other essential subsystem "VMs", and all systems will gracefully save their states in the event a driver reinitialisation is not possible. Aggressive error handling, correction, detection, cleanup, and garbage collection is enabled to allow recovery from even a graphics/storage subsystem error.

Networking stack

• Isolated The networking stack will run separate just like other subsystem "VMs". It will communicate with what it needs to via the message bus microkernel or a vm-to-vm message bus.
• Virtual NICs In the case of VMs in an "island" state, virtual NICs are enabled to allow the VM to run its own separate networking stack. The Virtual NICs merely act as if they were physical ports on a physical switch. They're just granted access to send/receive packets on the physical interface. Traffic isolation is provided via the primary hypervisor security subsystem

Corrections

• USB USB will be handled in a dedicated VM, devices are assigned to other "VMs" on a per-device level, not a port-based level. A USB device can only go to one device at a time unless it is a special device supporting dual-porting

Copyright: 2014. gewt.net. (VM (operating system name) and IUCV are trademarks of IBM). I claim copyright on the content, not the terms used in this article.