Login


 
Newsletter
Werbung

Sa, 16. Februar 2002, 00:00

GNU/Hurd Status Report 2002-A

Da der Markt an deutschsprachigen Hurd-News noch nicht übersättigt ist, soll an dieser Stelle in unregelmäßigen Abständen darüber berichtet werden, was es Neues in der Hurd-Welt gibt. Da dies die erste Ausgabe dieser Rubrik ist, soll hier erläutert werden, wie die aktuelle Lage aussieht. Ich möchte dabei nichts schönreden, da niemand etwas von enttäuschten Benutzern hat. Dies ist außerdem keine Einführung in die Konzepte des Hurd.

GNU Hurd, oder einfach nur Hurd, ist eine Sammlung von Server-Prozessen, die Dinge wie Dateisysteme und Netzwerkprotokolle bereitstellen und damit einen Ersatz für den Unix-Kernel bilden. Die Hurd-Server laufen auf dem Mach Microkernel. In Kombination mit den anderen GNU-Programmen und weiterer Software wie XFree86 formt Hurd das Betriebssystem GNU/Hurd, das »Hurd-basierte GNU-System«. Debian GNU/Hurd ist eine (bzw. derzeit die einzige) Distribution dieses Systems.

Die oft gestellte Frage nach der Hardware-Unterstützung ist bereits falsch gestellt: Hurd verfügt über keine Hardware-Unterstützung, dies ist Sache des verwendeten Kernels. Um genau zu sein, wird derzeit der Kernel GNUmach verwendet. Dabei wird nicht viel Arbeit in Treiber gesteckt, die sowieso praktisch wertlos wären, wenn das System einmal ernsthaft einsatzbereit ist. Zudem sind Hardware-Treiber nicht Sache von Hurd. Es werden nur noch Änderungen an GNUmach durchgeführt, welche die Stabilität verbessern oder etwas zum Laufen bringen, was unbedingt notwendig ist. GNUmach besteht aus zwei Komponenten: Einerseits die Mach-Schnittstelle und andererseits die Treiber von Linux 2.0. Die Treiber im Kernel zu haben ist nur eine vorübergehende Notlösung, langfristig sollten Treiber natürlich aus dem Kernel ausgelagert werden, soweit möglich. Mittelfristig ist geplant, auf OSKit-Mach umzusteigen, da dieser die Treiber aus dem OSKit verwendet, welches nicht von den Hurd-Entwicklern gepflegt werden muss und derzeit die Treiberunterstützung von Linux 2.2 bietet. Langfristig erscheint es sinnvoll, auf einen anderen Microkernel wie L4 umzusteigen, doch dazu ist einiges an Arbeit erforderlich, mit der noch nicht begonnen wurde. Auch unter L4 könnte das OSKit für die Hardware-Unterstützung verwendet werden, wäre aber dort wohl nicht in den Kernel eingebaut.

Das klingt alles nicht sehr positiv, doch so schlecht sieht es eigentlich gar nicht aus: Etwa die Hälfte der Software in Debian unstable ist unter GNU/Hurd verfügbar und es ist geplant, mit woody+1 auch eine stable-Version freizugeben. Derzeit werden jedoch keine neuen Pakete compiliert, weil die glibc von stdio auf libio umgestellt werden soll (was in der Praxis unter anderem bedeutet, dass C Ein-/Ausgabefunktionen mit denjenigen aus C++ problemlos kombiniert werden können). Zugleich wird auch auf GCC3 umgestellt. Nachdem diese Umstellungen vollzogen sind, wird der »Great Rebuild« der Pakete durchgeführt werden.

Die ausführliche Debian GNU/Hurd FAQ ist dank Henning Riedel und Lars Weber seit einiger Zeit auch in deutscher Sprache verfügbar. Das System ist bereits einigermaßen stabil, d.h. wenn man nicht gerade vergißt, Swap zu aktivieren, obwohl man wenig RAM hat, dann sollten Abstürze nicht an der Tagesordnung sein. Für manche nichtkritischen Einsatzgebiete ist Hurd also prinzipiell brauchbar. Leider ist das System derzeit noch etwas langsam. Es wurden allerdings auch noch keine Optimierungsversuche durchgeführt, noch nicht einmal mit dem Profiling wurde begonnen, aber immerhin ist Unterstützung für Profiling aktiviert.

Der eigentliche Fokus der Entwicklung liegt jedoch darauf, die speziellen Features des Hurd zu vervollständigen und die verbleibenden Fehler zu korrigieren. Shadowfs (womit praktisch mehrere Dateisysteme auf der gleichen Node »gemountet« werden können und somit übereinandergelegt) funktioniert teilweise und mit der Entwicklung eines HTTP-Übersetzers (Translators) wurde begonnen. Ein teilweise funktionierender gopher-Übersetzer existiert, ftpfs ist schon lange brauchbar, NFS ist auch benutzbar, jedoch nicht zuverlässig genug, um z.B. größere Compiliervorgänge über NFS zu betreiben. PPP funktioniert inzwischen auch. Die Größenbeschränkung für Dateisysteme, die dadurch zustande kommt, dass das komplette Dateisystem in den Speicher des Translators eingeblendet wird, existiert leider noch. Die mögliche Größe liegt zwischen 1 und 2 GB: 4 GB RAM sind adressierbar, davon sind 2 GB für den Kernel reserviert, 2 GB stehen dem Dateisystem-Translator für das Mapping der Shared Libs, des Programms, der geöffneten Dateien etc. zur Verfügung.

Inzwischen gibt es eine größere Menge an Übersetzern, die nicht Teil des Hurd sind, sondern von anderen Personen entwickelt wurden. Dazu zählen sowohl einige der oben genannten als auch solche wie memfs (eine Art Ramdisk). Zudem gibt sowohl für Perl als auch für Ruby ein Modul, mit dem einfache Übersetzer entwickelt werden können. Solcher Beispielcode ist leider teilweise die einzige Dokumentation (neben dem Code der Bibliotheken und den Headern), doch es gibt mehrere Leute, die Interesse daran haben, Dokumentation zu erstellen und damit in nächster Zeit beginnen werden. Die fehlende Dokumentation ist wohl für Neueinsteiger die größte Hürde, wobei ich versuche, mit meinem leider noch relativ unvollständigen Hurd Hacking Guide einen leichteren Einstieg zu bieten. Es wäre allerdings wünschenswert, wenn mehr Leute an der Erweiterung und Verbesserung der Dokumentation arbeiten würden.

Es mag zwar von außen so aussehen, als würde die Entwicklung sehr langsam vorangehen, insbesondere da sich auf den Webseiten über Hurd wenig ändert, doch es gibt ständig interessante Neuerungen und positive Überraschungen, manchmal natürlich auch negative, z.B. wurde bemerkt, dass der Treiber für serielle Schnittstellen in GNUmach extrem veraltet war und mit heute üblichen Übertragungsraten nicht mehr funktionierte. Interessant ist aber der Zuwachs an neuen Entwicklern in letzter Zeit, der darauf hoffen läßt, dass das Problem der »lacking manpower« sich bald ein wenig reduziert.

Dass der Hurd-Code sehr portabel ist, hat die von einer einzigen Person durchgeführte Portierung auf die PowerPC-Architektur gezeigt.

Abschließend möchte ich mich noch bei Marcus Brinkmann für seine Verbesserungsvorschläge bezüglich des Artikels bedanken. As it has been said before: Marcus, you rule!

  • Dieses Werk wurde unter der GNU Free Documentation License veröffentlicht. Das Kopieren, Verbreiten und/oder Modifizieren ist erlaubt unter den Bedingungen der GNU Free Documentation License, Version 1.2 oder einer späteren Version, veröffentlicht von der Free Software Foundation.

    - Weitere Informationen
Kommentare (Insgesamt: 0 || Kommentieren )
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung