GNU Hurd 0.6 ist da, oder: »Der allgemeine GNU-Hurd-Thread«

systemd ist super!111

Ich fand das ja schon lustig, dass Hurd nun auch SysV-init hat. Mit fortschreitender systemdifizierung der linuxlandschaft gelingt Hurd womöglich endlich der große durchbruch!

Zitat von mrshadowtux

Hurd hat doch ganz andere Probleme, es fehlt überall noch die Hälfte. Wobei deren Microkernel-Architektur imho besser zur Unixwelt passt, als der monolithische von Linux.

Du weißt schon, dass praktisch alle Unixkernel monolithisch sind?
Die erfolgreichen zumindest. HURD … na siehste ja selber.

Zitat von thosch97

Du weißt schon, dass praktisch alle Unixkernel monolithisch sind?

Finde mrshadowtux hat da aber schon nen Punkt: Der modulare, abgekapselte, simpel gehaltene Aufbau vom Unix-Userspace passt nicht so recht mit einem monolithischen Kernel zusammen. Mikrokernel gehen viel besser mit der Unix-Philosophie zusammen.

Verstehe aber eh nicht so recht, warum GNU Hurd nach wie vor soviel Aufmerksamkeit kriegt. Der Mach-Microkernel ist schon seit den 90ern nicht mehr State of the Art was Microkernel angeht, Konkurrenten wie L4 haben sich jenseits vom Server/Desktop-Markt ja auch eher durchgesetzt und Architekturen wie der Exokernel sind sowieso vielversprechender.

Zitat von gandro

Der modulare, abgekapselte, simpel gehaltene Aufbau vom Unix-Userspace passt nicht so recht mit einem monolithischen Kernel zusammen. Mikrokernel gehen viel besser mit der Unix-Philosophie zusammen.

Der Unix-Userspace ist so gemacht, um dem User die Flexibilität in seiner täglichen Arbeit zu geben. Mit dem Kernel arbeitet nie irgendjemand direkt zusammen, insofern ist die interne Struktur des Kernels in etwa so wichtig wie die interne Implementierung von bash oder gcc. Nämlich gar nicht.

Für den User wärs dann nett, wenn sich aus der besseren Struktur des Kernels handfeste vorteile ergeben würden, z.B. dass das Ding stabiler ist und die Entwicklung wegen der besseren Komponentisierung womöglich schneller wäre, aber GNU Hurd ist nach wie vor auf dem Stand von Linux 2.0 oder so, und instabilität des Linuxkernels ist von allen Problemen im Umfeld freier Software das kleinste.

Kurzum: Microkernel versuchen mit viel overhead ein Problem zu lösen, was nicht existiert.

oreissig:

Der Overhead von Mikrokerneln ist ein Mythos (an dem Mach die Hauptschuld trägt) der seit den 90ern widerlegt ist. Das Performance-Argument lässt sich für Exokernel (die bestreitbar Ableger der Mikrokernel-Philosophie sind) sogar umdrehen: Die Kontextswitch-Kosten bei für I/O notwendigen Syscalls bei monolithische Kerneln sind für viele Anwendungen heutzutage der Performance-Blocker schlichthin, ein Problem was Exokernel lösen: 84% of a single-threaded 1KB write in Redis is spent in the kernel

GNU Hurd hat damit freilich nichts zu tun, da es wie oben schon beschrieben nach wie vor auf Pre-Liedtke-Technologie aufbaut. Aber Mikrokernel sind deswegen noch lange nicht tot. Ich verweise hier wie immer darauf, dass die ganzen Android-Services mit Binder eine Mikrokernel-Architektur parallel zum Linux-Kernel aufgebaut haben; und dass mit systemd/kdbus auch Desktop-Linux in Zukunft in die Richtung gehen wird.

Das Nutzen-Argument finde ich ist halt auch nicht so einfach. Klar ist es dem User egal ob das jetzt nen Mikrokernel ist oder nicht, wie es damals auch den Usern unter MS-DOS oder MacOS egal war, dass sie keine Trennung zwischen Prozessen haben. Ich glaube die User fändens trotzdem sehr cool wenn nen buggy USB-Treiber mir nicht den kompletten Kernel hijackt.

Ich teile aber die Einschätzung, dass GNU Hurd niemals mehr gross auskommen wird. Denn für den Erfolg im Consumer-Markt ist erstmal wichtig, dass Treiber und Applikationen verfügbar sind - das ist komplett unabhängig von der Kernelarchitektur. Momentan sehe ich den Durchbruch von Mikrokerneln auf Consumersystem* nur in Form von einem Hypervisor, wo das Legacy-OS für den Benutzer virtualisiert wird. So ähnlich wie der Windows 10 Device Guard oder der PlayStation3 OtherOS-Modus. Die deren Hypervisor waren zwar keine Mikrokernel, könnten es aber problemlos sein.

*Obligatorische Nebenbemerkung, Mikrokernel finden sich bei Consumergeräten natürlich schon: Eine von Apple modifizierte Variante von L4 läuft auf jedem Apple SoC seit dem Apple A7, als OS für die Secure Enclave. Oder bei manchen Qualcomm SoCs auf dem Baseband.

Zitat von gandro

Ich teile aber die Einschätzung, dass GNU Hurd niemals mehr gross auskommen wird.

https://xkcd.com/1508/

Zitat von gandro

Ich verweise hier wie immer darauf, dass die ganzen Android-Services mit Binder eine Mikrokernel-Architektur parallel zum Linux-Kernel aufgebaut haben; und dass mit systemd/kdbus auch Desktop-Linux in Zukunft in die Richtung gehen wird.

das ist aber auf dem makrolevel. man könnte auch argumentieren, dass das kein microkernel auf userlandebene ist, sondern Single Machine SOA, nur um mal nen anderes Buzzword zu pullen Abstraktionen auf Basis lose gekoppelter Einheiten gibts überall und das ist schon prinzipiell eine gute Idee, aber der benefit ist für die daran schraubenden Developer eigentlich größer als die Auswirkungen, die man als User so merkt.

Zitat von gandro

Das Nutzen-Argument finde ich ist halt auch nicht so einfach. Klar ist es dem User egal ob das jetzt nen Mikrokernel ist oder nicht, wie es damals auch den Usern unter MS-DOS oder MacOS egal war, dass sie keine Trennung zwischen Prozessen haben. Ich glaube die User fändens trotzdem sehr cool wenn nen buggy USB-Treiber mir nicht den kompletten Kernel hijackt.

ja aber wie häufig kommt denn das vor? Man wechselt seine Treiberlandschaft nicht so oft, gerade bei den ganzen embedded systems (das schließt explizit alle Smartphones und Tablets ein) wird die gesamtmenge der Treiber sogar händisch zusammengestellt und verifiziert. Treiber in User Space sind halt vor allem geil, wenn man selbst Treiberentwickler ist, aber sonst?

Zitat von oreissig

das ist aber auf dem makrolevel. man könnte auch argumentieren, dass das kein microkernel auf userlandebene ist, sondern Single Machine SOA, nur um mal nen anderes Buzzword zu pullen

Hauptgrund warum ich das in die Mirkokernel-Ecke gestellt habe, weil sie Inter-Process RPC via Kernel machen, also durchaus den Kernel wie einen Mikrokernel verwenden.

Zitat von oreissig

Treiber in User Space sind halt vor allem geil, wenn man selbst Treiberentwickler ist, aber sonst?

Treiberentwicklung ist nach wie vor ein unheimlicher Schmerz. Treiber im Userspace debuggen zu können war ja die Grundmotivation für NetBSDs Rumpkernel. Wenn die Entwickler weniger Zeit mit Hexaddressen von Bluescreens abtippen verbringen und sich mehr mit interessanteren Problemen beschäftigen, dann profitiert der User letztendlich auch davon. Gerade wenn man (wie das Rumpkernel-Projekt es auch macht) die Definition von Treiber generell auf klassische In-Kernel-Funktionalität (TCP/IP-Verarbeitung etc) erweitert.

Zitat von oreissig

Wenn die Entwickler weniger Zeit mit Hexaddressen von Bluescreens abtippen verbringen und sich mehr mit interessanteren Problemen beschäftigen, dann profitiert der User letztendlich auch davon.

genau das ist der Kern meiner Argumentation: diese Art von Vorteilen find ich super. bei Hurd seh ich das aber nicht, dass die tiefergehendere Abstraktion sich in erhöhter Effektivität niederschlägt, im gegenteil die kämpfen seit äonen mit den trivialsten OS-aufgaben, die woanders längst gelöst sind. Da stell ich mir halt die Frage, ob das erhoffte Wunderwerkzeug vielleicht doch von anfang an ein totes Pferd war.

Dass das zur Steuerung von Mobilfunkchips super funktioniert ist schön und gut, aber vielleicht hat ein Desktop-OS doch andere Anforderungen.

Ist bisschen wie bei Serverprogrammierung, das ist auch ganz grundlegend was anderes als GUI-Apps zu schreiben. Für das eine ist Java nach wie vor alive and kicking, beim anderen ists zurecht in der Versenkung verschwunden.

Da hast du schonen validen Punkte. Ich halte ich GNU Hurd allerdings für das denkbar schlechteste Beispiel was die Schönheit von Mikrokernel-Architektur angeht. Und da in praktisch keinem Aspekt technisch überlegener als Linux ist, hat da natürlich keiner Lust dafür zu entwickeln. Projekte wie NetBSD oder MirageOS hätten da eher Chancen aufgrund ihrer Software-Engineering-Qualitäten Leute zu rekrutieren.

Letztendlich lohnt es sich halt nicht, gegen ein Linux oder Windows in den Kampf steigen zu wollen. Da sind abseits vom OS-Kern (Speicher- und Prozessverwaltung) tausende Personenjahre an Treiber- und Applikationsentwicklung drin, selbst wenn man mit $AlternativOS um Faktor 10x schneller entwickeln könnte weil es ne geile modulare Mikrokernel-Architektur hat, bräuchte man immer noch Horden von Programmierern um ein Desktop-OS hinzukriegen.

NetBSD mit seinem anykernel krams ist da schon deutlich interessanter, wobei selbst die noch viel zu obskur für irgendwelche realistische Benutzung außerhalb von embedded sind.

Mit DeforaOS gibt es jedenfalls ein aus dem NetBSD-Umfeld kommendes OS mit dem Desktop als Ziel. Hauptsächlich allerdings nur eine Person als Entwickler Cooler Typ allerdings, hab mit dem mal ne Mate getrunken.