Ich brauchte mal einen neuen Thread da ich fuer ein aktuelles "Problem" eine Umfrage brauche.
Es geht darum wie EasyLFS in Zukunft an seine zig-millionen User verteilt werden soll.

Huhu,
Wie wärs wenn man wie bei Gentoo eine Minimal-CD rausbringt die nur ein paar MegaByte groß ist und den ganzen Rest aus dem Internet holt?
Und könnte man nicht GRUB benutzen, das ist mir ehrlich gesagt viel lieber als LILO

Gruß

Zitat von Westbär

Huhu,
Wie wärs wenn man wie bei Gentoo eine Minimal-CD rausbringt die nur ein paar MegaByte groß ist und den ganzen Rest aus dem Internet holt?
Und könnte man nicht GRUB benutzen, das ist mir ehrlich gesagt viel lieber als LILO

Gruß

Theoretisch ja, nur muesste ich dann auf der CD alle Moeglichkeiten der Internetverbindung beruecksichtigen und der User muesste dann auch die Moeglichkeit haben diese nutzen zu koennen.
Man kann ja nicht davon ausgehen dass jeder hinter einem Router sitzt.
Das wuerde also bedeuten dass die CD alle moeglichen Netzwerktreiber, inklusive PPP und ISDN braucht. Zudem noch Wireless, wo es dann das Problem gibt dass so einige Karten nur ueber NDISWrapper unterstuetzt werden, welcher nicht Teil von EasyLFS ist.

Eben das macht es etwas problematisch eine NetInstall-CD zu bauen. Und da die CD nun auch nicht so gross ist wie es bei anderen Distributionen der Fall ist, wie z.B. bei Debian, denke ich dass der einmalige Download doch besser ist als der Weg ueber eine Netzinstallation, wo doch eh (fast) alles runtergeladen werden muss (im Gegensatz zu groesseren Distros, wie eben Debian ).

Ich hab zur Zeit nur LILO drin da ich zum einen LILO immer Grub vorgezogen habe, und zum anderen da sich dieser einfacher automatisch konfigurieren laesst. Immerhin kann ich bei LILO ganz einfach mit /dev/... arbeiten, waehrend ich das fuer Grub irgendwie in hd(...,...) umsetzen muesste.
Aber keine Sorge. Irgendwo auf dem Weg zur 1.0 wird auch Grub mit an Bord kommen sodass man dann auswaehlen kann was man will.

So, es war ja nun eine Weile seit ich zuletzt hier gepostet hab.
EasyLFS 0.4 ist ja mittlerweile schon eine Weile verfuegbar und ich hab auch nichts in der Richtung getan.
Jetzt kommt mal was neues. Zur Zeit spiele ich mit Xen rum, und da hab ich mir ueberlegt ob ich EasyLFS nicht irgendwie "xenified" kriege.
Ich kompilier also grad den aktuellen Xen-Kernel von xen.org, 2.6.18-xen, und will dann mal schauen.

Waer ja mal interessant EasyLFS fuer Xen fertig zu machen.

So, wie in meinem Blog gepostet geht es wieder heiter weiter.
Die Diskussionsrunde ist also wieder eroeffnet. Feature-Wuensche koennen gern vorgebracht werden, bevorzugt hier, denn dies ist nach wie vor der Thread zur Diskussion meines Projektes.

Nachdem ich beschlossen habe mir über die Sommerferien mal Unix oder Linux "anzutun" bin ich mal an der Idee von LFS, Gentoo und den FreeBSD Ports hängengeblieben Software aus dem Quellcode möglichst optimiert an die jeweilige Architektur, CPU etc. angepasst zu kompilieren.

Bei Gentoo und den FreeBSD-Ports steckt dann im Hintergrund ja quasi eine große "Bibliothek" an Quellcode und quasi kleinen Korrekturen + Inhaltsangaben der "Maintainer" damit man die Sachen möglichst schnell möglichst einfach und möglichst immer bei sich daheim dann auch durchkompilieren kann.

Wie schaut das dann mit LFS aus?

Wäre es z.B. möglich sowas wie einen Minipaketmanager zu haben, der sich in den Repositories der 50(?) Programme die ich dann auch nutze alle neuen Versionen auscheckt (für ein Bleeding Edge System) und versucht zu kompilieren? Ich nehme mal an, dafür könnte/müsste man ein größeres Shellscript schreiben das dann eben mit SVN, GIT und CVS zurechtkommt - oder gibt's da schon was von Ratioph... irgendnem GPL-Jünger?

Im Normalfall arbeitet LFS ganz ohne Paketierung etc ... dadurch dass wirklich alles aus Stage 1 heraus kompiliert wird und LFS als solches ja eigentlich nur eine Anleitung zum Aufbau eines komplett selbst kompilierten Systems darstellt. LFS ist da nur ein weg, der eine recht ordentliche Gemeinde hat.

EasyLFS beinhaltet ind em Sinne Scripte, die das LFS-Format automatisieren, am Ende ebenfalls ein rudimentaeres, arbeitsfaehiges System bereitstellen.

In wie weit da Paketierungssoftware sinn macht weiss ich nicht ... mich stoert die apt und rpm-Geschichte oft mehr als dass sie hilft, da sie auf aehnliche Systeme zum Teil eklatant schlecht portierbar ist (Anpassungen fuer bestimmte Distries der Pakete etc).

Ich hab mich jetzt auf Slack eingeschossen, in dem sinne auch keine Paketsoftware, aber alles schoen uebersichtlich gestaltet und vor allem selbststaendig anpassbar ...

Das ist mir schon klar, nur fände ich es interessant immer mal die aktuellen Versionen der Programme, die ich nutze auf der Platte zu haben - und das möglichst automatisch.

Wenn ich mich schon in ein anderes Betriebssystem reinfuxe, dann möchte ich das auch verwenden können und nicht nach einem "rudimentären System" aufhören, ein paar Pakete draufklatschen und alle paar Monate dann zig Websites abklappern um zu sehen, ob nicht eines der verwendeten Programme dank offenem Quellcode schon eine fesche Sicherheitslücke aufweist auf die man maßgeschneiderte Exploits loslassen kann. Lieber hätte ich z.B. eine Liste mit den Sourceforge/whatever Quellcodeseiten und das System kompiliert sich dann automatisch neue Versionen, wechselt auf diese und löscht die vorletzte. Wenn die aktuelle nicht funktioniert, geht man auf die Vorgängerversion und schreibt den Entwickler an, was beim Kompilieren schiefgelaufen ist - so profitiert jeder davon.

Ob das mit Linux derzeit möglich ist - keine Ahnung, aber vielleicht wäre das was für (easy)LFS - immerhin ist das ja quasi DIE "Distribution" um Quellcode in Massen zu verarbeiten und möglichst alles anpassbar etc. zu haben.

Zitat von Sukrim

Ob das mit Linux derzeit möglich ist - keine Ahnung, aber vielleicht wäre das was für (easy)LFS - immerhin ist das ja quasi DIE "Distribution" um Quellcode in Massen zu verarbeiten und möglichst alles anpassbar etc. zu haben.

Naja, EasyLFS sicher zu halten ist die Aufgabe des Nutzers, und somit recht aufwaendig, da dieser eben selbst nach Advisories, Patches und Paketen schauen muss, und nicht ueber ein Update-Tool mit neuem Kram versorgt wird wie es z.B. bei Fedora, Debian, etc. der Fall ist.

EasyLFS hat zwar "easy" im Namen, das heisst aber nicht dass es ein System fuer jedermann ist, sondern eben eher ein System das die Installation von Linux from Scratch vereinfacht, und LFS ist nunmal ein System was eher fuer Bastler ausgelegt ist.
(Easy)LFS kann Dir ein schickes System bieten, dafuer musst Du aber auch gewillt sein mit der Mehrarbeit zu leben.

EasyLFS enthaelt uebrigens Dpkg und RPM, welche optional installiert werden koennen. Beide kommen aber mit einer leeren Paketdatenbank daher.

So, ich heb diesen Thread mal wieder aus der Traufe.

Bin grad ueber ein nettes Projekt gestolpert, welches eine Grafische Oberflaeche nur auf gtk+ und den Framebuffer aufsetzt. Nennt sich Xfast 0.9 und wuerde das Arbeiten evtl erleichtern, ohne gleich den sperrigen X-Server mit dem ganzen restlichen Krempel mit zu bringen.

Ich versuchd as grad auf nem normalen Debian 5 zum Laufen zu bringen, muss das einfach mal testen. Waere vllt mal nen Blick wert fuer easyLFS

xfast.wiki.sourceforge.net

Bezüglich der Aktualität diverser Software in einem LFS-System, hab ich mir seit langem,
ein umfangreiches Repertoire an sogenannten Buildscripten erstellt.
Beispiel sind in den Anhängen zu finden.

Ich brauch somit nur die Version zu ändern, Patches entfernen/hinzufügen bzw. notwendige Korrekturen durchführen.

Der/die Download,Konfiguration,Build,Deinstallation,Installation erfolgt dann automatisch beim Aufruf des Buildscriptes.

Schönen Tag noch, man liest sich.
Euer Jens Ornot alias Webstar

So, es sind ein paar Monate untaetig in's Land gezogen, was an einem Hardware-Problem meinerseits lag, aber nun geht es eifrig weiter.

Wie ueblich wurden viele Pakete aktualisiert und meine CPU hat fleissig kompiliert, oft die 32- und die 64-Bit Versionen parallel. Mit meinem neuen Speicher kann ich das ja machen.

Es gab einige Probleme hier und da, aber der groesste Teil davon ist ausgeraeumt.

Im Moment arbeite ich daran die Scripts so umzustricken dass die Libraries der 64-Bit Version alle in die lib64-Verzeichnisse installiert werden damit ich mir die Links von den lib-Verzeichnissen auf die lib64-Verzeichnisse sparen kann.

Dadurch will ich zum einen ein saubereres System erstellen, zum anderen denke ich darueber nach der 64-Bit Version die Moeglichkeit zu geben dass man die GLibC auch in 32-Bit installieren kann und somit ein System bekommt welches sowohl 32- als auch 64-Bit Binaries erstellen kann.

Hi,

schön mal wieder was von LFS zu hören.
Habe zwar im moment keine Möglichkeit weiter mitzuwirken da mir aus berufl. Gründen
die Zeit fehlt, aber testen werde ich das ganze bald mal wieder - immerhin steckt da ja
nun genug Arbeit drin die es auch Wert ist belohnt zu werden

@Dennis hoffe Dir geht es gut !

LG
Andy

Zitat von andy72

@Dennis hoffe Dir geht es gut !

Natuerlich geht es mir gut.
Du weisst doch: Schlechten Menschen geht es immer gut.
Und ich bin ja nun seit 9 Monaten Papa, da kann es einem doch nur gut gehen.

Ja, an EasyLFS hat sich in der Zwischenzeit einiges getan. Auch der SELinux-Support hat sich weiter gebessert und mit der naechsten Version will ich eine richtig gute Policy liefern.
Dafuer hab ich mich auch auf der SELinux-Mailing-Liste eingeschrieben um von dort Hilfe und Informationen bekommen zu koennen.

Grad jetzt kompilieren meine beiden EasyLFS-VMs wieder fleissig vor sich her. Durch den Wechsel auf GCC4 (GCC3 gibt es jetzt nicht mehr in EasyLFS) dauert die Installation aber gleich ein wenig laenger. Dafuer erhoffe ich mir verschiedene Verbesserungen durch die neuen Features die GCC4 bietet.

So, wieder mal ein Update.

Ich hab mittlerweile die aktuelle Test-Version in KVM installiert bekommen und darin diese auch nochmal gebaut. Die aktuelle Version von EasyLFS ist also in der Lage sich selbst zu kompilieren. Zuvor hab ich ja mit einer etwas getunten 0.4 kompiliert.
Im Anschluss an diese beiden Durchgaenge hab ich die Live-Scripts bearbeitet und auch an ein paar anderen Scripts fuer meine LiveCD geschraubt sodass nun auch dieser Teil mehr oder weniger abgeschlossen ist.

Was mir aufgefallen ist ist dass die Nutzung von SMP die Installation nicht gross beeinflusst. Grund scheint zu sein dass make sequentiell arbeitet.
Um die Installation auf SMP-Systemen zu beschleunigen bin ich nun dabei alle Aufrufe von make durch Aufrufe von make -j, gefolgt von der Anzahl an CPUs/Kernen im System, zu ersetzen.
Das sollte beim kompilieren helfen wenn man mehrere CPUs/Kerne hat.

Zudem wird die naechste Version auch keine 2 Kernel mehr beim Booten bieten. Die Auswahl SMP/Nicht-SMP erspare ich dem User indem ich einfach einen SMP-faehigen Kernel auf die CD packe.
Das macht es mir auch etwas leichter bei der Erstellung der LiveCD.