1.5. Comparing vortexOS to Other OSes

We share quite a lot with other operating systems.

System Calls

The vortexOS API is Unix-like. For instance, we have system calls like open, pipe, pipe2, lseek, read, write, brk, execv, and so on. Currently, we support the most common POSIX and Linux system calls.

However, vortexOS does not necessarily implement them as direct system calls. Much of the functionality for these operations (typically the man(2) functions) is provided in user space through an interface library, relibc.

"Everything is a File"

In a model largely inspired by Plan 9, in vortexOS, resources can be socket-like or file-like, providing a more unified system API. Resources are named using paths, similar to what you would find in Linux or another Unix system. However, when referring to a resource managed by a particular resource manager, you can address it using a scheme-rooted path. We will explain this later in Schemes and Resources.

The Kernel

vortexOS's kernel is a microkernel, with an architecture largely inspired by MINIX and seL4.

In contrast to Linux or BSD, vortexOS has around 50,000 lines of kernel code, a number that is often decreasing. Most system services are provided in user space, either through an interface library or as daemons.

Having a vastly smaller amount of code in the kernel makes it easier to efficiently identify and fix bugs and security issues. Andrew Tanenbaum (author of MINIX) stated that for every 1,000 lines of properly written C code, there is a bug. This implies that in a monolithic kernel with nearly 25,000,000 lines of C code, there could be nearly 25,000 bugs. A microkernel with only 50,000 lines of C code would likely contain around 50 bugs.

It's important to note that the extra code is not discarded; it is simply based outside of kernel space, making it less hazardous.

The primary idea is to ensure that system components and drivers, which would typically reside within a monolithic kernel, exist in user space and adhere to the Principle of Least Authority (POLA). This means that each component is:

• Completely isolated in memory as separate user processes (daemons).

• The failure of one component does not crash other components.

• Foreign and untrusted code does not compromise the entire system.

• Bugs and malware cannot spread to other components.

• Communication with other components is restricted.

• Lacks Admin/Super-User privileges.

• Bugs are confined to user space, reducing their potential impact.

All of these factors significantly enhance the system's reliability, which is crucial for users seeking minimal issues with their computers or for mission-critical applications.