# SkiftOS: A Capability-Based Microkernel and Desktop Environment in C++

> SkiftOS is an LGPL-3.0 open source operating system built around the Hjert microkernel, the Hideo desktop environment and the Karm C++ library. It is aimed at developers exploring niche operating systems, and its own README warns it is not ready for daily use.

**skift-org/skift** — 🥑 A modern delightful operating system (mirror)

- Repository: https://github.com/skift-org/skift
- Website: https://codeberg.org/skift/os
- Stars: 2,984 · Forks: 149
- Language: C++
- License: LGPL-3.0
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/skift-org-skift

## What SkiftOS Is Trying to Fix

The README frames the project around a complaint: contemporary operating systems offer fragmented user experiences, and SkiftOS wants deep integration and a cohesive aesthetic instead. That is the stated motivation, and it shapes the component list. Rather than assembling a distribution from existing kernels and desktop stacks, the project writes its own microkernel, its own UI framework, its own desktop environment and its own browser engine, so the pieces can be designed against each other.

The audience is narrow by design. The README says SkiftOS is intended for developers and people interested in exploring niche, open source operating systems, and it describes the work as an artistic pursuit rather than a commercial product. The warning at the top is blunt: skiftOS is in the early stages of development, is not ready for daily use, and should not be used in production environments. Anyone evaluating it as a desktop replacement is reading the wrong document.

## Hjert, Karm, Hideo and Vaev: How the Pieces Fit

The architecture visible in the README is a stack of named components, each with its own directory. Hjert is the kernel, described as a capability-based "pragmatic" microkernel, and it lives in src/kernel. Karm is the C++ core library in src/libs, providing what the README calls foundational building blocks. KarmUI, in src/libs/karm-ui/, is a reactive UI framework for building interfaces. Hideo, in src/apps, is the desktop environment built on top of that framework. Vaev, in src/web, is a browser engine.

The capability-based microkernel choice is the most consequential one. A microkernel keeps services outside the kernel and communicates through message passing, and a capability model means access to a resource is held as an unforgeable token rather than checked against a global permission table. The README does not describe the message-passing protocol, the scheduling policy or how capabilities are transferred between processes, so those details have to come from the source tree and the documentation site rather than the front page.

CuteKit sits outside the component list as the build system and package manager, hosted at codeberg.org/cute-engineering/cutekit. The README describes it as designed for cross-compilation and complex project management. That is a real dependency: the repository contains project.json and project.lock at the top level, which is where CuteKit configuration lives, and building SkiftOS means building with CuteKit rather than with a generic Makefile or CMake setup.

## Building SkiftOS from Source

The README does not inline the build steps. It points to doc/building at docs.skiftos.org and says only that building from source is easy. That page is the authoritative source for the toolchain, the required packages and the exact commands, and the README does not repeat them, so treat anything below as orientation rather than a substitute.

The repository layout tells you what the build entry point looks like. There is a shell script named skift.sh at the top level, alongside project.json, project.lock and meta/. Those are the files a CuteKit-based project uses to describe itself and pin its dependency graph. The README does not document the arguments skift.sh accepts, so read the script and doc/building before assuming a subcommand exists.

```bash
./skift.sh
```

Running that script is the entry point the repository exposes, and what it does depends on the CuteKit installation on your machine. Because CuteKit is hosted in a separate repository and the README does not pin a version of it, the practical first step is installing CuteKit from codeberg.org/cute-engineering/cutekit and confirming that skift.sh resolves it.

The documentation site is where the cross-compilation toolchain requirements are listed. Nothing in the README describes how to run the resulting system in a virtual machine or on real hardware, so that question belongs to doc/building as well.

## Where SkiftOS Is the Wrong Tool

The README's own warning is the first limitation, and it is not boilerplate. SkiftOS is in the early stages of development, is not ready for daily use and should not be used in production. That rules out servers, workstations, CI runners and anything with an uptime expectation.

The second limitation is narrower and more interesting: the project is a mirror. The homepage field points to codeberg.org/skift/os, and the README's own links for CuteKit go to codeberg.org. If you intend to file issues or send patches, the mirror may not be where that happens, and the README directs contributors to doc/contributing rather than to a GitHub workflow.

The third is dependency shape. A capability-based microkernel with its own UI framework, desktop environment and browser engine is a large surface for one project, and the README lists no releases. There is no tagged version to pin against, so anyone building it is tracking the main branch. That is normal for an operating system at this stage, but it means a build that works today is not reproducible tomorrow unless project.lock is committed and respected.

Finally, the README does not document rollback, an upgrade path, or a supported hardware list. If you need any of those, the project is silent, and silence here is a real answer.

## SkiftOS and SerenityOS: Two Different Bets

SerenityOS is the obvious comparison for anyone reading this far, and the difference is in the architecture rather than the ambition. SerenityOS is a monolithic Unix-like kernel with a POSIX-shaped userspace, and its desktop, browser and libraries are built to feel like a coherent Unix system. SkiftOS takes the microkernel route: Hjert is described as a capability-based microkernel, which moves services out of kernel space and makes resource access a matter of holding a token.

That choice changes what an application developer does. On a Unix-like system, a program opens a file by path and the kernel checks permissions. Under a capability model, the program needs to have been handed the capability for that resource in the first place, which makes the security boundary explicit but also makes the plumbing more visible in application code. The README does not show what that looks like in practice, so the honest position is that the model is stated but not demonstrated on the front page.

The second difference is the UI stack. SkiftOS ships KarmUI, a reactive UI framework, and builds Hideo on it, so the desktop and the framework evolve together. SerenityOS has its own widget toolkit too, but the reactive framing is a distinct bet about how interface state should be expressed. Neither approach is settled, and the README gives no benchmarks that would settle it.

## Licence and Long-Term Maintenance Cost

The licence is LGPL-3.0 or later, covering the operating system and its core components according to the README, with the full text in license.txt. LGPL rather than GPL matters for anyone who wants to link against Karm or KarmUI from a differently licensed program: the LGPL permits that under conditions the licence text spells out, and the README does not add any project-specific exception or clarification. Whether those conditions fit a given product is a question for a lawyer, not for this article.

The maintenance picture is straightforward. The repository is not archived, and the last push was on 2026-07-08. There are no retrieved releases, so there is no version to track and no changelog to read between builds. The practical cost of following SkiftOS is therefore the cost of tracking a moving main branch plus the cost of keeping CuteKit working, since the build system is an external project with its own release cadence.

For a hobbyist or a student, that cost is the point. For a team, it is a recurring expense with no upgrade path documented in the README, and the README does not describe how breaking changes are announced.

## What to Check Before You Commit Time

Start with doc/building rather than the README, because the README deliberately delegates the toolchain and the commands. Confirm which C++ standard and compiler the build expects, and whether cross-compilation is required for your target. Then install CuteKit from codeberg.org/cute-engineering/cutekit and run skift.sh against a clean checkout.

Next, decide which component you actually care about. If you want the kernel, src/kernel is the directory. If you want the UI framework, src/libs/karm-ui/. If you want the browser engine, src/web. The README lists these as separate features, and they can be read independently even though they are designed to work together.

Finally, check where the project actually lives. The homepage is codeberg.org/skift/os, and the README's contribution link goes to doc/contributing. If your workflow depends on GitHub pull requests, verify that the mirror accepts them before planning around it.

## Conclusion

SkiftOS is for developers who want to read or contribute to a from-scratch C++ operating system with a capability-based microkernel, a reactive UI framework and its own browser engine. It is not for anyone who needs a daily driver, a production host or a supported platform, because the README states it is in the early stages of development and should not be used in production. Before adopting it, read doc/building for the toolchain steps, confirm which components are covered by LGPL-3.0, and check whether CuteKit is installed, since the repository does not pin a version of it.

## FAQ

### What is SkiftOS?

SkiftOS is an open source operating system built from the ground up with a focus on modularity, simplicity and modern design principles. Its components include the Hjert capability-based microkernel, the Karm C++ core library, the KarmUI reactive UI framework, the Hideo desktop environment and the Vaev browser engine.

### Is SkiftOS ready for daily use?

No. The README states that skiftOS is in the early stages of development, is not yet ready for daily use, and should not be used in production environments.

### How do I build SkiftOS from source?

The README says building from source is easy and points to doc/building at docs.skiftos.org for the steps. The repository provides skift.sh at the top level alongside project.json and project.lock, which are CuteKit files, and CuteKit is hosted separately at codeberg.org/cute-engineering/cutekit.

### What licence does SkiftOS use?

The skift operating system and its core components are licensed under the GNU Lesser General Public License v3.0 or later, with the full text in license.txt.

### Who is SkiftOS for?

The README states it is intended for developers and those interested in the exploration of niche, open source operating systems, and describes the project as an artistic pursuit rather than a commercial product.

## Sources

- [Issues](https://github.com/skift-org/skift/issues)
- [License: LGPL-3.0](https://github.com/skift-org/skift/blob/main/LICENSE)
- [Project website](https://codeberg.org/skift/os)
- [README](https://github.com/skift-org/skift/blob/main/README.md)
- [skift-org/skift on GitHub](https://github.com/skift-org/skift)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/skift-org-skift