1# `takana-os.net` — el sitio del proyecto
2
3Una sola página, autocontenida, en dos idiomas y dos temas. **No le pide nada a terceros:** las
4tipografías de la marca (Chivo e IBM Plex, las dos SIL OFL) viajan acá en `fuentes/`, subconjuntos
5`latin` y `latin-ext`, 154 KB en total. Un sitio sobre no depender de binarios ajenos que cargara
6las fuentes de Google en cada visita sería una contradicción barata.
7
8| | |
9|---|---|
10| `index.html` | la página entera: CSS y JS adentro, el símbolo como `<symbol>` SVG inline |
11| `fuentes.css` + `fuentes/` | las ocho caras `@font-face`, servidas de acá |
12| `simbolo.svg` | el favicon — el martillo tocapu 7×7, derivado de `docs/marca/simbolo-fondo-claro.svg` |
13
14## La sección «las decisiones»
15
16Diez fichas, cada una con tres lecturas de lo mismo: contra qué se decide, qué implica por dentro,
17y qué quiere decir sin jerga. **No son opinión: cada una sale de un ADR o de una decisión ya tomada
18en `docs/`** — fuentes clavadas (ADR 0006), `zig cc` (0003), `arje` de init (0007) y el arranque por
19grafo (0010), multi-origen con índice firmado (0014), imágenes ajenas enjauladas (0015), y las de
20Wayland-only y PipeWire, que viven en los frentes de escritorio y audio.
21
22⚠ **Si una decisión cambia, esta página miente hasta que alguien la toque.** Es el precio de
23explicar el diseño en una landing y no en un doc generado: se gana claridad y se paga en
24mantenimiento. Las fichas se armaron con un guion de un solo uso — la página es la fuente, no hay
25generador que mantener.
26
27La paleta y la tipografía salen de **`docs/marca/README.md`** y no se inventan acá. La única
28desviación, deliberada: en tema claro el texto de acento usa un brasa oscurecido (`#9E3F16`), porque
29el `#DF6B2A` de la marca sobre alpaca da 2,9:1 y no se lee. Las combinaciones de la página están
30medidas: ninguna baja de 4,5:1.
31
32## El instalador: `/descargas/` vive FUERA del repo
33
34`https://takana-os.net/descargas/takana-instalador.run` es **un fichero que trae todo adentro**:
35cabecera `sh` + un `tar.gz` pegado detrás con el binario `takana`, el instalador que corre en RAM, su
36kernel y el censo del terreno. Se baja, se le da permiso y se corre; no baja nada más.
37
38⚠ **No está en el repo, y no puede estarlo.** Son 137 MiB: en git serían 137 MiB para siempre en
39cada clon, y además **el espejo de GitHub rechaza cualquier fichero de más de 100 MiB** — o sea que
40el `push` se rompería y nadie relacionaría la causa con el sitio. Vive en `/work/sergio/descargas`,
41que está en `sdc` (255 G) y no en la raíz de 5,8 G, que se llena y tira la caja entera.
42
43```sh
44scripts/instalador-paquete.sh # arma el paquete (y comprueba su coherencia)
45scripts/instalador-autoextraible.sh # lo convierte en UN fichero, y lo desempaqueta para probarlo
46cp work/takana-instalador.run /work/sergio/descargas/
47( cd /work/sergio/descargas && sha256sum takana-instalador.run > takana-instalador.run.sha256 )
48```
49
50El `.sha256` que se publica al lado es **el del fichero entero**, para comprobar la descarga
51(`sha256sum -c takana-instalador.run.sha256`). Es distinto del que el `.run` lleva adentro, que es
52el **del payload** y lo verifica él solo antes de desempaquetar (`./takana-instalador.run --sha256`
53lo imprime).
54
55⚠ **El hash NO se escribe en `index.html`, y es deliberado.** La primera versión lo traía pegado en
56la página y habría empezado a mentir en el primer rebuild — que es el modo de fallo que este mismo
57README ya avisa para la sección «las decisiones». La página muestra el comando; el número lo sirve
58el fichero de al lado, que se regenera junto al `.run`.
59
60⚠ `/descargas` queda **fuera del `encode`** del vhost: el `.run` ya viene comprimido, y volver a
61comprimirlo por HTTP gasta CPU en cada descarga sin ahorrar un byte.
62
63### La imagen USB, para cuando el salto no se puede
64
65`takana-instalador-usb.img` (519 MiB) es **el mismo instalador por otro camino**: mismo árbol, mismo
66censo, mismas guardas. Se graba con `dd` y arranca por la ruta de medios removibles del firmware.
67
68⚠ **No lleva el instalador en la ESP, y no es un capricho:** el cuelgue del primer viaje a metal fue
69un initrd de ~100 MiB cargado por el EFI-stub ([ADR 0010](../../docs/adr/0010-arranque-grafo-mirada.md)
70paso 2), y el del instalador son ~122 MiB. El USB usa el patrón que **sí** está probado —el de un
71disco instalado—: la ESP lleva el kernel y un pivote de 736 KiB, y el pivote encuentra la ext4 por
72`LABEL=takana-medio` y hace `switch_root`. La etiqueta NO es `hammer-root` a propósito: si el medio
73se llamara igual que la raíz de un sistema instalado, el pivote podría montar el disco del usuario
74en vez del USB, y el que pierde es el disco.
75
76```sh
77scripts/instalador-usb.sh # arma work/takana-instalador-usb.img
78scripts/instalador-usb-test.sh --instalar # lo arranca en OVMF y lo contesta por el serial
79cp work/takana-instalador-usb.img /work/sergio/descargas/
80( cd /work/sergio/descargas && sha256sum takana-instalador-usb.img > takana-instalador-usb.img.sha256 )
81```
82
83**Está probado de punta a punta, no sólo servido:** `VIA_RUN=1 scripts/metal-salto-test.sh` mete el
84fichero publicado en una VM con `linux-metal-kexec`, lo corre, y comprueba sobre el DISCO que se
85verificó solo, se desempaquetó, saltó e instaló — 13 comprobaciones, con el `bootmgfw.efi` del
86vecino byte a byte igual y la tabla de particiones sin cambiar.
87
88Y el USB, `scripts/instalador-usb-test.sh --instalar`: **arranca por firmware de verdad** (OVMF por
89`pflash`, sin `-kernel`, que es la única forma de probar la tabla, la ESP, el stub y el nombre
90`\initramfs.cpio.gz` que el cmdline horneado exige), **contesta el menú tecleando por el serial** y
91comprueba el disco destino. 12 en verde.
92
93⚠ El arnés corre con `-vga none`, y eso decide qué rama del código se prueba: sin pantalla el
94instalador detecta el `vtconsole` `dummy` y se va al serial. **Con** pantalla —el caso del usuario—
95la pregunta sale por `tty0`. Las dos ramas existen porque el cmdline HORNEADO del kernel pone `tty0`
96primero y `ttyS0` último, o sea que `/dev/console` es el serial: en un portátil sin puerto serie, sin
97esta detección, el censo y la pregunta se irían a un sitio que no existe y el arranque parecería
98colgado.
99
100## Las dos direcciones que publica
101
102- **código** → `https://git.gioser.net/sergio/takana` (público; `git clone` por HTTPS)
103- **paquetes** → `https://takana-os.net/repo/`, que es el MISMO `/srv/repo` firmado que sirve
104 `repo.gioser.net`. Comprobado: `takana install age --repo https://repo.gioser.net --trust ./trust`
105 responde `release: trusted (by release)`.
106
107Y **desde el 2026-09-21 se puede mirar el repo sin construir nada**, que antes no se podía:
108`repo list` y `repo verify` aceptan la misma lista de orígenes que `install`. Hasta ese día sólo
109miraban directorios locales y ante una URL respondían «repo vacío» **con salida 0** — 173 paquetes
110leídos como ninguno.
111
112```sh
113takana repo list --repo https://takana-os.net/repo # 173 paquete(s)
114takana repo verify --repo https://takana-os.net/repo --trust ./trust # release: trusted
115```
116
117## Cómo se sirve
118
119Caddy, en la caja `takana`, vhost `takana-os.net, www.takana-os.net`. La raíz es
120**`/work/sergio/takana/web/takana-os.net`**, el árbol de trabajo vivo: *publicar es guardar el
121fichero*. No lo refresca `publicar-webs.sh` a propósito — un `pull` sobre el árbol compartido mueve
122HEAD bajo los pies de otro agente (CLAUDE.md §2 ter).
123
124Este README **no se sirve**: son notas de operación, y el matcher del vhost las 404ea.
125
126Los bloques, por si hay que rehacer la caja (`caddy validate` → `arjectl restart caddy`, **nunca**
127`caddy reload`: el Caddyfile lleva `admin off`, SDD 28 §6.14):
128
129```caddyfile
130takana-os.net, www.takana-os.net {
131 import acceso
132 @comprimible not path /descargas/*
133 encode @comprimible gzip zstd
134
135 redir /descargas /descargas/ permanent
136 handle_path /descargas/* {
137 root * /work/sergio/descargas
138 file_server browse
139 }
140
141 redir /repo /repo/ permanent
142 handle_path /repo/* {
143 root * /srv/repo
144 file_server browse
145 }
146
147 handle {
148 root * /work/sergio/takana/web/takana-os.net
149 @oculto path /.* */.* /README.md
150 respond @oculto 404
151 file_server
152 }
153}
154
155git.takana-os.net {
156 import acceso
157 redir https://git.gioser.net{uri} permanent
158}
159
160takana.gioser.net {
161 import acceso
162 redir https://takana-os.net{uri} permanent
163}
164```
165
166`scripts/servidor/publicar-webs.sh` comprueba los cuatro: los dos que sirven ficheros por sha
167contra el disco, y los dos que redirigen por destino.
168
169## Los nombres
170
171| nombre | qué hace | estado |
172|---|---|---|
173| `takana-os.net`, `www` | el sitio | ✅ con certificado de Let's Encrypt (2026-09-21) |
174| `takana-os.net/repo/` | el repo de paquetes, el mismo `/srv/repo` | ✅ |
175| `takana-os.net/descargas/` | el instalador en UN fichero, y la imagen USB (`/work/sergio/descargas`) | ✅ (2026-09-23) |
176| `takana.gioser.net` | **301 → `takana-os.net`** | ✅ |
177| `git.takana-os.net` | **301 → `git.gioser.net`** | ⏳ vhost puesto, **falta el registro A** |
178
179`git.takana-os.net` sólo redirige, y es deliberado: gitea tiene UN `ROOT_URL` con el que arma cada
180enlace y cada URL de clon que muestra, así que colgarlo de un segundo nombre daría un sitio que se
181contradice —entrás por uno y te ofrece clonar del otro— y moverlo de verdad rompe los clones y el
182CI que ya apuntan al viejo.
183
184Los registros van a `2.29.29.217`, la IP de la caja:
185
186```
187takana-os.net. A 2.29.29.217 ✅ puesto
188www.takana-os.net. A 2.29.29.217 ✅ puesto
189git.takana-os.net. A 2.29.29.217 ⏳ falta
190```
191
192El certificado sale solo en la primera petición tras el DNS — y **tarda unos segundos más que el
193primer `curl`**: si da error, reintentar antes de ir a mirar logs (SDD 28 §6.14). Si el nombre ya
194resolvía cuando Caddy arrancó pero el certificado no llegó, **reiniciar caddy fuerza el reintento**
195sin esperar el backoff: fue lo que hizo falta acá.
README.md
takana-os.net — el sitio del proyecto
Una sola página, autocontenida, en dos idiomas y dos temas. No le pide nada a terceros: las
tipografías de la marca (Chivo e IBM Plex, las dos SIL OFL) viajan acá en fuentes/, subconjuntos
latin y latin-ext, 154 KB en total. Un sitio sobre no depender de binarios ajenos que cargara
las fuentes de Google en cada visita sería una contradicción barata.
| |
index.html | la página entera: CSS y JS adentro, el símbolo como <symbol> SVG inline |
fuentes.css + fuentes/ | las ocho caras @font-face, servidas de acá |
simbolo.svg | el favicon — el martillo tocapu 7×7, derivado de docs/marca/simbolo-fondo-claro.svg |
La sección «las decisiones»
Diez fichas, cada una con tres lecturas de lo mismo: contra qué se decide, qué implica por dentro,
y qué quiere decir sin jerga. No son opinión: cada una sale de un ADR o de una decisión ya tomada
en docs/ — fuentes clavadas (ADR 0006), zig cc (0003), arje de init (0007) y el arranque por
grafo (0010), multi-origen con índice firmado (0014), imágenes ajenas enjauladas (0015), y las de
Wayland-only y PipeWire, que viven en los frentes de escritorio y audio.
⚠ Si una decisión cambia, esta página miente hasta que alguien la toque. Es el precio de
explicar el diseño en una landing y no en un doc generado: se gana claridad y se paga en
mantenimiento. Las fichas se armaron con un guion de un solo uso — la página es la fuente, no hay
generador que mantener.
La paleta y la tipografía salen de docs/marca/README.md y no se inventan acá. La única
desviación, deliberada: en tema claro el texto de acento usa un brasa oscurecido (#9E3F16), porque
el #DF6B2A de la marca sobre alpaca da 2,9:1 y no se lee. Las combinaciones de la página están
medidas: ninguna baja de 4,5:1.
El instalador: /descargas/ vive FUERA del repo
https://takana-os.net/descargas/takana-instalador.run es un fichero que trae todo adentro:
cabecera sh + un tar.gz pegado detrás con el binario takana, el instalador que corre en RAM, su
kernel y el censo del terreno. Se baja, se le da permiso y se corre; no baja nada más.
⚠ No está en el repo, y no puede estarlo. Son 137 MiB: en git serían 137 MiB para siempre en
cada clon, y además el espejo de GitHub rechaza cualquier fichero de más de 100 MiB — o sea que
el push se rompería y nadie relacionaría la causa con el sitio. Vive en /work/sergio/descargas,
que está en sdc (255 G) y no en la raíz de 5,8 G, que se llena y tira la caja entera.
scripts/instalador-paquete.sh # arma el paquete (y comprueba su coherencia)
scripts/instalador-autoextraible.sh # lo convierte en UN fichero, y lo desempaqueta para probarlo
cp work/takana-instalador.run /work/sergio/descargas/
( cd /work/sergio/descargas && sha256sum takana-instalador.run > takana-instalador.run.sha256 )
El .sha256 que se publica al lado es el del fichero entero, para comprobar la descarga
(sha256sum -c takana-instalador.run.sha256). Es distinto del que el .run lleva adentro, que es
el del payload y lo verifica él solo antes de desempaquetar (./takana-instalador.run --sha256
lo imprime).
⚠ El hash NO se escribe en index.html, y es deliberado. La primera versión lo traía pegado en
la página y habría empezado a mentir en el primer rebuild — que es el modo de fallo que este mismo
README ya avisa para la sección «las decisiones». La página muestra el comando; el número lo sirve
el fichero de al lado, que se regenera junto al .run.
⚠ /descargas queda fuera del encode del vhost: el .run ya viene comprimido, y volver a
comprimirlo por HTTP gasta CPU en cada descarga sin ahorrar un byte.
La imagen USB, para cuando el salto no se puede
takana-instalador-usb.img (519 MiB) es el mismo instalador por otro camino: mismo árbol, mismo
censo, mismas guardas. Se graba con dd y arranca por la ruta de medios removibles del firmware.
⚠ No lleva el instalador en la ESP, y no es un capricho: el cuelgue del primer viaje a metal fue
un initrd de ~100 MiB cargado por el EFI-stub (ADR 0010
paso 2), y el del instalador son ~122 MiB. El USB usa el patrón que sí está probado —el de un
disco instalado—: la ESP lleva el kernel y un pivote de 736 KiB, y el pivote encuentra la ext4 por
LABEL=takana-medio y hace switch_root. La etiqueta NO es hammer-root a propósito: si el medio
se llamara igual que la raíz de un sistema instalado, el pivote podría montar el disco del usuario
en vez del USB, y el que pierde es el disco.
scripts/instalador-usb.sh # arma work/takana-instalador-usb.img
scripts/instalador-usb-test.sh --instalar # lo arranca en OVMF y lo contesta por el serial
cp work/takana-instalador-usb.img /work/sergio/descargas/
( cd /work/sergio/descargas && sha256sum takana-instalador-usb.img > takana-instalador-usb.img.sha256 )
Está probado de punta a punta, no sólo servido: VIA_RUN=1 scripts/metal-salto-test.sh mete el
fichero publicado en una VM con linux-metal-kexec, lo corre, y comprueba sobre el DISCO que se
verificó solo, se desempaquetó, saltó e instaló — 13 comprobaciones, con el bootmgfw.efi del
vecino byte a byte igual y la tabla de particiones sin cambiar.
Y el USB, scripts/instalador-usb-test.sh --instalar: arranca por firmware de verdad (OVMF por
pflash, sin -kernel, que es la única forma de probar la tabla, la ESP, el stub y el nombre
\initramfs.cpio.gz que el cmdline horneado exige), contesta el menú tecleando por el serial y
comprueba el disco destino. 12 en verde.
⚠ El arnés corre con -vga none, y eso decide qué rama del código se prueba: sin pantalla el
instalador detecta el vtconsole dummy y se va al serial. Con pantalla —el caso del usuario—
la pregunta sale por tty0. Las dos ramas existen porque el cmdline HORNEADO del kernel pone tty0
primero y ttyS0 último, o sea que /dev/console es el serial: en un portátil sin puerto serie, sin
esta detección, el censo y la pregunta se irían a un sitio que no existe y el arranque parecería
colgado.
Las dos direcciones que publica
- código →
https://git.gioser.net/sergio/takana (público; git clone por HTTPS)
- paquetes →
https://takana-os.net/repo/, que es el MISMO /srv/repo firmado que sirve
repo.gioser.net. Comprobado: takana install age --repo https://repo.gioser.net --trust ./trust
responde release: trusted (by release).
Y desde el 2026-09-21 se puede mirar el repo sin construir nada, que antes no se podía:
repo list y repo verify aceptan la misma lista de orígenes que install. Hasta ese día sólo
miraban directorios locales y ante una URL respondían «repo vacío» con salida 0 — 173 paquetes
leídos como ninguno.
takana repo list --repo https://takana-os.net/repo # 173 paquete(s)
takana repo verify --repo https://takana-os.net/repo --trust ./trust # release: trusted
Cómo se sirve
Caddy, en la caja takana, vhost takana-os.net, www.takana-os.net. La raíz es
/work/sergio/takana/web/takana-os.net, el árbol de trabajo vivo: publicar es guardar el
fichero. No lo refresca publicar-webs.sh a propósito — un pull sobre el árbol compartido mueve
HEAD bajo los pies de otro agente (CLAUDE.md §2 ter).
Este README no se sirve: son notas de operación, y el matcher del vhost las 404ea.
Los bloques, por si hay que rehacer la caja (caddy validate → arjectl restart caddy, nunca
caddy reload: el Caddyfile lleva admin off, SDD 28 §6.14):
takana-os.net, www.takana-os.net {
import acceso
@comprimible not path /descargas/*
encode @comprimible gzip zstd
redir /descargas /descargas/ permanent
handle_path /descargas/* {
root * /work/sergio/descargas
file_server browse
}
redir /repo /repo/ permanent
handle_path /repo/* {
root * /srv/repo
file_server browse
}
handle {
root * /work/sergio/takana/web/takana-os.net
@oculto path /.* */.* /README.md
respond @oculto 404
file_server
}
}
git.takana-os.net {
import acceso
redir https://git.gioser.net{uri} permanent
}
takana.gioser.net {
import acceso
redir https://takana-os.net{uri} permanent
}
scripts/servidor/publicar-webs.sh comprueba los cuatro: los dos que sirven ficheros por sha
contra el disco, y los dos que redirigen por destino.
Los nombres
| nombre | qué hace | estado |
takana-os.net, www | el sitio | ✅ con certificado de Let's Encrypt (2026-09-21) |
takana-os.net/repo/ | el repo de paquetes, el mismo /srv/repo | ✅ |
takana-os.net/descargas/ | el instalador en UN fichero, y la imagen USB (/work/sergio/descargas) | ✅ (2026-09-23) |
takana.gioser.net | 301 → takana-os.net | ✅ |
git.takana-os.net | 301 → git.gioser.net | ⏳ vhost puesto, falta el registro A |
git.takana-os.net sólo redirige, y es deliberado: gitea tiene UN ROOT_URL con el que arma cada
enlace y cada URL de clon que muestra, así que colgarlo de un segundo nombre daría un sitio que se
contradice —entrás por uno y te ofrece clonar del otro— y moverlo de verdad rompe los clones y el
CI que ya apuntan al viejo.
Los registros van a 2.29.29.217, la IP de la caja:
takana-os.net. A 2.29.29.217 ✅ puesto
www.takana-os.net. A 2.29.29.217 ✅ puesto
git.takana-os.net. A 2.29.29.217 ⏳ falta
El certificado sale solo en la primera petición tras el DNS — y tarda unos segundos más que el
primer curl: si da error, reintentar antes de ir a mirar logs (SDD 28 §6.14). Si el nombre ya
resolvía cuando Caddy arrancó pero el certificado no llegó, reiniciar caddy fuerza el reintento
sin esperar el backoff: fue lo que hizo falta acá.