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.
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.
Zuletzt bearbeitet:
