# oasis: a statically linked Linux where the build system writes your filesystem into git > A small musl based system built with samurai and Lua manifests, where there is no package manager, a 16 line init script, and the components are chosen to be smaller rather than more capable. **oasislinux/oasis** — a small statically-linked linux system - Repository: https://github.com/oasislinux/oasis - Stars: 3,115 · Forks: 98 - Language: Roff - License: NOASSERTION - Published: 2026-10-07 · Updated: 2026-10-07 · Language: en - Canonical page: https://hysenlabs.com/projects/oasislinux-oasis ## Static linking as the organising decision oasis describes itself as a small Linux system and immediately qualifies that: it is quite a bit different from other Linux based systems you might be familiar with, and is closer to a BSD. The first of the distinguishing features is that everything is completely statically linked, including the display server, which is velox, and the web browser, which is NetSurf. The reasoning is given rather than assumed. Static linking is a simpler mechanism which eliminates problems with upgrading libraries, and produces completely self-contained binaries that can be copied to other systems. For an operating system whose stated principle list includes the line that executables should be linked statically, this is not a packaging preference but the organising constraint that everything else follows from. That constraint explains most of what is unusual here. A display server small enough to link statically cannot be Xorg, so it is velox. A browser small enough to link statically is NetSurf. An init system that works without systemd is perp and sinit. Each substitution is named explicitly in the README's software list, alongside musl for glibc, sbase for coreutils, ubase for util-linux, pigz for gzip, mandoc for man-db, oksh for bash, sdhcp for the DHCP clients, vis for vim and emacs, byacc for bison, samurai for ninja, and netbsd-curses for ncurses. Read that list as a philosophy rather than a shopping list. Every entry is a case where a smaller implementation was chosen deliberately, and the README frames it that way: oasis uses smaller and simpler implementations of libraries and tools whenever possible. The measurable payoff is that the binary is one file with no shared library resolution at all. You can copy it to another machine and run it, which is a property that matters more for an appliance or a recovery environment than for a desktop. ## No package manager, and a filesystem you get from a git merge The feature most likely to surprise a Linux user is the absence of a package manager. Instead of installing packages, you configure a set of specifications of what files from which packages to include on your system, and the build system writes the resulting filesystem tree into a git repository. That tree can then be merged into `/`, or pulled from another machine. This is a real design decision rather than a missing feature, and it has real consequences. Your filesystem state is a git tree, so it is diffable, revertable and reviewable, and deploying to a machine is a pull. The cost is that there is no runtime dependency resolution and no way to add a program without going through the build, which is why the README spends a paragraph on what to do when the software you want is missing. That paragraph is the answer: oasis works well with OS agnostic package systems, specifically pkgsrc and Nix. Rather than maintaining yet another repository with thousands of packages, the base system stays small and focused and you extend it with pkgsrc or Nix. The wiki carries the pkgsrc integration notes, and the README's advice to authors who cannot find their favourite tool is to install it via pkgsrc or nix. The configuration file is `config.def.lua`, a Lua file at the repository root, and the README links directly to the specification block in it. Reading that block is the fastest way to understand what the system actually contains, because it is the list of things you have decided to include. ## samurai, Lua manifests, and a bootstrap you can run from anywhere Builds are handled by samurai rather than ninja, with build manifests generated by Lua scripts. The README describes this as involving considerable up-front packaging cost but minimal maintenance cost, and lists the advantages as near optimal build times, predictable and reproducible builds, reduced build time dependencies, and incremental builds even across package boundaries. The tree explains how the manifests are produced. `gen.lua`, `ninja.lua`, `sets.lua` and `config.def.lua` sit at the top level alongside `build.ninja`, `rules.ninja` and a `project_files.txt`, with `pkg/` holding the per-package definitions and `probe/` holding what look like feature probes. `setup.lua` and `template/` suggest the pattern used for scaffolding, `scripts/` holds helper scripts, and `dist/` is where the produced artifacts land. The presence of samurai in the tree as well as in the README is consistent: a build system project that expects ninja would be redundant when the point is to avoid depending on it. Bootstrap requirements are minimal and stated as a list: any POSIX system with git, lua, curl, a sha256 utility, standard compression utilities, and an `x86_64-linux-musl` cross compiler. Because that is a short list of ordinary tools, the README points out it is trivial to cross-compile, even from non-Linux systems such as macOS or OpenBSD. That is a stronger claim than most systems make, and it follows directly from static linking plus musl: nothing on the build host needs to match the target. BearSSL is the system TLS and crypto library throughout, reached through libcurl with its native BearSSL support and through libtls-bearssl, an alternative implementation of libtls based on BearSSL. The README is candid that BearSSL is not widely adopted, and notes that only a few optional packages still require LibreSSL, with an issue tracking that gap. ## A 16 line init script and a set of principles The stated guiding principle is that the `/etc` directory should be simple enough for system administrators to understand completely and customize appropriately. The README then names the test of that principle: the most complex file in the default configuration is the system initialisation script, `/etc/rc.init`, at only 16 lines. That is a concrete, checkable claim, and it is the design goal that most explains the rest of the system. A full `/etc` you can read is not achievable with a conventional init system and a conventional service manager, which is why the init here is sinit and the service supervision is perp. The principles list is short and specific enough to be useful as a design document: Software complexity should be measured by including all transitive dependencies. Executables should be linked statically. Software components should allow for easy customization and/or modification. Package sources should be referenced through a URL or git submodule, but not included directly. `/etc` should be simple enough to be understood in its entirety. Patches should be well organized, have good descriptions, and should always apply cleanly. The fourth principle is the one that explains the missing package manager. Sources are referenced, not vendored, which is what makes the bootstrap dependency list so short and what makes the pkgsrc and Nix integration the natural extension path rather than an awkward exception. On ISO C, the README describes building with cproc, a C compiler much stricter about the standard than gcc or clang and orders of magnitude smaller. It is explicit that this is a work in progress effort and that all core packages and most others build successfully with it, which is the honest formulation: the goal is achievable, the work is not finished. ## Trying it in QEMU before committing to an install The install path is a wiki page rather than a section in the README, and the README sets expectations before sending you there: oasis is an ambitious project, there is still a lot of work to do, and users should be comfortable building their own kernel and tinkering with their system when things go wrong. The maintainer adds that help is available by mail. For an evaluation, the QEMU image is the better starting point. The README describes an archive containing the root filesystem, a Linux kernel and a script to launch QEMU, along with a README of its own covering how to use it. In short, `./run` launches in graphical mode and `./run -s` launches in serial mode: ```bash ./run ./run -s ``` Serial mode is the one to reach for over SSH, and it is also the fastest way to get a readable view of the boot sequence, which for a system with a different init and a different display server is the interesting part. Two details in the repository metadata are worth holding in mind. The single GitHub release is tagged `20170211` and was published on 2017-02-12, which is the last tagged release rather than a description of the current state: the repository is not archived and the last push was on 2026-06-09, so work has continued long after that tag and the tag tells you nothing about what is in `master`. And the license field reports nothing recognised while the tree contains a `LICENSE` file, so read that file for terms rather than relying on the metadata field. Help lives on a mailing list at `~mcf/oasis@lists.sr.ht` and an IRC channel on libera.chat, and the CI badge points at sourcehut rather than GitHub Actions, so the build system is not running on the same forge as the repository. ## Conclusion oasis is a good fit if what you want is a system you can hold in your head, with an init script you can read in one sitting and components whose sources you could replace. It is a bad fit if you need a package catalogue, hardware support breadth or a desktop you did not assemble yourself, and the README does not soften that: it says the project is ambitious and that users should be comfortable building their own kernel and tinkering when things go wrong. Try the QEMU image before installing, read the wiki install guide, and read `config.def.lua` first, since that is the file that decides what ends up on your disk. ## FAQ ### What is oasis? oasis is a small Linux system, statically linked throughout including its display server and web browser, and built on musl rather than glibc. The README says it is closer to a BSD in character than to other Linux distributions you may be familiar with. ### How do you install packages on oasis? There is no package manager. You configure specifications of what files from which packages to include, and the build system writes the resulting filesystem tree into a git repository that can be merged into / or pulled on another machine. For software outside the base system, the README says to use pkgsrc or Nix. ### What does it take to build oasis? Any POSIX system with git, lua, curl, a sha256 utility, standard compression utilities and an x86_64-linux-musl cross compiler. Because nothing on the build host has to match the target, the README notes it is straightforward to cross-compile from non-Linux systems such as macOS or OpenBSD. ### How do I try oasis without installing it? A QEMU image is published containing the root filesystem, a kernel and a launch script. Use ./run for graphical mode and ./run -s for serial mode, which is also the better choice over SSH and the fastest way to watch the boot sequence. ### Which init system and C compiler does oasis use? perp and sinit instead of sysvinit or systemd, and it aims to build with cproc, a compiler much stricter about ISO C than gcc or clang. The README describes the cproc goal as a work in progress, with all core packages and most others already building successfully. ## Sources - [Issues](https://github.com/oasislinux/oasis/issues) - [oasislinux/oasis on GitHub](https://github.com/oasislinux/oasis) - [README](https://github.com/oasislinux/oasis/blob/master/README.md) - [Releases](https://github.com/oasislinux/oasis/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/oasislinux-oasis