The above describes Sivelkiria’s advantages. It would only be fair to discuss the disadvantages as well.
1. The development of software for Sivelkiria will be more difficult than in the case of any classical OS because of the need to coordinate that development with the structure of object interfaces and prototypes of modules adopted in the system.
2. Data transfer between modules creates a bottleneck because it requires context switching at the very least. For many time-critical applications, some optimization will be required.
3. The process-free structure does not fit well with the optimization of existing hardware (processors).
4. Most of the existing software cannot be ported to Sivelkiria, which means that the work has to be done from scratch. The reason for this is the need to split it into modules, which often requires a huge amount of effort.
5. Interaction with the OS support team slows down software development in cases where the API does not exist or is not yet stable.
6. Splitting programs into interfaces, objects and modules is ambiguous in many cases, and a single wrong design-related decision may lead to further problems.
7. The need to alter the standard libraries of programming languages significantly slows down the process of creating software. This is because the operating system’s API, which is usually actively used by standard libraries, is context-dependent in Sivelkiria.
8. Using individually developed modules can affect a system’s stability.
It is easy to see that at least some of these problems may turn into serious obstacles to building the solution or even jeopardize it. The full picture will become clearer at the design, prototyping and development stages.