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