SIRTX Design principles

SIRTX is designed as a new operating system based on a number of design principles. This page discusses them. As all of them are equally valid there is no specific order to them.

Principles

SIRTX is a research project

While SIRTX is meant to be used in production, it is mostly a research project at this point. As such, topics like performance or matching what other projects do or expect is a less important aspect. It is also expected that SIRTX will adjust heading with future versions to better reach its goals.

SIRTX is databased oriented

Many aspects of the operating system are centred on the database as the core of the system. Software is not just expected to interact with the database, but to fully integrate with it. This is made easy by the powerful handle based system API.

Semantic nature

In SIRTX the question is not about how but about what to do. The goal is to allow the user to communicate what is needed with the system, without any user actually considering how it is to be done. This also allows for type agnostic operations, operations to be split into uncoupled units, and both clean user flows and clean code.

Functions, no programs

SIRTX considers software to be organised into independent functions that can be combined by both the user and other functions to solve complex problems with simple and easy to understand blocks. This principal directly results in there being no programs on SIRTX, just functions provided by different components.

One system out of many parts

On SIRTX the user nor any software needs to consider which part a function they are using belongs to. The system represents itself as a whole, not as parts. This results in artificial boundaries as found by other systems being avoided: There is no difference when using a function (or any API) between kernel and userland, main program and libraries, different programs or products.

Global look and feel

All software uses the same way to interact with the user. For example the same keyboard shortcut works in all functions equally.

Handle based system API

Access to the system happens via handles. A handle can represent any type of subject or object, both virtual and physical. This also allows for any API to be fully type save, simplifying a many security checks. This also means that any call between to functions is type safe, independent on the implementation of both functions.

High level abstraction of hardware and user input/output

Hardware should be abstracted as much as possible, with drivers providing semantic interfaces to it. This allows for users and developers not focus overly on their operating environment. It also means that a user can use a terminal setup they prefer and any software will work with it.

Many physical address spaces

SIRTX makes no assumption on the organisation of address spaces. Both Harvard and von Neumann architectures are supported. Support for additional address spaces such I/O, or system EEPROM is transparently included. There is no assumption on the size of address spaces (for example 16 or 64 bit). Specifically access via handles is independent on any hardware details.

No assumption on the user's terminal

No assumption on the user's terminal is made. Different terminals may have options such as text input and output, graphics, sound, and pointing device. There should generally be no assumption on those. The terminal API is designed to avoid the need for them.

Consequences and conclusions

• SIRTX is not compatible with POSIX or Windows. While some ideas of modern POSIX or Windows are present in SIRTX, POSIX or Windows compatibility would undermine SIRTX's design principels.
• POSIX or Windows software is hard to port to SIRTX. It would require a substantial compatibility layer and would not interact with the rest of the system as expected by the user. Running POSIX software in the SIRTX VM might be possible to some extent.
• Every implementation can be exchanged for any other implementation of the same interface/contract.
• As all resources are accessed via a handle that implements access to that resource, it is not only possible to access remote resources but also transparent to the user.