sergioandClaude Opus 4.8
ac2835f4e7
Pieza 1+2 de 'hammer en el metal' (laptop TigerLake, WiFi AX201): - recipes/linux-metal.toml: variante del kernel con hardware real built-in (efifb/simpledrm, USB+HID, AHCI/NVMe, cfg80211+mac80211+iwlwifi/iwlmvm, e1000e/r8169, USB-CDC). Conserva los bits hammer (overlay/userns/fanotify/ virtio) ⇒ sigue booteando en QEMU. MODULES=off (monolítico, sin modprobe). Deja linux.toml INTOCADO (su of_tree es load-bearing del selfhost). - scripts/metal-firmware.sh: inyecta iwlwifi-QuZ-a0-hr-b0/cc-a0 + regulatory.db en /lib/firmware de un rootfs (descomprime .zst → .ucode plano). Blobs fijos (TODO pin a linux-firmware). - ESTADO.md: resumen humano del proyecto. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
3.7 KiB
¿Dónde está hammer hoy? (mapa amigable)
Una foto en lenguaje humano de qué funciona, qué falta y por dónde seguir. Fecha: 2026-06-22. Para el detalle de arquitectura, ver
docs/.
La idea en una frase
hammer es una distro de Linux con dos pisos: un sótano de laboratorio que compila
todo desde fuente de forma reproducible y guarda cada binario por su hash, y un piso de
arriba clásico y mutable (un Linux normal con /bin, /lib, /etc) donde puedes romper
cosas y revertir. Está pensada para que una IA entienda y modifique el sistema entero.
El semáforo: qué está listo
| Pieza | Estado | En cristiano |
|---|---|---|
| 🟢 Núcleo del laboratorio | Listo | Compila aislado (bubblewrap + zig cc + musl), direcciona por hash BLAKE3 |
| 🟢 Auto-hospedaje (self-host) | Listo y verificado | El toolchain se reconstruye a sí mismo bit a bit dentro de una VM |
| 🟢 Kernel propio | Listo | Linux 6.16.12 compilado por nosotros, arranca la VM y se reproduce idéntico |
| 🟢 Frente Rust/LLVM | Cerrado | Cadena pura mrustc → rustc 1.91.1, sin binarios ajenos de confianza |
🟢 Paquetería .swm |
Listo (6/6 piezas) | Empaquetar, repo firmado, instalar/desinstalar, deps, repo por red |
| 🟢 Catálogo de software | 145 recetas | Subió de 88 a 145 en una sola sesión (sobre todo CLIs de Rust) |
| 🟡 Instalar en disco real | En curso | Imágenes EFI/ISO existen; falta pulir "instalar desde el live" |
| 🟡 Userland Rust-nativo | En curso | coreutils/findutils de uutils ya construyen y corren |
| ⚪ Distro instalable redonda | Pendiente | Las etapas B/D/E del roadmap |
Lo más importante que se logró
-
Soberanía del arranque. No dependemos de binarios precocidos de nadie. Partiendo de un compilador mínimo, hammer reconstruye su propio Rust, su propio kernel y sus propias herramientas — y al hacerlo dos veces da exactamente el mismo resultado (reproducible bit a bit). Eso se probó dentro de una máquina virtual, no solo en teoría.
-
Una "granja" de software que escala. Hay un pipeline que toma recetas de
nixpkgsy Alpine, las adapta al formato de hammer, las compila y promueve las que funcionan al catálogo. En esta sesión pasó de 88 a 145 paquetes, casi todo CLIs de Rust populares (ripgrep, bat, fd, zoxide, helix, zellij, uv, ruff, biome…). -
El "techo" actual es conocido. Lo que frena más builds ya no es un misterio: es la versión mínima de Rust que pide cada programa (MSRV) y los paquetes que arrastran C/C++ (
openssl,git2). Subir el toolchain de 1.91.1 a 1.96 destrabó una tanda entera.
Por dónde sigue
- Escalar el catálogo a cientos de paquetes con la cola ya pre-cargada
(
JOBS=4 scripts/build-farm.sh). - Terminar "instalar desde el live": que arrancar el ISO y darle a instalar deje un sistema usable en disco (Etapa B del roadmap).
- Seguir reemplazando el userland por equivalentes Rust-nativos (xargs es el próximo).
- Pulidos opcionales: squashfs+overlay, arranque EFI fino, rollback al boot.
Para orientarte en el repo
crates/— el código de hammer (CLI, daemon, build lab, journal, overlay…).recipes/— el catálogo (145.toml);recipes/incoming/es la cola por procesar.scripts/— orquestadores:selfhost-verify.sh(la prueba de fuego),build-farm.sh(la granja),import-batch.sh(importa tandas),rust-frontier/(la cadena Rust pura).docs/— el diseño completo (SDD); empieza por00-vision.mdy10-roadmap.md.
Este archivo es el resumen humano. El estado técnico denso vive en la memoria del proyecto y en los mensajes de commit (en español, granulares).