Als Nachteil stellt sich auch hier der hohe Aufwand dar, den man investieren muss, um ein lauffähiges System zu erhalten.
LFS dient ja in erster Linie als Lehrmaterial. Etwas neues lernen ist immer mit einem Aufwand verbunden. Was soll also dieser Satz? Sorry, aber selbst ich, der zwei linke Hände fürs kompilieren hat, habe das Buch mit einem AMD 1500+ in 24 Stunden durchgearbeitet. Ein hoher Aufwand ist für mich ein debian-System mit Raid zu installieren, welches ums verrecken nicht mit der HW zusammen spielen möchte, ja quasi eine Installations-Resistenz besitz. Ich kann das Buch LFS nur jedem empfehlen, der Interesse an Linux oder Betriebssystemen allg. hat. Gruß
Nach vielen Ausfluegen zu OpenBSD, NetBSD, Debian, Ubuntu, ArchLinux, T2, sogar LFS und CLFS(beta), aber auch buildroot[1], bin ich schlussendlich wieder bei CRUX [2] gelandet.
Was mich an BSD stoert, sind der zunehmende 'lacking hardware support' vor allem auf Desktop-Systemen (im besonderen auf Notebooks), deshalb sind die BSDs keine Option mehr fuer mich, obwohl ich lange Jahre sehr gute Erfahrung damit gesammelt habe.
Debian und Ubuntu laufen relativ einfach und sind schnell installiert, aber die Systeme sind total aufgeblaeht mit 'useless crap' wie zB. dem wirklich bescheuerten SysV Init-System (das ist wirklich so ziemlich das aergste was ich an den meisten Linux Distros hasse, wozu kompliziert wenn es doch auch so einfach geht?). Nach Eskapaden mit ArchLinux, das CRUX und vielleicht sogar Slackware etwas aehnlich ist, mir aber nun doch schon etwas zu wenig 'lightweight geworden ist - zuviele User vermutlich, die die Entwicklung in Richtung bloat vorantreiben - habe ich zunaechst mit {H,C,}LFS versucht ein eigenes System zu erstellen. Aber die LFS-Systeme sind schon weitmehr aufgeblaeht als es eine simple Anleitung 'von Bootloader bis zur Kommandozeile' bereits vor Jahren deutlich machte (erstellen einer Toolchain, kompilieren der Basis-Software, erstellen eines Kernels und eines Init-Scriptes)...
Da ich die glibc zum Erbrechen nicht ausstehen kann, bin ich dann auf [1] gestoszen, und hab versucht eine uClibc-basierte Distro zu erstellen. Man scheitert aber sehr schnell an fehlenden ioctl-Konstanten und der Aufwand mir die uClibc Internas anzusehen war mir in der knappen Zeit dann doch etwas zu monstroes. Allerdings hab ich es geschafft ein bootfaehiges System mit kleineren Hacks zu erstellen, das sogar in der Lage war X.org 7.0 mit uClibc zu compilieren (es waren aber dutzende Patches notwendig und summasummarum habe ich nach 2 Tagen keine Lust mehr gehabt weiter zu machen, weil durch fehlende ioctl-Konstanten /dev/pt/* irgendwie broken war und sich X nicht starten liess geschweige denn ein weiteres vt oeffnen liess - schlieszlich wollte ich ein System mit dem ich arbeiten kann. Die buildroot-Umgebung, die standardmaessig auf busybox basiert habe ich aber komplett ersetzt im Laufe des Bootstraps (am Ende war so ziemlich der GNU Standard installiert wie coreutils, inetutils, etc.pp.)
Da ich einen recht schnellen Server zum Compilieren rumstehen habe, bin ich dann auf T2 gekommen - genaugenommen auch eine Mischung aus jhalfs und buildroot, aber doch etwas komfortabler und das funktioniert auch halbwegs. Aber irgendwie ist das System wie eine Zwangsjacke, relativ undurchsichtig (wie buildroot auch) und dadurch relativ unflexibel. Auch die Dependency-Generierung bei der Konfiguration eines Systems erschien mir erbrechend langsam (fuer jede Option die ausgewaehlt wurde, wurde scheinbar die Maske komplett neu generiert und was im Hintergrund fuer exponentielle Algorithmen rumrechneten will ich garnicht wissen - bei der Auswahl von Tools zum Linken gegen dietlibc hat es laenger gedauert ein Tool auszuwaehlen als dietlibc selbst zu kompilieren, sehr seltsam das ganze).
Nun bin ich wieder bei CRUX gelandet, weil die core Tools genau dem Userland entsprechen was ich mir wuensche in einer selbst gebackenen Distro und man darueber hinaus das System seinen eigenen Vorstellungen leicht uptodate halten kann, durch Besuch auf [3]. Ich hatte CRUX schon vor Jahren im Einsatz und war begeistert von dieser Distro - es ist die Linux Distro fuer mich, die am wenigsten saugt...
Von Dominikus am Do, 28. September 2006 um 16:58 #
Leider ist DeliLinux IMHO eher ein Beispiel für eine unzumutbare Linux-Distribution. Bei der Installation wird einem lediglich eine ZWANGSFORMATIERUNG mit Ext2 "angeboten" - natürlich auch ohne jegliche Optionen. Und die Installation von Lilo (wieder keine Wahl) schlug fehl.
Natürlich wird die Zielpartition formatiert (was denn sonst?) wobei es natürlich eine Abbruchfunktion gibt. Da der Kernel so klein wie möglich gehalten werden soll ist auch nur ext2 enthalten. Man kann es problemlos später mit "tune2fs -j" auf ext3 ändern (wobei ext3 beim mounten erheblich langsamer ist als ext2).
Was die fehlgeschlagene LILO-Installation angeht -> Bugreport.
1. Du hast zu viel Zeit. 2. Dein Deutsch ist etwas "broken". 3. CRUX ist mir persönlich zu minimalistisch. Slackware stellt für mich einen guten Kompromiss dar.
Umlaute ausschreiben muss er wohl, wenn er soviele verschiedene Systeme benutzt ;-) "sz" ist die eigentlich korrekte ausgeschriebene Form für "ß". Nur weiß das heute keiner mehr und es sieht komisch aus, da es bei den lateinischen Buchstaben keine zwei verschiedenen "S" gibt und eigentlich ein "langes S" vor dem "Z" steht, woraus sich dann das Schriftzeichen "ß" entwickelt hat.
Ansonsten gibt es hier wirklich schlimmeres Deutsch ...
Von heul doch am Do, 28. September 2006 um 14:36 #
Nettes Spielzeug Und immer wieder der vorgeholte Spruch das man mit LFS ja soviel lernen könnte über sein System... Muss jeder selber wissen. Ich zumindest kann als Produktivsystem mit einem LFS absolut nichts anfangen. Alleine das aktuellhalten ist ja schon nahezu ein Unding ohne vernünftiges Paketsystem.
Da magst Du sicherlich Recht haben, allerding kann man schon einiges via LFS lernen. Klar versteht man dabei nicht alles und v.a. nicht alles bis ins Detail, aber es vermittelt einem einen guten Gesamtüberblick über ein Linux-System, z.B. welche Software erfüllt welchen Zweck usw. und am Ende hat man wirklich ein besseres "Gefühl" für sein System, zumindest erging es mir so. Ein LFS-Produktiv-System würde ich dennoch nicht so schnell in Betracht ziehen, es sei denn, es geht um ausgefallene Lösungen, z.B. im embedded Bereich, also wenn man seine eigene Distri aus LFS herstellt. Aber als Server oder Desktop-System? Sicherlich nicht. Da gibt es schon bessere Ansätze, z.B. ROCK-Linux oder für diejenigen, die in Linux nicht mehr den stabilen Kernel sehen, wie ich, (Free)BSD. Gruß
Lass mich raten: Du bist jahrelang in der Linux-Welt rumgeeiert hast mit Slackware, SuSE, LFS, RetHat, Debian, ... (you name it) gearbeitet und rumgefrickelt, bist dann schließlich zu FreeBSD gewechselt, weil du - genauso wie ich - eingesehen hast, dass es nach dem tausendsten mal Suchen nach Konfigurationsmöglichkeit X/Y und wir machen es anders Susi/Rothut/Debian den Wert von Konsistenz zu schätzen gelernt hast. Herzlichen Glückwunsch. Wir wissen, was viele andere Leser hier noch vor sich haben ;-). Bevor hier ein falschen Bild entsteht; ja ich steh zu kldload linux
Ja ein bisschen. ;) Ein anderer Grund war bzw. ist, dass ich rein subjektiv FreeBSD als einfacher empfinde. Das fängt schon beim Übersetzen des Kernels an und hört bei den Ports auf, wo ich noch die Möglichkeit habe, Option X für meine Zwecke umzubiegen. Desweiteren ist es um einiges leichter Jails für den produktiven Einsatz einzurichten, als es z.B. mit Xen oder besser v-server unter Debian ist. Letztenendes sind es aber die häufigen Kernel-Updates, die mich zu FreeBSD getrieben haben. Das muss im Server-Bereich nicht sein. Da kommt man in letzter Zeit zu nichts anderes mehr, nur weil Geek XY jetzt auch den ALDI Dosenöffner unter Linux zum laufen gebracht hat. :s Ich will lieber was solides. :) Gruß
Von Anothermous am Do, 28. September 2006 um 18:53 #
Wenn du dich gegen ein Paketsystem entscheidest, ist das dein problem, aber nicht die Schuld von LFS! Schließlich gibts dazu ein eigenes Kapitel.
Was ist für dich "aktuellhalten"? Die großen Distributionen liefern auch nur Security-Fixes für die Pakete in ihren Versionen -- der entsprechende Aufwand für ein LFS-System hält sich da auch in Grenzen. Pakete einer anderen Distribution (auch anderen Version der gleichen Distribution) sollte man sich eh nicht installieren -- es sei denn man steht auf Instabilität. Und bei single-user Systemen ist in vielen Fällen sowieso nicht die aller höchste Dringlichkeit gegeben.
Man kann mit LFS durchaus sehr gut lernen, das ist nicht einfach nur ein Spruch, das ist Tatsache - wenn man richtig daran heran geht! Ob es als Produktivsystem geeignet ist, steht hingegen auf einem ganz anderen Blatt und hängt wohl primär von den eigenen Ansprüchen ab.
Zum Lernfaktor: Wenn du das ganze lediglich Kochbuch mäsig durchziehst wirst du herzlich wenig lernen, aber wenn du dich ein wenig mit den Programmen beschäftigst die du da installiert ist es eine sehr gute Möglichkeit diverse Details eines Linuxsystems zu erfahren: Wie funktioniert der Boot-Vorgang, wie funktioniert das Login genau, vorallem: Welcher Prozess macht was und diverse andere Dinge. Klar, das alles kann man auch anders lernen, aber zumindest für mich waren meine LFS-Versuche vor diversen Jahren keine Zeitverschwendung sondern eine ziemlich schnelle Methode Linux-Interna zu lernen und zu verstehen. Richtig interessant wird es beim Lern-Faktor dann wenn man auf eigene Faust versucht Komponenten des Systems zu ersetzen (z.B. init durch runit und so "Scherze").
LFS dient ja in erster Linie als Lehrmaterial. Etwas neues lernen ist immer mit einem Aufwand verbunden. Was soll also dieser Satz? Sorry, aber selbst ich, der zwei linke Hände fürs kompilieren hat, habe das Buch mit einem AMD 1500+ in 24 Stunden durchgearbeitet. Ein hoher Aufwand ist für mich ein debian-System mit Raid zu installieren, welches ums verrecken nicht mit der HW zusammen spielen möchte, ja quasi eine Installations-Resistenz besitz.
Ich kann das Buch LFS nur jedem empfehlen, der Interesse an Linux oder Betriebssystemen allg. hat.
Gruß
Was mich an BSD stoert, sind der zunehmende 'lacking hardware support' vor allem auf Desktop-Systemen (im besonderen auf Notebooks), deshalb sind die BSDs keine Option mehr fuer mich, obwohl ich lange Jahre sehr gute Erfahrung damit gesammelt habe.
Debian und Ubuntu laufen relativ einfach und sind schnell installiert, aber die Systeme sind total aufgeblaeht mit 'useless crap' wie zB. dem wirklich bescheuerten SysV Init-System (das ist wirklich so ziemlich das aergste was ich an den meisten Linux Distros hasse, wozu kompliziert wenn es doch auch so einfach geht?). Nach Eskapaden mit ArchLinux, das CRUX und vielleicht sogar Slackware etwas aehnlich ist, mir aber nun doch schon etwas zu wenig 'lightweight geworden ist - zuviele User vermutlich, die die Entwicklung in Richtung bloat vorantreiben - habe ich zunaechst mit {H,C,}LFS versucht ein eigenes System zu erstellen. Aber die LFS-Systeme sind schon weitmehr aufgeblaeht als es eine simple Anleitung 'von Bootloader bis zur Kommandozeile' bereits vor Jahren deutlich machte (erstellen einer Toolchain, kompilieren der Basis-Software, erstellen eines Kernels und eines Init-Scriptes)...
Da ich die glibc zum Erbrechen nicht ausstehen kann, bin ich dann auf [1] gestoszen, und hab versucht eine uClibc-basierte Distro zu erstellen. Man scheitert aber sehr schnell an fehlenden ioctl-Konstanten und der Aufwand mir die uClibc Internas anzusehen war mir in der knappen Zeit dann doch etwas zu monstroes. Allerdings hab ich es geschafft ein bootfaehiges System mit kleineren Hacks zu erstellen, das sogar in der Lage war X.org 7.0 mit uClibc zu compilieren (es waren aber dutzende Patches notwendig und summasummarum habe ich nach 2 Tagen keine Lust mehr gehabt weiter zu machen, weil durch fehlende ioctl-Konstanten /dev/pt/* irgendwie broken war und sich X nicht starten liess geschweige denn ein weiteres vt oeffnen liess - schlieszlich wollte ich ein System mit dem ich arbeiten kann. Die buildroot-Umgebung, die standardmaessig auf busybox basiert habe ich aber komplett ersetzt im Laufe des Bootstraps (am Ende war so ziemlich der GNU Standard installiert wie coreutils, inetutils, etc.pp.)
Da ich einen recht schnellen Server zum Compilieren rumstehen habe, bin ich dann auf T2 gekommen - genaugenommen auch eine Mischung aus jhalfs und buildroot, aber doch etwas komfortabler und das funktioniert auch halbwegs. Aber irgendwie ist das System wie eine Zwangsjacke, relativ undurchsichtig (wie buildroot auch) und dadurch relativ unflexibel. Auch die Dependency-Generierung bei der Konfiguration eines Systems erschien mir erbrechend langsam (fuer jede Option die ausgewaehlt wurde, wurde scheinbar die Maske komplett neu generiert und was im Hintergrund fuer exponentielle Algorithmen rumrechneten will ich garnicht wissen - bei der Auswahl von Tools zum Linken gegen dietlibc hat es laenger gedauert ein Tool auszuwaehlen als dietlibc selbst zu kompilieren, sehr seltsam das ganze).
Nun bin ich wieder bei CRUX gelandet, weil die core Tools genau dem Userland entsprechen was ich mir wuensche in einer selbst gebackenen Distro und man darueber hinaus das System seinen eigenen Vorstellungen leicht uptodate halten kann, durch Besuch auf [3]. Ich hatte CRUX schon vor Jahren im Einsatz und war begeistert von dieser Distro - es ist die Linux Distro fuer mich, die am wenigsten saugt...
[1] http://buildroot.uclibc.org/
[2] CRUX Linux/
[3] http://crux.nu/portdb/index.php
Siehe http://www.delilinux.de. Inklusive eines Ports Systems welches auf dem von Crux aufbaut.
Was die fehlgeschlagene LILO-Installation angeht -> Bugreport.
2. Dein Deutsch ist etwas "broken".
3. CRUX ist mir persönlich zu minimalistisch. Slackware stellt für mich einen guten Kompromiss dar.
Umlaute ausschreiben muss er wohl, wenn er soviele verschiedene Systeme benutzt ;-)
"sz" ist die eigentlich korrekte ausgeschriebene Form für "ß". Nur weiß das heute keiner mehr und es sieht komisch aus, da es bei den lateinischen Buchstaben keine zwei verschiedenen "S" gibt und eigentlich ein "langes S" vor dem "Z" steht, woraus sich dann das Schriftzeichen "ß" entwickelt hat.
Ansonsten gibt es hier wirklich schlimmeres Deutsch ...
Muss jeder selber wissen. Ich zumindest kann als Produktivsystem mit einem LFS absolut nichts anfangen. Alleine das aktuellhalten ist ja schon nahezu ein Unding ohne vernünftiges Paketsystem.
Gruß
Herzlichen Glückwunsch.
Wir wissen, was viele andere Leser hier noch vor sich haben ;-).
Bevor hier ein falschen Bild entsteht; ja ich steh zu kldload linux
Gruß
Ja ein bisschen. ;)
Ein anderer Grund war bzw. ist, dass ich rein subjektiv FreeBSD als einfacher empfinde. Das fängt schon beim Übersetzen des Kernels an und hört bei den Ports auf, wo ich noch die Möglichkeit habe, Option X für meine Zwecke umzubiegen. Desweiteren ist es um einiges leichter Jails für den produktiven Einsatz einzurichten, als es z.B. mit Xen oder besser v-server unter Debian ist. Letztenendes sind es aber die häufigen Kernel-Updates, die mich zu FreeBSD getrieben haben. Das muss im Server-Bereich nicht sein. Da kommt man in letzter Zeit zu nichts anderes mehr, nur weil Geek XY jetzt auch den ALDI Dosenöffner unter Linux zum laufen gebracht hat. :s Ich will lieber was solides. :)
Gruß
LFS! Schließlich gibts dazu ein eigenes Kapitel.
Was ist für dich "aktuellhalten"? Die großen Distributionen liefern auch nur Security-Fixes für die
Pakete in ihren Versionen -- der entsprechende Aufwand für ein LFS-System hält sich da auch in
Grenzen. Pakete einer anderen Distribution (auch anderen Version der gleichen Distribution) sollte
man sich eh nicht installieren -- es sei denn man steht auf Instabilität. Und bei single-user
Systemen ist in vielen Fällen sowieso nicht die aller höchste Dringlichkeit gegeben.
A.
Zum Lernfaktor: Wenn du das ganze lediglich Kochbuch mäsig durchziehst wirst du herzlich wenig lernen, aber wenn du dich ein wenig mit den Programmen beschäftigst die du da installiert ist es eine sehr gute Möglichkeit diverse Details eines Linuxsystems zu erfahren: Wie funktioniert der Boot-Vorgang, wie funktioniert das Login genau, vorallem: Welcher Prozess macht was und diverse andere Dinge. Klar, das alles kann man auch anders lernen, aber zumindest für mich waren meine LFS-Versuche vor diversen Jahren keine Zeitverschwendung sondern eine ziemlich schnelle Methode Linux-Interna zu lernen und zu verstehen. Richtig interessant wird es beim Lern-Faktor dann wenn man auf eigene Faust versucht Komponenten des Systems zu ersetzen (z.B. init durch runit und so "Scherze").