Sivelkiria’s main idea is to take a new look at the basics, which results in removing or replacing some common concepts. Sivelkiria OS is free from the following entities that usually establish the grounds for an operating system:
- An application.
- A process.
- A file as a sequence of bytes on a disk.
- An end-to-end file system with access to its contents limited only by security permissions.
- A command line as a tool for initiating applications.
- Universal scripts.
- Basic operating system API available to any component.
- The capability of porting standard libraries of modern programming languages. As a consequence, it does not allow direct porting of existing software from other operating systems, except for some rare cases.
- Support for non-object-oriented programming languages.
This list is not exhaustive. It is not intended to limit developers’ or users’ abilities in any way. It is only meant to stress that Sivelkiria uses other tools to achieve the same goals as the majority of existing operating systems.
It is proposed to build the new operating system on the following principles:
- The Sivelkiria operating system is object-oriented in the sense that it offers object interfaces to express all concepts of application domain that the software for this OS works with. All entities an application or system software works with must be represented as objects implementing one or more interfaces defined by the operating system. No data exchange is allowed beyond this structure. Any data received from outside sources is wrapped into these interfaces at the entry point.
- Every distribution unit of program code is represented as a module. There is little or no difference between modules offering application and system services.
- The operating system contains a library of module prototypes which are distinguished by their functionality. Every prototype defines the function the module offers and the input and output data it operates with. Any module implements one, and only one, prototype. Prototypes are organized in such a way that each of them has a single function regardless of input data origin or output data destination.
- It is the operating system that defines the order in which modules are composed, loaded/unloaded and the order in which functions from them are called. The OS also organizes, prioritizes and synchronizes threads and determines objects’ lifetime as well as ways to process them. Implementations of modules and objects only have guarantees that are given in the definitions of interfaces and prototypes. No other assumptions may be made.
- The module only has access to data and APIs that are required to complete its function, which is defined by the prototype. No module has access to all functions of the OS. Functions that are not defined by the module’s prototype are prohibited.
- Data interfaces and module prototypes are developed continuously with the joint efforts of software developers and the operating system’s developers. Interfaces and prototypes can be altered and extended if required.
The next chapters will demonstrate in detail how these and other principles could be implemented.