Kaisen Linux 2.0 für den USB-Stick des Administrators

Kaisen Linux ist eine Linux-Distribution, die für SysAdmins und andere IT-Profis entwickelt wurde, um Fehler eines installierten Betriebssystems zu diagnostizieren und zu beheben. Kaisen Linux bietet alle notwendigen Werkzeuge für die Diagnose und Behebung von Fehlern, die Wiederherstellung verlorener Daten, die Behebung von Boot-Problemen, die Formatierung von Festplatten und vieles mehr.

MATE als Standard

Kaisen Linux erschien erstmals auf den Tag genau vor zwei Jahren und ist gerade in Version 2.0 vorgelegt worden. Es handelt sich um ein Rolling Release auf der Basis von Debian Testing. Somit basiert die neue Version auf Debian 12 »Bookworm«. Die Standard-Desktop-Umgebung ist MATE, darüber hinaus werden Abbilder für KDE Plasma und Xfce ausgeliefert. Lxde wird bei Kaisen 2.0 durch LXQt ersetzt. Lxde ist weiterhin installierbar, wird aber mit Kaisen 3.0 in frühestens 18 Monaten aus den Repositories entfernt.

Neue Tools für die Cloud

Bei den Anwendungen und Tools werden unter bei Verwendung von Btrfs die Btrfs Snapshot Tools hinzugefügt. Für Cloud-Arbeiter kommen unter anderem Terraform, Trivy, Kubernetes, k6, k9s hinzu. Des Weiteren wurde das Menü vereinfacht und mit moderneren Icons versehen. Der optische Auftritt des Systemmonitors Conky wurde unter allen Desktops vereinheitlicht.

Boot-Optionen von Kaisen 2.0

USB mit Persistenz

Gemäß seiner Bestimmung als Werkzeug für SysAdmins und andere IT-Profis lässt sich Kaisen mit Persistenz bootfähig auf einen USB-Stick übertragen. Der Vorgang wurde vereinfacht und ein Fehler beim Booten behoben. Ein spezielles System-Rescue-Abbild ist jetzt so konzipiert, dass es im Konsolenmodus startet und Xfce als grafische Benutzeroberfläche bei Bedarf mit einem Befehl gestartet werden kann.

ZSH oder Bash

Wird beim Netinstall-Abbild keine grafische Benutzeroberfläche ausgewählt, wird Bash als Standard für den Benutzer festgelegt, der während der Installation angelegt wird. Wenn eines der Metapakete zur Installation einer GUI oder das Paket kaisen-skeleton installiert wird, wird das Profil automatisch für alle Benutzer kopiert und ZSH als Standard eingestellt.

Apparmor und passende Standardprofile wurden der Distribution hinzugefügt. Die Apparmor-Verwaltungstools und -Profile wurden standardmäßig in die Live-Installationen integriert, beim Netinstall werden sie zur Installation angeboten. Das Paket kaisen-interfaces-common installiert sämtliche Werkzeuge, die in jeder unterstützten Desktop-Umgebung verfügbar sind.

Kaisen 2.0 kann auf Deutsch lokalisiert installiert werden, allerdings sind die Übersetzungen im Boot-Menü im Gegensatz zum Rest des Systems nicht sonderlich gelungen. Die Abbilder für die Desktops MATE, KDE Plasma, Xfce und LXQt sowie das System-Rescue und das Netinstall-Abbild stehen auf der Downloadseite des Projekts bereit.

Kommentare

11 Antworten zu „Kaisen Linux 2.0 für den USB-Stick des Administrators“

  1. Avatar von tuxnix
    tuxnix

    „Es handelt sich um ein Rolling Release auf der Basis von Debian Testing“.
    Das Testing Repositorium erhält seine Pakete 7-14 Tage nachdem diese in unstable getestet wurden und das jeweilige Paket mit allen anderen kompatibel ist. Auch steht in den Debian Richtlinien, dass „Testing“ das zukünftige „Stable“ Repositorium ist und bis auf wenige Korrekturen entsprechen fast alle Pakete schon der zukünftigen Hauptausgabe von Debian.

    Kaisen Linux macht hier das vor, was Debian längst tun könnte.Dazu müsste man an den inneren Strukturen von Debian nicht einmal etwas änderen, denn es ist ja schon alles da was benötigt wird. Ein klein wenig die Aufmerksamkeit auf „Testing“ verlagert anstatt mit Korrekturen zu warten bis der nächste Freeze stattfindet, wäre alles was man bräuchte um bei den Usern im Desktopbereich wieder anzukommen zu können.

    1. Avatar von Uxx
      Uxx

      Nimm halt auf dem Desktop einfach Void Linux 🙂

    2. Avatar von kamome
      kamome

      Naja, so wie aktuell ist _testing_ die schlechteste Wahl in Sachen Sicherheit (für die hier vorgestellte Distri vielleicht weniger kritisch) – aber die Rolle können ja andere ausfüllen, z. B. _siduction_.

      1. Avatar von tuxnix
        tuxnix

        Meine Kristallkugel (sie kann auch in die Vergangenheit schauen) sagt, dass neben dem freundlichen Support immer schon bei Siduction die Idee dabei war, das Pferd von vorn und nicht von hinten zu satteln. Trotzdem ist das immer noch (fälschlich) genannte Testring Repositorium bei Debian das, was die höhere Integrität mit allen anderen Paketen verspricht und eigentlich schon (wenn man von recht wenigen Korrekturen mal absieht) das rollende stable ist. (Auch sind da nur wenige Tage dazwischen)

        Schau dir den Ablauf noch mal genauer an.
        Ein Software-Paket, kommt (wenn noch einiges unklar damit ist) zuerst nach experimental. Für alles andere ist Sid der erste Anlaufafen für eine neue Sofware-Version. Wenn Abhängigkeiten und Integrität mit dem Rest-System gewährleistet ist, darf das Paket nach wenigen Taagen nach testing. Und wenn nichts dagegen spricht ist das Paket genau so wie es in testing aufgenommen wurde, bereits komplett und fertig für stable.
        (So seht das bei Debian in den Richtlinien)
        Bis auf ganz wenige Änderungen ist testing zu jeder Zeit das zukünftige stable.

        1. Avatar von kamome
          kamome

          Danke, Ablauf ist bekannt – „Compared to stable and unstable, next-stable testing has the worst security update speed. Don’t prefer testing if security is a concern.“ (https://wiki.debian.org/DebianTesting)

    3. Avatar von perko
      perko

      Das hört sich alles sehr gut an. Da soll das alles hin, cool!

      Nur das „rolling release“ ist falsch in dem Zusammenhang glaube ich.

      Rolling release heisst immer es gibt keinen Zustand alles ist rolling, man kann jedes Paket aktualisieren auf dem System, alles. Das hiesse ebenfalls es gibt keine Releases mehr wie z.B.: Debian 16 (spongy) und Debian 17 (winki) weil es in diesem Zusammenhang (rolling release) sinnlos wäre.

      Oder kann man jetzt im laufendem Betrieb die glibc einfach mal updaten ohne dass alles kaputt ist?

      1. Avatar von tuxnix
        tuxnix

        Auch beim Rollen gibt es immer einen Zustand zwischen den Updates.
        Das benennen der rollenden Repositorien (unstable und testing) bei Debian ist m.M.n. ohnehinn unsinnig und schafft zudem bei den Usern Verwirrung. Man könnte darauf auch verzichten und eine Namensgebung erst für die jeweils stabile Auskopplung vornehmen.

        Das alles ist aber lediglich ein Perspektivwechsel, der an den Sachverhalten selbst noch gar nichts ändern würde. Intern krank m.M.n. Debian, ein wenig, weil man intern zu sehr auf die „stable“ Ausgabe fixiert ist und dabei der Weg dahin zu langwierig gestaltet.
        Es ist die selbe Arbeit, ob man ein Problem gleich löst oder ob man 2 Jahre abwartet bis der allgemeine freeze einsetzt. Wenn aber alle Maintainer lediglich auf die stabile Ausgabe fixiert sind, dann bekommt man eine Distribution mit relativ alten Paketen und das ist dann nicht mehr ganz zeitgemäß bei der Geschwindigkeit in der sich das Desktop mittlerweile entwickelt.

  2. Avatar von Uwe
    Uwe

    Da habe ich u.U. eine zerschossene Linux Variante auf einem Pc vor mir und soll die nun mit einer instabilen Reparaturversion zum Laufen bringen.

    Habe ich das in etwa richtig verstanden?

    1. Avatar von Ferdinand

      Hast du. Und wenn das bei dir jetzt Erstaunen hervorruft, dann hast du ‚unstable‘ nicht richtig verstanden. Man könnte auch sagen, die Bezeichnung ist irreführend.

      1. Avatar von Uwe
        Uwe

        Danke.

  3. Avatar von perko
    perko

    BTW, der erste Screenshot mit LXQt da oben im Artikel sieht richtig cool aus. Das gefällt mir. Muss ich mir mal anschauen die DE.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert