Los desarrolladores de AerynOS, anteriormente conocido como SerpentOS, han publicado un artículo extenso que revela detalles sobre la concepción y la implementación técnica del proyecto, justificando las decisiones arquitectónicas tomadas. El líder del proyecto, Ikey Doherty, enfatiza que AerynOS no es simplemente "otra distribución de Linux", sino una plataforma, una base y un conjunto de herramientas creadas con una visión clara.
La idea principal del proyecto se formula como una pregunta: "¿Qué pasaría si un sistema operativo se comportara como una infraestructura moderna?". AerynOS se presenta como la respuesta a esta pregunta: un sistema construido desde cero, en lugar de seguir el modelo tradicional de mutaciones integradas dentro de una distribución. El proyecto se basa en la experiencia de los autores en el desarrollo de otras distribuciones, incluyendo Solus y Clear Linux.
Entre las principales decisiones técnicas de AerynOS se destacan:
- El uso de la herramienta LLVM en lugar de GNU, usando libc++ y compiler-rt por defecto. Los desarrolladores explican esta decisión no solo como una preferencia por LLVM, sino como una elección estratégica para garantizar diagnósticos de mejor calidad, así como la corrección y portabilidad de los paquetes. Sin embargo, el sistema utiliza glibc en lugar de musl, lo cual es una elección consciente a favor de la compatibilidad y el rendimiento.
Como se señala en el artículo: "La ventaja de glibc sobre musl en términos de rendimiento está bien documentada, especialmente para cargas de trabajo intensivas en cálculos y aplicaciones que requieren un rendimiento óptimo de multitarea". Los creadores enfatizan que su objetivo es construir un sistema funcional y utilizable para una variedad de escenarios de aplicación.
- El concepto de "sin estado" (statelessness) implica que los paquetes no deben contener ningún archivo fuera del directorio /usr. Como explican los desarrolladores, este enfoque obliga a establecer valores razonables por defecto en todos los niveles y elimina "horribles conflictos de fusión de tres vías al actualizar paquetes". No hay conflictos porque todo en /etc y /var pertenece al usuario, mientras que /usr es exclusivamente del sistema. Este concepto fue desarrollado durante la era de Clear Linux y Solus, y en AerynOS ha sido llevado aún más lejos.
- Las actualizaciones atómicas: cada transacción de moss es atómica. El sistema crea rápidamente un nuevo árbol /usr utilizando enlaces duros de un caché desduplicado. Tras la creación y preparación exitosa, el nuevo árbol se reemplaza de forma atómica. La transacción preparada se intercambia con el directorio real /usr utilizando renameat2 con la bandera RENAME_EXCHANGE. La actualización se ejecuta completamente o no se ejecuta en absoluto, sin estados intermedios.
- Gestión de arranque basada en los proyectos blsforme y disks-rs. La característica de este enfoque es que el sistema forma dinámicamente los parámetros para la línea de comandos del núcleo, leyendo los superbloques de los dispositivos del sistema de archivos raíz, por lo que en AerynOS no hay archivo de configuración que contenga el parámetro 'root='. Además, el identificador de transacción de moss se codifica en la línea de comandos del núcleo y se procesa durante el arranque temprano en initramfs. 'En resumen, esto significa que cada núcleo está sincronizado correctamente con el sistema de archivos raíz correspondiente, y la reversión es económica, simple y accesible directamente desde el menú de arranque', explican los desarrolladores. Otra ventaja es la ausencia de /etc/default/grub, y si se borra el ESP, moss puede restaurarlo desde cero.
- El formato de paquetes .stone es un formato binario propio de paquetes con un encabezado independiente de la versión para permitir cambios futuros. Cada paquete .stone contiene cuatro tipos específicos de datos (payload), cada uno de los cuales puede evolucionar de manera independiente gracias a la versionado:
- Carga de contenido (Content payload): un bloque secuencial de datos desduplicados, es decir, el contenido mismo de los archivos del paquete.
- Carga del índice (Index payload): contiene las posiciones de la carga de contenido, indexadas por el hash XXH128 del contenido (se planea la transición a Blake3). Esto permite encontrar y extraer datos de manera eficiente.
- Carga del diseño (Layout payload): describe el diseño esperado del sistema de archivos al aplicar el paquete, es decir, dónde y qué archivos deben instalarse.
- Metadatos (Metadata payload): una secuencia de registros de metadatos estrictamente tipados y etiquetados, como el nombre del paquete, las capacidades proporcionadas, etc.
La compresión de todas las cargas se realiza mediante Zstd, lo que garantiza un excelente rendimiento de descompresión mientras se mantiene una buena relación de compresión. El proceso de «instalación» de .stone es radicalmente diferente de otros sistemas. En lugar de realizar una instalación directa de archivos, el paquete se almacena en caché y su contenido se entrelaza en un repositorio común con direccionamiento basado en el contenido (CAS). Los metadatos y la información sobre el diseño se almacenan por separado y se utilizan al crear una transacción. Este enfoque asegura la atomicidad de las actualizaciones y la posibilidad de reversión, ya que cada transacción crea un nuevo segmento raíz en lugar de modificar uno existente.
Los desarrolladores señalan que el enfoque actual de emular la gestión imperativa de paquetes es «totalmente absurdo» y «de hecho introduce más errores de los que soluciona». Dado que para cada transacción se crea un nuevo sistema de archivos raíz, en el futuro se planea crear un nuevo grafo para cada transacción, abandonando los cambios integrados en favor de un enfoque declarativo, similar a Gentoo o Nix.
Otra aclaración interesante tiene que ver con la inmutabilidad (immutability). Los creadores señalan que a menudo AerynOS se describe como un OS inmutable, pero «esto no es del todo cierto». Aunque cada transacción conduce a un nuevo árbol /usr y los cambios locales no se guardan, el sistema no es inmutable en el sentido de acceso solo de lectura. Se planea en el futuro implementar una verdadera inmutabilidad del sistema sin necesidad de reiniciar, utilizando erofs y overlayfs.
Actualmente, AerynOS está en activo desarrollo, ya publica imágenes ISO con el entorno GNOME, es apto para juegos (soporte para drivers NVIDIA, Steam, Flatpak), tiene usuarios reales que destacan la estabilidad y la innovación del sistema. Según los desarrolladores, el proyecto se encuentra en una fase alfa y no está exento de problemas, pero ya representa un sistema integral que «simplemente funciona».
Fuente: opennet.ru
