Wenn Leidenschaft nicht genug ist: Kleine Linux-Projekte, große Probleme

Probieren Sie gerne neue Linux-Distributionen aus? Kleine Projekte können Spaß machen - aber sie können auch versteckte Risiken mit sich bringen. Hier ist, worüber die meisten Leute nicht sprechen.
Eine Übersetzung von 🇬🇧 Linuxiac.com

In zahllosen Artikeln ist zu lesen, dass eines der größten Argumente von Linux sein unglaublich vielfältiges Ökosystem an Distributionen ist. Und es stimmt - es gibt Hunderte von Distributionen, die so ziemlich jeden technischen Bedarf abdecken, den man sich vorstellen kann.

Egal, ob Sie ein Tontechniker sind, der eine fein abgestimmte Workstation sucht, ein Gamer, der eine optimierte Leistung benötigt, ein Entwickler, der plattformübergreifend containerisierte Anwendungen ausführt oder Server aller Art verwaltet - es gibt eine Linux-Distribution, die auf Sie zugeschnitten ist.

Es gibt jedoch etwas, das nicht oft erwähnt wird: Ein großer Teil dieser Vielfalt - etwa 80 % oder mehr - stammt aus einer bestimmten Ecke der Linux-Welt. Ich beziehe mich dabei auf diese Ein-Mann-Show-Projekte oder andere, die von einem kleinen Team von Entwicklern entwickelt und gepflegt werden.

Wie ich noch erklären werde, können diese Projekte zwar ein schönes Gebiet sein, das hauptsächlich für Distro-Hopper reserviert ist, aber sie können auch ein gewisses Risiko darstellen - vor allem, wenn Sie nicht genau wissen, worauf Sie sich einlassen. In den folgenden Abschnitten werde ich aufschlüsseln, warum der Einstieg in diesen Teil des Ökosystems für den durchschnittlichen Linux-Benutzer riskant sein kann.

Die versteckten Risiken kleiner Linux-Distributionen

Um eines gleich zu Beginn klarzustellen: Dieser Artikel ist nicht gegen kleine Linux-Projekte gerichtet. In der Tat sind sie ein großer Teil dessen, was Linux so aufregend und voller Möglichkeiten macht. Der eigentliche Fokus liegt hier auf neueren Benutzern, die zum ersten Mal in Linux eintauchen, sich von all den Optionen mitreißen lassen und dann später feststellen, dass sie vielleicht die falsche Distribution für ihre Bedürfnisse gewählt haben.

Ich hoffe, dass dieser Artikel den Leuten dabei hilft, eine fundiertere Entscheidung zu treffen - damit sie diese Art von Enttäuschung später vermeiden können.

Heute hier, morgen weg

Das größte Problem dabei ist ganz einfach: Wenn ein Vertrieb nur von einer einzigen Person oder einer kleinen Gruppe von Enthusiasten abhängt, verschwindet er normalerweise (im besten Fall) innerhalb weniger Jahre. Natürlich gibt es Ausnahmen (Hut ab vor Herrn Volkerding), aber ehrlich gesagt, bestätigen diese nur die Regel.

Normalerweise läuft es folgendermaßen ab: Ein leidenschaftlicher Linux-Enthusiast hat eine Idee für eine neue Distribution, von der er glaubt, dass sie das nächste große Ding in der Open-Source-Welt sein könnte. Die Begeisterung ist riesengroß, und sie stürzen sich mit aller Kraft in das Projekt.

Wenn alles gut läuft, schaffen sie es, ein paar Gleichgesinnte an Bord zu holen. Nachdem sie eine Menge harter Arbeit investiert haben, kommt das Projekt schließlich zustande. Und dann kommt der große Moment - sie verkünden der Linux-Gemeinschaft: Es gibt eine brandneue Distribution in der Stadt.

Alles beginnt besser als erwartet - es ist aufregend, sogar irgendwie magisch. Aber leider fangen die Dinge dann an, bergab zu gehen. Ein Haufen neugieriger Linux-Benutzer, vor allem Distro-Hopper, stürzen sich darauf, die glänzende neue Distro auszuprobieren. Und, wie bei jedem neuen Projekt, stoßen sie schnell auf Probleme.

Schon bald füllen sich die Foren und Git-Repositories mit Fehlerberichten und Korrekturanfragen. Anfangs reitet der Entwickler noch auf der Welle der Begeisterung und fängt an, die Dinge zu flicken. Aber die Bugs kommen immer wieder - einer nach dem anderen. Was sich gestern noch wie ein lustiges Nebenprojekt anfühlte, wird nun zu einem Vollzeitjob.

Es dauert nicht lange, bis die anfängliche Begeisterung nachlässt und sich ein Burnout einschleicht. Der Entwickler beginnt zu erkennen, dass die Erstellung der ersten Version der einfachste Teil des Prozesses war.

In der Zwischenzeit hört das wirkliche Leben nicht auf - und jetzt verbringen sie über 12 Stunden am Tag mit etwas, das wahrscheinlich nicht wachsen wird, ohne ein Team oder andere Mitwirkende, die die Last teilen. Sie haben also eine Bruchstelle erreicht und sich still und leise von dem Projekt zurückgezogen.

Manchmal gibt es eine Ankündigung, die besagt, dass das Projekt stillgelegt wird - aber meistens gibt es nicht einmal das. Ein Jahr später, wenn Sie versuchen, die Website des Projekts zu besuchen, ist die Domain einfach... weg. Das war's dann. Ende der Geschichte.

Es gibt auch noch ein anderes übliches Szenario - wenn ein Entwickler auf die Idee kommt, dass dies noch niemand zuvor getan hat, und sich daran macht, eine neue Distribution mit einem Paketmanager zu erstellen, der versucht, alle existierenden in einer einzigen Komplettlösung zu vereinen. Und um das Ganze abzurunden, ist es unveränderlich und kommt sogar mit einem eingebauten KI-Assistenten, der Ihnen genau sagen kann, wie lange Sie morgens Ihren Speck braten müssen.

Meistens enden solche Projekte als persönliche Spielwiese für Entwickler, um ihre technischen Fähigkeiten zu verbessern. Aber schon bald, nachdem sie einige Erfahrungen gesammelt und einen frischen Blick auf das geworfen haben, was sie gebaut haben, stellen sie fest, dass sie vielleicht nicht alles optimal gemacht haben. Nachdem sie dabei viel gelernt haben, stellen sie das Projekt ein und kündigen an, dass sie sich der nächsten "revolutionären" Idee zuwenden werden.

Wie Sie sehen können, ist das Ergebnis in jedem dieser Fälle dasselbe - das Projekt wird eingestellt. Die Gründe dafür sind ziemlich offensichtlich. Wenn es einem Projekt nicht gelingt, weitere Entwickler zu gewinnen, die helfen, die Last zu teilen, ist es ehrlich gesagt unrealistisch zu erwarten, dass eine Person - oder sogar ein kleines Team - eine Linux-Distribution über Jahre hinweg aufrechterhalten kann.

Denn, nun ja... das Leben passiert. Die Rechnungen hören nicht auf einzutrudel. Deine Freundin (jetzt deine Frau) möchte verständlicherweise, dass du mehr Zeit damit verbringst, das Kinderzimmer herzurichten und tatsächlich Babysachen zu kaufen, anstatt einem Fehler nachzujagen, der von jemandem auf den Philippinen gemeldet wurde (nichts für ungut - übrigens ein tolles Land). Oder vielleicht ist es etwas wie: "Meine Freundin und ich ziehen an die Westküste, und in den nächsten sechs Monaten bis zu einem Jahr werde ich keine Zeit haben, dieses Projekt zu pflegen." Das ist auch völlig in Ordnung.

Sie sehen, worauf ich hinaus will - ohne eine Community hat eine Distribution keine Chance. Den Punkt zu erreichen, an dem sich genügend Freiwillige an der Entwicklung beteiligen? Das ist etwas, was nur eine Handvoll Projekte geschafft haben. Und natürlich gibt es auch Projekte, die von Unternehmen unterstützt werden und bei denen bezahlte Mitarbeiter mithelfen - aber das ist eine andere Geschichte.

Erhöhte Sicherheitsrisiken

Sicherheit ist ein weiteres wichtiges Thema bei kleinen Projekten, die sich stark auf die Freizeit einer Handvoll Entwickler stützen. Ein häufiges Problem ist, dass diese Projekte oft beschließen, aus welchen Gründen auch immer, das Rad neu zu erfinden. Sie bauen zum Beispiel einen eigenen Wrapper um einen bestehenden Paketmanager, der bereits ohne ihn funktioniert.

Das Problem ist, dass diese Art von benutzerdefinierten Lösungen in der Regel recht experimentell sind und im Laufe der Zeit nicht gründlich getestet wurden. Und wenn die Distribution keine breitere Benutzerbasis anzieht, ist es nicht ungewöhnlich, dass Dinge über lange Zeiträume nicht aktualisiert werden. Sie liegen dann einfach im System herum. Das ist riskant, denn ohne regelmäßige Updates oder breitere Tests ist es schwer zu wissen, ob etwas wirklich sicher oder stabil genug ist, um sich darauf zu verlassen.

Eine viel unangenehmere - und riskantere - Situation entsteht, wenn die fragliche Distribution auf einer großen Linux-Distribution aufbaut, was fast immer der Fall ist. Und warum? Für die meisten kleinen Projekte ist es einfach nicht realistisch, eine völlig neue Distribution von Grund auf zu erstellen - mit einer eigenen Paketbasis, eigenen Verwaltungstools und allen dazugehörigen Komponenten. Es ist ein enormer Arbeitsaufwand, der normalerweise weit über das hinausgeht, was ein einzelner Entwickler oder ein kleines Team bewältigen kann.

Nun stellen Sie sich Folgendes vor: Eine neue Distribution erscheint, die auf Fedora 40 aufbaut. Der Chefentwickler ist enthusiastisch und voller Energie. Aber dann - wie wir bereits erwähnt haben - tritt das wahre Leben ein. Ein Jahr vergeht, und der Entwickler zieht sich (verständlicherweise) zurück, so dass das Projekt in der Versenkung verschwindet. In der Zwischenzeit sind die Paketquellen immer noch an Fedora 40 gebunden, das schon lange das Ende seiner Lebensdauer erreicht hat und keine Updates mehr erhält.

Die Gefahr dabei ist, dass ein neuer oder gelegentlicher Linux-Benutzer über die Distribution stolpert, einen Screenshot mit einem auffälligen Hintergrundbild sieht, denkt, dass es "cool" aussieht, und beschließt, es zu installieren - ohne zu wissen, worauf er sich einlässt. Am Ende hat er ein System voller veralteter Pakete, das Dutzenden von Sicherheitslücken ausgesetzt ist, was uns zum nächsten Abschnitt bringt.

Support? Wetten Sie nicht darauf

Ich werde mich kurz fassen. Lassen Sie es mich klar und deutlich sagen - auch wenn es vielleicht schon offensichtlich ist. Eine Linux-Distribution, die nur von einer Handvoll Entwicklern gepflegt wird, kann nicht dasselbe Maß an Unterstützung bieten wie eine Distribution, die von einem größeren Team unterstützt wird, ganz gleich, wie gut gemeint oder wie leidenschaftlich die Bemühungen sind. Wichtige Sicherheitsprobleme werden möglicherweise nicht so schnell behoben, und die Entwicklung und Verbesserung benutzerdefinierter Tools oder Funktionen dauert wahrscheinlich länger.

Und wenn Sie auf ein Problem stoßen, haben Sie viel Glück, eine gut dokumentierte Lösung zu finden - denn die Chancen sind ziemlich gering. Wenn Sie z. B. fragen: "Wie verhindere ich, dass sich bestimmte Pakete in Arch aktualisieren?", werden Sie in wenigen Minuten eine klare, präzise Antwort finden.

Aber wenn Sie sich fragen: "Wie bringe ich Packzilla dazu, automatische Aktualisierungen auf einem Out-Of-This-World-Linux durchzuführen?" - nun, diese Antwort könnte für immer in der Schwebe bleiben. Oder vielleicht, nur vielleicht, stolpert der Entwickler, der dahinter steckt, über Ihren Beitrag auf Reddit... anderthalb Jahre später. Sie verstehen, was ich meine.

Und schließlich, wenn es um die Dokumentation geht, kommen sehr kleine Projekte in der Regel zu kurz - entweder gibt es überhaupt keine, oder das, was da ist, ist einfach nicht auf der Höhe der Zeit. Der Grund dafür ist ziemlich einfach: Für eine gute Dokumentation braucht man ein größeres Team, mit Leuten, die sich auf das Schreiben konzentrieren und wissen, wie man es gut macht. Das ist nichts, was ein einzelner Entwickler oder Hobbyist, egal wie leidenschaftlich er ist, normalerweise alleine schaffen kann.

Ökosystem-Kompatibilität

Lassen Sie uns ein wenig über Kompatibilität sprechen. In den meisten Fällen drehen sich Distributionen, die von einem einzelnen passionierten Entwickler erstellt werden, um ein bestimmtes Tool - normalerweise das, das den Anstoß für das ganze Experiment gegeben hat. Der Prozess läuft in der Regel folgendermaßen ab: Man nehme eine bestehende Distribution, füge das neue Tool hinzu, tausche das Thema und das Hintergrundbild mit etwas aus dem Internet aus und nenne es eine brandneue Distribution.

Das Problem dabei? Dieses Tool ist in der Regel etwas Obskures und hat nichts mit den etablierten, kampferprobten Tools zu tun, denen die breite Linux-Gemeinschaft vertraut. Wenn Sie sich also für eines dieser kleinen Projekte entscheiden, binden Sie sich an dieses seltsame Ding, das, wie bereits erwähnt, möglicherweise nie die notwendigen Updates oder Verbesserungen erhält. Schon bald werden Sie wahrscheinlich auf lästige Fehler stoßen und mit der Entwicklung ins Stocken geraten. Ehrlich gesagt, ist es die Kopfschmerzen nicht wert - besser, Sie ersparen sich den Ärger von Anfang an.

Jahrelange Daten in Sekundenschnelle verloren

Und zu guter Letzt ist eines der größten Probleme bei der Verwendung einer Distribution, die auf der Experimentierfreudigkeit eines Entwicklers basiert, das Risiko, dass Ihre Daten verloren gehen. Es besteht eine reale Chance, dass Sie sich von wichtigen Dingen verabschieden müssen - seien es Arbeitsprojekte, geliebte Familienvideos oder die Musiksammlung, die Sie seit Jahren aufgebaut haben.

Ein Update - oder vielleicht eine neue Option - wird zu dem "erstaunlichen" benutzerdefinierten Tool hinzugefügt, aber es wurde nicht richtig getestet. Es soll eine bestimmte Funktion erfüllen, aber stattdessen passiert etwas ganz anderes... und wenn alles schief geht, ist natürlich niemand da, der die Schuld auf sich nimmt. Das Ergebnis: Alle Ihre wertvollen Daten können im Handumdrehen verschwinden. Ich sage nicht, dass das passieren wird - aber sind Sie bereit, das zusätzliche Risiko einzugehen, dass es passieren könnte?

Unterschätzen Sie auch nicht die Gefahr, dass Sie Ihren Computer einfach neu starten und plötzlich mit einer Reihe von Fehlermeldungen konfrontiert werden, die Sie nicht verstehen und die es Ihnen unmöglich machen, Ihr System zu starten. Und wenn Sie niemanden in der Nähe haben, der sich mit Technik auskennt und das Problem entweder beheben oder Ihnen zumindest dabei helfen kann, Ihren Computer mit einem Wiederherstellungstool zu starten und Ihre wichtigen Daten auf ein sicheres externes Laufwerk zu kopieren, dann haben Sie ein echtes Problem am Hals.

Fairerweise muss man sagen, dass selbst bei bewährten, gut unterstützten Namen etwas schief gehen kann. Die Wahrscheinlichkeit ist jedoch wesentlich geringer. Bei größeren Projekten ist die Qualitätskontrolle der Software in der Regel sehr viel gründlicher und professioneller, was die Wahrscheinlichkeit, auf einen schwerwiegenden Fehler zu stoßen, der Ihr System zum Absturz bringen könnte, deutlich verringert.

So würde ich es ausdrücken - mein Rat? Verlassen Sie sich niemals, und ich meine wirklich niemals, auf eine kleine Linux-Distribution ohne solide Erfolgsbilanz als Ihr Hauptsystem für den täglichen Gebrauch. Nur weil es die neueste "innovative" Idee eines Entwicklers ist, heißt das noch lange nicht, dass Sie ihr vertrauen können. Es ist das Risiko wirklich nicht wert.

Schlussfolgerung

Diese Schlussfolgerung wird ein wenig anders (und länger) ausfallen als meine üblichen. Vor mehr als 20 Jahren saß ich im selben Boot wie einige von Ihnen jetzt - völlig fasziniert von der Vielfalt der Möglichkeiten, die die Linux-Welt zu bieten hatte. Und glauben Sie mir, damals waren die Möglichkeiten sehr viel begrenzter als heute. Ich habe in jenen frühen Jahren einige harte Lektionen gelernt. Und ehrlich gesagt kann ich mich nicht daran erinnern, dass ich in den letzten 15 Jahren jemals wichtige Daten verloren habe - weil ich es mir zur Regel gemacht habe, mich an Namen zu halten, denen ich vertraue.

Das heißt aber nicht, dass ich selbst den bekannten Namen blindes Vertrauen entgegenbringe. Deshalb habe ich mich immer an die 3-2-1-Backup-Regel gehalten. Aber das ist ein ganz anderes Thema. Was die kleinen Linux-Projekte angeht? Ich habe sie immer begrüßt... in meinen virtuellen Maschinen. Und nur wenn ich etwas für wirklich vielversprechend hielt, habe ich in Erwägung gezogen, es auf Bare Metal zu installieren - aber selbst dann nur auf einem Testsystem. Für meinen täglichen Desktop auf sie angewiesen zu sein? Das ist etwas, das ich mir einfach nicht vorstellen kann.

Sie können mich altmodisch nennen - ich werde Ihnen nicht widersprechen, Sie hätten Recht. Und wenn es um Server geht, werde ich wirklich altmodisch. Nur weil irgendeine neue Distribution von Entwickler X und ein paar Freunden auftaucht - selbst wenn sie auf einem grundsoliden RHEL basiert (Alma und Rocky, keine Sorge, das gilt nicht für euch - ihr erfüllt alle meine Kriterien) - bedeutet das nicht, dass sie auch nur annähernd bereit ist, meine Server zu bedienen.

Hinzu kommt, dass selbst etablierte Linux-Namen (man möge mir verzeihen) meine spezifischen Anforderungen oft nicht erfüllen, während OpenBSD als Firewall oder FreeBSD (gesegnet sei ZFS) für bestimmte Anwendungsfälle besser geeignet sind.

Seien Sie klug, nicht impulsiv. Nur weil etwas Neues behauptet, eine "noch nie dagewesene" Erfahrung zu bieten, heißt das nicht, dass Sie sich darauf stürzen sollten, ohne es zu durchdenken - vor allem, wenn es von einem enthusiastischen Experimentator kommt, der das Aufkommen einer weiteren Linux-Distribution ankündigt.

Letztendlich kommt es darauf an, dass Ihre Daten sicher sind - oder die Informationen und Dienste Ihres Unternehmens, wenn Sie dies beruflich tun. Das ist es, was in diesem Bereich wirklich zählt. Und darauf können Sie sich bei einem Ein-Mann-Projekt oder einem kleinen Team nicht verlassen.

Ich verstehe, dass dieser Artikel für einige Entwickler, die aufrichtig ihren Schweiß, ihre Tränen und ihr Blut in Projekte und Träume investieren, um eine Linux-Distribution zu schaffen, die der Open-Source-Gemeinschaft zugute kommt, nicht besonders angenehm sein mag - und ja, das kann passieren. Ich habe also nichts als Respekt vor ihnen. Das schließt jedoch nicht etwas aus, an das ich glaube - beweisen Sie sich erst, und dann sind Sie bei mir mehr als willkommen.

Kleine Projekte - insbesondere Linux-Distributionen - haben zweifellos ihren eigenen Charme. Sie bringen oft einzigartige Funktionen mit, die es aus dem einen oder anderen Grund nicht in die großen Distros schaffen. Da sie aber in der Regel ziemlich experimentell sind, ist es keine gute Idee, sich auf sie als Hauptsystem zu verlassen.

Zumindest solange nicht, bis sie bewiesen haben, dass man ihnen vertrauen kann - indem sie vorhersehbare Schritte machen, eine solide Erfolgsbilanz aufbauen und, was am wichtigsten ist, eine ausreichend starke Community anziehen, um zu beweisen, dass sie etwas Wertvolles anbieten. Abgesehen davon werden sie wahrscheinlich immer einen Platz in den Herzen der Distro-Hopper haben - und ehrlich gesagt, ist das eine gute Sache.

Spendieren Sie Bobby einen ☕ Ko-fi

Ein Service von s3n🧩net