I like Linux, but

I like Linux, but there are a few things about its model — and the Unix model in general — that I have disliked for a long time, especially:

  • the idea of “everything is a file”. Historically, it probably made sense, but today we often need different representations of all kinds of system resources, for example as serialized objects, etc.

  • it seems quite messy to me to put files on disk, devices, processes, sockets, system information, and so on into one single tree structure.

  • on top of that, allowing mount points anywhere in this structure, which after being unmounted can make the same path point to a different device, feels almost dangerous to me. For example, after a reboot, some storage might fail to mount and services may start writing to the system disk instead. Sure, this can be prevented somehow, but those are already workarounds.

… and a few other things.

So I asked myself: If I were designing an OS from scratch, how would I do it differently?

And so I designed and developed my own kernel and userspace, and the result is my experimental open-source system — LiberSystem :slight_smile:

A microkernel OS written in Rust, based on typed objects, capability-based security, isolated services/drivers, and explicit volumes instead of classic mount points.

I do not see it as a replacement for Linux, more as an experiment.

I would be interested to hear what you think: does this direction make sense to you, or is the Unix model still the best approach in your opinion?

More info about my project: libersystem dot com
Source code on GitHub: libersoft-org/libersystem

2 Likes

Interesting…I will check it out…

The default is to fail the boot if a device cannot be mounted.

You need to specifically allow continuing the boot if a mount fails for that to happen.

The unix developers tried something different, it had limited impact

1 Like

Is Unix the “best” approach? The answer is No.

Best? Who knows. Better than windows? Yes.

Ideal? Come up with something better that actually works.

2 Likes

Welcome to the forum. I love a big dream, may you have all the perspiration you need to make-real your inspiration!

Don’t forget pipes, network sockets, io_uring ring-buffers queuing up commands and waiting for completions, eBPF virtual machine ecosystem for filtering and tracing, sched_ext pluggable userspace scheduler written in eBPF, XDP and rDMA high-bandwidth hardware assistance, and the devicetree and netlink configuration interfaces.

Linux’s two strengths are the development community and the filesystem caching that grew out of the dentry / lru and bufferheads caches. The caches came from engineering around system constraints: Linus needed to manage patches to the code tree and compile binaries (and chew gum, but I doubt he ever ran out of gum).

Today’s constraints are that we’ve got many CPU cores and L2/L3 cache but memory access needs the scheduler to balance batching work with access latency while avoiding stalling the CPU pipelines. We also have enormously greedy LLM workloads that want parallelism and shared memory for the model – but adding more parallel workers needs low-latency links to get to that ‘next symbol’ in the calculation.

OCI-compatible containers might also make a useful target. Look at WSL and Apple Containers where other OS’s have worked to run OCI-compatible containers on another kernel. So maybe you also need to support enough of the OCI spec to host Linux’s containerised workloads.

For microkernels with network-first aggregation of services, look at Plan 9 From Bell Labs and 9front distribution, which also swaps mount points for ‘Storage Servers’. (Plan 9’s focused around a second abstraction beyond ‘everything is a file you can pipe from and to’ in that ‘every app is a server’ and RPC invocation is the first-class abstraction. Compute Servers are the other first-class abstraction in that anything on your network can receive computation tasks and execute programs for you.)

For capability-based security, look at Cap’n’Proto (a lean wire-serialisation library with capability to delegate permissions and chain permitted activity in workflows) and Spritely Goblins (a distributed capability-based runtime in Guile/Racket that grew out of E).

Think also about reproducible builds and recreating a system installation like Nix does, with a content-addressed store of registered binaries. Version-control like git helps manage the manifests of installed software as well as the configuration database.

Good luck on your journey to working code!

2 Likes

Another nice one to look at, HelenOS.

https://www.helenos.org/

Good idea!