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>
78 lines
4.5 KiB
Markdown
78 lines
4.5 KiB
Markdown
# SDD 00 — Visión y filosofía
|
|
|
|
## 1. El problema
|
|
|
|
El panorama de distribuciones Linux te obliga a elegir entre dos extremos malos:
|
|
|
|
- **Inmutables / declarativas** (NixOS, Guix, Fedora Silverblue): determinismo y
|
|
reproducibilidad reales, pero a costa de tu agencia. El sistema operativo *es* el grafo.
|
|
Pierdes la estructura familiar de directorios, pierdes el control directo en la terminal,
|
|
y vives editando un archivo de configuración abstracto en lugar de habitar el sistema.
|
|
Para una herramienta de automatización (una IA), además, la complejidad está *oculta tras
|
|
capas de abstracción* que la obligan a simular a un humano.
|
|
|
|
- **Tradicionales / imperativas** (Arch, Gentoo, Slackware): control y mutabilidad totales,
|
|
pero con el tiempo se pudren — el gestor de paquetes pierde el rastro de lo que el usuario
|
|
hizo a mano, se acumulan archivos huérfanos, y reproducir tu sistema en otra máquina es
|
|
imposible sin documentar cada acción manualmente.
|
|
|
|
Ninguno de los dos sirve bien para el escenario que viene: **un usuario con una IA
|
|
programadora que entiende, modifica y comparte su sistema en cualquier contexto.**
|
|
|
|
## 2. La tesis
|
|
|
|
Se puede tener lo mejor de ambos separando dos mundos que hoy están fusionados:
|
|
|
|
> **La automatización funcional es mi empleada en el sótano. En el piso de arriba mando yo.**
|
|
|
|
- **El sótano (el laboratorio):** compilación determinista, hermética, direccionada por
|
|
contenido. Aquí reina la teoría de grafos y el hashing. Cero efectos secundarios.
|
|
- **El piso de arriba (el userland):** un Linux clásico, mutable, con `/bin`, `/lib`, `/etc`
|
|
reales. Aquí reina el usuario. Un `rm -rf` rompe cosas de verdad. La terminal es un espacio
|
|
vivo de interacción directa, no la interfaz de lectura de un archivo de config.
|
|
|
|
El puente entre ambos es la **hidratación**: los artefactos del store se proyectan al FHS
|
|
real por hardlinks, normalizados para no arrastrar rutas del store.
|
|
|
|
## 3. Por qué esto es AI-nativo (el verdadero diferenciador)
|
|
|
|
La distro en sí no es la innovación — ensamblar componentes conocidos (musl, busybox, un
|
|
kernel) es trabajo conocido. **La innovación es el substrato de baja entropía** que resulta:
|
|
|
|
1. **Compilación determinista** → la IA pide cambios de fuente, recompila en el lab aislado,
|
|
y el binario es predecible. Vuelve atrás sin dramas.
|
|
2. **El sistema ejecutable es texto plano + binarios atómicos** → la IA no parsea bases de
|
|
datos binarias de configuración (registro de Windows, journal de systemd). Lee/escribe
|
|
archivos e inspecciona binarios con `readelf`/`objdump`.
|
|
3. **Mutabilidad = agencia real** → la IA experimenta en un overlay y promueve cambios. Si se
|
|
equivoca, desmontas la capa. Sin rollbacks complejos ni snapshots pesados.
|
|
4. **musl mantiene el código C legible** para el contexto de un LLM (glibc es un laberinto de
|
|
macros prehistóricas).
|
|
5. **El enlazado estático** garantiza que una herramienta mutada por la IA corre sin romper
|
|
enlaces de librerías en otros programas.
|
|
|
|
Mientras la industria diseña sistemas para *proteger al sistema del administrador*
|
|
(restringiendo, aislando, inmutabilizando) — y al hacerlo también ciega a las herramientas de
|
|
IA — `hammer` hace lo contrario: **mantiene las tuberías expuestas y de baja entropía**, y
|
|
trata al usuario (y a su IA) como un operador consciente, no como un peligro.
|
|
|
|
## 4. Principios de diseño
|
|
|
|
- **Determinismo en la fábrica, libertad en la ejecución.** No negociar ninguno de los dos.
|
|
- **Texto plano y binarios atómicos por encima de bases de datos opacas.** Si algo del sistema
|
|
no se puede `cat`, `grep` o `readelf`, es una bandera roja.
|
|
- **Verificar, no confiar.** Se comparten recetas reproducibles, nunca binarios cocidos.
|
|
- **La IA propone; el humano dispone.** Toda acción de la IA es reversible y queda registrada.
|
|
- **No reinventar lo resuelto.** Usamos motores y compiladores existentes como herramientas;
|
|
el valor está en el pegamento AI-nativo, no en reescribir Nix o un toolchain.
|
|
- **El diario es la verdad.** Vives imperativamente; el sistema deriva el estado declarativo
|
|
*a posteriori*. Nunca al revés.
|
|
|
|
## 5. Anti-objetivos (lo que `hammer` NO es)
|
|
|
|
- No es un gestor de paquetes inmutable ni un daemon que restaura estado.
|
|
- No reescribe un motor de build desde cero (ver [ADR 0004](adr/0004-no-custom-nix.md)).
|
|
- No compila contra `HEAD` vivo a ciegas (ver [ADR 0006](adr/0006-pinned-commits.md)).
|
|
- No oculta complejidad tras abstracciones que cieguen al usuario o a la IA.
|
|
- No promete estabilidad de ABL de musl como magia (ver [SDD 03](03-hydration.md)).
|