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

[oreissig]

(25.04.2015 17:29)gandro schrieb:  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.

(25.04.2015 17:29)gandro schrieb:  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?

[gandro]

(25.04.2015 17:45)oreissig schrieb:  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.

(25.04.2015 17:45)oreissig schrieb:  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.

[oreissig]

(25.04.2015 17:45)oreissig schrieb:  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.

[gandro]

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.

[oreissig]

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.

[gandro]

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.