hurd?

[suhs]

hallo,

ich habe schon oefters gelesen, dass der gnu hurd eine alternative zu linux sei.

deshalb wuerde mich interessieren, welche vorteile es beim hurd gibt bzw. welche probleme?

wer kennt sich da aus?


gruesse
suhs

[stefan.becker]

Hurd ist ziemlich kompatibel zu Bielefeld :-)

Sprich: Version 1.0 gab es nicht, gibt es nicht, und wird es nie / irgendwann /zusammen mit "Duke Nukem Forever" geben (weiss der Geier wann).

Kurz: Die Architektur ist angeblich moderner, eine "problemlos einsatzbare Version" gibt es nicht. Daher ist die Frage relativ theoretisch.

Suchfunktion => microkernel

[jonah]

Hurd ist ziemlich kompatibel zu Bielefeld :-)


... Voooooorsicht ! Du leugnest da meine Existenz :)

;)

[ThorstenHirsch]

Gnu/Hurd ist nicht binärkompatibel zu Gnu/Linux => es gibt (noch) keine nVidia- oder Ati-Treiber dafür => Du kannst kein Quake4 damit spielen.

Damit ist wohl alles gesagt. :ugly:

[Gromobir]

GNU/Hurd hat, wie schon vorher geschrieben, eine lange Entwicklungsgeschichte hinter sich und wird (nach derzeitigem Stand) auch noch eine lange vor sich haben. ;)
Das Konzept, welches hinter dem Hurd Kernel bzw. Mikrokerneln generell steckt ist in der Tat dennoch sehr interessant und meiner Meinung nach auch wert sich damit zu beschäftigen.
Leider ist es bei diesem Projekt so, dass es derzeit keinen "richtigen Maintainer" zu geben scheint. Von Zeit zu Zeit tut sich zwar etwas auf der Mailingliste aber produktiv und vor allem konstant wird offenbar nicht programmiert.

In jüngster Vergangenheit gab es auf der Hurd-L4 Mailingliste einige Diskussionen über den Einsatz von Persistenz (http://de.wikipedia.org/wiki/Persistenz_%28Informatik%29).
und sogar ein neuer Kernel namens Coyotos (http://www.coyotos.org/) wurde ins Auge gefasst. Es bleibt jedoch abzuwarten ob nun gänzlich auf L4 verzichtet werden soll oder dieser doch um die geforderten Features erweitert wird.

Ich hoffe, dass diesen Diskussionen nun auch Taten in Form von Quellcodezeilen folgen, da auf der "GNU/Hurd Mailinglist" bereits treffend bemerkt wurde:
"Wenn für 100 Zeilen einer Diskussion 1 Zeile Code geschrieben worden wäre, wäre GNU/Hurd schon lange einsatzfähig". :)

In diesem Sinne...
Gromobir

[ness]

Da ich mich selber als hurd developer (zumindest alles, was nicht auf mach basiert) sehe will ich auch mal was dazu sagen.

Leider ist es bei diesem Projekt so, dass es derzeit keinen "richtigen Maintainer" zu geben scheint.
Für das hurd/L4 Projekt (das seinem namen wohl nicht mehr gerecht wird, sobald wir wieder mit coden anfangen) ist Marcus Brinkmann maintainer.

Von Zeit zu Zeit tut sich zwar etwas auf der Mailingliste aber produktiv und vor allem konstant wird offenbar nicht programmiert.
Nein, natürlich nicht. Schon vor Monaten wurde (wenn auch nicht allzu laut) festgestellt, dass Hurd/Pistachio aussichtslos ist.

In jüngster Vergangenheit gab es auf der Hurd-L4 Mailingliste einige Diskussionen über den Einsatz von Persistenz.
Eines der Ziele unseres Projektes ist es, nicht nur die performanceprobleme zu lösen (auch wenn das der initiale auslöser war, AFAIK), sondern auch andere grundlegende designprobleme anzugehen. Mit passive translators gibt es ein designtechnisches Problem, das sich mittels persitenz lösen lässt. Da auch coyotos persistent ist, bietet sich das an. Nochmal: persistenz ist ein Mittel zum Zweck, kein Ziel.

und sogar ein neuer Kernel namens Coyotos wurde ins Auge gefasst
Richtig. Das hat mehrere Gründe. Zunächst halten wir coyotos für "planbarer", da mehr zeitdruck/planung existiert. Außerdem halte ich die coyotos entwickler für zugänglicher (darüber scheiden sich die geister...) und coyotos wird in einem offenem tree entwickelt, dass heißt wenn wir wollen, können wir jederzeit die neueste development version benutzen (da ist bei L4ng/L4.sec nicht so).

Es bleibt jedoch abzuwarten ob nun gänzlich auf L4 verzichtet werden soll oder dieser doch um die geforderten Features erweitert wird.
So wie es jetzt aussieht, wird wohl höchstwahrscheinlich ganz auf coyotos umgestiegen. Auch das hat mehrere Gründe. 1. werden nicht wir den microkernel erweitern. Das ist eine extrem kompizierte und kritische aufgabe. 2. Sieht es nicht so aus, als ob in naher Zukunft L4ng/L4.sec code erhältlich sein wird. 3. (ist ein persönlicher punkt) wurde auf dem coyotos-vorgänger EROS ein OS relisiert, dass man annähernd mit hurd vergleichen kann.


Ich hoffe, dass diesen Diskussionen nun auch Taten in Form von Quellcodezeilen folgen, da auf der "GNU/Hurd Mailinglist" bereits treffend bemerkt wurde:
"Wenn für 100 Zeilen einer Diskussion 1 Zeile Code geschrieben worden wäre, wäre GNU/Hurd schon lange einsatzfähig".
Kann sein. Tatsächlich gibt es auch bei uns oft streit, ob diese methode des design-bis-perfekt dann implementierung richtig ist. Fakt ist, dass ein so komplexes OS gut geplant sein will.

[koxbox]

hurd ist etwas das NIE fertig wird :-)

[ThorstenHirsch]

Also der Spruch ist jetzt aber etwas unpassend, nachdem uns ness diesen interessanten Blick hinter die Kulissen gewährt hat.

[suhs]

hallo ness,

ich hatte dir vor ein paar tagen eine private nachricht geschickt.

kannst du vielleicht bitte mal anworten?


vielen dank!
suhs

[Gromobir]

@ness: Vielen Dank für deinen interessante Einblick in den aktuellen Status der Entwicklung.

Ich wollte meinen Beitrag auch nicht als negative Kritik an GNU/Hurd verstanden wissen, sondern lediglich als Überblick für Neulinge, was du jedoch um einiges besser beschreiben konntest.

Ich freue mich im Gegenteil über viele Leute aus dem "GNU/Linux Lager", die sich für den Einsatz von Mikrokerneln interessieren.
Die derzeitigen Diskussionen über die Zukunft der verschiedenen Kernel (Mach, L4, Coyotos) hindern mich im Moment jedoch eher daran mich auf ein System festzulegen, welches ich testen könnte.
Sollte sich dort jedoch bald etwas ändern, wäre ich gerne bereit auch etwas produktives beizutragen obwohl ich mir (noch) nicht zutrauen würde, direkt an der Kernelentwicklung oder anderen tiefergreifenden Anwendungen "herumzudoktorn".

In diesem Sinne...
Gromobir

[lfhelper]

hallo,
...
deshalb wuerde mich interessieren, welche vorteile es beim hurd gibt ...?
...

Hurd ist die "first software to be named by a pair of mutually recursive acronyms."

Das kann Linux nicht bieten. :)

Gruss,
lfhelper.

[Stephanw]

Kann das sein, das GNU/Hurd so ein bisschen mit dem BeOS-System vergleichbar ist?
Auf Beos gibt es ja neben dem Kernel (vgl. Mach,L4,Weiss der Teufel) auch Server/Dienste, die die Systemfunktionalität (Treiber, Protokollstacks, ...) implementieren (->vergleichbar HURD).

Also ich finde es seltsam, das GNUs Software bis auf das eigentliche Betriebssystem schon seit Jahren in hervorragender Qualität fertiggestellt ist. GNU ist doch älter als Linux, oder? Warum kommt denn ein Linux daher und stiehlt dem GNU/Hurd die Show?

Mich persönlich würde es echt freuen, wenn das mal was wird. Würde das System gerne mal in Betrieb nehmen.

Gruß Stephan

[ness]

Kann das sein, das GNU/Hurd so ein bisschen mit dem BeOS-System vergleichbar ist?
Auf Beos gibt es ja neben dem Kernel (vgl. Mach,L4,Weiss der Teufel) auch Server/Dienste, die die Systemfunktionalität (Treiber, Protokollstacks, ...) implementieren (->vergleichbar HURD).Ich kenne BeOS nicht, aber was du jetzt zum vergleich herangezogen hast nennt man multiserver architektur.


Also ich finde es seltsam, das GNUs Software bis auf das eigentliche Betriebssystem schon seit Jahren in hervorragender Qualität fertiggestellt ist. GNU ist doch älter als Linux, oder? Warum kommt denn ein Linux daher und stiehlt dem GNU/Hurd die Show?Ich finde das nicht so seltsam.
Einerseits ist mit linux der druck weg, dass umbedingt ein brauchbarer freier kern her muss (und *bsd gibts ja auch schon länger).
Andererseits ist Hurd von der architektur her viel anspruchsvoller als Linux oder *bsd, womit sich auch einfach erklären lässt, wie Hurd sozusagen "im nachhinein von linux überholt wurde".
Und als dritten Punkt möchte ich noch anführen, dass die Zeit damals einfach noch nicht reif war für ein freies multiserver OS. Wenn Hurd in seiner jetzigen implementation auf einem ordentlichen second gen microkernel liefe, wären zwar nicht alle probleme beseitigt, geschweigedenn das System problemlos nutzbar, aber es wäre benutzbar, was eine der Hauptvoraussetzungen für wirklich aktive Entwicklung ist.


Mich persönlich würde es echt freuen, wenn das mal was wird.Das ist schön zu hören. Ich denke mal ich kann dir versichern, dass wir unser bestes geben.

Würde das System gerne mal in Betrieb nehmen.Wenn du willst, kannst du Hurd/Mach probieren. Images findest du im internet, und zumindest das, was ich habe, bootet in qemu.

[TCA]

Zum Thema qemu und hurd möchte ich mal folgenden Link beisteuern.

http://www.zabor.org/balrog/hurd/

Ist ein fertiges Image, was mit Qemu ohne Installation läuft.

[Stephanw]

Also,

ich hab mir mal einen alten 450 MHz Testrechner an Land gezogen. Da habe ich gestern mal ne Hurd-Live-CD reingeschmissen. Das System startete ganz normal und ich konnte ein bissel in der Konsole spielen. Dass das System nicht wirklich stabil lief (musste mehr als eimal hochfahren) lag dabei eher an meinem PC, der wirklich aus dem allerletzten Loch pfeift. Ansonsten sah das schon ganz nett aus.

Ich könnte mir vorstellen, das die Kombination GNU/Hurd mit X und einem WM nach wunsch (KDE, GNOME, ...) im Desktopbereich leichter zu handhaben ist; insbesondere für Anfänger. Wäre schön wenn das System noch vor Duke Nukem Forever in einer einigermaßen stabilen Version zur Verfügung stehen würde; idealerweise auch für 64-bit. Ich denke das die fehlenden Treiber leicht ergänzt werden könnten, da es ja schon sehr viele OpenSource-Treiber gibt, denen man die Funktionsweise der Geräte durchaus entnehmen könnte...

Gruß Stephan

[ness]

Also,

ich hab mir mal einen alten 450 MHz Testrechner an Land gezogen. Da habe ich gestern mal ne Hurd-Live-CD reingeschmissen. Das System startete ganz normal und ich konnte ein bissel in der Konsole spielen. Dass das System nicht wirklich stabil lief (musste mehr als eimal hochfahren) lag dabei eher an meinem PC, der wirklich aus dem allerletzten Loch pfeift.Unwahrscheinlich. Hurd/Mach ist extrem langsam und instabil. Das hat (normalerweise) nix mit deinem Rechner zu tun.
Ansonsten sah das schon ganz nett aus.

Ich könnte mir vorstellen, das die Kombination GNU/Hurd mit X und einem WM nach wunsch (KDE, GNOME, ...) im Desktopbereich leichter zu handhaben ist; insbesondere für Anfänger. X ist durchaus portiert. Ich hab auch schon mal Hurd/Mach mit X + nem wm gesehen, ist aber wirklich extrem langsam (lies: nahezu unbenutzbar).
Wäre schön wenn das System noch vor Duke Nukem Forever in einer einigermaßen stabilen Version zur Verfügung stehen würde; idealerweise auch für 64-bit. Ich denke das die fehlenden Treiber leicht ergänzt werden könnten, da es ja schon sehr viele OpenSource-Treiber gibt, denen man die Funktionsweise der Geräte durchaus entnehmen könnte...Das Problem ist die schiere masse an treibern. Einen treiber von einem OS auf ein anderes zu portieren ist normalerweise machbar, aber wenn man die treiber auf breiter front wiederverwenden will, ist es unakzeptabel, jeden treiber einzeln zu portieren. Und das problem mit wrappern/bindings ist, dass es sich als sehr schwer heruasgestellt hat, welche zu schreiben (siehe gnumach 2.0), zumal in einer microkernelumgebung (da die meisten treiber ja für monolithische kerne sind). Es scheint aber einen recht vielversprechenden ansatz zu geben [1].

[1] LeVasseur und Uhlig, A Sledgehammer Approach to Reuse of Legacy Device Drivers