Chimera Linux

• Chimera es un sistema operativo de propósito general basado en Linux que nace de la insatisfacción con el ecosistema Linux existente, y busca ofrecer funciones prácticas manteniendo la simplicidad y la transparencia
• Es una distribución construida desde cero, que busca combinar simplicidad conceptual y facilidad de uso mediante herramientas nuevas y herramientas de espacio de usuario (userland)
• Combina herramientas principales de FreeBSD, el toolchain LLVM y la biblioteca C Musl, adoptando una composición distinta a la de las distribuciones Linux habituales
• Aunque es una distribución binaria, ofrece un sistema de compilación de paquetes desde código fuente para admitir el empaquetado de software nuevo y builds personalizados
• Apunta a varias arquitecturas de procesador, como Intel/AMD, ARM AArch64, POWER y RISC-V, y busca ampliar la cobertura de paquetes mediante un sistema de build centralizado

---

Objetivos y enfoque de diseño

• Chimera es un sistema operativo de propósito general basado en Linux orientado a la simplicidad, la transparencia y una baja barrera de entrada
• Sin renunciar a la practicidad ni a una amplia funcionalidad, busca combinar simplicidad conceptual y comodidad mediante un diseño de software cuidadoso y de alta calidad
• Se puede consultar una explicación más detallada en Read more

Características principales de la distribución

• Herramientas alternativas de espacio de usuario

  • Combina las herramientas principales de FreeBSD, el toolchain LLVM y la biblioteca C Musl
  • Con esta combinación, busca ofrecer una experiencia de usuario y ventajas clave distintas a las de las distribuciones existentes

• Un sistema limpio y coherente

  • Busca eliminar restos heredados siempre que sea posible
  • Tiene como objetivo ser un sistema operativo moderno, de propósito general y con funciones completas

• Compilable desde código fuente

  • Chimera es, por defecto, una distribución binaria
  • Ofrece un sistema de compilación de paquetes desde código fuente para facilitar el empaquetado de software nuevo y la creación de paquetes personalizados

• Soporte para varias arquitecturas

  • Puede usarse en diversos procesadores, incluidos Intel/AMD, ARM AArch64, POWER y RISC-V
  • Un sistema de build centralizado permite que los paquetes estén disponibles en múltiples entornos

[GN⁺]

Comentarios en Hacker News

• Si llevas mucho tiempo usando herramientas GNU antiguas (GNU grep, sed, less, awk, find, tar, etc.), puede resultar mucho más frustrante de lo que uno esperaría
  En la era de UNIX había diferencias sutiles entre las herramientas de línea de comandos y eso era realmente doloroso; esa también fue una de las razones por las que las herramientas GNU se volvieron populares incluso antes de Linux
  Si las instalabas en cualquier UNIX como irix, hpux o sun, podías evitar diferencias extrañas como las de hpux grep frente a irix grep

  • Si la preocupación principal es la compatibilidad de API de las utilidades de CLI, como el espacio de usuario principal de Chimera viene de “FreeBSD, NetBSD, OpenBSD”, en teoría esta fricción sería parecida a la que hoy se tiene al usar BSD o Mac
  • He instalado GNU ports en Solaris varias veces
    Pero como no podía controlar los servidores AIX y HP-UX, los scripts que debían correr en todos los servidores tenía que mantenerlos compatibles con POSIX o escribirlos en Perl
  • Sigue pareciéndome raro y molesto que estos comandos no se instalen por defecto con nombres con prefijo
    A menudo awk se instala explícitamente como gawk o mawk, y estaría bien que también fuera común usar tar como bsdtar o gtar
    En nixpkgs es fácil especificar la versión exacta según el caso, pero en la mayoría de los demás entornos casi siempre se termina adivinando
  • Lo que más seguido me hacía tropezar entre distintas implementaciones de Un*x era tar(1), y curiosamente las diferencias más mínimas de awk(1) ya las tenía tan interiorizadas que no me afectaban
    Agarré la costumbre de instalar gtar de inmediato en cualquier caja Solaris donde tuviera permisos de root, especialmente por el “/” inicial dentro de los archivos del archivo
    Lo segundo más difícil era que en el trabajo usaba SunOS y HP/UX, y fuera de ahí Ultrix; lo peor fue las pocas veces que me topé con MS-DOS y no podía entender por qué no almacenaba en búfer la entrada del teclado
  • Estas diferencias todavía existen entre GNU Awk y el awk BSD de OSX

• Me gustan varias decisiones de diseño de Chimera Linux, en especial el sistema de empaquetado/compilación, pero como alguien que actualmente usa Alpine Linux en su PC principal, todavía me cuesta justificar musl
  Me gusta el software pequeño, simple y correcto, pero aun con esas ventajas, en mi experiencia musl es más lento que glibc y a veces se vuelve lento en puntos difíciles de predecir
  Al portar software a musl aparecen bastantes problemas menores, y la mayoría de los upstream no está muy dispuesta a aceptar parches, lo que termina convirtiéndose en una carga de mantenimiento para la distro
  También hay casos en que se rompe sutilmente en tiempo de ejecución; por ejemplo, los builds de Firefox de Alpine y Chimera muestran los mismos dos fallos que no aparecen en los builds oficiales de Mozilla ni en los de Arch Linux
  Al final uno termina dependiendo con demasiada frecuencia de un glibc chroot para tareas como compilar Mozilla Firefox

  • A veces, o incluso seguido, la razón de que musl sea lento puede deberse simplemente al asignador de memoria
    Si no recuerdo mal, Chimera usa un asignador distinto al asignador predeterminado de musl
  • En Alpine me pasó algo parecido
    musl termina causando muchos más problemas de los que vale
  • musl es en la práctica una elección obligatoria
    Por cómo está configurada la toolchain, las otras opciones no encajan bien, y glibc no se lleva bien con clang+compiler-rt
    glibc apenas hace poco empezó a poder compilarse con clang, pero todavía asume un runtime centrado en gcc, y de hecho glibc hace dlopen de libgcc_s
    Es muy probable que las demás libc sean mucho peores en términos de soporte
    Las dificultades de portar software a musl están algo exageradas
    La mayor parte del software ni siquiera necesita trabajo de portabilidad desde el principio, y los upstream tampoco son tan reacios como se dice
    Si hay fallos específicos de Firefox, me pregunto si se llegaron a reportar
    La lentitud suele ser más bien un problema del asignador predeterminado, pero eso no aplica a Chimera, y en algunos casos incluso podría ser más rápido
  • Además de Chimera, también valdría la pena probar Void Linux
  • Esto se sale un poco del tema, pero me pregunto si hay recursos o consejos recomendables para empezar a usar Alpine como sistema principal en la PC
    Tengo un equipo de System76 y me gustaría intentarlo alguna vez

• No estoy completamente de acuerdo, pero la postura de este proyecto sobre systemd es la más madura, matizada y equilibrada que he visto hasta ahora
  https://chimera-linux.org/docs/faq#what-is-the-projects-take...

  • Cambiando un poco de tema, me pregunto si existe alguna distribución que adopte por completo los componentes de systemd
    He trabajado mucho con servidores Linux y lo veo de forma muy pragmática: systemd ha hecho muchas cosas más fáciles, es configurable, tiene mantenimiento, se actualiza con frecuencia y está bien estandarizado
    Entiendo a la gente que quiere sentir que tiene el control, pero yo quiero una computadora confiable que funcione de una sola manera
    Al final, los servidores son algo que se trata como ganado
    Así que me gustaría ver algo como un experimento mental sacado del blog de Poettering: imágenes de sistema inmutables, arranque firmado y todo compuesto de arriba abajo con servicios de systemd
  • Este documento está realmente bien, pero la parte de que “systemd fue escrito para abusar deliberadamente de todas las extensiones no portables del mundo” debería estar más desglosada
    Habría que separar las funciones del kernel exclusivas de Linux de las extensiones en espacio de usuario, es decir, GNU frente a POSIX
    Usar funciones del kernel exclusivas de Linux como cgroups es algo bueno en sistemas Linux
    Antes era común que, cuando la carga subía, sshd se volviera lento y costara iniciar sesión, pero systemd configura el sistema para que esto ocurra menos
    En el caso de las extensiones en espacio de usuario, me habría gustado ver que systemd se considerara una ganancia neta por construirse sobre un conjunto más pequeño de herramientas y funciones, pero esa página no parece verlo así
    Me da curiosidad saber qué pasó de ese lado
  • Esa es también la postura de Void Linux
    Void no busca eso solo por ser systemd-free, sino por mantener la herencia Unix de componentes pequeños y débilmente acoplados, preservar razonablemente POSIX y la portabilidad (xbps), y ofrecer un sistema Linux en el que el usuario pueda elegir la libc
  • Apoyo bastante a systemd, pero antes de systemd estaba upstart de Canonical, que se usaba en Ubuntu
    systemd se creó para resolver las desventajas de upstart
    Es excelente que Chimera tenga como objetivo implementar por su cuenta, y a su manera, funciones de systemd que de verdad son útiles
    El mayor valor de systemd es que ya existen muchísimos archivos de servicio escritos, y en mi directorio ~/.config/systemd también tengo más de una decena de servicios
    Por eso creo que hay valor en ser compatible con systemd
  • Apoyo bastante a systemd, pero antes de systemd estaba upstart de Canonical, que se usaba en Ubuntu
    systemd se creó para resolver las desventajas de upstart

• Para entender la intención de Chimera Linux, hay que verlo como llevar Void Linux un paso más allá
  Su fundador antes era mantenedor de PPC en Void, y la elección de arquitecturas compatibles de Chimera también se entiende en ese contexto
  Según mi interpretación, Chimera es el tipo de sistema que querría un usuario de FreeBSD si tuviera que usar Linux
  Comparte el mismo compilador y espacio de usuario, y su sistema de compilación también resulta familiar
  Al principio la elección de GNOME parece extraña, pero Chimera intenta evitar mucho legado y desde el inicio está basado en PipeWire y Wayland

  • Se ve bastante bien, pero la elección de GNOME hace que me atraiga un poco menos
    Me pregunto si COSMIC de System76 llegará a consolidarse lo suficiente como para ser una opción a considerar algún día
    Estaría bien que surgiera un nuevo entorno de escritorio estable, práctico y centrado en la productividad y en el usuario
    Plasma tiene bastantes errores, GNOME no me parece ni práctico ni centrado en el usuario, y el resto da la impresión de carecer, en cierto grado, de pulido y mantenimiento
    System76 tiene dinero para invertir en esto y también parece tener la motivación para crear algo ajustado a las necesidades y sensibilidad de los usuarios, más que a los ideales de los desarrolladores, así que con el tiempo podría convertirse en un competidor importante

• Aunque se ve genial, me preocupa cada vez que veo algo que parece querer convertirse en una distro principal amigable para el usuario.
  Lo digo porque vi cuánto se esforzó Manjaro con objetivos como “simplicidad para las masas”, y aun así cuántos problemas sigue teniendo.
  Me pregunto si esto es una distro experimental o de hobby, o si apunta a algo que hasta una abuela pueda usar.
  Si tuviera que elegir esto o algo parecido en vez de BSD, lo consideraría bastante en serio, pero no lo veo como un reemplazo de Ubuntu o Windows.
  La simplicidad no es un factor que el usuario final común considere.
  Como desarrollador al que le gusta el software moderno y no le interesa mucho un entorno ligero y amigable para hackers, es muy poco probable que use algo con menos del 1% de cuota en escritorio.
  La gente que no es fanática de Arch/Kali/BSD/suckless tiene muy desarrollado ese sentido de “ah, esto se siente como cuando pienso en project cars, mejor me salgo”.
  Puede ser un proyecto excelente y valioso, pero atraer la atención de gente más allá de quienes disfrutan andar parchando cosas será una batalla difícil, y como este tipo de cosas toma mucho tiempo, si no se manejan las expectativas puede venir una gran decepción si no tiene éxito.
  Yo también empecé varios proyectos nuevos, y fue bastante duro pasar por el proceso de darme cuenta de que probablemente no iban a llegar a ningún lado pronto.
  Para lograr adopción masiva, parece que tendría que cambiar todo el ecosistema de software.
  Creo que habría problemas al portar aquí apps gigantes actuales como Steam o Chrome.
  Además, el enlace dinámico no parece encajar muy bien con una distro amigable para usuarios finales.
  Sin algo como Snap o Flatpak, me parece difícil ofrecer paquetes modernos, grandes y complejos de terceros sin problemas ocasionales de compatibilidad.
  Mi experiencia con distros basadas en enlace dinámico no ha sido terrible en general, pero siempre hubo uno u otro problema.
  También me pregunto si tiene sandboxing como AppArmor.

  • Si quieres algo que hasta una abuela pueda usar, entonces usa lo que usa todo el mundo.
    Chimera es una distro experimental de hobby, bastante de nicho y contraria a varios estándares.
    Siempre te vas a encontrar con problemas propios de Chimera.
    A cambio, tiene un sistema de compilación transparente que se puede tocar.
    Sobre Manjaro, no creo que sea difícil hacer una distro basada en Arch que funcione bien.
    Es solo que los desarrolladores de Manjaro no pueden hacerlo.
  • Si esperas que cualquier proyecto tenga éxito, por lo general vas a terminar decepcionado.
    Porque la mayoría de los proyectos no lo logran.
    Este tipo de cosas normalmente hay que hacerlas porque te son útiles o divertidas, no porque quieras volverlas exitosas.
    También me parecen bien los proyectos dirigidos a un público más específico y más de hobby.
    No todos los proyectos tienen que ser para todo el mundo.
  • El sitio web no da la impresión de que quiera ser un sistema operativo masivo.
    El marketing se parece más a “una distro ligera para hackers que usa musl, pero más simple que otras de la misma categoría”.
    Ojalá las distros Linux pudieran promocionarse entre usuarios actuales de Linux sin crear accidentalmente esta confusión en medios tecnológicos no centrados en Linux.
    Muchos usuarios de Linux no quieren que el sistema operativo se vuelva masivo.
    Porque si se vuelve popular, en muchos sentidos en realidad empeoraría.
    El “año del escritorio Linux” o hablar de debilidades del producto desde una visión estrecha comparándolo con Windows suele venir solo de usuarios nuevos y de medios tecnológicos.
    Fedora equilibra bastante bien este problema de imagen pública.
    En la primera página enfatiza que es para “todo tipo de desarrolladores y creadores”, pero Fedora Workstation en realidad está muy cerca de ser una distro fácil para casi cualquiera, así que en la página “Is Fedora For Me” explican que también puede servirle a gente no desarrolladora con curiosidad o entusiasmo por las computadoras en general.
    La cita también dice que Fedora fue hecho para usuarios de computadoras curiosos y con ganas de aprender, que puede no ser para todos, pero si quieres un Linux estable con soporte para hardware moderno y la disposición de contribuir a la comunidad FOSS, puede ser el sistema perfecto.
  • No estoy muy seguro de que Arch deba ir en ese grupo.
    En las estadísticas de Steam es más popular que Ubuntu, y eso sin contar SteamOS.

• “Un sistema simple no necesita requerir una configuración y personalización interminables para ser práctico” y un espacio de usuario alternativo no combinan muy bien.
  Porque cualquier espacio de usuario alternativo va a romper muchas cosas y al final va a requerir bastante trabajo de ajuste.

  • Sí son compatibles, pero no de la forma en que lo estás pensando.
    Chimera está diseñado para dar una configuración lista para funcionar con lo que sea que instales desde el repositorio.
    Si quieres un escritorio, lo instalas y funciona, sin necesidad de meter mano obligatoriamente para acomodar dbus, audio, Wi‑Fi/Bluetooth, etc.
    Lo más importante es que está construido de forma que la instalación sea consistentemente determinista y auditable.
    Sin depender de hooks complejos de shell ni de ese tipo de “trabajo de ajuste”, la mayoría de los paquetes se configuran con una simple extracción.
    Claro, si empiezas a arrastrar cosas como scripts de shell de terceros, puedes encontrarte con problemas de compatibilidad, pero puede que no pase tan seguido como crees.
  • Si es un reemplazo pero mayormente compatible, no parece que haya mucho que ajustar.
    Si es sustancialmente distinto, antes de ajustar lo principal será aprender.

• Chimera está siendo desarrollado por la persona que porteó Void Linux a PowerPC.
  https://web.archive.org/web/20230811081600/https://voidlinux...
  https://voidlinux.org

• Si no pareciera que se subió a la ola de entusiasmo exagerado por Wayland, probablemente me entusiasmaría mucho más.
  Parece que tomó muchas buenas decisiones: suficientemente simple sin ser demasiado simple, y con suficiente compatibilidad hacia atrás sin cargar con demasiado legado, pero personalmente Wayland todavía no encaja en ese lugar.

  • La buena noticia es que en el repositorio contrib hay una distribución completa de xorg, y no se espera que desaparezca pronto, quizá nunca.
  • Parece que todas las grandes empresas están 100% a favor de Wayland.
    Más allá de qué tan bueno sea Wayland en sí, romper compatibilidad con ellas parece una molestia.

• La perspectiva sobre SystemD es interesante.
  Personalmente me parece muy útil, pero uno de sus grandes defectos como proyecto, tomando prestada la expresión de Benno Rice, es que es agresivamente exclusivo de Linux.
  Aun así, la selección de software de Chimera en sí parece impedir el uso de systemd, y la frase del FAQ de “implementar por separado, a nuestra manera, las funciones útiles de systemd” lo resume bien.
  Me pregunto si sería posible portar SystemD a otras pilas de software.
  Más que reescribir SystemD de forma literal, parece bastante útil intentar portarlo, y eso quizá podría satisfacer tanto a quienes apoyan systemd como a quienes se oponen.
  Claro, si aparece un competidor que haga lo mismo, eso también podría llevar a innovaciones en el futuro.

  • SystemD avanza demasiado rápido, tiene posturas demasiado fuertes y un alcance demasiado amplio.
    Por eso, incluso la gente que tendría la capacidad de portarlo probablemente preferiría usar un reemplazo parcial como este proyecto, en vez de ponerse a hacer ese trabajo.
  • Nadie va a usar SystemD en Mac o Windows, así que no entiendo por qué sería importante que sea exclusivo de Linux.

• No sé si al fundador le gustaría, pero mi forma favorita de usar Chimera en escritorio ahora mismo es instalar dentro un distrobox de Arch Linux.
  Así puedo disfrutar del sistema base de Chimera y al mismo tiempo tener acceso inmediato a todo el repositorio de Arch y al catálogo de AUR.
  Las aplicaciones que dan problemas con MUSL también se pueden ejecutar fácilmente con glibc dentro de distrobox, y como Distrobox reenvía Wayland, las apps gráficas también funcionan muy bien.
  La idea es ejecutar de forma nativa en Chimera tanto como sea posible, pero a veces simplemente hay que terminar otra cosa.
  El repositorio de Chimera no incluye distrobox, pero sí viene con podman, así que en general eso resuelve el problema.
  En cualquier caso funciona bien, y ahora mismo también estoy escribiendo esto desde Chimera.
  Algunas personas prefieren Flatpak, pero a mí me sigue gustando más la gestión de paquetes a la antigua.
  Flatpak me parece demasiado pesado y opaco, aunque sé que puede haber opiniones distintas.
  Distrobox definitivamente encaja mejor para trabajo de consola.
  También es una herramienta práctica para levantar sandboxes rápidas y entornos de desarrollo temporales.
  Arch es solo una preferencia personal; igual podría haber elegido Void, Debian o cualquier otra cosa.