Construido sobre Perl

Toda la arquitectura de Chinaski, un CMS en Perl, un builder de sitios estáticos en Perl y una base de datos SQLite, descansa sobre una apuesta deliberada: la tecnología aburrida sobrevive a la tecnología emocionante en producción. Esta página explica el razonamiento detrás de esa elección, con las palabras del propio proyecto, y lo que significa para ti como operador.

Un lenguaje estable por décadas

Perl 5 es aburrido en el buen sentido. La interfaz binaria no se ha roto entre versiones menores en décadas. Las dependencias no se renombran solas. El lenguaje viene de serie en Debian, sin necesidad de añadir un compilador encima. Un programa Perl escrito en 2005 sigue funcionando hoy, en la opinión del proyecto, esa es la elección de ingeniería correcta para software de infraestructura que debe poder depurarse a las 2 de la mañana por alguien que no lo escribió.

El argumento de la superficie de ataque también favorece la estabilidad: un lenguaje fijo con dependencias empaquetadas por Debian es más pequeño y más auditable que un stack cuyo árbol de node_modules o requirements.txt cambia debajo de ti entre versiones.

Lo que el proyecto mismo usa

La aplicación de administración (Mojolicious), el builder estático (Template Toolkit), la capa de base de datos embebida (DBI con DBD::SQLite) y el procesamiento de imágenes (Imager, sin shell-out a ImageMagick) son las elecciones prácticas. Las piezas de seguridad también son estándar: hash de contraseñas con bcrypt mediante Crypt::Passphrase, cifrado AES-256-GCM para credenciales almacenadas y firma de sesiones HMAC vía CryptX, y DateTime con DateTime::TimeZone usando la base de datos de zonas horarias de la IANA para una programación correcta.

Donde un subsistema necesita capacidad opcional, el importador de Markdown, por ejemplo, esos módulos se cargan de forma diferida y solo en el momento en que se necesitan. Un sitio al que le falta uno de ellos arranca y sirve todo lo demás; solo esa ruta se degrada, con un mensaje claro en el área de administración.

La apuesta de las dependencias

La mayoría de los sistemas de gestión de contenido acumulan superficie, plugins, integraciones, endpoints de analítica, assets de CDN. Cada adición apuesta a que la capacidad añadida vale la complejidad y la superficie de ataque añadidas, y como dice el README del proyecto, la mayoría de esas apuestas ganan en demos y pierden en producción. Chinaski hace la apuesta contraria.

Resultados concretos de esa apuesta, tal como los documenta el proyecto:

• Una lista de dependencias pequeña contenida por completo en Debian stable, una instalación fresca se resuelve enteramente desde paquetes del sistema, sin compilación.
• Cero JavaScript en tiempo de ejecución en la salida pública, una garantía estructural y no una promesa de política. El servidor web Caddy sirve archivos estáticos desde el disco; la aplicación Perl nunca está en la ruta de peticiones públicas, así que no existe ningún mecanismo por el cual un beacon pueda enviarse junto con tus páginas.
• Compatible con air-gap por defecto, sin telemetría, sin validación de licencia contra un servidor externo, sin fuentes ni iconos de CDN. Una vez instalado, Chinaski no necesita internet. Todas las integraciones capaces de salir hacia fuera (comprobaciones de actualizaciones, SMTP, webhooks, respaldos en la nube) vienen desactivadas hasta que las enciendas deliberadamente.

Escrito con IA, funciona sin IA

Chinaski fue escrito con asistencia de IA (Claude Code y Kimi) y se espera mantenerlo de la misma manera. La estabilidad de Perl hace esto inusualmente auditable: el lenguaje no ha cambiado sus modismos en treinta años, así que el código generado se lee con claridad de principio a fin. La postura del proyecto es que la fluidez en IA es la habilidad de contribución relevante, la fluidez en Perl no es necesaria para mantener Chinaski.

Trade-offs honestos

El minimalismo tiene costos reales, que el proyecto declara sin rodeos:

• No hay ecosistema de plugins, sin arquitectura de hooks, sin registro de plugins, sin marketplace de temas.
• La base de datos es SQLite, no Postgres (Postgres está planeado para un futuro nivel multi-tenant).
• Sigue siendo trabajo operativamente involucrado: tú eres dueño del servidor, de la base de datos y de los respaldos.

Si administras muchos sitios de clientes y quieres stacks idénticos que puedas reconstruir con confianza, ese intercambio resulta atractivo. Si necesitas el ecosistema que trae una plataforma más grande, eso es exactamente lo que Chinaski se niega a ofrecer.

Lo que significa para ti

El beneficio práctico de la elección del lenguaje aparece en las operaciones, no en el marketing:

• Instala una vez, reinicia menos. El stack se distribuye como paquetes de la distro, sin agitación de frameworks entre actualizaciones del sistema.
• Lee el código. La implementación vive en un número pequeño de archivos, escritos con comentarios primero y estructurados de modo que las correcciones no requieran arqueología, los treinta años de modismos estables del lenguaje mantienen todo sencillo.
• Salida auditable. Las afirmaciones relevantes para la seguridad (manejo de sesiones, cifrado en reposo, sin telemetría) se aplican todas en lugares únicos del código, nada que auditar a lo largo de cinco directorios.
• El core tiene licencia MIT; los futuros módulos comerciales Pro están planeados para usar archivos de licencia firmados localmente sin phone-home, en línea con la promesa de air-gap.