-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ein sehr guter Artikel (Englisch) zum Thema im Betreff, wie ich finde: http://www.h-online.com/open/features/GNU-HURD-Altered-visions-and-lost-prom...
LG Alex
- -- Alexander Kahl GNU/Linux Software Developer
Moin, bei allem Respekt vor GNU und seinen Leistungen aber ich finde das GNU/Hurd vaporware ist. Etwas das im Moment niemand braucht, da Linux und die BSD Varianten genug freie Auswahl bieten. Wenn wir es bräuchten würde es GNU/Hurd geben, wenn man sich git ansieht weiss man welche Entwicklungen möglich sind wenn die Software gebraucht wird. Gruss Arnulf
2010/7/2 Alexander Kahl e-user@fsfe.org:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ein sehr guter Artikel (Englisch) zum Thema im Betreff, wie ich finde: http://www.h-online.com/open/features/GNU-HURD-Altered-visions-and-lost-prom...
LG Alex
Alexander Kahl GNU/Linux Software Developer -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkwtpkEACgkQVTRddCFHw11ofwCcD9lXHQRy+Q918DrDpiAmPDFs g/kAoL+CEx1qprH5rFweSwvSJsR8oUbT =tR4t -----END PGP SIGNATURE----- _______________________________________________ fsfe-de mailing list fsfe-de@fsfeurope.org https://mail.fsfeurope.org/mailman/listinfo/fsfe-de
--
Am 02.07.10 18:30, schrieb Arnulf Pelzer:
Moin, bei allem Respekt vor GNU und seinen Leistungen aber ich finde das GNU/Hurd vaporware ist.
Ja, es gibt ja solche "Running Gags", die in der Richtung gehen, dass z. b. im Jahr 2030 der Release-Canidate von Hurd 1.0 erscheinen soll.
Etwas das im Moment niemand braucht, da Linux und die BSD Varianten genug freie Auswahl bieten.mailman/listinfo/fsfe-de
Ja, mit Linux und BSD gibt es unixoide System, die für den Produktionseinsatz geeignet sind. Das hat natürlich zur Folge, dass viele Entwickler eben zu diesen attraktiven Projekten gezogen werden, während GNU/Hurd und Mimix ein Nischendasein führen Diese System sind z. Z. noch nicht einmal in der Lage die minimalen Requirements für den Einsatz auf zeitgemäßen produktiven System auszuföllen.
mfg: Jochen Schmitt
Alexander Kahl e-user@fsfe.org schrieb:
Ein sehr guter Artikel (Englisch) zum Thema im Betreff, wie ich finde: http://www.h-online.com/open/features/GNU-HURD-Altered-visions-and-lost-prom...
Es gibt dazu einen hochinteressanten Insider-Bericht in den "Hacker News" (oberstes Kommentar):
http://news.ycombinator.com/item?id=1474941
Auch die übrigen Kommentare sind sehr lesenswert.
Zum Beispiel der Hinweis auf große Parallelen zu einem aktuellen Trend in der Virtualisierung:
http://news.ycombinator.com/item?id=1476188
Auch sehr interessant finde ich die Anmerkung, dass man mit FUSE & Co. letztendlich nur versucht, die fehlenden HURD-Features auf den Kernel oben drauf zu bauen:
http://news.ycombinator.com/item?id=1475938
Das erinnert mich daran, wie man mit Ajax & Polling verzweifelt versucht, dynamische Webseiten trotz HTTP-Zwang zu bauen. Man "löst" dort Probleme auf eine sehr umständliche Weise, die eigentlich kein Problem wären, wenn man sie auf einer tieferen Ebene angeht (HTTP erweitert bzw. gegen etwas anderes austauscht).
Klar, es "geht" auch über HTTP, vorallem wenn man HTTP so sehr beugt, dass es weh tut (Stichwort BOSH). Von daher "braucht" man nichts besseres als HTTP, aber es wird halt umständlich, instabil und fehleranfällig.
Gruß Volker
Am 03.07.10 16:57, schrieb Volker Grabsch:
Auch sehr interessant finde ich die Anmerkung, dass man mit FUSE& Co. letztendlich nur versucht, die fehlenden HURD-Features auf den Kernel oben drauf zu bauen:
Ja, und auf dem Linuxtag soll laut meinen Informationen einen Vortrag über die aktuellen Herausforderungen der Kernelentwicklung gegeben haben, in der unter anderen ausgeföhrt wurde, dass die ohoen I/O-Raten von SSDs Probleme in der Kernelentwicklung bereiten sollen.
Bei FUSE hat man aber, wie auch bei anderen Konzepten, die z. B. für Minix entwickelt wurden, das Problem, dass durch den Taskswitch wertvolle CPU-Zeit verloren geht.
Das erinnert mich daran, wie man mit Ajax & Polling verzweifelt versucht, dynamische Webseiten trotz HTTP-Zwang zu bauen. Man "löst" dort Probleme auf eine sehr umständliche Weise, die eigentlich kein Problem wären, wenn man sie auf einer tieferen Ebene angeht (HTTP erweitert bzw. gegen etwas anderes austauscht).
In diesem Bereicht hat man zwei Probleme:
1.) HTTP ist ein verbindungsloses Protokoll bei dem die Informationen zwischen den Dialogschritten auf em Server verloren gehen. Dies erinnert mich an IMS-Transaktionen, bei denen Informationen in Dunkelfelder gespeichert wurden.
2.) Man will den Komfort einer nativen GUI-Anwendung haben, ohne dass man einen Anwendung auf einem Endgerät installieren muss.
Beide Anfroderungen führen zu dem RIA-Trend, den man z. Z. erleben kann.
mfg: Jochen Schmitt
Jochen Schmitt Jochen@herr-schmitt.de schrieb:
Bei FUSE hat man aber, wie auch bei anderen Konzepten, die z. B. für Minix entwickelt wurden, das Problem, dass durch den Taskswitch wertvolle CPU-Zeit verloren geht.
Dieses Problem ist aber an anderer Stelle bereits gelöst, nämlich in Form von leichtgewichtigen Threads. Am bekanntesten dürften die von Erlang sein, aber es gibt noch weitere Implementierungen.
Allerdings scheinen keine davon "Unix-tauglich" zu sein.
Das erinnert mich daran, wie man mit Ajax & Polling verzweifelt versucht, dynamische Webseiten trotz HTTP-Zwang zu bauen. Man "löst" dort Probleme auf eine sehr umständliche Weise, die eigentlich kein Problem wären, wenn man sie auf einer tieferen Ebene angeht (HTTP erweitert bzw. gegen etwas anderes austauscht).
In diesem Bereicht hat man zwei Probleme:
1.) HTTP ist ein verbindungsloses Protokoll bei dem die Informationen zwischen den Dialogschritten auf em Server verloren gehen.
Nein, das meinte ich gar nicht. Klar, auch hier sind auch Workarounds nötig (Session-ID, Cookies). Aber das ist Kleinkram, der Overhead ist minimal. (er beschränkt sich im Wesentlichen darauf, abgebrochene Session zu erkennen und regelmäßig zu entfernen)
Das größere Problem ist, dass bei HTTP die Initiative ausschließlich vom Client ausgeht. Der Server kann nicht von sich aus einem bestimmten Client (oder allen Clients) irgendwelche Infos zusenden.
Also muss der Client pollen, was auf die Datenrate und vorallem die Latenz drückt. Und mit jeder Anfrage muss der Server entweder alle Daten komplett senden, oder er muss sich merken, wann welche Daten geändert wurden, um nur die interessanten Daten neu zu übermitteln.
BOSH ist eine "Vergewaltigung" des HTTP, die eine solche bidirektionale Übertragung möglich macht. Man benutzt das, um XMPP durch HTTP zu tunneln, wodurch ein XMPP-Server insbesondere hinter einem HTTP-Reverse-Proxy stehen kann, sodass er trotz Same-Origin-Policy erreichbar ist. Das ist ziemlich krank, läuft aber erstaunlich gut. Man erhält fantastische Reaktionszeiten, komplett ohne Polling. (http://xmpp.org/extensions/xep-0124.html)
Zwei große Probleme gibt es dennoch bei diesem Ansatz:
1) BOSH ist empfindlich gegenüber Netzwerkstörungen. Eine abgebrochene BOSH-Verbindung wird nicht in allen Fällen sauber erkannt, vorallem wenn noch ein HTTP-Proxy in der Mitte hängt.
2) Es gibt AFAIK nur eine einzige Java-Script-Library, die BOSH clientseitig ordentlich implementiert. Der Rest ist Schrott. (http://code.stanziq.com/strophe/)
Gruß Volker
Am Freitag, 2. Juli 2010 10:41:37 schrieb Alexander Kahl:
Ein sehr guter Artikel (Englisch) zum Thema im Betreff, wie ich finde: http://www.h-online.com/open/features/GNU-HURD-Altered-visions-and-lost-pro mise-1030942.html
Der Autor "Richard Hillesley" hat etwas wichtiges weggelassen: Eine Portierung der Anwendungen auf HURD ist sehr schwer, bis unmöglich. Sie müssten neu geschrieben werden oder wären unsicher.
Erkannt und veröffentlicht haben Neil und Marcus das 2007 [1]. Seitdem ist klar, dass HURD wohl ein Betriebssystemkern für die Forschung bleiben wird.
Gruß, Bernhard
[1] @article{walfield07hurd-critique, author = {Neal H. Walfield and Marcus Brinkmann}, title = {A critique of the GNU hurd multi-server operating system}, journal = {SIGOPS Operating System Review}, volume = {41}, number = {4}, year = {2007}, month = jul, issn = {0163-5980}, pages = {30--39}, doi = {http://doi.acm.org/10.1145/1278901.1278907%7D, publisher = {ACM Press}, address = {New York, NY, USA}, }
Das PDF gibt es auch von http://walfield.org/
Hallo Bernhard,
Am Donnerstag, 22. Juli 2010, 18:03:52 schrieb Bernhard Reiter:
Seitdem ist klar, dass HURD wohl ein Betriebssystemkern für die Forschung bleiben wird.
das wird praktisch gesehen leider wohl so stimmen ;(.
Aber dies ändert imho nichts daran, dass es äußerst erfreulich für unsere Informationsgesellschaft wäre, wenn wir heute ein freies Mikrokern- und Capability-basiertes Multi-Server-Betriebssystem zur Verfügung hätten, das GNU/Linux sowie anderen momentan gängigen Desktopsystemen featuremäßg zumindest ebenbürtig ist.
*Seufz*... ;)
Lg micu
On Thu, Jul 22, 2010 at 06:03:52PM +0200, Bernhard Reiter wrote:
Eine Portierung der Anwendungen auf HURD ist sehr schwer, bis unmöglich. Sie müssten neu geschrieben werden oder wären unsicher.
Erkannt und veröffentlicht haben Neil und Marcus das 2007 [1]. Seitdem ist klar, dass HURD wohl ein Betriebssystemkern für die Forschung bleiben wird.
Sagen wir mal lieber, sie bräuchten mehr Leute, die sich dafür interessieren und sich aktiv daran beteiligen.
Was die Portierung von Software betrifft, so gibt es durchaus schon etliches an Software für HURD. Auf der Homepage von Debian GNU/Hurd steht, dass etwa jedes zweite Debian-Paket portiert ist. Debian ist eine der umfangreichsten Distrubutionen. Jedes zweite ist also insgesamt eine ganze Menge! http://www.debian.org/ports/hurd/index
Fallstricke und Lösungen zur Portierung gibt es auf folgender Seite: http://www.gnu.org/software/hurd/hurd/porting/guidelines.html
Ein aktueller Artikel, der tiefer geht und die Sache positiver sieht: http://lwn.net/Articles/395150/
Am Sonntag, 1. August 2010 15:52:24 schrieb Andreas K. Foerster:
On Thu, Jul 22, 2010 at 06:03:52PM +0200, Bernhard Reiter wrote:
Eine Portierung der Anwendungen auf HURD ist sehr schwer, bis unmöglich. Sie müssten neu geschrieben werden oder wären unsicher.
Erkannt und veröffentlicht haben Neil und Marcus das 2007 [1]. Seitdem ist klar, dass HURD wohl ein Betriebssystemkern für die Forschung bleiben wird.
Sagen wir mal lieber, sie bräuchten mehr Leute, die sich dafür interessieren und sich aktiv daran beteiligen.
Nein, so wie ich die Kritik verstanden habe, wäre es für viele Anwendungen ein Neuschreiben, inklusive des vorherigen Neudenkens und das ist auch mit sehr vielen Leuten sehr schwierig. Vermutlich bedarf es eines neuen Kernels.
Was die Portierung von Software betrifft, so gibt es durchaus schon etliches an Software für HURD. Auf der Homepage von Debian GNU/Hurd steht, dass etwa jedes zweite Debian-Paket portiert ist.
Die Auswirkungen der Sicherheitserkenntnisse auf diese Pakete würde ich gern wissen, meine Vermutng ist, dass sie eben in der vorliegenden Form nicht sicher funktionieren.
Zumindest Neil und Marcus haben ein Gutteil Interesse am Hurd verloren, aber es ist gut, dass weiter geforscht wird.
Gruß, Bernhard
Am Freitag, 2. Juli 2010, 10:41:37 schrieb Alexander Kahl:
Ein sehr guter Artikel (Englisch) zum Thema im Betreff, wie ich finde:
Dazu ein schöner kurzer (!) Vortrag von Neal Walfield:
http://audio-video.gnu.org/video/ghm2010/GNU-Hurd_- _Its_About_Freedom,_Or_Why_you_should_care.ogv
(weitestgehend allgemeinverständlich für Techies) -- GnuPG: https://www1.inf.tu-dresden.de/~s3418892/micuintus.asc Fingerprint: 1A15 A480 1F8B 07F6 9D12 3426 CEFE 7455 E4CB 4E80
<<</>>