Warum wir aptosid forken

Von Knoppix zu sidux

Wer sich schon länger im Dunstkreis von Distributionen bewegt, die auf Debian Unstable setzen, wird den bisherigen Verlauf von Knoppix über Kanotix nach sidux und aptosid kennen.

Gegen aptosid gibt es technisch wenig zu sagen. Es ist solide, wird regelmäßig released, verantwortungsvoll maintained. Mit zwei Worten: es funktioniert. Was aptosid den Erfolg verwehrt, den sidux versprach, haben zu können, ist eher der Umgang mit den Usern, der das Gefühl aufkommen lässt, eine Community sei eigentlich nicht gewollt und eher lästig. Aus diesem latenten Gefühl formte sich mit der Zeit eine Gruppe als renitent angesehener User, die dann auch generalstabsmäßig vertrieben wurden, weil sie Kritik übten. Ich konnte am Ende nicht mehr darumhin, einzusehen, dass bei aller technischen Brillianz, die mich immer noch in deren Lager hielt, dort keine Zukunft liegt.

Von sidux zu aptosid

Viele der jetzt bei diesem Neustart teilhabenden Nutzer haben schon den Schritt zu aptosid nicht mehr mitvollzogen. Ich hielt zu dem Zeitpunkt noch nicht alles für verloren und habe mit diesem deutschsprachigen Forum versucht, den deutschen Usern eine Plattform zu geben, die nicht den in meinen Augen unsinnigen und vollkommen überzogenen Zensurauflagen unterliegt und auf der freie Rede und Respekt vorherrschen. In der Zeit in der dieses Forum besteht, stellte sich das Konzept, wie erwartet, als unproblematisch heraus. Was eigentlich klar war, denn aptosid.com ist das einzige Forum, dass ich kenne, dass derart rigide seine verbliebenen User entmündigt und vertreibt.

Von aptosid zu einem freundlichen OS

Das oben gesagte rechtfertigt in meinen Augen noch nicht wirklich einen Fork, und unsere Ideen enden auch dort nicht. Allerdings sind wir überzeugt, dass eine Distribution davon leben sollte, ihre User einzubinden. Immerhin ist das Give & Take das Grundprinzip Freier Software. Das Prinzip gilt natürlich genauso in Richtug Upstream. Wir sollten so viel wie möglich zurückgeben an Debian. Bei aptosid wurden meine Bemühungen, näher an Debian zu rücken, immer ein wenig misstrauisch beäugt. Wenn es einmal zu praktischen Ergebnnissen kommen sollte, gab es immer Rückzug. So ist bis heute z.B. ceni nicht in Debian enthalten, obwohl reges Interesse besteht. Auch gab es bei aptosid nie eine Infrastruktur, um Bugtracking und Bug-Triage zu erleichtern, um Debian zuzuarbeiten. Das soll sich nun ändern.

Das Artwork von aptosid wurde in den letzten Releases immer schlechter und inkonsistenter. Ein Konzept ist nicht mehr zu erkennen. Die Versuche, zu Zeiten von sidux ein Corprate Design zu etablieren scheiterte leider am Weggang zweier Mitglieder des Art-Teams. aptosid Design hat mittlerweile einen Wiedererkennungswert, aber eher durch schlechtes Design wie aus dem Kindergarten.

Wir werden bei Kerneloptionen, Paketauswahl und Voreinstellungen nicht unsere eigenen Vorlieben durchsetzen (bei aptosid siehe z.B. K-Menu-Voreinstellung). Überall, wo es sinnvoll erscheint, soll die Community mitentscheiden. Wir werden zwar freie Software und freie Treiber immer präferieren, aber keinesfalls unfreie Varianten verhindern. Wichtig ist, dass der User informiert ist, was frei und proprietär in diesem Zusammenhang bedeuten. Dann muss er selber entscheiden.

Wir haben zwar noch keinen Namen ausser dem Arbeitstitel newsid, aber wir sind euer freundlicher aptosid Fork 2011 🙂

Ein Gedanke zu “Warum wir aptosid forken

  1. Sehr schön, das so lesen zu können. Etwas Nostalgie in den verrückten Coronazeiten tu so gut.
    So habe ich das auch mit Euch miterleben könnten und dürfen. Danke devel ( mit z ) und allen Beteiligten dafür. Beste Grüße nuc

Schreibe einen Kommentar zu nuc Antworten abbrechen

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