Files
takana/docs
Sergio 42404bc692 SDD 26 §3.bis: el diff contra Alpine dice que no es sólo PGO, y una de las diferencias es de seguridad
Pregunta del usuario: «¿firefox está sin pgo-lto-bolt? ¿eso es una desventaja frente a las otras
distros?». Sí, y para medirlo se trajeron el APKBUILD + mozconfig de community/firefox de aports y
el PKGBUILD de Arch, y se compararon línea a línea con el mozconfig de recipes/firefox.toml.

La comparación importa porque ALPINE ES NUESTRO PROPIO UPSTREAM: de ahí salen los once parches de
musl. No es una distro lejana sacándonos ventaja, es la que ya construye este mismo código con
`--enable-lto=cross` + `--enable-profile-use=cross` + jarlog. Arch hace lo mismo («Do 3-tier PGO»).

BOLT NO ES LA DESVENTAJA: cero menciones en los dos ficheros. Lo que nos separa es PGO+LTO.

Y el diff completo da más que velocidad:
- RLBOX APAGADO (`--without-wasm-sandboxed-libraries`) es una desventaja de SEGURIDAD y pesa más que
  el PGO: es la jaula wasm de graphite/ogg/expat/woff2, o sea el código que come entrada no
  confiable. Encenderlo pide wasi-sdk + wasi-compiler-rt en el corpus: receta, no flag.
- `--with-unsigned-addon-scopes=app,system` nos falta y ATUQ LO NECESITA para shipear sus propias
  extensiones ⇒ una capacidad de atuq que NO se resuelve en el overlay: exige tocar la base.
- Falta RELR; el linker es GNU ld y no lld.
- `--disable-jemalloc` NO es desviación nuestra: Alpine también lo pasa. Un fantasma menos que
  perseguir.
- Bundlear en vez de `--with-system-*` es diferencia a propósito: el corpus ES la fuente.

Corolario que ordena el plan: TODO ESO ENTRA EN UN SOLO REBUILD. Cada uno son cuatro horas y
re-sella la cola Gecko entera, así que la unidad 3 pasa a ser una pasada única y RLBox se separa
como 3.b.

Y dos muros del PGO que las distros no tienen, porque no persiguen lo que nosotros perseguimos:
- las dos corren el profileserver bajo `xvfb-run`, y NO TENEMOS X11 en el corpus (Wayland-only) ⇒ va
  bajo sway headless, que ya existe del frente wlr.
- el profdata NO ES DETERMINISTA (contadores dependientes del timing) ⇒ se genera una vez, se sella
  como artefacto propio y se consume por hash, o firefox deja de reproducir.

Bonus para el §2: el jarlog del PGO ordena el omni.ja para el arranque. Re-empacarlo a lo bruto tira
esa optimización a la basura sin que nadie lo note.
2026-09-05 03:03:23 +00:00
..

Documentación de diseño de hammer

Estos documentos son la fuente de verdad del diseño. El código los implementa; cuando haya discrepancia, o se corrige el código o se actualiza el SDD con un commit que explique por qué.

Software Design Documents (SDD)

# Documento Qué cubre
00 Visión y filosofía Por qué existe, qué problema resuelve, la actitud de ingeniería
01 Arquitectura general El modelo de dos mundos, componentes, flujo de datos
02 El laboratorio de build Sandbox, zig cc, recetas, CAS, grafo de dependencias
03 Hidratación y store Store content-addressed, hardlinks a FHS, patchelf, rollback
04 Overlay de experimentación overlayfs en caliente, try/commit/discard
05 Diario de mutaciones fanotify, log append-only, config-sin-ser-declarativa
06 Formato .swm Manifiesto de mutación compartible, esquema, firma
07 Bus de init y de agente /run/init.control, /run/agent.sock, protocolo
08 Integración de la IA El bucle agéntico, seguridad, intención → .swm
09 Modelo de confianza Reproducibilidad, verificar-no-confiar, log de transparencia
10 Roadmap Fases, MVP, primer entregable
11 Bootstrap from-scratch Track posterior: Stage 0/1/2, auto-alojamiento, semilla pinned
12 arje como init real del Stage 1 Contrato de runtime: seed card, hammerd supervisado, CRASHED real
16 harkaq: la jaula de hammer Landlock+seccomp sobre el bwrap actual; política = clausura; evidencia negativa de hermeticidad
26 atuq: el envoltorio Gecko Navegador propio como artefacto DERIVADO de firefox (no fork de fuente); la toolchain clang como puerta de PGO/LTO; qué se promete y qué no

Runbooks (operativos)

Runbook Para qué
Validar Stage 1 booteando en QEMU stage0stage1→initramfs→QEMU; criterios de éxito y troubleshooting

Architecture Decision Records (ADR)

Decisiones tomadas, con su contexto y consecuencias. Ver adr/.

# Decisión
0001 Rust para el tooling y daemons
0002 Validar sobre Alpine antes de la distro propia
0003 zig cc como compilador por defecto del lab
0004 No escribir nuestro propio Nix
0005 Hidratación por hardlinks
0006 Commits fijados, no HEAD vivo
0007 arje como init propio del track posterior
0008 Bootstrap en 3 stages, zig como semilla
0009 Código direccionado por contenido (estilo Unison)
0010 Arranque por grafo: el menú de boot como navegación del grafo
0011 Etapa Escritorio: campaña KDE Plasma 6
0012 El árbol de fuentes es caché y workspace a la vez — PENDIENTE, dilema abierto