The compositor, shell, toolkit, renderer and apps are one Java codebase that talks to the kernel directly — DRM/KMS, Vulkan, libinput, io_uring — with no wlroots, GTK or Qt underneath. Owning every layer is what lets Sabas do things other desktops can't.
Taken one at a time, some of these exist somewhere. Together, in one system, they don't. Each card links to the full design in the docs.
Compositor, shell, UI toolkit, Vulkan renderer and apps are one Java 25 codebase that reaches the kernel through Panama. One debugger and one profiler, from the frame loop to the app.
Elsewhere: a C compositor, a JavaScript or QML shell, GTK or Qt apps.
Architecture overviewThe shell, every app and the compositor's controls are MCP servers, so one assistant can drive all of them. Every call passes policy, consent and an audit log; local models by default.
Elsewhere: a chat box inside one app, or a cloud-only assistant.
AI designEach frame takes the cheapest correct path (skip, direct scanout, hardware planes, partial or full repaint) and learns at run time what your driver accepts. A refused shortcut costs speed, never a wrong frame.
Elsewhere: per-driver rules and blocklists written by hand.
Compositor designVideo is decoded on the GPU and stays in GPU memory through colour conversion, compositing and scanout, for every player. HDR10 and HLG play in range on HDR displays and are tone-mapped on SDR ones.
Elsewhere: zero-copy for some apps, on some drivers.
Media and colour designOne service per session crawls and watches your files and answers in milliseconds, with results in shared memory. The IDE uses it today; Files, search and the AI are next.
Elsewhere: on Linux, each app walks your folders or keeps its own index.
File index designThe compositor owns the facts about every window; the shell, a separate process, only presents them. A crashed shell restarts and gets the whole window model back, so your windows stay put.
Elsewhere: on GNOME the shell is the compositor, so a shell crash ends the session.
Window managementWhere Sabas is different, and where it is still catching up.
| Feature | Sabas OS | Windows 11 | macOS | Linux GNOME / KDE |
|---|---|---|---|---|
| Desktop and AI | ||||
| The whole desktop in one language | ✓Java, compositor to apps | —C, C++, C# | —C, Objective-C, Swift | —C or C++, plus JavaScript or QML |
| An AI that can operate every app and the shell | ✓every app is an MCP server | ◐Copilot; MCP in preview | ◐Siri through App Intents | —none built in |
| Local models by default, any provider | ✓Ollama; Claude, ChatGPT, DeepSeek | ◐cloud first, some on-device | ◐Apple models; ChatGPT option | —none built in |
| Every AI action consented and audited | ✓one gateway, one audit log | —no system-wide log | —no system-wide log | —no built-in AI |
| Shell crash keeps your session | ✓restarts, windows come back | ✓Explorer restarts | ✓Dock and Finder restart | ◐KDE yes; GNOME ends the session |
| Graphics and media | ||||
| Scanout path chosen per display, any GPU mix | ✓automatic: same GPU, GBM, PRIME, CPU copy last | ✓hybrid graphics in WDDM | ◐Apple GPUs only | ◐PRIME; varies by driver |
| Cheapest correct pipeline every frame | ✓skip, direct, planes, partial, full; learns the driver | ✓independent flip, overlay planes | ✓direct-to-display | ◐direct scanout; plane use varies |
| Video zero-copy, decoder to display | ✓VA-API to DMA-BUF, every player | ✓DXVA and overlay planes | ✓VideoToolbox and Core Animation | ◐some apps, some drivers |
| HDR video in range, tone-mapped on SDR | ✓HDR10 and HLG | ✓HDR10, Dolby Vision | ✓EDR | ◐KDE; newer in GNOME |
| Colour transform applied by the display hardware | ○one baked LUT per display | ◐some hardware | ◐Apple displays | —shader only |
| Sound | ||||
| Sound modes and loudness levelling for every app | ✓EBU R128, true-peak limiter | ◐loudness equalisation, per driver | —per app only | —add-ons such as EasyEffects |
| Spatial audio for any headphones, speakers up to 7.1.4 | ✓built in, royalty-free | ◐Windows Sonic; Atmos is paid | ◐best with Apple headphones | —add-ons |
| Apps and platform | ||||
| Windows apps (.exe), natively | ○native .exe support | ✓native | ◐CrossOver (paid) or Wine | ◐Wine or Proton, set up per app |
| Android apps (.apk), natively | ○native .apk support | —Android subsystem retired | —no | ◐Waydroid, an add-on |
| Workspaces isolated by the kernel | ◐up to 6 namespaces + Landlock; opt-in for apps today | ◐Windows Sandbox, one throwaway VM | —per-app sandbox only | ◐per-app, through Flatpak |
| An IDE that shares the system AI | ◐built in, in development | —separate install | —Xcode, separate download | —separate install |
| Telemetry | ✓none | —on by default | ◐asked at setup | ✓none, or opt-in |
| Open source | ✓the whole stack | —proprietary | ◐Darwin core only | ✓yes |
| Hardware | ◐x86-64 with a Vulkan 1.3 GPU | ◐PCs with TPM 2.0 | —Apple hardware only | ✓almost anything |
| Maturity | ◐in active development | ✓mature | ✓mature | ✓mature |
✓ yes ◐ partly ○ planned— no · Current releases, as of October 2026. The architecture comparison covers the graphics stack.
Sabas OS is a full desktop operating system built entirely in Java — not a Java desktop environment running on top of Linux, but a compositor, shell, window manager, and application platform that speaks directly to the hardware through Java 25's Panama Foreign Function & Memory API.
The project started from a single question: what does a modern OS look like if you remove the assumption that the graphics stack must be written in C? The answer turned out to be a cleaner architecture — one runtime, one memory model, one toolchain — with no JNI bridges and no wlroots dependency anywhere in the stack.
Today Sabas OS boots from a live ISO on real AMD and Intel hardware and ships a desktop with a terminal, file manager, system monitor, software center, browser and IDE, plus an AI panel that runs end to end on local models.