The process of software development on Sivelkiria differs from that of other operating systems (Windows, Linux, Android, etc.) because developers deal with reusable components without knowing the specific usage scenario that will be applied later. In other words, it looks like development of shared libraries rather than applications.
No module can perform functions it’s not supposed to perform. No module can require or assume that it will be interacting with the module it was developed for or tested with. Thus, the module does not depend on the version of any other module, which helps it to avoid the dependency hell problem. Let us emphasize that Sivelkiria rejects the application paradigm, including considering an application to be a program consisting of a predefined set of modules.
In this case, the module can determine which interfaces it uses to interact with other modules. In addition, it can require and recommend that the module it works with passes the specific tests available at the main repository. The module is not required to use the latest version of an interface, since the operating system resolves the version compatibility issues by itself.
When it comes to available languages and environments, Sivelkiria provides the same options as other operating systems. The module can contain native code, byte code or script code. Different code types are handled by different executors which are modules themselves. Their task is to ensure that the module code is executed and that calls and data pass through its borders, as well as to perform necessary maintenance (e.g. garbage collection). This approach makes it possible to support many compiled and scripting languages and many environments. At the same time, the restrictions set by the operating system apply to the module regardless of the language and environment, since any executor interacts with the operating system using the same API whose permissions are controlled in a universal way.
In Sivelkiria, the concept of a dynamically linked library is replaced with the concept of a module. One or more modules distributed together can share some code if necessary. However, no code belonging to any other package would be able to access it. The problem of finding a shared library is also solved by the fact that the library included in the delivery package is always used. All other interactions with shared code are done through the module subsystem.