The only way (…) is to encourage a software culture that knows that small is beautiful, that actively resists bloat and complexity: an engineering tradition that puts a high value on simple solutions, that looks for ways to break program systems up into small cooperating pieces

Eric S. Raymond, The Art of UNIX Programming

X15 is a project for a Hurd-like operating system. As such, it is intended to be a general-purpose multi-server operating system, running on top of a capability-based microkernel, where the VFS (Virtual File System) acts as a decentralized service directory. The goal of the project is to provide a performant, scalable, robust, real-time, POSIX-conforming, open-source multi-server operating system. It is not intended to be compatible with GNU/Hurd. The microkernel is also meant to host hard real-time embedded applications.

Source code : https://git.sceen.net/rbraun/x15.git/

Documentation: https://www.sceen.net/~rbraun/x15/doc/intro.9.html

IRC : #x15 @ Freenode

A question that is often asked is “what are the benefits of a Hurd-like system ?”. Here are those I consider most important :

  • Extensibility: system services can easily be added, removed, or replaced, usually at runtime without restarting and, whenever possible, without requiring root privileges. For example, think FUSE but not only for file systems.
  • Security: each instance of a system service runs in its own address space, with its own privileges, and the total amount of critical code is low and can be audited. For example, an attacker exploiting a bug in the networking stack is still severely restricted.
  • Robustness: if a non-essential system service fails, the system as a whole isn’t compromised. Services can even be restarted, sometimes transparently. For example, if a network interface controller driver crashes, the networking stack gets an error and reopens the underlying network device, transparently restarting the driver, without dropping any socket.

Developers should also appreciate :

  • Debugging: since most system services run as regular userspace processes, debugging tools can be used on them the same way as for any other common application. For example, you can use the GNU debugger when developing device drivers.
  • Languages: since most system services run as regular userspace processes, they can use libraries and runtimes the same way as any other common application can. For example, provided the appropriate bindings are available, device drivers can be written in Python or Java.
  • Virtualization: by forcing programs to request system services through capabilities, namespace isolation and location independence are naturally provided and simplify the construction of features such as containers and virtual machines.
  • Customization: the system is built around a microkernel and a few essential servers, but other servers can import code from other projects. Users can choose what implementation they want to run and what interface to expose. For example, developers working on an embedded system could run a Linux-based networking stack, providing Netfilter, or a NetBSD networking stack with pf. They can even be run concurrently, either completely separately, or combined with VPN features.

On top of these properties, X15 focuses primarily on :

  • Performance and scalability
  • Direct POSIX compliance (without an additional layer of emulation)
  • Real time

Although the design of the Hurd is promising and attractive, its implementation has a number of severe issues. X15 takes the approach of the complete rewrite to make sure that key ideas are kept in mind at all times during development. Since it’s not meant to be compatible with the Hurd, critical interfaces such as IPC and signals can be reimplemented completely differently. There is a lot of emphasis on code quality and ease of maintenance, obtained from disciplined application of best practices.

Currently, the project is still incomplete. There is no userspace, only a small kernel. But here are a few interesting things that have already been done :

  • Multiprocessor scheduling using the GR3 and DWRR algorithms
  • Lockless synchronization (like RCU) using passive serialization
  • Per-processor page tables
  • Scalable reference counting based on Refcache as described in the RadixVM paper

The internal kernel interfaces are very clean and simple. Basic services like spin locks, mutexes (with or without priority inheritance), condition variables, memory allocation, work queues and data structures such as lists and balanced trees are already available.