Get best of the week

Sivelkiriya Operating System: Introductory Description

Hello, Habr.

This article opens a series of publications about the Sivelkiriya operating system, which is currently at an early stage of design and development. The articles in the series will describe in detail the system problems of popular operating systems and suggest ways to solve them. The author does not set himself the goal of convincing anyone of anything and focuses solely on the description of the proposed solutions in order to benefit from the discussion. The publication will be carried out in parts, since the volume of the full description goes beyond any reasonable restrictions on the size of the article.

Everyone who is interested, welcome to cat.

Nowadays, you will not surprise anyone with statements about the development of the next operating system, which should become better, more convenient and more attractive than its predecessors and competitors. There are at least three major players in the OS market for personal computers and two in the OS market for mobile devices. Despite the apparent diversity, it is impossible not to note a certain similarity between them: although the technologies and methods for presenting services by the operating system vary, most of the concepts and concepts remain unchanged during the transition from one system to another.

So, almost all currently popular operating systems provide support for general functionality at the implementation level (windows, graphics, files, network, equipment), but not at the level of expression of the concepts of the subject area (chat messages, track lists, service bills). Existing exceptions (contact list, clipboard, notification bar) only emphasize the rule. Technical implementation (files, processes, threads) is also very similar in many respects.

The unit of use of computer capabilities in all cases is the application, which itself decides how to direct available resources to achieve their goals. Various applications are interconnected only insofar as their developers have taken care of such a connection; Often, programs that perform close functions cannot exchange data, have a different interface, use different terminology, and so on. This isolation of components has purely technical roots, but the user suffers as a result. A computer from an integral tool turns into a heap of heterogeneous solutions, and universal compatibility, deserving of becoming the fundamental principle of design, remains only an optional opportunity.

Currently, there are more and more solutions integrating various applications and services with each other. Manufacturers of software products seem to have realized that reducing many possibilities to one convenient system is the only way to harmony and order, which makes the life of the user better and easier. However, in many cases, the blind struggle of incompatible programs, each of which tries to embrace the immense, is replaced by an even more fierce struggle of integrators, who are doing everything possible to not let the user (and developer) out of their platform. Instead of uniting the world, integrators separate it to rule.

Another inevitable aspect of the world of individual applications for solving specific problems is that each of the applications will have its own advantages and disadvantages, often unrecoverable. The choice between usability, rich functionality and support for specific operations is as inevitable as regrettable. If a user needs capabilities that are not provided within the framework of one application to achieve his goals, this forces him to use more than one tool, spending time and effort switching and transferring data.

Software development is a time-consuming process, and therefore the quantity and quality of functionality within any product will inevitably be limited. At the same time, the lion's share of tasks and problems solved by developers have already been solved in other products; reuse of these solutions instead of re-developing them would free up resources that can be used to achieve other goals that are more necessary for the user.

Finally, program behavior is often not ethical. Instead of helping the user in their work, programs pester him with annoying comments and suggestions. Instead of developing a convenient way of providing services based on mutual respect, they mix the advertising content with the target. The result is a situation in which even the owner of the device does not control his behavior.

The Sivelkiriya operating system is intended as a solution to the above and some other problems. According to the plan and design, it should centrally, respectfully, on mutually beneficial conditions help to achieve the following categories of participants in the process of developing and using software:

  1. — , , , .
  2. — , , , , — , - .
  3. — , , .
  4. — , , , .
  5. — , , , .

Below we will describe the architecture of such an operating system and how it helps to rectify the situation. Further articles in the series will examine in detail the problems that it solves in order to show that they require a systematic approach. Finally, the advantages and disadvantages of the proposed solution and how it can turn from a concept into a finished product will be shown.

The concept of OS Sivelkiriya


The Sivelkiriya operating system begins with a revision of the basics, in which part of the generally accepted concepts are eliminated or replaced. The following entities, which usually form the basis of the operating system, do not exist within the Sivelkiriya OS:

  1. Application.
  2. Process.
  3. File as a data area on disk.
  4. End-to-end file system, navigation on which is limited only by access rights.
  5. Command line as an environment for running individual applications.
  6. Universal scripts.
  7. Availability of the base operating system API to any component.
  8. The ability to directly transfer standard libraries of most modern programming languages. As a result, the ability to directly transfer existing software from other operating systems, except in certain cases.
  9. Support for programming languages ​​without object orientation.

This list is not complete. It does not in any way mean limiting the capabilities of a programmer or user and only indicates that within the framework of the Sivelkiriya OS, the same goals are achieved differently than in most existing operating systems.

Having abandoned these established entities, we intend to build an operating system based on the following principles:

  1. «» - , , , . , , , , . . , , .
  2. . , , , , .
  3. , . , ( ). ( ) . , ( ) .
  4. , , , , . , .
  5. Each module is available only the data and methods of interaction with the operating system that are necessary to perform its function (defined by the prototype). No module has access to all the functions of the operating system. Duplication of functions already assigned to a particular prototype within the module relating to another prototype is not allowed.
  6. The development of data interfaces and prototype modules is carried out continuously, by joint efforts of program developers and developers of the operating system. Interfaces and prototypes are modified and supplemented as needed.


The following articles in the series will show in detail how these and other principles will be applied in practice.

The second article of the cycle is available here . The full text is available on the project website .

Source: https://habr.com/ru/post/undefined/

More articles:


All Articles