Mir scheint Hurd ist einfach der Zeit voraus (und in der Entwicklung hinterher). So aehnlich wie der Itanium Prozessor von Intel. Sehr schnell, sehr fortschrittlich, so fortschrittlich dass ihn die meisten Kunden nicht nutzen koennen. Intel ist mit dem Itanium ueber einen Graben gesprungen und hat dabei vergessen dass die meisten Menschen eine Bruecke brauchen um ueber den Graben zu gelangen. Die Bruecke hat dann AMD gebaut. So aehnlich schaut es mit dem Hurd aus, da wird auch gesprungen, und Linux baut die Bruecken. Eigentlich schade
Naja - also wenn es wirklich fortschrittlich wäre, dürfte man aber nicht so eine IPC-Krücke wie Mach verwenden, sondern sollte einen modernen Mikrokern a la L4 verwenden. Die Idee eines Mikrokern-Systems ist allerdings wirklich nicht schlecht. An QNX sieht man ja auch, daß das ganz gut funktionieren kann.
Woran liegt es eigentlich, dass sich GNU/Hurd so langsam entwickelt? Wieso hat "keiner" interesse daran? Die Konzepte scheinen ja mehr als nur interessant zu sein.
Ist doch egal ob die Entwicklung schnell oder langsam vorangeht. GNU/Hurd soll doch nächstes Jahr fertig sein und bis dahin dauerts nicht mehr allzu lange.
Danke viel mals für diesen absolut geistreichen und vor Information platzenden Beitrag! Da wäre ich selbst nicht darauf gekommen, dass Hurd nächstes Jahr kommt, und das schon seit Jahren.
Viele Leute gehen halt den pragmatischen Weg und sind mit dem Zufrieden, was sie haben. Also Linus seine erste Version veröffentlicht hat gabs viele, die mit Minix unzufrieden waren und deshalb an einem Ersatz interresiert waren. Zu dem Zeitpunkt war der Rechtsstreit bezüglich der BSDs noch nicht niedergelegt und ein brauchbarer Kern fürs GNU System war noch nicht sichtbar.
Heute ist das aber anders. Sowohl (GNU)Linux als auch *BSD sind vollkommen einsatzfähige Systeme, weshalb größtenteils nur Idealisten an Hurd mitentwickeln.
Hurd hat gute Ideen, aber es hat das HenneEi Probleme, das bei sogut wie jeder Software existiert, noch nicht überwunden (falls es das jemals tut).
Politik ist wichtiger als Leistung. Diskussionen um den politisch richtigen Weg, ist wichtiger, als eine praktikable Lösung zu finden. Der 'richtige' Weg ist wichtiger als funktionalität. Microkernel eigenen sich ausschließlich für Umgebungen, wo jeder Code-Beitrag genauestens überprüft wird, ob die zusätzlichen Zeilen auch notwendig sind, der Micro des Hurd hingegen ist dank GNU auf riesige größen afgebläht und wird immer schlimmer.
Um einen Microkernel erfolgreich zu kontruieren gilt: je weniger Leute dabei sind, desto besser (siehe QNX. Drei Leute haben den geschrieben, er läuft super).
Und schließlich und schlußendlich: es braucht niemand. Hurd war vor 15 Jahren ein interessanter Ansatz, der sich inzwischen selbst überholt hat und nur deswegen noch lebt, weil sich einige GNU'ler nicht mit Linux abfinden konnten.
> Microkernel eigenen sich ausschließlich > für Umgebungen, wo jeder Code-Beitrag > genauestens überprüft wird, ob die > zusätzlichen Zeilen auch notwendig sind,
Wie kommst du denn auf sowas?! :-O
> der Micro des Hurd hingegen ist dank GNU > auf riesige größen afgebläht und wird > immer schlimmer.
Du meinst, weil die Treiber für Tastatur, Grafikkarte und Speaker zusammen mit der gesamten Konsole vom Kernel in den Userspace verlegt wurden, wird der Kernel größer, ja?
Für mich klingt das, was du schreibst, nach dümmlicher Polemik und sonst nichts.
Ich wuerde meinen weil sich fuer komplexere Systeme (wsa ein Microkernel nunmal ist), nicht so einfach entwickler begeisternlassen, wie fuer einen relativ einfachen monolitischen kernel.
Eines der Probleme ist wohl dass alle sagen Mach sei doof. Wer will schon an einem System mitarbeiten dessen Kern doof ist. Wäre er l33t d.h. l4 wäre das was anderes ;-)
Es gibt halt alternativen die (gut) funktionieren - Linux und die BSDs oder auch Darwin. Hurd hingegen funktioniert mehr schlecht als recht, da dran zu arbeiten (und ständig zu hören man sei ja nächstes Jahr fertig) ist auch nicht so spassig.
Ausserdem hat sich offenbar RMS auch ab und zu in nicht gerade produktiver Weise eingemischt. (Der letzte (oder vorletzte) Maintainer musste gehen weil er sich öffentlich gegen die GNU FDL geäussert hatte)
Mach ist sicher ein Problem. Ich selber habe mir auch schon den Hurd angesehen, irgendwie fehlt mir aber die Motivation sich in etwas einzuarbeiten und etwas zu lernen, was selbst nach Aussage der ENtwickler keine Zukunft hat. Ich verstehe nicht, warum hier nicht konsequent auf eine Zukunftsfähigen Microkernel gearbeitet wird.
Hurd hatte einfach das "Pech", das Linux schneller war. Wenn es einen gut funktionierenden freien Kernel gibt, dann sinkt nunmal die Motivation bei vielen etwas neues zu Entwickeln und nochmal bei Null anzufangen.
>Ausserdem hat sich offenbar RMS auch ab und zu in nicht gerade produktiver Weise eingemischt. (Der letzte (oder vorletzte) Maintainer musste gehen weil er sich öffentlich gegen die GNU FDL geäussert hatte)
Das kann man so einfach nicht stehen lassen (auch wenn RMS bashing mittlerweile fast so beliebt ist wie MS bashing). Es gab ausseinandersetzungen mit Thomas Bushnell wegen der GFDL, die er immer wieder öffentlich kritisiert hat. Das man sojemanden langfristig nicht in der FSF halten kann ist wohl jedem klar. Das eine hat mit dem anderen aber nichts zu tun, niemand hat ihn gezwungen seine Entwicklung am Hurd zu beenden und man muß auch kein Mitglied der FSF sein um an einem GNU Projekt zu arbeiten.
Ich gehöre eigentlich normalerweise nicht zu den RMS-Bashern. Naja. Aber in dem Falle - zur GFDL kann man halt nun mal wirklich verschiedener Meinung sein - das sollte imo auch innerhalb der FSF möglich sein. Es wirkt auf jeden Fall auch nicht gerade motivierend auf potentielle Entwickler...
Aber das muß intern geregelt werden und nicht nach aussen. Wenn du in einer Partei oder einer anderen Organisation dauernd öffentlich Grundlegende Sachen kritisierst und schlecht redest, wird man auch irgendwann entscheiden, dass du für die Partei oder Organisation nichtmehr tragbar bist und dich zur Tür bitten
Das mag jetzt vielleicht spitzfinderisch klingen und ist in keiner Weise böse oder so gemeint, aber Kilo und Giga werden mit K und G abgekürzt. Also KB und GB. Ist ja auch z.B. bei Kilometer km der Fall.
Ich schreib das nur, da ich etwas irritiert war. Hab erst gedacht, es handelt sich um Gigabit oder so...(bei einem Dateisystem...??)
Also wenn schon genau, dann ganz genau: Da in der EDV Potenzen von 2 als Einheitenvorsätze verwendet werden, sollte man nicht Kilobyte sondern kByte (oder kB), nicht Megabyte sondern MByte (MB) sagen etc. Damit ist der Unterschied zum international eingeführten metrischen Einheitensystem (SI / Basis: Zehnerpotenzen) sprachlich klar ausgedrückt.
Eben nicht... Ob du nun Kilobyte, kByte oder kB schreibst ist egal. Strengenommen würde all das 1000 Byte bedeuten. Wie oben schon erwähnt müstest du KiBiByte oder KiB schreiben um die 1024er Notation zu verdeutlichen.
Das Problem sind nicht die Byte, sondern die Kilo :)
Die einen sagen: 1024, die anderen sagen 1000. Und eben da liegt das Problem. Durch MB oder MByte wird das nicht deutlicher, weil das M das Problem ist, nicht das B(yte)
Ich finde das ist mitlerweile ein einzigstes Wirrwar. Warum hat man nicht einfach RiKiBytes gemacht? (Richtige Kilo Bytes.) Ich meine, wo werden denn wirklich diese '1000'er verwendet? Man weiss mitlerweile nicht, ob 1024 oder 1000 gemeint ist. Der Nutzen davon ist gleich 0. Ich werde mich auch in Zukunft nicht an diesen Unsinn halten und dieses System ablehnen. (Es sei denn, jemand hat wirklich gute Argumente)
Ich meine, wo werden denn wirklich diese '1000'er verwendet? Nun, wenn Du ein Kilo Äpfel oder Wurst kaufst, dann interessiert dich das schon, ob es 1024 oder 1000 Gramm sind. Es ist auch ein Unterschied ab Du 1024 2^Meter oder nur 1000 2^Meter Land besitzt. Eigentlich ist 1000 Standard für Kilo
Sowie bei normalen Einheiten 1000 für die Skalierung "Kilo" allgemein verwendet wird, ist bei Informatikeinheiten 1024 allgemein anerkannt und verwendet. Das dies einige Plattenhersteller aus Kosten- und Marketinggründen anders sehen, ändert nix an der Tatsache.
Ich kann mich an diese komische Schreibweise mit dem "i" auch nicht gewöhnen und muß immer, sofern es mich interessiert, einige Zeit erstmal per Google suchen, ob damit nur die Plattenhersteller-kB oder die 1024'er kB gemeint sind. Bei kB, MB und GB ist das klar, daß damit 1024 gemeint ist.
Von theBohemian am Mo, 20. Dezember 2004 um 20:37 #
"Das dies einige Plattenhersteller aus Kosten- und Marketinggründen anders sehen, ändert nix an der Tatsache." Die 10er Potenzen werden auch bei Übertragungs-"geschwindigkeiten" benutzt.
Je, eher wir uns an die Binary Bytes gewöhnen, umso besser für alle.
> Ich meine, wo werden denn wirklich diese '1000'er verwendet? Bei Festplatten zum Beispiel. Wenn du dir eine 80 GB Festplatte kaufst, dann sind das 80.000.000.000 Bytes (da stimmt es ja auch). Nutzbar sind aber "nur" etwa 76 GiB.
Von Johannes Rohr am Mo, 20. Dezember 2004 um 15:31 #
Die oben angezeigte Statistik der Debian-Hurd-Mailingliste gibt leider ziemlich genau wieder, was auch mein Eindruck ist: Um die Jahre 2001-2002 gab es - vor allem dank Marcus Brinkmanns Engagement für Debian GNU/Hurd einen relativen Aufschwung, bis dahin dass etwa die Zeitschrift FreeX GNU/Hurd eine Titelgeschichte widmete. Ich hörte damals erstmal von Hurd und war vom äußerst durchdachten und eleganten Design zutiefst beeindruckt, das maximale Sicherheit mit maximalem "empowerment" der Nutzer zu kombinieren verstand.
Viele Websites haben damals über (Debian) GNU/Hurd berichtet, auf debian-hurd war ziemlich viel los.
Mittlerweile hat diese Liste nur noch ein paar wenige Postings im Monat und von einigen zentralen Entwicklern wie etwa Neil Walfield, Roland McGrath und nicht zuletzt Marcus Brinkmann selbst war schon lange nichts mehr dort zu lesen. Marcus Brinkmann scheint dann einige Energie in das hurd-l4-Projekt gesteckt zu haben, das an einem Redesign von Hurd auf Grundlage des vom leider verstorbenen Jürgen Liedke designten l4-Minimalkernels. Auch l4-hurd ist wieder ein Projekt, das äußerst sexy und elegant in seiner Zielsetzung ist, aber schaut man sich die Commits an, sieht man, dass dieses Projekt seinen (nach mehrjähriger Diskussion entwickelten) zwischenzeitlichen Schwung wieder verloren hat und nicht vom Fleck kommt.
Traurig, denn eine echtes Microkernel-basiertes freies Betriebssystem wäre absolut wünschenswert. Schon allein der Umstand, dass jeder Treiber für jede neue Revision des Linux-Kernels neu kompiliert werden muss, ist ein absolutes Ärgernis. Da kann sich Linux von Windows NT (nicht schlagen!) tatsächlich 'ne Scheibe abschneiden, denn das letztere kann auch heute noch mit Binärtreibern aus der Mitte der 90er Jahre umgehen.
Modularisierung nach dem Muster von the Hurd würde viele Probleme lösen, die Linux plagen. Doch die Chancen stehen schlecht!
Linux ist einfach was zum Anfassen.. etwas das man JETZT benutzen kann. Hurd hingegen versucht zu innovativ, zu radikal und zu komplex zu sein. Zwar ist Linux von Natur aus monolithisch, es wird aber wo es möglich ist versucht Funktionen in den User-Space auszulagern (z.B. udev). Und außerdem kann eine Idee manchmal noch so gut sein, sie interessiert leider keine Sau wenn es keine Software dafür gibt.
Und zum Thema Treiber Interface: http://www.kroah.com/log/linux/stable_api_nonsense.html?seemore=y
"würde viele Probleme lösen, die Linux plagen." ..und dafuer aber 1000 andere schaffen.
Wahsinnige Logik! Wenn das ganze so toll waere waere Hurd doch schon viel weiter.
Das problem liegt doch ganz wo anders: MK BSeme sind gut fuer Profs und Doktoranden aber in der real world haben sie noch nie gezeigt, dass sie was besser machen geschweige denn dass man auf ihnen schneller entwickeln kann.
Das ist eben der unterschied zwischen Theorie und Praxis.
JKFF
PS: Wenn du glaubst WindowsNT is nen MK BS dann bist du auf POT!
Von Johannes Rohr am Mo, 20. Dezember 2004 um 21:43 #
Nein, ich behaupte nicht, dass NT eine Microkernel-OS ist, aber es hat immerhin eine Abstraktionsschicht zwischen Kernel und Treibern, die dafür sorgt, dass man dort weniger Probleme mit Treiber-Kernel-Kompatibilität hat als bei Linux.
Hurd geht hier natürlich viel weiter, indem es - dem Anspruch nach - alle Treiber ins Userland verlagert. Nur leider löst GNUmach diesen Anspruch nicht ein. Und ob aus hurd-l4, das einen wirklich konsequenten Microkernel-Ansatz verfolgt, jemals etwas wird, halte ich für zumindest zweifelhaft.
Da muss ich dir doch etwas von deinem Optimismus nehmen: ===== Da kann sich Linux von Windows NT (nicht schlagen!) tatsächlich 'ne Scheibe abschneiden, denn das letztere kann auch heute noch mit Binärtreibern aus der Mitte der 90er Jahre umgehen. ===== Kunststück. Ein Treiber der explizit für WindowsNT entwickelt wurde wird natürlich mit WindowsNT laufen. Die Frage ist nur: Welches WindowsNT meinst du? Dass heute noch aktiv irgendwelche Treiber für WindowsNT 3.51 oder WindowsNT 4.0 entwickelt werden ist mir nicht bekannt. Das meisten Hersteller beschränken sich bei aktuellen Treibern ja auf die aktuellen Windows Versionen. Also WindowsXP und Windows 2003 Server -- und solange der extended support seitens Microsoft noch läuft: Windows 2000.
Dass du einen für WindowsNT 4.0 erstellten Treiber unter der aktuellen Version von Windows NT (v5.0 => Win2000; v5.1 => WinXP) zum Laufen bekommst wage ich zu bezweifeln.
NT4-Treiber gehen meistens sogar unter XP - wenn nicht die API für die Geräteklasse geändert wurde (zB bei Bandlaufwerken der Fall). Man wird halt angemotzt dass der Treiber nicht signiert sei, und evtl. funzt der Standby-Modus nicht mehr. Selbst '95er (VXD!)-Treiber hab ich teilweise mangels Alternative unter XP und 2k eingesetzt, je nach Geräteklasse. Viel schlimmer finde ich da dass man neue Geräte nicht richtig mit alten Systemen betreiben kann, zB bei vielen Digitalkameras der Fall (2000 kann kein PTP, Zugriff auf nicht-USB-Storage-Kameras wenn überhaupt nur umständlich über TWAIN möglich). DAS nervt! Da find ich unter Linux die Backports richtig angenehm - muss man zwar evtl. nen neuen Kernel bauen aber immerhin funzt es ohne dreistellige Update-Gebühren und ewiges Gefummel bis die ganze Software wieder läuft.
Von Johannes Rohr am Mo, 20. Dezember 2004 um 22:00 #
Ein ähnliches Ziel verfolgt unter Linux das FUSE-Projekt (Filesystem in Userspace), welches die Implementierung von Dateisystemen außerhalb des Kernelspeichers ermöglichen soll. Für diesen Zweck ist allerdings ein generisches Kernelmodul von Nöten, welches die Anfragen über eine Bibliothek an reguläre Programme weiterleitet.
Da liegt genau der Hase im Pfeffer: FUSE, LUFS & friends können die Limitationen eines monolithischen Kernel nicht überwinden: Auch wenn man Userland-Dateisysteme nutzt, bleib das (un)mounten eine privilegierte Aktion, die Root-Rechte erfordert. So lässt sich shfs nur dann sinnvoll durch den User nutzen, wenn der Administrator shfsmount SUID root gesetzt hat - ein Risiko, das kein sicherheitsbewusster Admin gerne eingehen wird.
Auch das Einbinden eines Floppy- oder eines ISO- oder Bochs-Images zeigt, dass ein monolithischer Kernel prinzipielle Designmängel hat. So wird etwa der Befehl "mount -o loop ~/floppy.img /home/user/mnt" mit der Fehlermeldung "only root can do that" quittiert, auch wenn ich volle Zugriffsrechte auf das Image wie auf den Mountpoint habe.
Hurd geht hier einen radikal neuen Weg: Das Einbinden beliebiger Dateisysteme mittels Übersetzer erfordert keinerlei besondere Privilegien, es gibt nicht einmal eine /etc/mtab. Das garantiert maximale Freiheit der Benutzer, ohne die Systemsicherheit in irgendeiner Weise zu gefährden.
settrans /home/user/floppy /hurd/ext2fs ./floppy.img darf jeder durchführen, der die entsprechenden Zugriffsrechte hat. Das ist nur ein Beispiel von vielen dafür, wie toll es wäre, wenn es ein für den Produktiveinsatz taugliches GNU/Hurd gäbe. Nur fehlt mir da so langsam der Glaube...
Das ist nur ein Beispiel von vielen dafür, wie toll es wäre, wenn es ein für den Produktiveinsatz taugliches GNU/Hurd gäbe. Nur fehlt mir da so langsam der Glaube...
Eile mir Weile. Hurd hat mehr Potenzial als "nur" Linux-Ersatz zu spielen. Man stelle sich vor, mit Hurd wird aus etlichen einzelnen Rechnern ein volldynamischer Cluster gebaut. Das System fühlt sich an wie ein einziger Rechner, wird beim Hinzufügen zusätzlicher Systeme ein bisschen performanter und regelt sonst alles von selbst. Natürlich ist dies mit ein paar Klimmzügen unter Linux auch möglich, aber Hurd ist die Clusterei quasi per Design in die Wiege gelegt worden.
Von mir aus kann es ruhig noch ein paar Mal "nächstes Jahr" werden, wenn um Hurd nur nichts überstürzt wird und in aller Ruhe eine gute, solide und fortschrittliche Technologie heran wächst. Bis dahin sorgt Linux für die Verbreitung offener Standards und Freier Software, wovon letztendlich auch Hurd profitiert.
Von Johannes Rohr am Di, 21. Dezember 2004 um 08:00 #
Von mir aus kann es ruhig noch ein paar Mal "nächstes Jahr" werden, wenn um Hurd nur nichts überstürzt wird und in aller Ruhe eine gute, solide und fortschrittliche Technologie heran wächst.
Wenn denn was wachsen würde, ja.
Leider scheint aber nicht mehr allzu viel zu geschehen, zumindest dem Traffic auf den einschlägigen Mailinglisten nach.
Von theBohemian am Di, 21. Dezember 2004 um 21:03 #
"Von mir aus kann es ruhig noch ein paar Mal "nächstes Jahr" werden, wenn um Hurd nur nichts überstürzt wird und in aller Ruhe eine gute, solide und fortschrittliche Technologie heran wächst."
Guter Punkt. Solange Freie Software nicht per Gesetzt verboten wird, ist es egal wann irgendwas fertig wird. Die einzigen, die damit nicht leben können sind die Kumpels von der 'opensource' Front, die jeden Tag beweisen müssen, dass ihre Software der proprietären überlegen ist. Ich weis es einfach und gut ist.
So aehnlich wie der Itanium Prozessor von Intel. Sehr schnell, sehr fortschrittlich, so fortschrittlich dass ihn die meisten Kunden nicht nutzen koennen. Intel ist mit dem Itanium ueber einen Graben gesprungen und hat dabei vergessen dass die meisten Menschen eine Bruecke brauchen um ueber den Graben zu gelangen. Die Bruecke hat dann AMD gebaut.
So aehnlich schaut es mit dem Hurd aus, da wird auch gesprungen, und Linux baut die Bruecken. Eigentlich schade
Die Idee eines Mikrokern-Systems ist allerdings wirklich nicht schlecht. An QNX sieht man ja auch, daß das ganz gut funktionieren kann.
GNU/Hurd soll doch nächstes Jahr fertig sein und bis dahin dauerts nicht mehr allzu lange.
Viele Leute gehen halt den pragmatischen Weg und sind mit dem Zufrieden, was sie haben.
Also Linus seine erste Version veröffentlicht hat gabs viele, die mit Minix unzufrieden waren und deshalb an einem Ersatz interresiert waren.
Zu dem Zeitpunkt war der Rechtsstreit bezüglich der BSDs noch nicht niedergelegt und ein brauchbarer Kern fürs GNU System war noch nicht sichtbar.
Heute ist das aber anders. Sowohl (GNU)Linux als auch *BSD sind vollkommen einsatzfähige Systeme, weshalb größtenteils nur Idealisten an Hurd mitentwickeln.
Hurd hat gute Ideen, aber es hat das HenneEi Probleme, das bei sogut wie jeder Software existiert, noch nicht überwunden (falls es das jemals tut).
das liegt an GNU:
Politik ist wichtiger als Leistung.
Diskussionen um den politisch richtigen Weg, ist wichtiger, als eine praktikable Lösung zu finden.
Der 'richtige' Weg ist wichtiger als funktionalität.
Microkernel eigenen sich ausschließlich für Umgebungen, wo jeder Code-Beitrag genauestens überprüft wird, ob die zusätzlichen Zeilen auch notwendig sind,
der Micro des Hurd hingegen ist dank GNU auf riesige größen afgebläht und wird immer schlimmer.
Um einen Microkernel erfolgreich zu kontruieren gilt: je weniger Leute dabei sind, desto besser (siehe QNX. Drei Leute haben den geschrieben, er läuft super).
Und schließlich und schlußendlich: es braucht niemand.
Hurd war vor 15 Jahren ein interessanter Ansatz, der sich inzwischen selbst überholt hat und nur deswegen noch lebt, weil sich einige GNU'ler nicht mit Linux abfinden konnten.
2GiB Grenze im Jahr 2004? Das ist doch peinlich.
> für Umgebungen, wo jeder Code-Beitrag
> genauestens überprüft wird, ob die
> zusätzlichen Zeilen auch notwendig sind,
Wie kommst du denn auf sowas?! :-O
> der Micro des Hurd hingegen ist dank GNU
> auf riesige größen afgebläht und wird
> immer schlimmer.
Du meinst, weil die Treiber für Tastatur, Grafikkarte und Speaker zusammen mit der gesamten Konsole vom Kernel in den Userspace verlegt wurden, wird der Kernel größer, ja?
Für mich klingt das, was du schreibst, nach dümmlicher Polemik und sonst nichts.
Wäre er l33t d.h. l4 wäre das was anderes ;-)
Es gibt halt alternativen die (gut) funktionieren - Linux und die BSDs oder auch Darwin. Hurd hingegen funktioniert mehr schlecht als recht, da dran zu arbeiten (und ständig zu hören man sei ja nächstes Jahr fertig) ist auch nicht so spassig.
Ausserdem hat sich offenbar RMS auch ab und zu in nicht gerade produktiver Weise eingemischt. (Der letzte (oder vorletzte) Maintainer musste gehen weil er sich öffentlich gegen die GNU FDL geäussert hatte)
Naja, kommt halt einiges zusammen.
MfG Peschmä
Ich verstehe nicht, warum hier nicht konsequent auf eine Zukunftsfähigen Microkernel gearbeitet wird.
Hurd hatte einfach das "Pech", das Linux schneller war. Wenn es einen gut funktionierenden freien Kernel gibt, dann sinkt nunmal die Motivation bei vielen etwas neues zu Entwickeln und nochmal bei Null anzufangen.
>Ausserdem hat sich offenbar RMS auch ab und zu in nicht gerade produktiver Weise eingemischt. (Der letzte (oder vorletzte) Maintainer musste gehen weil er sich öffentlich gegen die GNU FDL geäussert hatte)
Das kann man so einfach nicht stehen lassen (auch wenn RMS bashing mittlerweile fast so beliebt ist wie MS bashing).
Es gab ausseinandersetzungen mit Thomas Bushnell wegen der GFDL, die er immer wieder öffentlich kritisiert hat. Das man sojemanden langfristig nicht in der FSF halten kann ist wohl jedem klar. Das eine hat mit dem anderen aber nichts zu tun, niemand hat ihn gezwungen seine Entwicklung am Hurd zu beenden und man muß auch kein Mitglied der FSF sein um an einem GNU Projekt zu arbeiten.
Es wirkt auf jeden Fall auch nicht gerade motivierend auf potentielle Entwickler...
MfG Peschmä
Wenn du in einer Partei oder einer anderen Organisation dauernd öffentlich Grundlegende Sachen kritisierst und schlecht redest, wird man auch irgendwann entscheiden, dass du für die Partei oder Organisation nichtmehr tragbar bist und dich zur Tür bitten
Das mag jetzt vielleicht spitzfinderisch klingen und ist in keiner Weise böse oder so gemeint, aber Kilo und Giga werden mit K und G abgekürzt. Also KB und GB.
Ist ja auch z.B. bei Kilometer km der Fall.
Ich schreib das nur, da ich etwas irritiert war. Hab erst gedacht, es handelt sich um Gigabit oder so...(bei einem Dateisystem...??)
Viele Grüße!
Dave
http://www.sengpielaudio.com/Rechner-bits.htm
Danke!
Da in der EDV Potenzen von 2 als Einheitenvorsätze verwendet werden, sollte man nicht Kilobyte sondern kByte (oder kB), nicht Megabyte sondern MByte (MB) sagen etc. Damit ist der Unterschied zum international eingeführten metrischen Einheitensystem (SI / Basis: Zehnerpotenzen) sprachlich klar ausgedrückt.
Ob du nun Kilobyte, kByte oder kB schreibst ist egal. Strengenommen würde all das 1000 Byte bedeuten.
Wie oben schon erwähnt müstest du KiBiByte oder KiB schreiben um die 1024er Notation zu verdeutlichen.
Die einen sagen: 1024, die anderen sagen 1000. Und eben da liegt das Problem. Durch MB oder MByte wird das nicht deutlicher, weil das M das Problem ist, nicht das B(yte)
Nun, wenn Du ein Kilo Äpfel oder Wurst kaufst, dann interessiert dich das schon, ob es 1024 oder 1000 Gramm sind. Es ist auch ein Unterschied ab Du 1024 2^Meter oder nur 1000 2^Meter Land besitzt. Eigentlich ist 1000 Standard für Kilo
Sowie bei normalen Einheiten 1000 für die Skalierung "Kilo" allgemein verwendet wird, ist bei Informatikeinheiten 1024 allgemein anerkannt und verwendet. Das dies einige Plattenhersteller aus Kosten- und Marketinggründen anders sehen, ändert nix an der Tatsache.
Ich kann mich an diese komische Schreibweise mit dem "i" auch nicht gewöhnen und muß immer, sofern es mich interessiert, einige Zeit erstmal per Google suchen, ob damit nur die Plattenhersteller-kB oder die 1024'er kB gemeint sind. Bei kB, MB und GB ist das klar, daß damit 1024 gemeint ist.
Die 10er Potenzen werden auch bei Übertragungs-"geschwindigkeiten" benutzt.
Je, eher wir uns an die Binary Bytes gewöhnen, umso besser für alle.
Bei Festplatten zum Beispiel. Wenn du dir eine 80 GB Festplatte kaufst, dann sind das 80.000.000.000 Bytes (da stimmt es ja auch). Nutzbar sind aber "nur" etwa 76 GiB.
Viele Websites haben damals über (Debian) GNU/Hurd berichtet, auf debian-hurd war ziemlich viel los.
Mittlerweile hat diese Liste nur noch ein paar wenige Postings im Monat und von einigen zentralen Entwicklern wie etwa Neil Walfield, Roland McGrath und nicht zuletzt Marcus Brinkmann selbst war schon lange nichts mehr dort zu lesen. Marcus Brinkmann scheint dann einige Energie in das hurd-l4-Projekt gesteckt zu haben, das an einem Redesign von Hurd auf Grundlage des vom leider verstorbenen Jürgen Liedke designten l4-Minimalkernels.
Auch l4-hurd ist wieder ein Projekt, das äußerst sexy und elegant in seiner Zielsetzung ist, aber schaut man sich die Commits an, sieht man, dass dieses Projekt seinen (nach mehrjähriger Diskussion entwickelten) zwischenzeitlichen Schwung wieder verloren hat und nicht vom Fleck kommt.
Traurig, denn eine echtes Microkernel-basiertes freies Betriebssystem wäre absolut wünschenswert. Schon allein der Umstand, dass jeder Treiber für jede neue Revision des Linux-Kernels neu kompiliert werden muss, ist ein absolutes Ärgernis. Da kann sich Linux von Windows NT (nicht schlagen!) tatsächlich 'ne Scheibe abschneiden, denn das letztere kann auch heute noch mit Binärtreibern aus der Mitte der 90er Jahre umgehen.
Modularisierung nach dem Muster von the Hurd würde viele Probleme lösen, die Linux plagen. Doch die Chancen stehen schlecht!
Und zum Thema Treiber Interface:
http://www.kroah.com/log/linux/stable_api_nonsense.html?seemore=y
..und dafuer aber 1000 andere schaffen.
Wahsinnige Logik! Wenn das ganze so toll waere waere Hurd doch
schon viel weiter.
Das problem liegt doch ganz wo anders: MK BSeme sind gut fuer
Profs und Doktoranden aber in der real world haben sie noch nie
gezeigt, dass sie was besser machen geschweige denn dass man
auf ihnen schneller entwickeln kann.
Das ist eben der unterschied zwischen Theorie und Praxis.
JKFF
PS: Wenn du glaubst WindowsNT is nen MK BS dann bist du auf POT!
Da ist Linux besser.
JKFF
Hurd geht hier natürlich viel weiter, indem es - dem Anspruch nach - alle Treiber ins Userland verlagert. Nur leider löst GNUmach diesen Anspruch nicht ein. Und ob aus hurd-l4, das einen wirklich konsequenten Microkernel-Ansatz verfolgt, jemals etwas wird, halte ich für zumindest zweifelhaft.
=====
Da kann sich Linux von Windows NT (nicht schlagen!) tatsächlich 'ne Scheibe abschneiden, denn das letztere kann auch heute noch mit Binärtreibern aus der Mitte der 90er Jahre umgehen.
=====
Kunststück.
Ein Treiber der explizit für WindowsNT entwickelt wurde wird natürlich mit WindowsNT laufen.
Die Frage ist nur: Welches WindowsNT meinst du?
Dass heute noch aktiv irgendwelche Treiber für WindowsNT 3.51 oder WindowsNT 4.0 entwickelt werden ist mir nicht bekannt.
Das meisten Hersteller beschränken sich bei aktuellen Treibern ja auf die aktuellen Windows Versionen. Also WindowsXP und Windows 2003 Server -- und solange der extended support seitens Microsoft noch läuft: Windows 2000.
Dass du einen für WindowsNT 4.0 erstellten Treiber unter der aktuellen Version von Windows NT (v5.0 => Win2000; v5.1 => WinXP) zum Laufen bekommst wage ich zu bezweifeln.
Viel schlimmer finde ich da dass man neue Geräte nicht richtig mit alten Systemen betreiben kann, zB bei vielen Digitalkameras der Fall (2000 kann kein PTP, Zugriff auf nicht-USB-Storage-Kameras wenn überhaupt nur umständlich über TWAIN möglich). DAS nervt! Da find ich unter Linux die Backports richtig angenehm - muss man zwar evtl. nen neuen Kernel bauen aber immerhin funzt es ohne dreistellige Update-Gebühren und ewiges Gefummel bis die ganze Software wieder läuft.
Da liegt genau der Hase im Pfeffer: FUSE, LUFS & friends können die Limitationen eines monolithischen Kernel nicht überwinden: Auch wenn man Userland-Dateisysteme nutzt, bleib das (un)mounten eine privilegierte Aktion, die Root-Rechte erfordert. So lässt sich shfs nur dann sinnvoll durch den User nutzen, wenn der Administrator shfsmount SUID root gesetzt hat - ein Risiko, das kein sicherheitsbewusster Admin gerne eingehen wird.
Auch das Einbinden eines Floppy- oder eines ISO- oder Bochs-Images zeigt, dass ein monolithischer Kernel prinzipielle Designmängel hat. So wird etwa der Befehl "mount -o loop ~/floppy.img /home/user/mnt" mit der Fehlermeldung "only root can do that" quittiert, auch wenn ich volle Zugriffsrechte auf das Image wie auf den Mountpoint habe.
Hurd geht hier einen radikal neuen Weg: Das Einbinden beliebiger Dateisysteme mittels Übersetzer erfordert keinerlei besondere Privilegien, es gibt nicht einmal eine /etc/mtab. Das garantiert maximale Freiheit der Benutzer, ohne die Systemsicherheit in irgendeiner Weise zu gefährden.
settrans /home/user/floppy /hurd/ext2fs ./floppy.img darf jeder durchführen, der die entsprechenden Zugriffsrechte hat. Das ist nur ein Beispiel von vielen dafür, wie toll es wäre, wenn es ein für den Produktiveinsatz taugliches GNU/Hurd gäbe. Nur fehlt mir da so langsam der Glaube...
Eile mir Weile. Hurd hat mehr Potenzial als "nur" Linux-Ersatz zu spielen. Man stelle sich vor, mit Hurd wird aus etlichen einzelnen Rechnern ein volldynamischer Cluster gebaut. Das System fühlt sich an wie ein einziger Rechner, wird beim Hinzufügen zusätzlicher Systeme ein bisschen performanter und regelt sonst alles von selbst. Natürlich ist dies mit ein paar Klimmzügen unter Linux auch möglich, aber Hurd ist die Clusterei quasi per Design in die Wiege gelegt worden.
Von mir aus kann es ruhig noch ein paar Mal "nächstes Jahr" werden, wenn um Hurd nur nichts überstürzt wird und in aller Ruhe eine gute, solide und fortschrittliche Technologie heran wächst. Bis dahin sorgt Linux für die Verbreitung offener Standards und Freier Software, wovon letztendlich auch Hurd profitiert.
/.
DocSnyder.
Wenn denn was wachsen würde, ja.
Leider scheint aber nicht mehr allzu viel zu geschehen, zumindest dem Traffic auf den einschlägigen Mailinglisten nach.
Guter Punkt. Solange Freie Software nicht per Gesetzt verboten wird, ist es egal wann irgendwas fertig wird. Die einzigen, die damit nicht leben können sind die Kumpels von der 'opensource' Front, die jeden Tag beweisen müssen, dass ihre Software der proprietären überlegen ist. Ich weis es einfach und gut ist.