Bericht der LFS-Gruppe (LinuxfromScratch)

    Erklärtes Ziel von Linuxfromscratch ist es, ein Linux nach eigenen Vorstellungen zu schaffen, ohne all den wuchernden Ballast der vorhandenen Linuxdistributionen. Ehe man aber soweit kommt, bedarf es eines Basis-Systems, das erstens funktioniert, d.h. korrekt bis zum Login-Prompt bootet und dessen Systemfunktionen und Utilities korrekt arbeiten.
    Doch dieser Beginn ist nicht so easy wie er beschrieben wird. Insbesondere wenn man das vorliegende Buch nur online liest. Viele Hinweise und wichtige Erklärungen liegen sehr verstreut und befinden sich selten da, wo sie wichtig sind und beachtet werden müssen. Damit wird die Erstellung des ersten Basis-Systems nicht gerade erleichtert. Besonders dann nich, wenn man erfolgsorientiert nur den Compiler-Anweisungen folgt und die allgemeinen und sonstigen Erklärungen übergeht und nicht vorher sich lesend umgesehen hat. So schleichen sich dann Fehler ein, die manchmal recht mysteriöse Wirkungen zeigen. Wie etwa der, dass ein wichtiges Programm plötzlich fehlt und nicht mehr gefunden wird vom System. Genau dies ist der Gruppe plötzlich passiert.
    Oft aber auch liegt die Fehlerträchtigkeit an den kryptisch komplizierten Anweisungen, zumal wenn man nicht voll versteht was sie bedeuten. Ein spezieller Kandidat dafür sind die Anweisungen mit sed. Würde man voll verstehen was da gemacht werden soll, was das Ziel dieser Aktion ist, würde die Sensibilität für falsche Eingaben und Tippfehler bestimmt steigen, da man auf den ersten Blick erkennen würde - das kann nicht gehen. Ein Beispiel dieser Art wre etwa diese Anweisung:

gcc -dumpspecs | sed 's@^/lib/ld-linux.so.2@/tools&@g' \ > `dirname $(gcc-print-libgcc-file-name)`/specs

    Zwar wird erklärt das damit die specs-Datei des Compiler gcc für die neue Umgebung eingerichtet wird - doch das es eine solche Datei überhaupt gibt haben bislang die wenigsten gewusst. Der Compiler wurde aufgerufen und machte seine Arbeit und das reichte normalerweise. So wird wieder mal der Mensch  zum Problem gemacht, nicht aber die Technik mit ihren komplizierten Anforderungen. Warum ist das alles nur so schwierig und kompliziert fragt man  sich da, wo doch die Technik das Leben erleichtern sollte. Wenn man jedoch den chatt irc.linuxfromscratch.org oder die entsprechende  Mailing-Liste verfolgt, sieht  man, mit diesen Problemen ist man/frau nicht so ganz allein, wie  man meinen könnte.
    So haben wir im Verlauf einige Erleichterungen entdeckt, auf die man erst durch die Praxis kommt. Da das Manual von LFS vollständig als HTML vorliegt und damit auch die notwendigen Anweisungen, kann man diese dort einfach herauskopieren um sie dann in die Befehlszeile hinein zu kopieren. Das ist ein leicht gangbarer Weg, Tippfehler auszuschließen.
    Aber auch wenn man dies sklavisch befolgt, sind damit nicht alle Fehlermöglichkeiten behoben. Selten nämlich wird bei einem Schritt der Erstellung und Kompilierung eines Pakets beschrieben, welche Umgebung und Voraussetzungen zur korrekten Erzeugung notwendig und einzuhalten sind. Das jedoch ist durch unsere wochenweise Unterbrechung besonders  fehlerträchtig, somit jedoch nicht weniger wichtig.
    Jedesmal am Montag muss die Umgebung wieder neu erstellt werden, wie sie zuletzt verlassen wurde. Das sich dies zudem verändert erleichtert die Sache natürlich nicht. Und das ist, wie man sich leicht vorstellen kann recht mühsam.  Daran liegt es wohl auch, dass wir uns jetzt ziemlich festgefahren haben.
    Das schon beschriebene Phänomen, dass der Assembler as flüchtig ist, scheint sich hartnäckig allen Reparaturversuchen zu widersetzen. Auch ist es uns noch nicht gelungen, auszumachen wo denn der Fehler genau liegt und bei welchem Schritt er entstanden ist. Könnte man dann doch dort wieder aufsetzen, um den Fehler zu beseitigen. So der erste Gedanke. Doch fragt sich hier, ob vordem nicht die Ergebnisse, in denen ja der Fehler stecken muss beseitigt werden  müssten, also korrekt der Stand hergestellt werden müsste der vor dem Fehler bestand, womit natürlich das Problem dann eigentlich mit beseitigt wäre, ein Dilemma. So stehen wir also in einer vertrackten, verzwickten, wenn nicht sogar komplizierten Situation, die nicht so einfach zu bewältigen ist,wie es der erste spontane Gedanke erscheinen lässt.
    Die radikalste, jedoch auch aufwendigste Lösung wäre natürlich wieder ganz neu zu beginnen. Doch dazu fehlt noch die Einsicht. Denn ganz hat noch niemand die Hoffnung aufgegeben, den Fehler doch noch beheben zu können.  Sollte es jedoch zum Neubeginn kommen, war der bisherige Weg nicht ganz so umsonst.   Wurden doch viele wichtige Erfahrungen gemacht, nicht nur was die Erstellung von LFS betrifft, auch sonst, was den Umgang mit dem Computer im allgemeinen betrifft. Lernt man so doch viel besser sich auf der Konsole zu bewegen, wozu es sonst kaum noch einen Anlass gibt unter KDE und GNOM. Zudem macht die Arbeit in der Gruppen viel mehr Spaß und Freude, als wenn man alleine zu Hause sich mit den Problemen herumärgert. Durch manch aufheiternde, lustig Bemerkung bekommt die Situation den ihr entsprechenden Stellenwert. LFS wird so zum Freizeitspaß gemacht. Ob das wohl beabsichtigt war? Wichtiger aber ist, das eben mehrere Leute auch viele Perspektiven einbringen und so eigentlich Fehler leichter zu vermeiden und schneller zufinden sind. Sollte man eigentlich meinen. Doch in unserem Fall, da wo wir jetzt stecken gilt das wohl nicht so ganz.
    Wie es nun in dieser Situation weitergeht mit der LFS-Gruppe liegt natürlich am Engagement und Einsatz ihrer Mitglieder. Daher kann darüber nicht allzuviel gesagt werden. Außer das beim letzten Treffen nun doch beschlossen wurde, nochmal neu zu beginnen. Nun jedoch mit dem gemachten Wissen, kann man die vielen Umstände und Fehler die vordem noch gemacht wurden sicher umgehen und vermeiden.
    Das ist der Stand von LFS und damit auch der Bericht, was wir gemacht haben und wo wir stehen.
(js)