Sivelkiria is designed to run in the following modes:
- As a primary operating system on x86 and ARM platforms;
- As a set of graphical applications running under a host operating system;
- As a set of libraries and / or processes controlled by a third-party application running under a host operating system.
Below is the explanation of why these features are necessary.
Running Sivelkiria as a primary operating system gives it direct control over available devices. On the one hand, this allows it to manage system resources such as processor time and operating memory in an optimal way. On the other hand, it presents the user with a tough choice between fully switching to a new operating system, which may lack some software at the beginning, and not using it at all. It is highly likely that many newly developed operating systems fail at this stage. The absence of software scares off users, and the absence of users scares off developers.
To resolve this, we propose to run Sivelkiria as a set of applications built for a host operating system (e.g. Windows, Linux or Android). From the point of view of the modules it runs, there is no difference as they still interact with other modules and the system kernel uses the same API. From the user’s point of view, the difference is that it is now possible to keep working under an existing host operating system, using Sivelkiria only for the tasks that it already supports.
Finally, the third option is designed to expose Sivelkiria’s object API to some external context. As a result, third-party software will be able to use Sivelkiria’s modules in the same way as it uses other shared libraries, and although the implementation could require module interaction and isolation using different libraries and/or processes, these details will be hidden from the calling context. From Sivelkiria’s point of view, the difference between these last two options is whether the user interacts with its GUI or the third-party software interacts with its API.
The proposed solution could make the period of filling the operating system with software as efficient as possible, because full migration can be delayed or even avoided by the end user without losing the ability to use Sivelkiria wherever it is convenient. This way, Sivelkiria’s main goals – compatibility and availability – would be achieved at minimal cost.
There is an open question as to whether Sivelkiria should be called an operating system if it is being executed under a host OS. We shall leave this discussion to the theorists.