> Una distribución Linux construida con un laboratorio funcional y hermético en el > sótano, y una terminal mutable, clásica y anárquica en el piso de arriba — diseñada > desde el suelo para que una IA programadora entienda, modifique y co…
1# Plan — juegos en hammer (kernel, nativos, y la jaula glibc)23**Fecha:** 2026-07-16 · **Contexto:** hammer es musl + estático + fuente; el mundo del juego en
4Linux es glibc + 32-bit + binarios ajenos (Steam/Proton). Este plan separa lo que hammer puede
5hacer *nativo y barato* (capas 1–2) de lo que exige un runtime ajeno *contenido y sellado*
6(capa 3), en vez de fingir que musl va a correr Steam.
78---
910## Capa 1 — kernel propio: casi gratis, ganancia real1112Los kernels ya fijan config por contrato explícito (`scripts/config -e/-d` en
13`recipes/linux-metal.toml:67`, mismo patrón que LANDLOCK/IO_URING/BPF de 2b7c701). Se extiende
14la misma línea:
1516- **T1.1 — `CONFIG_NTSYNC=y`** (driver de primitivas de sincronización NT, kernel ≥6.14; el
17 6.16.12 propio lo trae). Es EL salto para Wine/Proton moderno — reemplaza los hacks
18 esync/fsync por un char device (`/dev/ntsync`). Built-in, compatible con el `-d MODULES`
19 del kernel metal.
20- **T1.2 — sched-ext: DIFERIDO (verificado 2026-07-16).** `SCHED_CLASS_EXT` en 6.16.12
21 depende de `BPF_SYSCALL && BPF_JIT && DEBUG_INFO_BTF` (kernel/Kconfig.preempt del tag) — y
22 la receta apaga BTF/DEBUG_INFO a propósito, más BTF exige pahole/dwarves en las deps de
23 build. Es tarea propia: receta `dwarves` + análisis de repro de BTF (pahole-skew) + medir
24 el costo en tamaño del bzImage. T2.1 (schedulers scx) queda gated por esto.
25- **T1.3 — `HZ_1000` + preempt** en linux-metal (el perfil de latencia de escritorio/juego;
26 linux-generic puede quedarse como está — son perfiles distintos y por eso hay dos recetas).
27- **T1.4 — `split_lock_detect=off` en el CMDLINE embebido** (`CONFIG_CMDLINE`,
28 linux-metal.toml:99). Juegos con locks mal alineados (los hay, famosos) reciben una
29 penalización brutal del detector; en una máquina de juego se apaga. OJO: el cmdline viaja
30 DENTRO del bzImage (EFI-stub, ADR 0010) ⇒ esto re-sella el kernel, no es un toggle de GRUB.
31- **T1.5 — sysctls de perfil juego**: `vm.max_map_count=1048576` (lo pide Valve; los defaults
32 de kernel siguen en 65530), THP en `madvise`. Dónde viven: perfil de arje/base-system, no
33 hardcodeado en kernel.
3435Re-sellar linux-metal re-hashea el kernel ⇒ pasa por la granja y el ciclo QEMU-boot de
36verificación existente, como el 2b7c701.
3738## Capa 2 — userspace nativo (sí compila en hammer)3940- **T2.1 — schedulers scx (`scx_lavd`, `scx_bpfland`)**: los schedulers de juego de CachyOS.
41 Son programas BPF con userspace en Rust/C — pero compilar la parte BPF exige clang+libbpf ⇒
42 **worker**. Entrega: receta + regla de arranque en el init (SDD 07) para activarlos por
43 perfil.
44- **T2.2 — `gamescope`**: el micro-compositor de Valve (frame limiting, VRR, HDR, upscaling).
45 C++ + Vulkan + cadena wayland ⇒ **worker, frontera GUI** (gotcha zig-skew: jamás rebuildear
46 la cadena en el laptop). Es la pieza con más valor: da una "sesión de juego" contenida que
47 además le queda bien a mirada como sesión alternativa.
48- **T2.3 — `MangoHud` (C++ ⇒ worker) y `gamemode` (C)**: overlay de métricas y gobernador de
49 perfil. gamemoded habla D-Bus — la cadena KDE ya lo trajo, la dep existe.
50- **T2.4 — mesa con RADV**: el driver Vulkan serio es AMD (RADV/ACO). Revisar features de
51 `recipes/mesa.toml` y activar RADV si no está. nouveau NO es para jugar (sabido por mirada);
52 NVK madura pero no este trimestre. El perfil de juego de hammer es honesto: **AMD primero**.
53- **T2.5 — variantes v3 de mesa/wine**: donde el truco CachyOS paga de verdad para juegos.
54 Depende del piloto de `plan-variantes-cpu.md` (T5→T1–T4 de ese plan); no se duplica aquí.
5556## Capa 3 — la jaula glibc (el elefante, por fases)5758Steam, Proton y el catálogo de juegos son binarios glibc, parte 32-bit. musl no los va a
59correr y perseguir eso es un pozo. La respuesta con ADN hammer: **el runtime ajeno se trae
60entero, pineado por hash, y corre enjaulado** — verificar, no confiar, aplicado a un rootfs
61que no construimos.
6263- **F0 — pragmático (hoy)**: Steam por Flatpak. El runtime freedesktop trae su mundo glibc
64 completo. Costo: entra flatpak al catálogo (cadena ostree/bwrap — bwrap ya es dep del
65 build lab). Es la validación de demanda antes de construir nada propio.
66- **F1 — la jaula propia**: importar el **Steam Linux Runtime** (sniper/pressure-vessel — el
67 contenedor que Valve ya usa para Proton) como artefacto `file_drop` content-addressed:
68 tarball pineado por sha256 en receta, sellado en el store, hidratable como cualquier
69 artefacto. Un `hammer-juego` (script primero) lo monta con bwrap + `/dev/dri` + ntsync +
70 sockets wayland/pipewire y lanza Steam adentro. Diferencia con F0: la cadena de custodia es
71 de hammer (hash en el índice firmado, no un remote de flathub).
72- **F2 — (sólo si F1 duele) glibc propio**: construir glibc + multilib 32-bit desde fuente es
73 una campaña entera (toolchain dual, loader, locales). El mundo se mueve además hacia
74 **WoW64** (wine ≥9 corre 32-bit sobre wine 64-bit sin multilib), que puede volver F2
75 innecesario antes de que se justifique. **No arrancar F2 sin una razón que F1 no cubra.**
7677**Cruce harkaq/arje (la parte que nadie más tiene):** la jaula de juego es un *usuario más*
78del cierre §3 — política Landlock declarada para el runtime ajeno (GPU, audio, input, red de
79Steam, y NADA más). El binario es ajeno pero la jaula es nuestra y sus permisos son una
80`ConcesionCapacidad` atestada como cualquier otra. Un Steam que no puede leer `~/.ssh` es un
81argumento de venta que ninguna distro gamer ofrece.
8283## Lo que NO se hace8485- **Perseguir Steam nativo sobre musl** — pozo sin fondo, y Valve ya resolvió el contenedor.
86- **Soporte NVIDIA propietario como frente** — fuera del modelo (driver no libre, no sellable
87 desde fuente); nouveau/NVK cuando maduren. AMD es el camino soportado.
88- **Fork del kernel "gaming"** — no hay kernel aparte: son flags de perfil en linux-metal,
89 bajo el mismo contrato explícito y el mismo ciclo de verificación.
9091## Orden propuesto92931. **T1.1–T1.5** — re-sellar linux-metal con NTSYNC/sched-ext/HZ/cmdline (worker + QEMU-boot).
942. **F0** — flatpak+Steam: valida demanda con costo mínimo y da juegos YA.
953. **T2.2–T2.3** — gamescope/MangoHud/gamemode a la cola del worker (cadena GUI).
964. **T2.1** — schedulers scx + regla de init.
975. **F1** — la jaula sellada con pressure-vessel + política harkaq del runtime.
986. **T2.4–T2.5** — RADV confirmado + variantes v3 de mesa (tras el piloto de variantes).
plan-jaula-juegos.md
Plan — juegos en hammer (kernel, nativos, y la jaula glibc)
Fecha: 2026-07-16 · Contexto: hammer es musl + estático + fuente; el mundo del juego en
Linux es glibc + 32-bit + binarios ajenos (Steam/Proton). Este plan separa lo que hammer puede
hacer nativo y barato (capas 1–2) de lo que exige un runtime ajeno contenido y sellado
(capa 3), en vez de fingir que musl va a correr Steam.
Capa 1 — kernel propio: casi gratis, ganancia real
Los kernels ya fijan config por contrato explícito (scripts/config -e/-d en
recipes/linux-metal.toml:67, mismo patrón que LANDLOCK/IO_URING/BPF de 2b7c701). Se extiende
la misma línea:
T1.1 — CONFIG_NTSYNC=y (driver de primitivas de sincronización NT, kernel ≥6.14; el
6.16.12 propio lo trae). Es EL salto para Wine/Proton moderno — reemplaza los hacks
esync/fsync por un char device (/dev/ntsync). Built-in, compatible con el -d MODULES
del kernel metal.
T1.2 — sched-ext: DIFERIDO (verificado 2026-07-16).SCHED_CLASS_EXT en 6.16.12
depende de BPF_SYSCALL && BPF_JIT && DEBUG_INFO_BTF (kernel/Kconfig.preempt del tag) — y
la receta apaga BTF/DEBUG_INFO a propósito, más BTF exige pahole/dwarves en las deps de
build. Es tarea propia: receta dwarves + análisis de repro de BTF (pahole-skew) + medir
el costo en tamaño del bzImage. T2.1 (schedulers scx) queda gated por esto.
T1.3 — HZ_1000 + preempt en linux-metal (el perfil de latencia de escritorio/juego;
linux-generic puede quedarse como está — son perfiles distintos y por eso hay dos recetas).
T1.4 — split_lock_detect=off en el CMDLINE embebido (CONFIG_CMDLINE,
linux-metal.toml:99). Juegos con locks mal alineados (los hay, famosos) reciben una
penalización brutal del detector; en una máquina de juego se apaga. OJO: el cmdline viaja
DENTRO del bzImage (EFI-stub, ADR 0010) ⇒ esto re-sella el kernel, no es un toggle de GRUB.
T1.5 — sysctls de perfil juego: vm.max_map_count=1048576 (lo pide Valve; los defaults
de kernel siguen en 65530), THP en madvise. Dónde viven: perfil de arje/base-system, no
hardcodeado en kernel.
Re-sellar linux-metal re-hashea el kernel ⇒ pasa por la granja y el ciclo QEMU-boot de
verificación existente, como el 2b7c701.
Capa 2 — userspace nativo (sí compila en hammer)
T2.1 — schedulers scx (scx_lavd, scx_bpfland): los schedulers de juego de CachyOS.
Son programas BPF con userspace en Rust/C — pero compilar la parte BPF exige clang+libbpf ⇒
worker. Entrega: receta + regla de arranque en el init (SDD 07) para activarlos por
perfil.
T2.2 — gamescope: el micro-compositor de Valve (frame limiting, VRR, HDR, upscaling).
C++ + Vulkan + cadena wayland ⇒ worker, frontera GUI (gotcha zig-skew: jamás rebuildear
la cadena en el laptop). Es la pieza con más valor: da una "sesión de juego" contenida que
además le queda bien a mirada como sesión alternativa.
T2.3 — MangoHud (C++ ⇒ worker) y gamemode (C): overlay de métricas y gobernador de
perfil. gamemoded habla D-Bus — la cadena KDE ya lo trajo, la dep existe.
T2.4 — mesa con RADV: el driver Vulkan serio es AMD (RADV/ACO). Revisar features de
recipes/mesa.toml y activar RADV si no está. nouveau NO es para jugar (sabido por mirada);
NVK madura pero no este trimestre. El perfil de juego de hammer es honesto: AMD primero.
T2.5 — variantes v3 de mesa/wine: donde el truco CachyOS paga de verdad para juegos.
Depende del piloto de plan-variantes-cpu.md (T5→T1–T4 de ese plan); no se duplica aquí.
Capa 3 — la jaula glibc (el elefante, por fases)
Steam, Proton y el catálogo de juegos son binarios glibc, parte 32-bit. musl no los va a
correr y perseguir eso es un pozo. La respuesta con ADN hammer: el runtime ajeno se trae
entero, pineado por hash, y corre enjaulado — verificar, no confiar, aplicado a un rootfs
que no construimos.
F0 — pragmático (hoy): Steam por Flatpak. El runtime freedesktop trae su mundo glibc
completo. Costo: entra flatpak al catálogo (cadena ostree/bwrap — bwrap ya es dep del
build lab). Es la validación de demanda antes de construir nada propio.
F1 — la jaula propia: importar el Steam Linux Runtime (sniper/pressure-vessel — el
contenedor que Valve ya usa para Proton) como artefacto file_drop content-addressed:
tarball pineado por sha256 en receta, sellado en el store, hidratable como cualquier
artefacto. Un hammer-juego (script primero) lo monta con bwrap + /dev/dri + ntsync +
sockets wayland/pipewire y lanza Steam adentro. Diferencia con F0: la cadena de custodia es
de hammer (hash en el índice firmado, no un remote de flathub).
F2 — (sólo si F1 duele) glibc propio: construir glibc + multilib 32-bit desde fuente es
una campaña entera (toolchain dual, loader, locales). El mundo se mueve además hacia
WoW64 (wine ≥9 corre 32-bit sobre wine 64-bit sin multilib), que puede volver F2
innecesario antes de que se justifique. No arrancar F2 sin una razón que F1 no cubra.
Cruce harkaq/arje (la parte que nadie más tiene): la jaula de juego es un usuario más
del cierre §3 — política Landlock declarada para el runtime ajeno (GPU, audio, input, red de
Steam, y NADA más). El binario es ajeno pero la jaula es nuestra y sus permisos son una
ConcesionCapacidad atestada como cualquier otra. Un Steam que no puede leer ~/.ssh es un
argumento de venta que ninguna distro gamer ofrece.
Lo que NO se hace
Perseguir Steam nativo sobre musl — pozo sin fondo, y Valve ya resolvió el contenedor.
Soporte NVIDIA propietario como frente — fuera del modelo (driver no libre, no sellable
desde fuente); nouveau/NVK cuando maduren. AMD es el camino soportado.
Fork del kernel "gaming" — no hay kernel aparte: son flags de perfil en linux-metal,
bajo el mismo contrato explícito y el mismo ciclo de verificación.
Orden propuesto
T1.1–T1.5 — re-sellar linux-metal con NTSYNC/sched-ext/HZ/cmdline (worker + QEMU-boot).
F0 — flatpak+Steam: valida demanda con costo mínimo y da juegos YA.
T2.2–T2.3 — gamescope/MangoHud/gamemode a la cola del worker (cadena GUI).
T2.1 — schedulers scx + regla de init.
F1 — la jaula sellada con pressure-vessel + política harkaq del runtime.
T2.4–T2.5 — RADV confirmado + variantes v3 de mesa (tras el piloto de variantes).