Files
hammer/ESTADO.md
T
sergioandClaude Opus 4.8 ac2835f4e7 Etapa metal: kernel-metal (drivers reales =y) + firmware AX201 + ESTADO.md
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>
2026-06-22 20:56:19 -04:00

63 lines
3.7 KiB
Markdown

# ¿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/`](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ó
1. **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.
2. **Una "granja" de software que escala.** Hay un pipeline que toma recetas de `nixpkgs` y
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…).
3. **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 por `00-vision.md` y `10-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).*