# Arbeitstitel "uClibc-LFS" Projektthread



## Laudian (21. April 2009)

So, die ersten 2-3 Wochen Brainstorming sind durch, nun reift langsam die Grundidee, wie sich die Distributionsidee auf Linux-Kernel darstellen koennte.

Ziel des Ganzen ist es, eine moeglichst kleine und schnelle Distribution zu bauen, die nicht auf den ueblichen Paketquellen aufbaut und damit kein Fork von Debian, Knoppix oder aehnlichen werden soll.

Ein weiteres Ziel wird sein, den X-Server zu umgehen. Dazu soll die Online-Desktop-Technik aehnlich wie EyeOS eingesetzt werden. Ein Webserver alias lighttpd wird genutzt um einen Browser der im Vollbildmodus auf dem Framebuffer liegt zu Speisen. Hier koennte bsw der in der letzten Woche in 1.0 erschienene Prism von Mozilla genutzt werden, der es erlaubt, Webapplikationen als lokale Anwendungen zu nutzen. Allerdings soll die Weboberflaeche auf den normalen lokalen Content zurueck greifen und nur frameworks wie gtk+ oder qt ersetzen, was effektiv weniger Rameinsatz zur Folge haben duerfte, im lokalen Einsatz auch schneller sein duerfte und vor allem ohne jegliche Probleme die Internet-Welt offen haelt, sofern sich Mittel finden, die Uebertragung sicher zu machen, so dass ein Thinclient-System auch ueber Intranetze oder Inet (TCP oder UDP) moeglich wird.

*Angedachte Software als Grundstock:*

Binutils 2.19.1
GCC 3.4.6
uClibc 0.9.30.1
dash 0.5.5.1
linux Kernel 2.19.x 
Python/Perl/php in aktueller Version
lighttpd
prism
FBdev
etc ... ist noch nicht vollstaendig und wird erweitert!


*Eine 2. Nutzungsmoeglichkeit, Respektive spezielles Anwendungsgebiet:*

Ein interessantes Gespraech letzte Woche hat mich auf eine zugegebenermassen verrueckte Idee gebracht. 

Die Fragestellung ist:
Was passiert, wenn man die typische Bios-Technik wegschmeisst, ein Minimallinux (aehnlich Linuxbios oder Coreboot) aufsetzt, diesem "Bios" ein Xen-Host ueberstuelpt und somit eine Art VM-Server-Bootloader baut?

Resultat waere ein Bios, welches die Betriebssysteme, welche installiert werden aktiv steuert und somit das alt bekannte Problem von Monosystemen loesst. So liesse sich ueber die VM und entsprechende Treiber jeder Kern der CPU fuer ein einzelnes OS nutzen, oder je nach Einstellung ueber das Bios auch mehrere OS pro Kern oder mehrere Kerne pro OS ... Somit lassen sich defakto mehrere OS parallel betreiben, sie muessen nicht mehr von einem Host auf einer Festplatte kontrolliert werden, sondern existieren quasi nativ parallel und koennen somit die Hardware auf einem modernen PC-System (in der Wirtschaft interessant) erheblich besser  auslasten. So lassen sich mehrere Server-Betriebssysteme parallel laufen lassen, im Unixfall sind das dann mehrere Multiuser-Systeme, so dass hier viel mehr Handlungsspielraum entsteht.

Im Privaten Bereich liesse sich hier ein Windows und ein Linux fuer verschiedene Zwecke wirklich parallel betreiben und je nach Einstellung auch die Grafikkarte nativ bsw durch Windows nutzen um Spiele (Windows) und Arbeit (Linux/BSD) parallel nutzen zu koennen.

Die Oberflaeche fuer den Dom0 wuerde dann quasi eine Art Bootloader fuer die DomU s enthalten, in dessen oberflaeche automatisch gebootet wird, wodurch sich fuer einen normalen Anwender weitgehend nichts aendert. Der Admin koennte sich im Bios wie an jedem anderen Linux anmelden und Einstellungen als root durchfuehren ... 

Die Softwareliste waere aehnlich der fuer die regulaere Distribution, natuerlich ohne Kompiler etc ... 

*Thema Bootsequenz*

Da ich in jedem Fall auf eine wesentlich rudimentaerere Shell setzen werde, hab ich vor die ebenfalls komplett abzuaendernden Bootscripte gleich aus der Shell-Version zu entfernen. Hier ist angedacht eine reine Scriptsprache wie Perl oder Python zu nutzen. Diese sollte hier Perfomrance liefern koennen, was den Bootvorgang beschleunigen soll. Effektiv ist es egal, ob alte Bootscripte umgeschrieben werden, oder ganz neue erstellt werden. 

*Paketmanagement*

Da kein aktuell bestehendes Paketmanagement genutzt wird, zumindest ist das bisher nicht geplant, weiss ich noch nicht, ob ich mir das antue, ein System zu erdenken, dass gewisse Aehnlichkeit mit emerge von Gentoo haben koennte (on the fly-compiling beim Installieren). Hier wird noch viel Ideenflut auflaufen.

*Login ... passwd/shadow*

Aufgrund der Nutzung von Perl oder Pyhton-Scripten fuer den Bootvorgang und den Rest der wichtigen Systemscripte, halte ich es fuer moeglich, auch den Login umzustellen. Hier bieten die genannten Scriptsprachen ja erhebliche Moeglichkeiten bsw in Verbindung mit einer Datenbank ala SQLite zu arbeiten. Dadurch wuerde sich unter anderem die Last auf das Dateisystem reduzieren ... 

Auch hier ist noch viel zu ueberlegen.

---------------------------------------------------

Bisher finden sich ausschliesslich Ideen in den oben genannten Punkten. Das Ganze ist noch mehr ein Hirngespinst als dass man es als Plan bezeichnen kann. Aber ich bin mir sicher, dass es theoretisch realisierbar ist. 

Derzeit setze ich einen Blog auf Wordpress auf um das Projekt auch sinnvoll verwalten zu koennen, allerdings wird das noch etwas dauern, bis der ansehnlich und mit ersten Beitraegen gefuellt ist.

Was die Anspielung an einen Online-Desktop angeht, wird sich zeigen, ob das ein eigenes Projekt werden soll, oder mit ein Teil Dieses.

-------------------------------------------------

Stand der Dinge ist, dass ich mit der Toolchainerstellung fuer uclibc am Basteln bin, bisher gibt es noch einige Probleme ... Allerdings, sollte die Toolchain lauffaehig werden, wird sie hoffentlich als LiveCD exportierbar werden.

PS, ueber Anregungen, skeptische Kommentare und weitere Ideen bin ich erfreut ... genauso ueber Leute die mitmachen wollen ... das Ganze soll unter GPL oder LGPL gestellt werden, was genau am Ende fuer ne Lizenz drauf kommt weiss ich noch nicht, das muss noch gut ueberlegt werden.

Edit: Im Speziellen wird noch ein passender Titel gesucht ... unter dem das Projekt erscheinen kann, bsw fuer den Blog.


----------



## Dennis Wronka (21. April 2009)

Laudian hat gesagt.:


> Linux-Kernel: Hier schwanke ich noch, ob Dinge wie Hal oder aehnlich blaehende Gebilde mit genutzt werden sollen. Ich halte sie fuer ueberfluessig und wuerde lediglich das absolut notwendige mit rein packen. Hier gibts entsprechend noch jede Menge zu ueberlegen.


HAL ist nicht noetig. Vor allem bringt HAL noch einige Abhaengigkeiten mit sich, darunter z.B. D-Bus und eben noch anderer Kram.
HAL ist nett wenn man in einer vollstaendigen Desktop-Umgebung (wie z.B. KDE oder Gnome) arbeitet um z.B. zu erkennen dass ein USB-Stick eingestoepselt wurde und dergleichen, aber ich denke dass was auch immer Du im Endeffekt aufbaust es HAL wahrscheinlich eh nicht nutzen wird. Entsprechend ist HAL fuer Dich meiner Meinung nach voellig ueberfluessig.
Ich hab es in EasyLFS mit drin (optional) da EasyLFS ja auch die Moeglichkeit bieten soll ein vollstaendiges Desktop-System bis hin zu KDE/Gnome/... installieren zu koennen, und somit finde ich die Option HAL installieren zu koennen schon angebracht.
Aber ich schweife ab...

UDev hingegen wuerde ich auf jeden Fall mitnehmen. Und da UDev von HAL unabhaengig ist brauchst Du HAL nicht damit UDev erkennen kann dass, um das vorige Beispiel aufzugreifen, ein USB-Stick eingesteckt wurde und das entsprechende Device zu erstellen.
UDev ist auch ziemlich klein (die Fedora-Pakete wiegen weniger als 1MB), somit wuerde ich sagen dass der Nutzen den UDev bringt den Speicherverbrauch deutlich ueberwiegt.


----------



## Laudian (21. April 2009)

Das ist schon mal eine gute Nachricht, so genau hatte ich mich mit HAL noch garnicht befasst, da derzeit die Toolchain ansich mehr Probleme macht ....

Udev ist ansich eine gute Sache und wird sicher ausprobiert werden. Wenn das wirklich so klein ist, dann sollte das kein grosses Problem sein.


----------



## Laudian (10. Mai 2009)

So, nach etwas Zeit des Brainstormings hat sich die Geschichte etwas konkretisiert. 

Die Testlaeufe fuer die uclibc Toolchain haben begonnen, noch hab ich allerdings meine Probleme. Aber es geht langsam aber sicher mit dem Konzept Vorran.

Ein Projektblog ist derzeit am Entstehen, sobald er vorzeigbar ist, wird die Adresse veroeffetnlicht.


----------



## saftmeister (25. September 2011)

Hi,

ist ja nett, das es diesbezüglich schon früher Ideen gab. Ich habe vor einem halben Jahr etwas ähnliches auf Fedora basierend aufgebaut. Mit DirectFB, Webkit  und Mono habe ich einen Webbrowser gebaut, der auf dem Framebuffer EyeOS laden konnte. Falls noch Interesse besteht, kann ich das gern veröffentlichen, mit samt allen Patches die nötig waren - versteht sich.

Ich habe die Idee mit uclibc auch gehabt, bin aber ebenfalls an der Toolchain gescheitert - bislang. Wie weit ist das Projekt fortgeschritten oder wurde es sozusagen eingestellt?

Wäre daran echt interessiert.


----------



## saftmeister (3. Oktober 2011)

Sorry für Doppel-Post. Nur falls es noch jemanden interessiert: Ich habe zwei interessante Dinge gefunden:

- Cross-LFS Ein LFS für Embedded Systeme. Leider habe ich noch kein Bootfähiges Environment damit hinbekommen.
- buildroot Eine uclibc-Umgebung, die man mittels 'make menuconfig' komplett erstellen kann. Hier habe ich ein chroot-System und arbeite grad am Kernel. Leider passieren grad im Perl- und Bash-Umfeld leider noch sehr viele Segfaults und andere Fehler.


----------



## Laudian (3. Dezember 2011)

Moin,

hab leider keine Zeit mich da aktuell weiter drum zu kuemmern. Jobumfeld hat sich geaendert.
Interesse besteht nach wie vor, aber zeitlich siehts aktuell und woh, auch zumindet fuers naechste Jahr mies aus.


----------

