{"id":125413,"date":"2025-05-22T15:05:15","date_gmt":"2025-05-22T13:05:15","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/predstavlena-konczepcziya-distributiva-aerynos-s-obosnovaniem-arhitekturnyh-reshenij"},"modified":"2025-05-22T15:05:15","modified_gmt":"2025-05-22T13:05:15","slug":"predstavlena-konczepcziya-distributiva-aerynos-s-obosnovaniem-arhitekturnyh-reshenij","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/predstavlena-konczepcziya-distributiva-aerynos-s-obosnovaniem-arhitekturnyh-reshenij","title":{"rendered":"Se presenta la conceptualizaci\u00f3n de la distribuci\u00f3n AerynOS con una justificaci\u00f3n de las decisiones arquitect\u00f3nicas.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Los desarrolladores de AerynOS, anteriormente conocido como SerpentOS, publicaron un art\u00edculo detallado que revela la concepci\u00f3n y la implementaci\u00f3n t\u00e9cnica del proyecto, justificando las decisiones arquitect\u00f3nicas tomadas. El l\u00edder del proyecto, Ikey Doherty, enfatiza que AerynOS no es solo \"otro distribuidor de Linux\", sino una plataforma, un fundamento y un conjunto de herramientas creadas seg\u00fan una visi\u00f3n clara. <\/p>\n
La idea principal del proyecto se formula en forma de pregunta: \"\u00bfQu\u00e9 pasar\u00eda 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 un distribuidor. El proyecto se basa en la experiencia de los autores en el desarrollo de otros distribuidores, incluidos Solus y Clear Linux. <\/p>\n
Entre las principales decisiones t\u00e9cnicas de AerynOS se destacan: <\/p>\n
\n
El uso de la herramienta LLVM en lugar de GNU, usando libc++ y compiler-rt por defecto. Los desarrolladores explican esta decisi\u00f3n no solo como una preferencia por LLVM, sino como una elecci\u00f3n estrat\u00e9gica para garantizar diagn\u00f3sticos de mejor calidad, as\u00ed como la correcci\u00f3n y portabilidad de los paquetes. Sin embargo, el sistema utiliza glibc en lugar de musl, lo cual es una elecci\u00f3n consciente a favor de la compatibilidad y el rendimiento.\n
Seg\u00fan se indica en el art\u00edculo: \"La ventaja de glibc sobre musl en rendimiento est\u00e1 bien documentada, especialmente para cargas de trabajo intensivas en c\u00e1lculos y aplicaciones que requieren un rendimiento \u00f3ptimo en multiprocesamiento\". Los creadores subrayan que su objetivo es construir un sistema \u00fatil y funcional para una variedad de escenarios de aplicaci\u00f3n. <\/p>\n
La concepci\u00f3n de \"statelessness\" (sin estado) proh\u00edbe que los paquetes contengan archivos fuera del directorio \/usr. Como explican los desarrolladores, este enfoque obliga a proporcionar valores razonables por defecto en todos los niveles y elimina \"los horribles conflictos de fusi\u00f3n de tres v\u00edas al actualizar paquetes\". No hay conflictos, porque todo en \/etc y \/var pertenece al usuario, mientras que \/usr es exclusivamente del sistema. Esta concepci\u00f3n fue desarrollada en tiempos de Clear Linux y Solus y ha evolucionado en AerynOS.\n
Las actualizaciones at\u00f3micas: cada transacci\u00f3n de moss es at\u00f3mica. El sistema crea r\u00e1pidamente un nuevo \u00e1rbol \/usr utilizando enlaces duros desde un cach\u00e9 desduplicado. Despu\u00e9s de la creaci\u00f3n y preparaci\u00f3n exitosa, el nuevo \u00e1rbol se sustituye at\u00f3micamente. De hecho, la transacci\u00f3n preparada se intercambia con el directorio real \/usr utilizando renameat2 con la bandera RENAME_EXCHANGE. La actualizaci\u00f3n se realiza completamente o no se realiza en absoluto, sin estados intermedios.\n
La gesti\u00f3n de carga basada en proyectos blsforme y disks-rs. La caracter\u00edstica de este enfoque es que el sistema forma din\u00e1micamente los par\u00e1metros para la l\u00ednea de comandos del n\u00facleo, leyendo los superbloques de los dispositivos del sistema de archivos ra\u00edz, por lo que en AerynOS no hay un archivo de configuraci\u00f3n que contenga el par\u00e1metro \u00abroot=\u00bb. Adem\u00e1s, el identificador de transacci\u00f3n moss se codifica en la l\u00ednea de comandos del n\u00facleo y se procesa durante el arranque temprano en initramfs. \u00abEn pocas palabras, esto significa que cada n\u00facleo est\u00e1 correctamente sincronizado con el sistema de archivos ra\u00edz correspondiente, y la reversi\u00f3n es barata, simple y accesible directamente desde el men\u00fa de arranque\u00bb, explican los desarrolladores. Otra ventaja es la ausencia de \/etc\/default\/grub, y si el ESP se borra, moss puede restaurarlo desde cero.\n
El formato de paquetes .stone es un formato binario propietario con un encabezado independiente de la versi\u00f3n para garantizar cambios futuros. Cada paquete .stone contiene cuatro tipos espec\u00edficos de datos (payload), cada uno de los cuales puede evolucionar de manera independiente gracias a la versionado:\n
\n
Carga de contenido (Content payload) \u2014 un bloque secuencial de datos desduplicados, es decir, el propio contenido de los archivos del paquete.\n
Carga de \u00edndice (Index payload) \u2014 contiene los desplazamientos para la carga de contenido, indexados por el hash XXH128 del contenido (se planea cambiar a Blake3). Esto permite localizar y extraer datos de manera eficiente.\n
Carga de dise\u00f1o (Layout payload) \u2014 describe el dise\u00f1o previsto del sistema de archivos al aplicar el paquete, es decir, d\u00f3nde y qu\u00e9 archivos deben instalarse.\n
Metadatos (Metadata payload) \u2014 una secuencia de registros de metadatos estrictamente tipados y etiquetados, como el nombre del paquete, las funcionalidades proporcionadas, etc. <\/ul>\n<\/ul>\n
La compresi\u00f3n de todas las cargas se realiza mediante Zstd, lo que garantiza un excelente rendimiento de descompresi\u00f3n mientras se mantiene una buena tasa de compresi\u00f3n. El proceso de instalaci\u00f3n de .stone es radicalmente diferente al de otros sistemas. En lugar de instalar directamente los archivos, el paquete se almacena en cach\u00e9 y su contenido se entrelaza en un almacenamiento com\u00fan con direccionamiento por contenido (CAS). Los metadatos y la informaci\u00f3n del dise\u00f1o se almacenan por separado y se utilizan al crear la transacci\u00f3n. Este enfoque asegura la atomicidad de las actualizaciones y la capacidad de revertir, ya que cada transacci\u00f3n crea una nueva ra\u00edz de divisi\u00f3n, en lugar de modificar la existente. <\/p>\n
Los desarrolladores se\u00f1alan que el enfoque actual de emulaci\u00f3n del control imperativo de paquetes es 'totalmente sin sentido' y 'de hecho introduce m\u00e1s errores de los que resuelve'. Dado que para cada transacci\u00f3n se crea un nuevo sistema de archivos ra\u00edz, en el futuro se planea crear un nuevo grafo para cada transacci\u00f3n, abandonando los cambios integrados a favor de un enfoque declarativo, similar a Gentoo o Nix. <\/p>\n
Otra explicaci\u00f3n interesante es sobre la inmutabilidad. Los creadores se\u00f1alan que a menudo se describe a AerynOS como un sistema operativo inmutable, pero 'eso no es del todo cierto'. Aunque cada transacci\u00f3n resulta en un nuevo \u00e1rbol \/usr y los cambios locales no se guardan, el sistema no es inmutable en el sentido de acceso solo de lectura. En el futuro se planea implementar una verdadera inmutabilidad del sistema sin necesidad de reiniciar utilizando erofs y overlayfs. <\/p>\n
Actualmente, AerynOS se est\u00e1 desarrollando activamente, ya se est\u00e1n lanzando im\u00e1genes ISO con el entorno GNOME, es apto para juegos (con soporte para controladores NVIDIA, Steam, Flatpak), y tiene usuarios reales que se\u00f1alan la estabilidad y la innovaci\u00f3n del sistema. Seg\u00fan los desarrolladores, el proyecto est\u00e1 en fase alfa y no est\u00e1 exento de problemas, pero ya representa un sistema integral que 'simplemente funciona'. \n Fuente: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"