# Fremde Software auf OrientOS — der Plan

Stand 08.09.2026. Grundlage: vier parallele Tiefenrecherchen mit Quellen (Win32-Umfang,
GPU-Wege, Übersetzer-/Recompiler-Wege, Minecraft konkret) plus **im Repo gemessener
Bestand** (`/root/osum-merge8`). Ergänzt die ROADMAP.md um die Frage, die Justin am
08.09. gestellt hat: *„läuft überhaupt irgendwas — Minecraft, Photoshop, Word?"*

**Der Stand heute:** Noch laeuft kein fremdes Programm auf Osum.
**Die interessante Antwort:** Der Weg dorthin ist deutlich kürzer, als er aussieht — aus
einem Grund, den wir schon haben und bisher nicht genutzt haben.

---

## -1. Leitsatz (Justin, 08.09.2026): brutal leichtgewichtig UND brutal kompatibel

Beides gilt gleichzeitig, und genau daraus folgt die Reihenfolge in diesem Dokument.

**Der scheinbare Widerspruch:** Kompatibilitaet erkauft man sich normalerweise mit
Umfang -- Wine ist Millionen Zeilen, Chromium auch. Wer alles nachbaut, wird schwer.

**Die Aufloesung: Kompatibilitaet ueber SCHMALE Schnittstellen, nicht ueber Nachbau.**
Wir bauen nie das fremde System nach, wir bedienen die duennste Stelle, an der die
fremde Software schon andockt:

| statt ... | bedienen wir ... | Breite |
|---|---|---|
| POSIX vollstaendig nachbauen (~1200 Funktionen) | WASI preview1 | **46 Funktionen** |
| Linux nachbauen | die Syscall-Nummern, die wir ohnehin schon fuehren | ~101 vorhanden, Rest Lueckenfuellen |
| ein Dateisystem je Programm | SQLites VFS | **~20 Rueckrufe** |
| eine Fensterbibliothek je App | wlib + wig, alles ueber einen Fensterserver | eine Schicht |
| Chromium einbetten (wie Steam) | Certus, unser eigener Browser | ein Programm |

**Regeln, die daraus folgen und fuer jede Runde gelten:**

1. **Schnittstelle vor Nachbau.** Vor jedem grossen Vorhaben die Frage: gibt es eine
   schmalere Stelle, an der dieselbe Software andockt? (Das ist der Grund, warum
   WASI vor CPython steht und Craft vor OpenJDK.)
2. **Statisch gelinkt, inhaltsadressiert, dedupliziert.** Schon entschieden (A9);
   passt genau zu leichtgewichtig, weil identische Teile nur einmal Platz kosten.
3. **Kein Ballast im Standardabbild.** Das Stick-Abbild ist heute 118 MiB und soll
   klein bleiben. Alles Optionale kommt aus dem Store, nicht ins Grundabbild.
4. **Kein Fremdcode im Kern.** Deuter, Laufzeiten und portierte Programme laufen in
   Ring 3. Der Kern bleibt klein und pruefbar.
5. **Tempo wird gemessen, nicht angenommen.** Jede Runde nennt Zahlen (ms, MB/s,
   fps, Faktor gegen nativ). „Leichtgewichtig" ohne Messwert ist eine Behauptung.
6. **Ein Weg, der 90 % bringt und 10 % kostet, schlaegt den vollstaendigen.**
   Beispiele in diesem Dokument: GOP statt eigener Modesetting-Kette,
   Write-Combining statt GPU-Treiber, Dirty-Rects statt Vollbild, GraalVM
   native-image statt ganz HotSpot, Craft statt Minecraft.

---

## 0. Der Fund, der alles verschiebt: wir haben LINUX-SYSCALL-NUMMERN

Gemessen in `kernel/sys.fi` (11 652 Zeilen, 174 Zweige im Gate):

```
SYS_READ = 0     SYS_WRITE = 1    SYS_OPEN = 2     SYS_CLOSE = 3
SYS_MMAP = 9     SYS_IOCTL = 16   SYS_CLONE = 56   SYS_EXECVE = 59
SYS_EXIT = 60    SYS_SOCKET = 41  SYS_CONNECT = 42 SYS_EXIT_GROUP = 231
```

Das sind **die Nummern von Linux x86-64**, nicht eigene. 160 Syscall-Konstanten,
davon **101 unter Nummer 400**. Osum-eigene Aufrufe liegen sauber ab 1000
(`SYS_SPAWN = 1000`, `SYS_OSUM_*`). Das README sagt es selbst: *„a POSIX layer with
the system call numbers of Linux x86-64"*.

**Konsequenz:** Linux-ABI-Kompatibilität ist bei uns kein Umbau, sondern **Lücken
füllen**. Ein statisch gelinktes Linux-Programm (musl, busybox, statisches Go/Rust)
braucht realistisch 60–90 Nummern. Wir haben 101. Das ist die größte ungenutzte
Karte im ganzen Projekt.

Was zusätzlich fehlt und geprüft werden muss, bevor fremde Binaries starten:
`auxv` beim ELF-Start, `fs`-Register/TLS (`arch_prctl`), `futex`, `vDSO` (oder
sauberer Fallback), `/proc/self/*`, `set_tid_address`, `rt_sigreturn`-Rahmen.
Das ist die Liste, an der WSL1, FreeBSDs Linuxulator und gVisor jeweils gearbeitet
haben — nicht 1000 Funktionen, sondern ein gutes Dutzend Details.

---

## 1. Win32 nachbauen: ausgeschlossen, mit Zahlen

| DLL | Exporte | Wine implementiert |
|---|---|---|
| `ntdll.dll` | 1535 | 1416 (93 %), 101 Stubs |
| `user32.dll` | 983 | 783 (79 %), 200 Stubs |
| `kernel32.dll` | ~1566–2000 | — |
| gesamt über alle Kern-DLLs | **grob 10 000–15 000** | — |

Wine dafür: **5,7 Mio Zeilen Code** (Wine 5.0), **135 558 Commits**, **~1586 Autoren**,
**seit 1993**. Das sind leicht dreistellige Mannjahre.

Auch die Abkürzung „nur was Notepad importiert" trägt nicht: jedes reale Programm
greift sofort in COM (`ole32`), GDI, den Fensterserver und die Registry. Win32 ist
kein API-Satz, sondern ein Ökosystem mit 30 Jahren Verhaltens-Altlast.

**Einordnung: Win32 liegt BEISEITE, nicht gestrichen.** Es ist der breiteste Posten
auf der Liste, deshalb kommt er nicht zuerst -- nicht, weil er unmoeglich waere.
Die Wine-Zahlen oben messen, was eine lose Freiwilligen-Gemeinschaft ohne
Werkzeuge wie unsere in 30 Jahren nebenbei geschafft hat; sie sind ein Groessen-
vergleich, keine Vorhersage fuer dieses Projekt. Der sinnvolle Einstieg, wenn wir
ihn angehen: die PE-Ladeschicht plus eine kleine Kernmenge aus kernel32/ntdll
(Speicher, Dateien, Faeden, Handles) und ein Win32-Fenster auf unseren
Fensterserver abgebildet -- Konsolenprogramme zuerst, GUI danach. Reihenfolge in
Abschnitt 7 beachten: die Schleuse (WASM) und die Linux-Kompatibilitaet bringen
frueher mehr Software aufs System.

---

## 2. Der Hebel: Schnittstellen, für die die Welt schon kompiliert

Die eine Zahl, die die ganze Strategie trägt:

> **POSIX hat rund 1200 Funktionen. WASI preview1 hat 46.**

Wer 46 Funktionen implementiert, für den läuft *alles*, was nach WebAssembly
kompiliert wurde. Für Hello World mit Dateizugriff reichen davon 8–10
(`proc_exit`, `fd_write/read/close/seek`, `fd_fdstat_get`, `path_open`, `args_*`,
`environ_*`).

**Was real als WASM existiert:** CPython (Pyodide, 250+ Pakete; offizielles
`wasm32-wasi`-Target seit 3.11), SQLite (offizielles `sqlite3.wasm`), ffmpeg,
Doom, Ruby, PHP, PostgreSQL (PGlite), Clang/LLVM, sogar Blender.

**Tempo (gemessen, Frank Denis 2026, libsodium-Benchmark, Faktor gegen nativ):**

| Laufzeit | Faktor |
|---|---|
| WAMR (AOT) | 1,57× |
| WasmEdge | 1,74× |
| Wasmer (`wide_arithmetic`) | 1,33× |
| wasm2c → Clang | ~2,0× |
| wasm3 (Interpreter) | 11,5× |
| Node/V8 | 7,95× |

**Aufwand für uns:** `wasm3` sind ~10 000 Zeilen C99 ohne Abhängigkeiten, läuft ab
64 KB Code — realistisch **2–6 Wochen** für einen funktionierenden Interpreter.
Noch billiger: **`wasm2c`** (aus wabt) übersetzt WASM nach C, das übersetzt unser
eigener Compiler — dann brauchen wir **gar keine Laufzeit**, nur die 46 Funktionen.

---

## 3. Sprach-Laufzeiten portieren (bestes Aufwand/Nutzen-Verhältnis sofort)

| Runtime | Umfang | Was sie mindestens braucht | Aufwand |
|---|---|---|---|
| **Lua 5.4** | ~30k Zeilen reines ANSI-C, **keine** OS-Annahme | nur ISO-C: `fopen/fread/fwrite/malloc/setjmp` | **Stunden bis 2 Tage** |
| **SQLite** | ~150k Zeilen, aber alles hinter dem VFS | **~20 Callbacks** (`xOpen, xRead, xWrite, xSync, xFileSize, xLock, xDelete, xAccess, xFullPathname, xRandomness, xSleep, xCurrentTime …`), `SQLITE_OS_OTHER=1` | **2–5 Tage** |
| **QuickJS** | ~90k Zeilen C, volles ES2023 | `malloc/free/memcpy/printf`; libc-Modul optional | **1–3 Tage** |
| CPython | ~1,1 Mio Zeilen | `fork/exec/waitpid`, `dlopen`, `mmap`, `select/poll`, pthreads, Signale, Sockets | Wochen–Monate |
| OpenJDK | >10 Mio, HotSpot ~1,5 Mio | s. Abschnitt 5 | **2–4 Mannjahre** |

**Das Muster von SerenityOS** (der beste Vergleichsfall: >300 Ports in ~4 Jahren):
Die ersten zehn Ports kosten Monate, die Ports 50–300 je einen Nachmittag. Grund:
**jeder Port ist ein Bug-Report gegen die eigene libc.** Der Engpass ist nie das
portierte Programm, sondern die fehlende libc-Funktion, die dabei auffällt.

**Reihenfolge:** Lua → SQLite → QuickJS → musl-kompatible libc → busybox/coreutils
→ Python. Danach WASM als Universalschleuse.

---

## 4. Grafik — was wirklich geht

### 4a. Der billigste Gewinn: Write-Combining (Tage, nicht Monate)

Der Framebuffer **muss** als Write-Combining gemappt sein (PAT/MTRR):

| Mapping | Durchsatz | 1080p-Vollbild (8,29 MB) |
|---|---|---|
| Uncached (UC) — der Klassiker-Fehler in Hobby-OS | 50–200 MB/s | 40–160 ms → **6–25 fps** |
| Write-Combining (WC) | 2–6 GB/s | 2,8 ms → **~360 fps** |

Dazu drei Regeln: **nie aus dem Framebuffer lesen** (WC/UC-Reads sind katastrophal),
immer im **Shadow-Buffer im RAM** rendern, und **Dirty-Rects** (ein Desktop ändert
1–5 % der Pixel pro Bild → Faktor 20–100 weniger Traffic). Ausgabe mit
**non-temporal Stores** (`vmovntdq`). Alpha-Blending mit SSE2/AVX2: Faktor 4–8×.

**Ergebnis:** 60 fps bei **3440×1440** sind mit reinem CPU-Compositing erreichbar.
Belegt durch ToaruOS und SerenityOS; Managarm fährt darauf KDE Plasma 6.

### 4b. virtio-gpu 2D (~1 Woche)

14 Kommandos in der Spec, für ein Bild reichen **6–7**: `GET_DISPLAY_INFO` →
`RESOURCE_CREATE_2D` → `RESOURCE_ATTACH_BACKING` → `SET_SCANOUT` → Schleife aus
`TRANSFER_TO_HOST_2D` + `RESOURCE_FLUSH`. Hardware-Cursor kostet 2 Kommandos mehr.
**~300–700 Zeilen** auf unserem vorhandenen virtio-Transport. Löst zugleich das
Page-Flip-Problem oberhalb 1280×800 (Runde VSYNC) für die Entwicklungsumgebung.

### 4c. Echte GPU

**Kein Hobby-OS hat je einen nativen 3D-Treiber geschrieben.** Wer 3D hat, hat
**Mesa portiert**: SerenityOS über virgl (in der VM), Haiku über RADV+Zink auf
echter AMD-Hardware — im Kern **eine Person, 2023–2025**, Blender läuft darauf.

Codegrößen zum Kalibrieren: amdgpu **5,9 Mio Zeilen** (Linux 6.16), NVIDIA open
modules **>935k** (nur Turing+, GSP-Firmware bleibt Blob), i915 ~400–500k,
virtio-gpu ~10k. Für **Modesetting-only** (ohne 3D) auf Intel Gen9: **5000–15 000
Zeilen, 6–18 Monate** — und Intel ist die einzige Plattform mit öffentlichem PRM,
also die einzige, auf der das eine Person schafft. **Abkürzung:** Modus einmalig
per UEFI-GOP setzen lassen, danach nur Plane-Basisadresse + Cursor umprogrammieren
— spart PLL-Programmierung und DP-Link-Training, also ~70 % des Aufwands.

Software-3D (llvmpipe) als Referenz: OpenArena 35 fps @800×600 auf altem i7,
**unter 10 fps @1080p**; hochgerechnet auf heutige 8-Kerner ~30–50 fps @1080p für
Quake-3-Klasse. Braucht LLVM im Gast. Für UI-Compositing **nicht nötig** — ein
eigener SIMD-Blitter ist schneller, kleiner (~1500–3000 Zeilen) und ohne
Abhängigkeiten.

---

## 5. Minecraft — konkret durchgerechnet

**Was 1.21 fordert:** Java 21 (aktuell 26.x: Java 25), **OpenGL 3.2 Core** als harte
Untergrenze (Sodium ≥0.5 sogar GL 4.5 wegen `ARB_direct_state_access`), LWJGL 3.3
mit GLFW/OpenAL/stb, 8–12 GB RAM, 4 Kerne, **15–25 lebende OS-Threads**.

**Was HotSpot vom Kern fordert** — hier scheitern Hobby-Kernel:
`mmap` mit Reserve-then-Commit und `MAP_FIXED`, W→X-umschaltbarer CodeCache,
`sigaltstack`, und vor allem: **SIGSEGV als normaler Kontrollfluss** (implizite
Null-Checks und Stack-Overflow-Erkennung), mit `si_addr`, `ucontext_t`,
Register-Zugriff und PC-Modifikation zum Fortsetzen. Dazu `dlopen`/`dlsym`
zwingend (JNI/LWJGL), monotone ns-Uhr, Condition Variables (futex nicht zwingend).

**Voller OpenJDK-Port: der groesste Einzelposten -- machbar, aber nicht als
Erstes.** Zur Einordnung: Haikus GSoC 2012 hat
in einem Sommer nur die **Zero-VM** geschafft (Interpreter, 10–50× langsamer als
C2) — der Port läuft seit 14 Jahren und braucht pro Major-Release Rebasing.
SerenityOS hat trotz 300+ Ports **kein Java**, genau aus diesen Gründen.

**Alternative JVMs:** Avian, JamVM, CacaoVM sind tot bzw. Java ≤7 → **Sackgasse**.
TeaVM kann kein Reflection (Eaglercraft schafft damit 1.8/1.12 im Browser, nicht 1.21).
**GraalVM native-image** ist die einzige kluge Abkürzung: nur die Substrate-VM muss
portiert werden statt ganz HotSpot (**5–10× weniger Aufwand, 6–12 Monate**); ein
nativer Minecraft-**Server** existiert bewiesen (<120 MB, hpi-swa), der Client ist
wegen Reflection/Unsafe fragil.

**Und selbst dann:** Minecraft unter llvmpipe liefert **3–8 fps @1080p**.
*Der Grafiktreiber ist der eigentliche Posten, nicht die JVM* -- deshalb steht in
Abschnitt 7 die Bildbeschleunigung vor der Laufzeit. Java bleibt auf der Liste,
nur weiter hinten.

**Der realistische Meilenstein stattdessen: Craft portieren.**
Michael Foglemans `Craft`: **~7000–10 000 Zeilen C**, GLFW + OpenGL 3 + SQLite,
alle Abhängigkeiten im Repo. Portierungsaufwand = **1 GLFW-Backend (~3000–8000
Zeilen) + GL-Kontext**, also **2–6 Wochen**. Ergebnis: echtes Voxel-Spiel mit
Multiplayer, **20–40 fps @1080p in Software**. Luanti (ex-Minetest) wäre die große
Variante: 200–250k Zeilen + IrrlichtMt, GLES2, 4–9 Monate, spielbar nur ≤720p.

---

## 6. Was spaeter kommt bzw. sich als Sackgasse gemessen hat

- **Win32** -- beiseite gelegt, nicht gestrichen. Begruendung und moeglicher
  Einstiegspfad in Abschnitt 1.
- **C automatisch in Firn übersetzen.** c2rust ist der ausgereifteste Transpiler
  überhaupt und produziert 26,5–99 % `unsafe`; **79 % der Roh-Pointer** lassen sich
  nicht in sichere Referenzen überführen. LLM-Übersetzung: **22 % Erfolgsquote**
  (CRUST-Bench, bestes Modell). Und selbst bei Erfolg ruft der übersetzte Code
  weiterhin `open()`, `mmap()`, `pthread_create()` — **Übersetzung ersetzt keinen
  Port**, sie verschiebt ihn nur. Nische: kleine algorithmische Bibliotheken ohne
  OS-Kontakt (Codecs, Krypto, Parser).
- **Statische Recompilation** (N64Recomp-Stil, liefert 100 % natives Tempo) braucht
  Symboltabellen und feste ROMs — funktioniert bei Konsolenspielen, nicht bei
  Desktop-Software mit `dlopen` und JIT.
- **Alternative JVMs** — alle tot oder Java ≤8.

---

## 7. Die Reihenfolge (Aufwand aufsteigend, Nutzen absteigend)

| # | Schritt | Aufwand | Was es bringt |
|---|---|---|---|
| 1 | **Write-Combining + Shadow-Buffer + Dirty-Rects + SIMD-Blitter** | Tage–Wochen | Der ganze Desktop wird schnell, 60 fps @3440×1440, trägt bis 4K |
| 2 | **Lua + SQLite + QuickJS portieren** | 1–2 Wochen zusammen | Osum wird skriptbar, mit Datenbank und JS |
| 3 | **WASI preview1 (46 Funktionen) + wasm3 oder wasm2c** | 2–6 Wochen | Python, SQLite, ffmpeg, Doom als WASM |
| 4 | **virtio-gpu 2D** | ~1 Woche | Page-Flip >1280×800, Multi-Head, HW-Cursor in QEMU |
| 5 | **Linux-ABI vervollständigen** (auxv, TLS, futex, /proc) + busybox starten | Wochen | Statische Linux-Binaries laufen |
| 6 | **musl-kompatible libc + Ports-System** | Monate, dann Tage je Port | SerenityOS-Pfad |
| 7 | **Craft portieren** | 2–6 Wochen | Echtes Voxel-Spiel, 20–40 fps |
| 8 | **Mesa portieren** (dann virgl in der VM, perspektivisch RADV) | Monate–Jahre | OpenGL für fremde Programme |
| 9 | Box64-artige x86-Übersetzung mit API-Wrapping | Monate | Fremde Binaries ohne Quelltext (CPU 50–60 %, GPU/IO 90–100 %) |
| 10 | Intel-Gen9-Modesetting nativ | 6–18 Monate | Echte Hardware ohne GOP-Krücke |
| 11 | **CUDA / NVIDIA auf Justins RTX 3060** — open-gpu-kernel-modules portieren (Ampere ist ab Turing dabei, GSP-Firmware-Blob bleibt), dann `libcuda.so`/Runtime als unveraendertes Linux-Binary | nach 5 + dynamischem Linken | CUDA-Programme, zugleich Modesetting + Vulkan-Grundlage fuer die Karte |

**Weiter hinten, bewusst:** OpenJDK/Java, Win32, nativer 3D-Treiber. Alle drei sind
breite Posten -- sie kommen, wenn das Fundament darunter steht (Bildweg, libc,
Schleuse, Linux-Binaerkompatibilitaet). Kein Ausschluss, eine Reihenfolge.

---

## 7b. CUDA und die NVIDIA-Karte (Justins Frage 08.09.2026)

Drei Schichten: Kerneltreiber (`nvidia.ko` + `nvidia-uvm.ko`) -- Userspace-Treiber
`libcuda.so` (uebersetzt PTX, redet per `ioctl` mit `/dev/nvidia*`) -- CUDA-Runtime.

- **Offen:** der Kerneltreiber, seit 2022 (open-gpu-kernel-modules, MIT/GPL), ab
  Turing -- die RTX 3060 (Ampere) ist dabei. Die Hardware-Initialisierung laeuft auf
  dem GSP (RISC-V in der GPU) mit NVIDIAs Firmware-Blob; der Kernelteil ist deshalb
  vor allem RPC. OS-abhaengiger Layer ~39 000 Zeilen, der Rest OS-agnostisch.
- **Nicht offen:** `libcuda.so` und Runtime -- nur als Linux-x86-64-Binary, dynamisch
  gegen glibc gelinkt. Laeuft auf Osum genau dann, wenn dynamisches Linken steht,
  die Linux-ABI `ioctl`/`mmap` auf Geraete kann, und der Kerneltreiber portiert ist.
  Dann startet es unveraendert wie heute Lua und SQLite.
- **Reihenfolge:** FREMDLAND (Threads/fork) -> dynamisches Linken -> Linux-ABI fuer
  Geraete -> open-gpu-kernel-modules als erster echter GPU-Treiber -> libcuda.
  Jeder Schritt bringt vorher schon Nutzen.
- **Frueher moeglich:** Vulkan-Compute/OpenCL ueber portiertes Mesa (offen bis unten),
  ZLUDA (CUDA auf Nicht-NVIDIA-Stapeln).

## 8. Quellen

Win32/Wine: [Wine API user32](https://source.winehq.org/WineAPI/user32.html) ·
[Wine API ntdll](https://source.winehq.org/WineAPI/ntdll.html) ·
[Wine 5,7 Mio Zeilen (Phoronix)](https://www.phoronix.com/news/Wine-Approaching-Six-Million) ·
[KERNEL32 Functions (Geoff Chappell)](https://www.geoffchappell.com/studies/windows/win32/kernel32/api/index.htm)

WASM/WASI: [wasi_snapshot_preview1.witx](https://github.com/WebAssembly/WASI/blob/main/legacy/preview1/witx/wasi_snapshot_preview1.witx) ·
[wasm3 Performance](https://github.com/wasm3/wasm3/blob/main/docs/Performance.md) ·
[Frank Denis, WASM-Laufzeiten 2026](https://00f.net/2026/06/23/webassembly-runtimes-2026/) ·
[Jangda et al., „Not So Fast", USENIX ATC '19](https://www.usenix.org/conference/atc19/presentation/jangda)

Grafik: [virtio-spec GPU](https://github.com/oasis-tcs/virtio-spec/blob/master/device-types/gpu/description.tex) ·
[Mesa virgl](https://docs.mesa3d.org/drivers/virgl.html) ·
[Mesa llvmpipe](https://docs.mesa3d.org/drivers/llvmpipe.html) ·
[Haiku Zink auf RADV (Phoronix)](https://www.phoronix.com/news/Haiku-OS-Zink-RADV) ·
[amdgpu 5,9 Mio Zeilen (Phoronix)](https://www.phoronix.com/news/Linux-6.16-AMDGPU-Driver-Size) ·
[NVIDIA open-gpu-kernel-modules](https://github.com/NVIDIA/open-gpu-kernel-modules)

Ports/Runtimes: [SerenityOS Ports](https://github.com/SerenityOS/serenity/tree/master/Ports) ·
[Linus Groh, My Journey With SerenityOS](https://linus.dev/posts/my-journey-with-serenityos/) ·
[CRUST-Bench (arXiv 2504.15254)](https://arxiv.org/pdf/2504.15254)

Minecraft/Java: [Mojang Systemanforderungen](https://help.minecraft.net/hc/en-us/articles/4409225939853-System-Requirements-for-Minecraft-Java-Edition) ·
[Sodium: GL 4.5 als harte Abhängigkeit](https://github.com/CaffeineMC/sodium/commit/69fb6d3616ecee7df042703ba35b21f49d0c55b2) ·
[os_linux.cpp, 5596 Zeilen](https://github.com/openjdk/jdk/blob/master/src/hotspot/os/linux/os_linux.cpp) ·
[OpenJDK Haiku-Port](https://openjdk.org/projects/haiku-port/) ·
[Native Minecraft Server mit GraalVM](https://medium.com/graalvm/native-minecraft-servers-with-graalvm-native-image-1a3f6a92eb48) ·
[fogleman/Craft](https://github.com/fogleman/Craft) ·
[Box86/Box64 vs QEMU vs FEX vs Rosetta2](https://box86.org/2022/03/box86-box64-vs-qemu-vs-fex-vs-rosetta2/)