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>
63 lines
3.7 KiB
Markdown
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).*
|