Oasis – a small, statically-linked Linux system
A minimalist Linux system called Oasis, built around static linking and smaller alternatives to common tools, is drawing interest from developers who want tiny, reproducible, self-contained binaries for uses like embedded devices, immutable images, and debugging hostile environments. Much of the debate centers on trade-offs between static and dynamic linking—simplicity, portability and reduced dependency hell versus memory use, update mechanisms, and plugin support—as well as musl vs glibc in terms of size, correctness, and performance. Commenters also note challenges around GPU drivers, TLS libraries, and dependency management culture, arguing that current container-heavy practices are partly a response to longstanding weaknesses in shared-library ecosystems.
Project goals & design choices
- Oasis is a small, statically linked Linux system that favors simple, minimal implementations of common tools: musl instead of glibc, sbase/ubase instead of coreutils/util-linux, oksh instead of bash, mandoc instead of man-db, netbsd-curses instead of ncurses, Netsurf instead of heavyweight browsers, and smaller init/build tools.
- It is seen as a spiritual successor to sta.li and other “suckless”-inspired systems.
Use cases
- Suggested uses include immutable images, embedded devices, and Kubernetes nodes, where fully self-contained, statically linked binaries are attractive.
- Some see it as ideal for dropping tools onto underpowered or heterogeneous embedded Linux devices without worrying about local library versions.
- Others ask what it offers over more mainstream distros or dynamic linking; for some, it’s “interesting but unclear” beyond niche/embedded scenarios.
Build system & reproducibility
- Oasis uses Samurai (a Ninja-compatible build tool) and emphasizes fast, reproducible full-system builds.
- One commenter described success building Oasis with Bazel to get distributed, incremental, reproducible OS builds; this led to a broader comparison of Bazel vs Nix.
- Nix is praised for hash-based, content-addressed builds and distributed caching, but criticized for coarse build granularity and higher per-derivation overhead inside projects.
Static vs dynamic linking debate
- Pro-static:
- Simplifies deployment and avoids “dependency hell”; good for portable binaries, containers, and constrained systems.
- With musl and LTO, per-binary size can remain small; linkers can drop unused code.
- Acceptable to rebuild/relink everything on library updates, especially with a single-tree build.
- Pro-dynamic:
- Better RAM sharing, easier security patching (update one shared lib), and mature tooling.
- Static linking has quirks: constructor ordering, ABI/version mismatches, larger total memory footprint in some workloads.
- Several note modern container practices already duplicate whole OS images, making static “bloat” less concerning to some but not all.
musl, BearSSL & alternative libs
- musl is praised for small size, portability, simpler semantics, and static-link friendliness; critics cite past DNS bugs, weaker malloc performance, and quirkier behavior vs glibc.
- Licensing is a factor: musl’s permissive license simplifies static linking compared to glibc’s LGPL.
- BearSSL is questioned because it self-describes as “beta” and lacks TLS 1.3; others argue version numbers don’t reliably signal production readiness and point to widely used <1.0 libraries elsewhere.
Practicalities & limitations
- An old Oasis QEMU image is reported around 360MB; current official image links were temporarily down.
- GPU drivers are highlighted as a major unresolved issue for a fully static OS: most realistic designs still require dynamic components or IPC-based GPU stacks.
- Netsurf is admired for minimalism but its documentation links appear stale; perceived rendering coverage is limited.