sergioandClaude Opus 4.8
8bf1623044
Arranque del proyecto hammer (distro AI-nativa: laboratorio funcional en el sótano, terminal mutable clásica arriba, integración de IA programadora). - Workspace Rust (compila, tests verdes): hammer-core, hammer-build, hammer-cli (bin `hammer`), hammerd. - SDDs 00-10 + 6 ADRs en docs/ con toda la arquitectura. - Esqueletos navegables mapeados a las fases del roadmap; Fase 0/1 listas para implementar el sandbox real. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
1.6 KiB
1.6 KiB
ADR 0005 — Hidratación por hardlinks
- Estado: aceptada
- Fecha: 2026-06-06
Contexto
Hay que llevar artefactos del store content-addressed al FHS real. Tres opciones:
- Symlinks al store (estilo Nix): rutas crípticas,
/binlleno de enlaces a un almacén oculto. Es justo el "pueblo fantasma" que rechazamos. - Copia ciega al FHS: rutas reales, pero se pierde el dedup y la relación con el store (rollback más torpe, más disco).
- Hardlinks del store al FHS.
Decisión
Hidratación por hardlinks como modo por defecto (con patchelf para normalizar el caso
dinámico antes del enlace).
Razones
- Rutas reales:
/bin/grepes un archivo de verdad, no un symlink a/store/.... Estructura familiar, control total en la terminal. - Dedup: el hardlink comparte el inode del store; cero copia mientras no se modifique.
- Mutabilidad con red de seguridad: pisar
/bin/grepen caliente rompe el hardlink (copy-on-write manual); el artefacto del store queda intacto como base de rollback. - Rollback simple: re-hidratar restaura el hardlink original desde el store.
Consecuencias
- Hardlinks requieren que store y FHS estén en el mismo filesystem. En la fase Alpine viven ambos en el rootfs → OK. En la distro propia se tendrá en cuenta al particionar (SDD 10).
- El caso dinámico necesita
patchelf(set-interpreter + set-rpath) antes del hardlink (SDD 03 §4). - El GC del store debe contar hardlinks/alcanzabilidad para no borrar artefactos vivos.