Chimera Linux

 (chimera-linux.org)
1 Punkte von GN⁺ 2023-12-18 | 1 Kommentare | Auf WhatsApp teilen
  • Chimera ist ein universelles Linux-basiertes OS, das aus Unzufriedenheit mit dem bestehenden Linux-Ökosystem entstanden ist und praktische Funktionen bieten will, ohne Einfachheit und Transparenz aufzugeben
  • Die Distribution wurde von Grund auf neu aufgebaut und strebt mit neuen Tools und Userland-Werkzeugen zugleich konzeptionelle Einfachheit und Benutzerfreundlichkeit an
  • Bei den Kernwerkzeugen setzt sie auf eine Kombination aus FreeBSD, beim Toolchain auf LLVM und bei der C-Bibliothek auf Musl und wählt damit eine andere Zusammenstellung als typische Linux-Distributionen
  • Obwohl Chimera eine Binärdistribution ist, bietet es ein Build-System für Quellpakete, das das Paketieren neuer Software und Custom Builds unterstützt
  • Ziel sind mehrere Prozessorarchitekturen wie Intel/AMD, ARM AArch64, POWER und RISC-V; über ein zentrales Build-System soll die Paketabdeckung erweitert werden

Ziele und Designrichtung

  • Chimera ist ein universelles Linux-basiertes Betriebssystem, das auf Einfachheit, Transparenz und eine niedrige Einstiegshürde abzielt
  • Ohne auf Praxisnähe und einen großen Funktionsumfang zu verzichten, verfolgt es durch sorgfältiges, hochwertiges Softwaredesign zugleich konzeptionelle Einfachheit und Komfort
  • Weitere Details gibt es unter Read more

Zentrale Merkmale der Distribution

  • Alternative Userland-Werkzeuge

    • Kombiniert die Kernwerkzeuge von FreeBSD, den LLVM-Toolchain und die Musl-C-Bibliothek
    • Diese Kombination soll eine andere Nutzererfahrung und wesentliche Vorteile gegenüber bestehenden Distributionen bieten

  • Sauberes und konsistentes System

    • Will Altlasten dort entfernen, wo es möglich ist
    • Ziel ist ein modernes, universelles und voll funktionsfähiges Betriebssystem

  • Aus dem Quellcode baubar

    • Chimera ist grundsätzlich eine Binärdistribution
    • Es bietet ein Build-System für Quellpakete, um das Paketieren neuer Software und Custom-Paket-Builds zu erleichtern

  • Unterstützung mehrerer Architekturen

    • Nutzbar auf verschiedenen Prozessoren wie Intel/AMD, ARM AArch64, POWER und RISC-V
    • Ein zentrales Build-System macht Pakete in mehreren Umgebungen verfügbar

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-12-18
Meinungen auf Hacker News

  • Wer lange GNU-Tools (GNU grep, sed, less, awk, find, tar usw.) verwendet hat, könnte das deutlich frustrierender finden als erwartet.
    In der UNIX-Ära gab es zwischen den einzelnen Kommandozeilen-Tools subtile Unterschiede, was wirklich mühsam war; genau deshalb wurden GNU-Tools schon vor Linux populär.
    Wenn man sie auf irgendeinem UNIX wie irix, hpux, sun usw. installierte, konnte man merkwürdige Unterschiede wie zwischen hpux grep und irix grep vermeiden.

    • Wenn die API-Kompatibilität von CLI-Utilities die zentrale Sorge ist, dann wird Chimeras zentraler Userland-Bereich laut Aussage von „FreeBSD, NetBSD, OpenBSD“ bereitgestellt; diese Reibung dürfte also theoretisch der ähneln, die man heute bei BSD oder Mac erlebt.
    • Ich habe mehrmals GNU-Ports auf Solaris installiert.
      Allerdings hatte ich über Aix- und HP-UX-Server keine Kontrolle, daher mussten Skripte, die auf allen Servern laufen sollten, POSIX-kompatibel bleiben oder in Perl geschrieben werden.
    • Ich finde es immer noch seltsam und ärgerlich, dass solche Befehle nicht standardmäßig unter Namen mit Präfix installiert werden.
      awk wird häufig explizit als gawk oder mawk installiert; bei tar wäre es schön, wenn Bezeichnungen wie bsdtar und gtar allgemein üblich wären.
      In nixpkgs ist es leicht, je nach Situation die exakte Version anzugeben, aber in den meisten anderen Umgebungen ist es eher ein Raten.
    • Was mir zwischen verschiedenen Un*x-Implementierungen oft ein Bein gestellt hat, war tar(1); merkwürdigerweise hatte ich mich an die winzigen Unterschiede von awk(1) gewöhnt.
      Auf Solaris-Kisten mit root-Rechten habe ich mir angewöhnt, sofort gtar zu installieren, besonders wegen führender „/“ in Archiven.
      Am zweitmühsamsten war es, im Job mit SunOS und HP/UX und außerhalb mit Ultrix zu arbeiten; am schlimmsten waren ein paar Begegnungen mit MS-DOS, bei denen ich nicht verstand, warum Tastatureingaben nicht gepuffert wurden.
    • Solche Unterschiede gibt es auch heute noch zwischen GNU Awk und dem BSD awk von OSX.

  • Viele Designentscheidungen von Chimera Linux gefallen mir, besonders das Packaging-/Build-System, aber als jemand, der aktuell Alpine Linux auf dem Haupt-PC nutzt, finde ich musl weiterhin schwer zu rechtfertigen.
    Ich mag kleine, einfache und korrekte Software, aber trotz dieser Vorteile ist musl meiner Erfahrung nach langsamer als glibc und wird manchmal an schwer vorhersehbaren Stellen langsam.
    Beim Portieren von Software auf musl gibt es ziemlich viele Kleinigkeiten, und die meisten Upstreams sind zurückhaltend beim Annehmen von Patches, was Wartungsaufwand für die Distribution erzeugt.
    Es gibt auch Fälle, in denen zur Laufzeit subtil etwas kaputtgeht; zum Beispiel zeigen die Firefox-Builds von Alpine und Chimera dieselben zwei Abstürze, die es in den offiziellen Mozilla-Builds oder den Arch-Linux-Builds nicht gibt.
    Am Ende greift man für Aufgaben wie Mozilla-Firefox-Builds viel zu oft auf ein glibc chroot zurück.

    • Manchmal, oder sogar oft, kann der Grund dafür, dass musl langsam ist, schlicht der Speicher-Allokator sein.
      Soweit ich mich erinnere, verwendet Chimera einen anderen Allokator als den Standard-Allokator von musl.
    • Bei Alpine war es ähnlich.
      musl führte am Ende zu deutlich mehr Problemen, als es wert war.
    • musl ist praktisch eine notwendige Wahl.
      Angesichts der Toolchain-Konfiguration passen andere Optionen nicht gut, und glibc harmoniert nicht mit clang+compiler-rt.
      glibc lässt sich zwar erst seit Kurzem mit clang bauen, setzt aber weiterhin eine gcc-zentrierte Runtime voraus; tatsächlich dlopen't glibc libgcc_s.
      Andere libcs sind in puncto Support wahrscheinlich noch deutlich schlechter.
      Die Schwierigkeit, Software auf musl zu portieren, wird zum Teil übertrieben.
      Die meiste Software braucht von vornherein keine Portierung, und Upstreams sind auch nicht so zurückhaltend.
      Falls es bestimmte Firefox-Abstürze gibt, würde mich interessieren, ob sie gemeldet wurden.
      Langsamkeit ist meist ein Problem des Standard-Allokators, was auf Chimera nicht zutrifft; in manchen Fällen kann es sogar schneller sein.
    • Neben Chimera ist auch Void Linux einen Versuch wert.
    • Etwas off topic, aber ich würde gern wissen, ob es empfehlenswerte Ressourcen oder Tipps für den Einstieg mit Alpine als Haupt-PC gibt.
      Ich habe ein System76-Gerät und würde es gern einmal ausprobieren.

  • Ich stimme nicht vollständig zu, aber die Haltung dieses Projekts zu systemd ist die reifste, differenzierteste und ausgewogenste, die ich bisher gesehen habe
    https://chimera-linux.org/docs/faq#what-is-the-projects-take...

    • Etwas off topic, aber ich frage mich, ob es umgekehrt eine Distribution gibt, die systemd-Komponenten vollständig übernimmt
      Aus der Sicht von jemandem, der viel mit Linux-Servern gearbeitet hat und das sehr pragmatisch sieht, hat systemd vieles einfacher gemacht; es ist konfigurierbar, wird gepflegt, häufig aktualisiert und ist ordentlich standardisiert
      Ich verstehe auch Menschen, die ein Gefühl von Kontrolle haben wollen, aber ich möchte einen zuverlässigen Computer, der auf eine bestimmte Weise funktioniert
      Schließlich behandelt man Server wie Nutzvieh
      Deshalb fände ich etwas gut, das dem Gedankenexperiment aus Poetterings Blog ähnelt: unveränderliche System-Images, signierter Boot und von oben bis unten aus systemd-Diensten aufgebaut
    • Dieses Dokument ist wirklich gut, aber die Aussage „systemd wurde geschrieben, um absichtlich alle nicht portablen Erweiterungen der Welt zu missbrauchen“ sollte stärker aufgeschlüsselt werden
      Man sollte zwischen Linux-spezifischen Kernel-Funktionen und Userland-Erweiterungen unterscheiden, also GNU gegenüber POSIX
      Linux-spezifische Kernel-Funktionen wie cgroups zu nutzen, ist auf Linux-Systemen eine gute Sache
      Früher kam es häufig vor, dass sshd bei hoher Last langsam wurde und man sich nur schwer einloggen konnte; systemd richtet das System so ein, dass solche Fälle seltener auftreten
      Bei Userland-Erweiterungen hätte ich mir gewünscht, dass systemd als Nettogewinn gesehen wird, weil es auf kleineren Werkzeugen und Funktionssätzen aufbaut, aber auf dieser Seite scheint das nicht der Fall zu sein
      Ich frage mich, was dort passiert ist
    • Das ist auch die Haltung von Void Linux
      Void macht das nicht einfach nur, um systemd-free zu sein, sondern um das Unix-Erbe kleiner, lose gekoppelter Komponenten zu bewahren, POSIX und Portabilität in vernünftigem Maß zu erhalten (xbps) und ein Linux-System anzubieten, bei dem Nutzer ihre libc wählen können
    • Ich bin ein großer Befürworter von systemd, aber vor systemd gab es auch Canonicals upstart, das in Ubuntu verwendet wurde
      systemd wurde entwickelt, um die Schwächen von upstart zu beheben
      Chimeras Ziel, tatsächlich nützliche systemd-Funktionen unabhängig und auf eigene Weise zu implementieren, ist großartig
      Der größte Wert von systemd liegt darin, dass sehr viele Service-Dateien geschrieben wurden, und auch in meinem Verzeichnis ~/.config/systemd liegen ein gutes Dutzend Services
      Deshalb sehe ich Wert darin, mit systemd kompatibel zu sein
    • Ich bin ein großer Befürworter von systemd, aber vor systemd gab es auch Canonicals upstart, das in Ubuntu verwendet wurde
      systemd wurde entwickelt, um die Schwächen von upstart zu beheben

  • Um die Absicht von Chimera Linux zu verstehen, kann man es als Void Linux einen Schritt weiter gedacht betrachten
    Der Gründer war früher PPC-Maintainer bei Void, und auch die Auswahl der von Chimera unterstützten Architekturen ist in diesem Kontext zu verstehen
    Nach meiner Interpretation ist Chimera das System, das sich ein FreeBSD-Nutzer wünschen würde, wenn er Linux verwenden müsste
    Es teilt denselben Compiler und dasselbe Userland, und auch das Build-System fühlt sich vertraut an
    Anfangs wirkt die Wahl von GNOME seltsam, aber Chimera versucht, viel Legacy zu vermeiden, und basiert von Anfang an auf PipeWire und Wayland

    • Sieht ziemlich gut aus, aber die Wahl von GNOME macht es für mich etwas weniger attraktiv
      Ich frage mich, ob System76s COSMIC irgendwann so weit etabliert sein wird, dass es in Betracht kommt
      Es wäre schön, wenn eine stabile, praktische und produktivitäts- sowie nutzerorientierte neue Desktop-Umgebung aufkäme
      Plasma ist ziemlich buggy, GNOME fühlt sich weder praktisch noch nutzerorientiert an, und dem Rest scheint es in gewissem Maß an Feinschliff und Wartung zu fehlen
      System76 hat das Geld, um hier zu investieren, und scheint auch die passende Motivation zu haben, etwas zu bauen, das sich eher an den Bedürfnissen und dem Empfinden der Nutzer orientiert als an den Idealen der Entwickler; daher könnte es mit der Zeit zu einem wichtigen Wettbewerber werden

  • Cool, aber ich mache mir jedes Mal Sorgen, wenn ich sehe, dass etwas offenbar eine benutzerfreundliche Mainstream-Distribution werden will.
    Ich habe gesehen, wie sehr Manjaro sich mit Zielen wie „Einfachheit für die breite Masse“ bemüht hat – und wie viele Probleme es trotzdem noch gibt.
    Ich frage mich, ob das eine experimentelle oder Hobby-Distribution ist, oder ob sie darauf abzielt, etwas zu sein, das auch die Oma benutzen kann.
    Wenn ich es im Vergleich zu BSD auswählen müsste, würde ich diese oder etwas Ähnliches ziemlich ernsthaft in Betracht ziehen, aber es wirkt nicht wie ein Ersatz für Ubuntu oder Windows.
    Einfachheit ist kein Faktor, den normale Endnutzer berücksichtigen.
    Als Entwickler, der moderne Software mag und wenig Interesse an einer leichtgewichtigen, hackerfreundlichen Umgebung hat, ist es sehr unwahrscheinlich, dass ich etwas verwende, das nicht einmal mindestens 1 % Desktop-Marktanteil hat.
    Wer kein Arch-/Kali-/BSD-/suckless-Enthusiast ist, hat ein sehr ausgeprägtes Gefühl von „Ah, das fühlt sich an wie damals, als ich über ein Projekt-Auto nachgedacht habe – da sollte ich lieber aussteigen“.
    Es kann ein großartiges und wertvolles Projekt sein, aber es wird ein harter Kampf, Aufmerksamkeit jenseits von Bastlern zu bekommen; solche Dinge verschlingen viel Zeit, und wenn man die Erwartungen nicht im Griff behält, kann es eine große Enttäuschung werden, wenn es nicht erfolgreich ist.
    Ich habe selbst schon mehrere neue Projekte gestartet, und der Prozess, zu erkennen, dass sie in absehbarer Zeit wahrscheinlich nirgendwohin führen, war ziemlich hart.
    Um Mainstream-Adoption zu erreichen, müsste sich vermutlich das gesamte Software-Ökosystem selbst ändern.
    Ich denke, es wird Probleme geben, heutige große Apps wie Steam oder Chrome darauf zu portieren.
    Außerdem scheint dynamisches Linken nicht besonders gut zu einer endnutzerfreundlichen Distribution zu passen.
    Ohne so etwas wie Snap oder Flatpak halte ich es für schwierig, aktuelle, große und komplexe Third-Party-Pakete ohne gelegentliche Kompatibilitätsprobleme bereitzustellen.
    Meine Erfahrung mit Distributionen auf Basis dynamischen Linkens war insgesamt nicht schrecklich, aber es gab immer irgendwelche Probleme.
    Ich frage mich auch, ob es Sandboxing wie AppArmor gibt.

    • Wenn man etwas will, das auch die Oma benutzen kann, sollte man das verwenden, was alle benutzen.
      Chimera ist eine experimentelle Hobby-Distribution, ziemlich nischig und verstößt gegen mehrere Standards.
      Man wird immer wieder auf Chimera-spezifische Probleme stoßen.
      Dafür gibt es ein transparentes Build-System, mit dem man herumspielen kann.
      Was Manjaro angeht: Ich glaube nicht, dass es schwierig ist, eine gut funktionierende Distribution auf Arch-Basis zu bauen.
      Die Manjaro-Entwickler können es einfach nicht.
    • Wenn man erwartet, dass irgendein Projekt erfolgreich wird, wird man meist enttäuscht.
      Denn die meisten Projekte werden nicht erfolgreich.
      Solche Dinge sollte man im Allgemeinen tun, weil sie einem selbst nützlich sind oder Spaß machen, nicht weil man sie zum Erfolg führen will.
      Ich finde auch Projekte in Ordnung, die auf eine eher hobbymäßige, spezifische Zielgruppe ausgerichtet sind.
      Nicht jedes Projekt muss für alle sein.
    • Die Website vermittelt nicht den Eindruck, ein Mainstream-Betriebssystem werden zu wollen.
      Das Marketing geht eher in Richtung „eine leichtgewichtige Hacker-Distribution mit musl, aber einfacher als andere in derselben Kategorie“.
      Es wäre schön, wenn Linux-Distributionen sich an bestehende Linux-Nutzer vermarkten könnten, ohne nebenbei in nicht-Linux-orientierten Tech-Medien solche Verwirrung auszulösen.
      Viele Linux-Nutzer wollen nicht, dass das Betriebssystem groß durchstartet.
      Denn wenn es sehr populär würde, würde es in vielerlei Hinsicht tatsächlich schlechter werden.
      Die „Year of the Linux Desktop“-Erzählung oder eng gefasste Produkt-Schwächen im Vergleich zu Windows kommen normalerweise nur von neuen Nutzern und Tech-Medien.
      Fedora balanciert dieses Problem der öffentlichen Wahrnehmung ziemlich gut aus.
      Auf der Startseite wird betont, dass es für „Entwickler und Kreative aller Art“ gedacht ist, aber Fedora Workstation ist tatsächlich fast eine Distribution, die für nahezu alle einfach ist; auf der Seite „Is Fedora For Me“ wird daher erklärt, dass es auch zu Nicht-Entwicklern passen kann, die allgemein neugierig oder begeistert von Computern sind.
      Das Zitat sagt ebenfalls, dass Fedora für neugierige, lernbereite Computer-Nutzer gemacht ist und vielleicht nicht für jeden passt, aber das perfekte System sein kann, wenn man stabiles Linux mit Unterstützung für aktuelle Hardware möchte und bereit ist, zur FOSS-Community beizutragen.
    • Ich bin mir nicht sicher, ob man Arch in diese Gruppe einordnen sollte.
      In den Steam-Statistiken ist es beliebter als Ubuntu, und SteamOS ist dabei nicht einmal enthalten.

  • „Ein einfaches System muss keine endlose Konfiguration und Anpassung verlangen, um praktisch zu sein“ und alternativer Userland passen nicht gut zusammen.
    Denn jedes alternative Userland wird vieles kaputtmachen und am Ende umfangreiche Anpassungsarbeit nötig machen.

    • Beides ist vereinbar, aber nicht so, wie du es dir vorstellst.
      Chimera ist so konzipiert, dass alles, was man aus den Repositories installiert, mit einer sofort funktionierenden Konfiguration kommt.
      Wenn man einen Desktop will, installiert man ihn und er funktioniert; man muss nicht zwingend Hand anlegen, um dbus, Audio, Wi-Fi/Bluetooth usw. passend einzurichten.
      Der wichtigste Punkt ist, dass die Installation konsistent deterministisch und auditierbar aufgebaut ist.
      Sie verlässt sich nicht auf komplizierte Shell-Hooks oder solche „Fix-up“-Arbeiten, und die meisten Pakete werden durch reines Entpacken eingerichtet.
      Natürlich kann man auf Kompatibilitätsprobleme stoßen, wenn man Dinge wie Third-Party-Shell-Skripte hereinholt, aber das passiert möglicherweise nicht so oft, wie man denkt.
    • Wenn es eine Alternative ist, aber weitgehend kompatibel, sieht es nicht nach viel Anpassungsarbeit aus.
      Wenn es sich tatsächlich unterscheidet, wird es vor dem Anpassen vor allem etwas zu lernen geben.

  • Chimera wurde von der Person entwickelt, die Void Linux auf PowerPC portiert hat.
    https://web.archive.org/web/20230811081600/https://voidlinux...
    https://voidlinux.org

  • Ich wäre wohl viel gespannter darauf gewesen, wenn es nicht so ausgesehen hätte, als würde es auf den Wayland-Hype aufspringen.
    Es scheint viele gute Entscheidungen getroffen zu haben: einfach genug, ohne zu simpel zu sein, und mit genügend Abwärtskompatibilität, ohne zu viel Legacy mitzuschleppen. Aber persönlich passt Wayland für mich noch nicht in genau diese Position.

    • Die gute Nachricht ist: Im contrib-Repository gibt es eine vollständige xorg-Distribution, und es wird nicht erwartet, dass sie bald verschwindet – vielleicht sogar nie.
    • Es wirkt so, als stünden alle großen Unternehmen zu 100 % hinter Wayland.
      Unabhängig davon, wie gut Wayland selbst ist, scheint es mühsam, die Kompatibilität mit ihnen zu brechen.

  • Die Sicht auf SystemD ist interessant.
    Persönlich halte ich es für sehr nützlich, aber einer der großen Nachteile als Projekt ist, um Benno Rice zu zitieren, dass es aggressiv Linux-exklusiv ist.
    Allerdings scheint Chimeras Software-Auswahl selbst die Nutzung von systemd zu verhindern, und der Satz in der FAQ, man wolle „nützliche systemd-Funktionen unabhängig auf eigene Weise implementieren“, fasst das gut zusammen.
    Ich frage mich, ob es möglich ist, SystemD auf einen anderen Software-Stack zu portieren.
    Statt SystemD buchstäblich neu zu schreiben, scheint es durchaus nützlich, es zu portieren; damit könnte man vielleicht sowohl systemd-Befürworter als auch -Gegner zufriedenstellen.
    Natürlich könnte ein Konkurrenzprodukt, das dasselbe tut, auch zu künftigen Innovationen führen.

    • SystemD bewegt sich zu schnell, ist zu meinungsstark und hat einen zu großen Umfang.
      Deshalb werden selbst Leute, die in der Lage wären, es zu portieren, diese Arbeit in der Praxis eher nicht machen wollen, sondern wie bei diesem Projekt Teil-Ersatzlösungen verwenden wollen.
    • Auf Mac oder Windows würde ohnehin niemand SystemD verwenden; ich verstehe daher nicht, warum es wichtig ist, dass es Linux-exklusiv ist.

  • Ich weiß nicht, ob der Gründer das gutheißen würde, aber meine derzeit liebste Art, Chimera auf dem Desktop zu nutzen, ist, darin eine Arch-Linux-distrobox zu installieren.
    So kann ich das Basissystem von Chimera genießen und habe gleichzeitig sofort Zugriff auf das gesamte Arch-Repository und das AUR-Angebot.
    Anwendungen, die unter MUSL Probleme machen, laufen in der distrobox einfach mit glibc, und da Distrobox Wayland durchreicht, funktionieren auch grafische Apps sehr gut.
    Das Ziel ist, so viel wie möglich nativ unter Chimera laufen zu lassen, aber manchmal muss man einfach andere Dinge erledigen.
    Im Chimera-Repository gibt es kein distrobox, aber podman ist enthalten, womit das meiste abgedeckt ist.
    Jedenfalls funktioniert es gut, und ich schreibe diesen Text gerade unter Chimera.
    Manche bevorzugen Flatpak, aber ich mag Paketverwaltung nach alter Art lieber.
    Flatpak fühlt sich für mich zu schwergewichtig und undurchsichtig an, aber ich weiß, dass man darüber unterschiedlicher Meinung sein kann.
    Distrobox passt definitiv besser für Konsolenarbeit.
    Es ist auch ein praktisches Tool, um schnell Sandboxen und temporäre Entwicklungsumgebungen zu starten.
    Arch ist nur meine persönliche Wahl; es hätte genauso gut Void, Debian oder irgendetwas anderes sein können.