Every design decision is documented, every module has a clear ownership boundary, and the architecture is designed to be understood.
Browse the source, open issues, submit pull requests. Every module is independently reviewable.
View repositoryFull architecture reference, module guides, render pipeline deep-dives and configuration reference.
Read the docsArchitecture questions, hardware compatibility reports, feature proposals — all in the open on GitHub Discussions.
Join the conversationThings people ask before they boot the ISO.
The JVM's reputation for latency comes from GC pauses and JNI overhead — Sabas OS eliminates both on the hot path. The render loop is allocation-free (pooled buffers, no per-frame heap traffic), so GC never fires during a frame. Panama FFM replaces JNI entirely, removing the marshalling cost. What remains is JIT-compiled native code that the JVM's optimizer can inline and vectorise across the whole stack.
Real hardware first. The compositor drives DRM/KMS directly — it talks to the kernel's display subsystem the same way a C compositor would. The live ISO boots bare-metal on AMD and Intel iGPU systems today. NVIDIA support (Path B, modifier zero-copy) is implemented and tested on a discrete card. Nested mode (running inside an existing GNOME or KDE session) is available for development without rebooting.
Every native call goes through Java 25's Panama Foreign Function and Memory API. There are no .so files compiled from C in the repo, no native keyword in any Java source file, and the GraalVM Native Image JNI config is empty. The only C in the project is a tiny PAM session-launch helper for the greeter, which is a separate process, not a library.
Yes. Sabas OS is a Wayland compositor — any Wayland-native app runs as a first-class client. XWayland support for legacy X11 apps is on the roadmap. The built-in browser (CEF-based) covers most web apps today. The Software Center auto-detects the underlying package manager (dnf on the Fedora base, apt on the Ubuntu base) so you can install packages from the distro's repos normally.
The Sabas compositor, shell and all built-in apps are identical on both — same Java binaries, same config format, same render pipeline. The difference is the userland underneath: kernel version, default package repos, driver packaging and update cadence. Fedora tracks a newer kernel (better for recent GPU and VRR support); Ubuntu LTS offers a longer support window.
The compositor JVM is the only one on the critical path for display output. The shell communicates over a Unix domain socket — control messages are ~52 bytes per panel per frame (3-5 microseconds, 0.08% of a 6ms frame budget at 165Hz), and pixel data travels as DMA-BUF file descriptors (zero-copy, kernel-mediated). In practice the split is a net win: a shell GC pause or crash doesn't stall the compositor's frame loop.
No by default. Inference runs locally through Ollama — the model weights live on your machine and no query leaves it unless you explicitly configure a remote endpoint. The MCP security gate redacts PII before any data crosses a process boundary, and every agentic action is written to a tamper-evident audit log you can inspect. Cloud endpoints are opt-in and clearly labelled in the settings UI.
Any GPU with a working Vulkan driver and VK_EXT_external_memory_dma_buf support. AMD (RDNA and GCN via AMDVLK / Mesa RADV), Intel (Gen 9+ via ANV), and NVIDIA (via proprietary driver, Path B) are all tested. The CPU fallback path (llvmpipe) works for development without a discrete GPU. Multi-GPU setups are handled automatically by OutputPathSelector at hotplug time.