Durabilidad

Chinaski está diseñado para sobrevivir a las tendencias, las modas del software, el desgaste de plataformas, el vendor lock-in, incluso el propio internet. Esta página explica qué significa eso en términos concretos: URLs duraderas, contenido duradero y formatos de salida duraderos, y qué los hace así.

URLs duraderas

Los enlaces son promesas. Chinaski las cumple así:

Los renombrados nunca rompen enlaces. Cuando renombras una page o post publicada, o cambias el prefijo de URL del blog, los redirects para cada dirección antigua se generan en el siguiente rebuild, automáticamente. Las URLs viejas siguen funcionando mientras tu site exista.
Un dominio se aplica con un redirect integrado: la grafía de tu host que no elegiste (www o apex) envía a los visitantes a la que sí elegiste, preservando la página.
Las URLs son archivos. Cada page existe estáticamente como un directorio HTML en disco. Los lectores llegan a ellas a través de cualquier servidor web capaz de servir un archivo, el sistema de contenido no necesita estar vivo, ni siquiera en ejecución, para que el site funcione. No hay esquemas de URLs propios de un framework que puedan podrirse.
Las traducciones y los enlaces alternativos permanecen coherentes. Cada idioma tiene su propio sitemap, sus reglas de redirect y sus etiquetas hreflang cruzadas, la descubribilidad sobrevive a los rediseños de la estructura de menús por encima de ella.

Contenido duradero

Un archivo, sin servidores. Todo el contenido, pages, posts, metadatos de media, cuentas, historial de auditoría, vive en un único archivo de base de datos SQLite. Respaldarlo es copiar un archivo; no hay nada que redescubrir o reconfigurar durante una restauración. Sin credenciales, sin rutas de red, sin ceremonias de migración entre versiones menores.
El historial viene incluido, no se compra. Cada guardado toma una snapshot de revisión; cada mutación de contenido se registra en un audit log; los envíos de formularios y sus metadatos se retienen según tus reglas de retención. Restaurar hasta ayer es una operación soportada que no requiere arqueología forense.
Los respaldos se verifican, no se asumen. Cada archivo se somete a una smoke test después de crearse, y cada ejecución programada registra su resultado en un log, éxito, fallo y resultado de verificación por respaldo.
Los drafts sobreviven a los crashes. Las ediciones sin guardar viven del lado del servidor mientras trabajas, así que cerrar una pestaña del navegador o perder una sesión tras un largo tramo de escritura no se come la tarde.
Nunca se requiere internet. La instalación puede hacerse desde un bundle offline; después de eso, sin telemetría, sin phone-home de licencia, sin dependencias de CDN. Si la red desaparece, tu site existe en el disco y el admin en tu servidor, continuidad planeada, no accidental. Hay un modo de despliegue "fin del mundo": el servidor responde HTTP plano para siempre, nada que renovar, nada que caduque.
Las dependencias son aburridas a propósito. Todo lo que el software necesita viene en la release estable del OS, así que las reescrituras mayores de librerías de terceros no pueden evaporar el comportamiento. La lista de dependencias es corta por diseño, nueve módulos, mantenidos deliberadamente pequeños.
Hasta la documentación viaja con la instancia. Los artículos de ayuda visibles en el área de administración se guardan en la misma base de datos, así que viajan con tus respaldos.

Formatos de salida duraderos

La salida publicada del site se apega a los formatos que la web nunca ha deprecado:

HTML plano, con estilos genéricos, sin runtime requerido, el site público tiene cero JavaScript en tiempo de ejecución, por construcción y no por política. Nada a lo que un tracker pueda agarrarse; nada que romperse cuando un proveedor de terceros cambia sus condiciones.
Feeds y archivos estándar, regenerados en cada build: sitemap.xml, feeds RSS, robots.txt, un archivo de política de seguridad (security.txt) y archivos de reglas de redirect en formatos portables que otros servidores pueden usar.
Datos estructurados (JSON-LD) escritos directamente en las páginas como HTML plano, legibles por décadas, por buscadores o scripts que aún no has escrito.
Extras opcionales offline-first: un service worker y una página offline son parte de la salida generada cuando las features de PWA están activadas.
El servidor de administración mismo puede sobrevivir sin internet . HTTP plano, sin certificado que renovar, sin servicio externo que falle.

Lo que deliberadamente no hacemos

La honestidad sobre los trade-offs es parte del mismo principio:

No hay un builder visual de páginas drag-and-drop. El contenido del body usa un editor de texto enriquecido; todo lo demás son formularios estructurados. Un builder visual está en el roadmap; hoy no existe.
No hay ecosistema ni marketplace de plugins, sin hooks, sin registros, sin cadenas de código de terceros que cambien silenciosamente lo que tu site hará el próximo año.
La base de datos es SQLite, un archivo por instancia. Un nivel multi-tenant con Postgres está en el roadmap, no enviado hoy; la ruta de migración aún no está definida.
Tú eres dueño del servidor, de la base de datos y de los respaldos. La durabilidad aquí significa tu responsabilidad, no nuestra custodia.

La apuesta silenciosa de fondo

Debajo de todo esto hay una sola apuesta: las herramientas estables sobreviven a las ingeniosas. El lenguaje en que el sistema está escrito (Perl) no ha roto compatibilidad en décadas de versiones menores; el motor SQL (SQLite) trata tu base de datos como un archivo; la salida son archivos HTML en disco; la interfaz de administración evita los frameworks que reescriben sus modismos cada dos años. Es aburrido a propósito, un site construido sobre Chinaski debería seguir renderizando bien en una década sin mantenimiento, y el contenido debería estar exactamente donde lo dejaste.