Introduction

This Web site is dedicated to providing information about an abstract operating system called Kueea system, as well as its proof-of-concept implementation Kueea OS. The system is developed as part of Project Kueea.

Kueea system is entirely composed of modules. They are abstract entities referenced by their globally unique identifier and revision number. (Higher revisions are backward compatible with lower revisions.) Modules are defined as a set of functions and objects. In order to use any of these objects and functions, an implementation of the module is needed.

Some modules define interfaces for other modules. These definitions are called protocols, because they define how one module communicate with another. They consist of objects and function declarations (prototypes). An example of a protocol is a hash function protocol, which consists of three functions: initialize, update, and finalize. The protocol defines their parameters and return values. A module wishing to adhere to this protocol would define these functions. This enables a module implementation to refer to functions at run-time.

There is no straightforward separation between kernel and user spaces. One does not use such terms when talking about Kueea system. All functionality is provided by modules. If you need to define a ‘kernel,’ it would simply be those modules which were loaded with high privileges.

The entry point module consists of a module manager, protocols for required system objects and an RPC interface. Inter-module communication is done via the RPC interface, because it abstracts the implementation of modules and their functions. They may be implemented as byte code within ELF shared objects, they may be Python scripts – the entry point does not care, because all modules are accessed through their interpreter module. An interpreter might as well serialize a function call request and send it to another machine.

Kueea system is event-based; modules simply provide functions which are to be called whenever a given event occurs. These events may come from a device, a task or a user. A user wishing to start an application is one such event. Kueea system exists to handle these events, to answer these requests. The system is to do whatever in its might in order to fulfill them, which includes fetching module implementations from remote devices.

The system does not aim to be compilant with POSIX. POSIX is a standard for stand-alone systems. This is reflected in that resources are tied to a system root directory. Kueea system is a decentralized network of devices. Therefore, there is no such thing as a root directory in the system. All resources, including devices, are nodes of a global graph. They are referenced directly or relative to another, known node. The system is defined in terms of high-level interfaces, which abstract all devices implementations execute on.

Within Kueea system, there are entities called Kueea system networks. They are sets of devices that adhere to network-defined rules. A device is either part of a Kueea system network or it is not. The idea behind Kueea system is that since the system is abstract and requires devices to physically exist, one buys access to the system by paying with one’s devices. One is asked to relieve some of their authority over a single device in order to gain access to the bigger system powered by many. For example, a network may decide that all of its nodes are to allow for storing data of one another. In this case, your storage devices would not be yours alone, but at the same time, you could also access devices provided by others.