Introduction to the Sivelkiria Operating System

Nowadays, it is common to announce the development of a new operating system that should be better, more intuitive and more attractive than its predecessors and competitors. There are at least three major players in the desktop OS market and two in the mobile OS market. Despite the apparent diversity, one cannot help noticing that they all have much in common: although technologies used and services provided differ, most concepts and ideas are the same in all these operating systems.

For example, almost all popular operating systems provide common functionality at implementation level (windows, graphics, files, network, devices), but not at the application level (chat messages, track lists, invoices). Exceptions, such as contact lists, exchange buffers, notification bars, only prove the rule. Technical implementations (files, processes, threads) are often similar, too.

In all cases, application usage is the only way to utilize all computer capabilities. The application defines how to utilize the device’s resources to achieve its goals. Compatibility between applications depends on whether the developers took steps to provide such compatibility, and to how much of an extent. Programs that actually provide similar functions often have different interfaces, use different terminology and are unable to exchange data. Such component isolation is available for purely technical reasons, but it impacts the user’s workflow. The computer becomes a collection of mixed solutions instead of a comprehensive whole. General compatibility still remains an option instead of becoming a basic design pattern.

However, there are more and more solutions integrating different applications and services. It seems that software manufacturers have finally realized that combining different capabilities into a single convenient system is the only way to make users’ lives easier and better. Nevertheless, this often only leads to a conflict between incompatible programs, each of them attempting to seize control, creates even more trouble for integrators who do everything to prevent the user (and developer) from leaving their platforms.  Instead of uniting the world, the integrators divide and rule.

Another unavoidable aspect of the world of isolated applications designed for specific tasks is that every application has its own advantages and disadvantages which are often irreparable. The choice between a user-friendly interface, rich functionality and support for specific operations is as unavoidable as it is regrettable. If there is a need for capabilities which are not provided by a single application, the user is forced to use more than one application and to waste time and effort on switching between applications and exchanging data.

Software development is a resource-heavy process, which ultimately limits the quantity and quality of the features implemented. At the same time, the lion’s share of the tasks and problems the developers usually work on is already solved in a different product. Reusing these solutions instead of re-implementing them would free up resources that could be reassigned to satisfy actual users’ demands.

Finally, software’s behavior is often unethical. Instead of helping the user, computer programs interfere with unwanted comments and suggestions. Instead of providing a convenient and non-invasive service, they mix meaningful content with advertising. This ends up in a situation where even the device’s owner cannot control its behavior.

The Sivelkiria operating system is meant to be the solution to these and some other problems. It is envisioned and designed as a centralized, non-invasive and mutually beneficial solution to the problems faced by software users and developers. It should improve things for the following parties:

  1. End users – by providing fully-fledged, convenient, compatible, portable and reliable solutions.
  2. Software buyers – by guaranteeing that all solutions bought will be compatible and that using any given solution, on one hand, won’t limit their abilities to use other solutions, and, on the other hand, won’t force them to replace the whole technology stack due to the inherent problems of a single legacy system.
  3. Software developers – by allowing them to concentrate on primary tasks and utilize existing code.
  4. Software publishers – by opening the market to the software which fits all possible use cases and thus suits as many customers as possible.
  5. Content providers – by allowing them to work on their content which automatically becomes available to as many people as possible in the widest context possible, without having to repeat existing technical solutions.

In the following chapters, the architecture of such an OS will be outlined and the way it fixes the situation will be described. The problems it solves will be described in detail to make it clear that they require a systematic approach. Finally, the pros and cons of the proposed solution will be discussed, alongside how it can be transformed from concept to product.