Hurd eine Option fuer den Desktop?

Post Reply
Message
Author
spark
Posts: 272
Joined: 08. Jul 2000 9:00
Location: Solingen, NRW
Contact:

Hurd eine Option fuer den Desktop?

#1 Post by spark »

Hoffentlich ist Wolfgang in der Naehe. ;) Ich hab da naemlich so ein paar Fragen...
Wer mich etwas kennt, dem ist sicher aufgefallen, dass ich mich mal recht viel mit AtheOS beschaeftigt habe... Der Grund dafuer ist, dass einige Konzepte dieses Systems so genial sind, dass ich einfach nicht akzeptieren will, dass diese niemals etwas weitere Verbreitung finden sollen. Das Prinzip ist sehr aehnlich zu BeOS, welches ja leider auch gestorben ist. AtheOS ist in letzter Zeit auch absolut inaktiv. :( Ausserdem ist nicht zu erwarten, dass ein Hobbyprojekt eines (extrem talentierten) Coders jemals die Verbreitung der "Grossen" erreicht. Es gibt noch andere Systeme, die versuchen diese Ideen umzusetzen aber die sind allesamt noch kleiner als AtheOS.
Meine Hoffnung ist, dass irgendwann einmal ein derartiges System gepusht wird von einer einflussreichen Organisation wie der FSF. Also Ueberlege ich im Moment so hin und her, ob sich Hurd vielleicht eignet um so ein System aufzuziehen. Die essentziellen Features sind folgende:
- Modulare Treiberarchitektur, so dass Treiber ganz easy im Binaerformat hinzugefuegt werden koennen und auf Anhieb funktionieren. Inklusive Autoerkennung des richtigen Treibers! Das funktioniert bei BeOS und AtheOS tadellos, warum nicht auch mal bei einem "grossen" System? Ist sowas moeglich mit der Hurd Architektur oder liegen die Geraetetreiber hier auch allesamt im Kernel? Ich habe gelesen, dass OS Kit verwendet werden soll spaeter, was genau ist das, wo kann ich mehr darueber erfahren und wie wird das dann mit den Treibern geregelt?
- Integrierte GUI, also aehnlich wie der Linux Framebuffer und dazu noch ein Toolkit. Grafikkarten muessten daher ebenfalls direkt vom System angesprochen werden.
- Zentrale Server die verschiedene Aufgaben erledigen und so ein vereinheitliches "Backend" bilden, wie z.B. ein Appserver fuer alle Anwendungen, ein Mediaserver fuer alle Video/Sound-Player, ein Mailserver fuer alle Emailprogramme, etc. Wenn ich das richtig sehe, geht das Design von Hurd schon etwas in diese Richtung, oder ist das doch was anderes?

Das waer's eigentlich schon. =)

bakunin
Posts: 597
Joined: 16. Aug 1999 6:44
Location: Lorsch (Südhessen)
Contact:

Re: Hurd eine Option fuer den Desktop?

#2 Post by bakunin »

Hi Spark! Natürlich bin ich in der Nähe, wenn jemand "Hurd" sagt.

Auf die Treiberfrage (die nicht wirklich viel mit Hurd zu tun hat, Treiber sind Sache des Mikrokernels, egal ob sie als Prozesse laufen oder im Kernel) gibt es zwei Antworten: Die aktuelle und die zukünftige. <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle"> Momentan sind alle Treiber (weitgehend die aus Linux 2.0.36) im GNU Mach Kernel. Es gibt einen Branch von GNU Mach namens OSKit-Mach, der später GNU Mach 2.0 werden wird. Der wird demnächst genutzt. Dieser unterscheidet sich von GNU Mach 1.x fast nur dadurch, dass für die Treiber das OSKit genutzt wird. Dabei handelt es sich um ein eigentlich separates Projekt, das die Treiber aus Linux 2.2.16 und FreeBSD wrappt. Es wird von etwa 2 Dutzend Projekten verwendet, d.h. von Verbesserungen daran profitieren viele Projekte. So sollte es eigentlich sein. Ich finde es schade, dass die Linux-Leute relativ wenig Interesse daran haben, wiederverwendbaren Code zu produzieren, aber das ist natürlich deren Entscheidung. Auch bei OSKit-Mach sind die Treiber noch im Kernel. Mach verfügt über die Möglichkeit, Treiber als Prozesse laufen zu lassen, aber das ist kaum relevant, denn da Neal Walfield derzeit dafür bezahlt wird, Hurd auf L4 zu portieren, sollte man eher auf L4 schauen. Dort müssen Treiber als Prozesse laufen. Zunächst wird hier wohl auch OSKit benutzt werden, aber die L4-Leute wollen unter der Bezeichnung "L4Env" die Linux 2.4 Treiber verwenden. Eine automatische Erkennung ist mehr oder weniger unter jedem Betriebssystem möglich, es muss sie nur jemand implementieren. Wie leicht oder schwer das auf L4 ist, vermag ich nicht einzuschätzen. Es ist nur noch anzumerken, dass kein Hurd-Entwickler ein Interesse daran hat, die Benutzung proprietärer Treiber einfach zu machen. Kurz gesagt: Dem was du willst, steht nichts prinzipiell entgegen.

Dein Vorschlag mit den zentralen Servern wird wohl kaum jemand bei uns gut finden, denn in Hurd soll jeder Benutzer für sich die Server verwenden können, die er benutzen will. Etwas definitiv Zentrales gibt es also nicht bzw. nur dann, wenn es sich nicht vermeiden lässt (um die globale Prozess- und Rechteverwaltung kommt man z.B. nur unter Einschränkungen herum). Man kann aber natürlich einen Server in /servers platzieren und solange alle Anwendungen ihn ansprechen anstatt einen anderen, ist er praktisch zentral. Nur vorschreiben kann man das nicht, und das ist ganz bewusst so realisiert. Da es möglich ist, Server gemeinsam zu nutzen, spricht also hier konzeptionell nichts gegen das, was du vorhast, oder ist die Zentralität absolut unabdingbar? Welche Probleme würden entstehen, wenn sie nicht gegeben ist.

Das mit der integrierten GUI ist eine schwierige Frage. Die Zukunft weist da eher in Richtung Fresco (ehemals "Berlin", doch diese Anspielung auf die Codenamen eines bekannten Software-Unternehmens war den Berlin-Entwicklern irgendwann zu abgestanden). Das ist zwar nicht "integriert" (was auch immer daran der Vorteil sein soll, wenn etwas untrennbar ist), aber es hat nicht die Krankheiten von X11, hat ein einheitliches Layout und ist für zukünftige Generationen von Eingabemedien gerüstet. Und wenn Tobias Hunger es schafft, GNU/Hurd auf seinem Laptop vernünftig zum Laufen zu kriegen, wird es bald Fresco für GNU/Hurd geben...

Cheers,
GNU/Wolfgang

spark
Posts: 272
Joined: 08. Jul 2000 9:00
Location: Solingen, NRW
Contact:

Re: Hurd eine Option fuer den Desktop?

#3 Post by spark »

Hallo! Wusste ich doch, dass man sich auf dich verlassen kann. ;)
Herrje, habe erstmal bis gerade geschlafen. Es ist schon erstaunlich wie lange sich ein Mensch wachquaelen kann, wenn er neue Betriebssysteme ausprobiert. *seufz*
Also los:

<b>"(Treiber Erklaerung)"</b>

Gut, so war das. Ich wusste, ich hatte da noch was vergessen. ;) Sehr verwirrent fuer mich, dass hier an einem neuen Treiber gearbeitet wird, bei dem schon im Vorfeld geplant ist, ihn dann wieder zu ersetzen. ;) Also was ich eigentlich sagen wollte, haette mich vielleicht einfacher ausdruecken sollen: Ganz wichtig finde ich Binaerkompatibilitaet. Das ermoeglicht nicht nur proprietaere Treiber, sondern macht das ganze auch um ein erhebliches einfacher und flexibler. Und Flexibilitaet ist IMO eine der allerwichtigsten Eigenschaften eines privaten Desktopsystems. Ein System soll mich nicht einschraenken sondern mir im Gegenteil soviele Moeglichkeiten wie moeglich bieten und mich dazu ermuntern indem es die einfachen Dinge auch einfach macht. :) Z.B. wie bei BeOS und AtheOS. Bei beiden waren die NV Treiber nicht im Release enthalten als ich sie getestet habe, also musste ich auf den VESA Treiber zurueckgreifen (bzw. das wurde automatisch gemacht). Um den NV Treiber zu installieren musste ich diesen lediglich downloaden (eine einzige .o Datei) und in den entsprechenden driver/video Ordner platzieren. Beim naechsten Reboot wurde er verwendet! Genau wie meine Netzwerkkarte, Sound, Maus, etc. Wozu umstaendlich Hardware einrichten, wenn das bei moderne Hardware auch so bequem automatisch geht? Zur Hardwareerkennung ist mir aufgefallen, dass Hurd schon meine NE2k-PCI Netzwerkkarte erkannt hat beim booten, so muss das sein. :) Leider konnte ich dann nicht testen ob es auch funktioniert, da sich das System kurz darauf aufgehangen hat... Kann das an der 4GB Partition liegen? Laut Mach News kann er ja jetzt auch grosse Partitionen aber vielleicht ist der noch gar nicht im gnu-latest Tarball enthalten?


<b>"(Zentrale Server)"</b>

Auch hier habe ich mich wohl zu umstaendlich ausgedrueckt. Ich meinte zentrale Server pro Benutzer, nicht unbedingt pro System. Auf einem Desktop System spielt das Multiuser Verhalten ja sowieso keine oder nur eine sehr untergeordnete Rolle, da i.d.R. nur ein Mensch an diesem Rechner sitzen wird. Du hast natuerlich Recht, dass es darauf ankommt, ob die Anwendungen diese Server dann auch verwenden, aber erstmal geht es mir nur um die Moeglichkeit. Der Vorteil solcher Zentraler Server ist, dass man z.B. seine Emaileinstellungen nur einmal vornehmen muss, danach erledigt der Emailserver alles, unabhaengig vom verwendeten Email Client. Wer einmal mit BeOS gearbeitet hat muesste wissen, was fuer ein Krampf das ist unter Windows und Linux. :) Sicher, unter Linux gibt es auch sendmail/procmail/postfix, etc, aber diese sind umstaendlich und werden von den meisten neuen Email Clients nur recht rudimentaer unterstuetzt. Ein Mediaserver hat den Vorteil, dass man einen zentralen Server hat, der alle Grafik-, Video-, Sound-, etc Formate bereitstellt, man fuegt also einfach ein neues Format zu diesem Server hinzu und JEDE Multimedia Anwendung kann diese sofort verwenden


<b>"(Integrierte GUI)"</b>

Ich meine natuerlich nicht untrennbar, aber dennoch eben integriert. :) Dazu kann man sich z.B. das Cosmoe OS anschauen. Hier wird die AtheOS GUI auf einem Linux Kernel mit Framebuffer betrieben, das nenne ich auch schon integriert. Wichtig waere mir vor allem, dass die Grafikschnittstelle im Kernel realisiert wird (aehnlich dem Linux Framebuffer), so dass Treiber genauso einheitlich und einfach hinzugefuegt werden koennen wie alle anderen Treiber. Sowas wie X faellt bei mir auch unter die Kategorie "unflexibel" ... Wenn ich daran denke wie ich gestern Stunden damit verbracht habe X unter Debian wieder ans laufen zu bekommen... Der integrierte NV Treiber mochte meine Geforce 4 wohl nicht (nach etlichen anderen Fehlern), weshalb ich dann "mal eben" den offiziellen Nvidia Treiber installieren musste wofuer ich "mal eben" wieder einen neuen Kernel bauen musste, was natuerlich auch prompt nicht geklappt hat, im zweiten Anlauf mit Kernel 2.4 ging's dann zum Glueck aber es macht keinen Spass...
Fresco ist ja hier denke ich schoen unabhaengig. Wenn man die Grafikschnittstelle im Kernel integriert, kann Fresco die sicher bald nutzen, richtig? Bleibt die Frage ob sich Fresco als effiziente Desktop GUI eignet... Oder ob es nicht eher wieder etwas uebertrieben ist? Immerhin habe ich die AtheOS GUI schon laufen gesehen komplett mit Fenstern und allem, von Berl... Fresco habe ich bisher nur ein paar (nicht so beeindruckende) Demos gesehen. =) Fresco haette natuerlich den Vorteil auch auf anderen Systemen zu laufen und daher unabhaengig zu sein... Hm... Die Frage ist, ob es die Geschwindigkeit einer "einfachen" integrierten UI erreichen kann. Ausserdem wird sich erst noch zeigen muessen, ob dieses Vektorprinzip im Endeffekt effizient ist. Mir ist da immer noch einiges unklar... Z.B. wie in so einer Umgebung mit Pixelgrafiken umgegangen wird. Pixelgrafiken gibt es ja ueberall, z.B. ein Webserver kommt ohne diese gar nicht aus. Und was ist mit Pixelgrafiken in der GUI, z.B. Buttongrafiken? Auf diese wird man doch hoffentlich nicht verzichten muessen. :) Werden diese dann auch skaliert oder wie soll das gehen? Und was ist mit Spielen. Koennen diese Problemlos die gesamte Darstellung uebernehmen, ohne den Vektoroverhead und mit guter Performance? Das sind vielleicht dumme Fragen, aber ich sehe bisher keine Antworten dazu, dabei sind solche Fragen doch essentiell fuer ein Dekstop System.


Und noch eine Frage: Wenn der Port auf GNU/Hurd bereits geplant ist, wie soll in diesem Fall die Grafikhardware angesprochen werden? Wird Fresco das uebernehmen wie X? *graus*

spark
Posts: 272
Joined: 08. Jul 2000 9:00
Location: Solingen, NRW
Contact:

Re: Hurd eine Option fuer den Desktop?

#4 Post by spark »

Zum Bitmap-Scaling ist mir gerade etwas eingefallen... Manche 3D Shooter wie Unreal Tournament 2003 machen das ja schon. Vielleicht ist es also gar nicht mal so unrealistisch zumindest fuer die GUI... Bleibt die Frage was mit Pixeldarstellungen in Grafikprogrammen und Webbrowsern passiert. Hier alles zu strecken und zu schrumpfen ist sicherlich nicht immer erwuenscht.

Argh, dummes Ich. Haette ein bisschen weiterlesen sollen vor dem Schreiben.
"One way to think about this is that in X, the default is pixels, and then people write special purpose applications to deal with vector drawing. In Berlin, we can display pixel-based images, and will probably add some more pixel-oriented support later for special purpose applications, but the default is vectors."

Das beantwortet meine Frage so ziemlich.
Last edited by spark on 14. Jun 2002 0:54, edited 1 time in total.

bakunin
Posts: 597
Joined: 16. Aug 1999 6:44
Location: Lorsch (Südhessen)
Contact:

Re: Hurd eine Option fuer den Desktop?

#5 Post by bakunin »

Hi Spark!

> Sehr verwirrent fuer mich, dass hier an einem neuen Treiber gearbeitet wird, bei dem schon im Vorfeld geplant ist, ihn dann wieder zu ersetzen.

An OSKit wird nicht gearbeitet, es existiert schon lange und ist einsatzbereit. Auch OSKit-Mach funktioniert schon, ihm fehlt lediglich eine Konsole. Die Userspace-Konsole, die gerade für OSKit-Mach entwickelt wird, wird auch unter L4 verwendbar sein. Es wird also nichts entwickelt, was dann ersetzt wird.

> Ganz wichtig finde ich Binaerkompatibilitaet.

Und ich finde Quellcodekompatiblität wichtiger. Binärkompatiblität kann von mir aus zweimal im Jahr oder öfter verlorengehen. Was Dank GCC ja auch der Fall ist. <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle">

> Das ermoeglicht nicht nur proprietaere Treiber, sondern macht das ganze auch um ein erhebliches einfacher und flexibler.

Dass dadurch proprietäre Treiber ermöglicht werden, ist genau das Problem. Natürlich ist es keine gute Idee, proprietäre Software mit technsichen Mitteln fernzuhalten, viel sinnvoller ist es, die Benutzer davon zu überzeugen, dass sie ihre Freiheit schätzen sollten und sie deshalb von selbst keine proprietäre Software einsetzen. Allerdings muss man es proprietärer Software ja auch nicht unnötig einfach machen. Dahger halte ich Quellcodekompatiblität für den besseren Weg, denn hierbei geht keine Flexibilität verloren.

> Kann das an der 4GB Partition liegen?

Die Größe von Partition ist egal und war auch schon immer egal. Relevant ist die Größe von Dateisystemen, und ich kann dir garantieren, dass ein 4 GB großes Dateisystem nicht funktioniert. Eigentlich müsste der Dateisystemserver aber schon beim Starten abbrechen. Dass Mach bis vor einiger Zeit irgendwelche Probleme (zu denen mir gar nichts näheres bekannt ist) mit Festplatten hatte, die größer als 10 GB waren, hat damit überhaupt nichts zu tun. Kann es sein, dass da jemand die Installationsanleitung nicht genau gelesen hat? <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle">

> Der Vorteil solcher Zentraler Server ist, dass man z.B. seine Emaileinstellungen nur einmal vornehmen muss, danach erledigt der Emailserver alles, unabhaengig vom verwendeten Email Client.

Die Idee gefällt mir. Dazu müssen die Anwendungen aber eben die entsprechenden Server benutzen. Existierende Programme aus dem POSIX-Land tun das dann eben nicht, was schade ist. Aber es spricht nichts dagegen, entsprechende Interfaces zu definieren und Anwendungen so zu (umzu)schreiben, dass sie diese verwenden.

> Wichtig waere mir vor allem, dass die Grafikschnittstelle im Kernel realisiert wird (aehnlich dem Linux Framebuffer), so dass Treiber genauso einheitlich und einfach hinzugefuegt werden koennen wie alle anderen Treiber.

Ich sehe nicht, aus welchem konzeptionellen Grund etwas im Kernel sein muss, damit Treiber einfach hinzugefügt werden können. Als Beispiel wäre hier unser neuer Konsolen-Treiber zu erwähnen. Er ist nach dem Client-Server Prinzip aufgebaut, d.h. wir haben einen Konsolenserver, der die Informationen über die virtuellen Konsolen bereitstellt und allen Clients (die für die Darstellung zuständig sind, also praktisch die Treiber) asynchrone Notification-Messages sendet, wenn sich etwas am Bildschirminhalt ändert. Es spricht nichts dagegen, einfach zur Laufzeit andere Clients zu aktivieren und existierende zu deaktivieren. Vom Konzept her wäre das für Grafik-Treiber, die eine GUI darstellen sollen, ähnlich zu realisieren, aus Effizienzgründen müsste man Details natürlich anders machen.

> Ausserdem wird sich erst noch zeigen muessen, ob dieses Vektorprinzip im Endeffekt effizient ist.

Als Backend wird da ja z.B. OpenGL verwendet, daher sollte man eigentlich eine brauchbare Geschwindigkeit erreichen können. Und die Vorteile des Fresco-Konzeptes sind - gerade aus Endanwendersicht - beachtlich, etwa bietet es die allerbesten Voraussetzungen für ein WYSIWYG, das auch tatsächlich funktioniert, da die gleichen zu Grunde liegenden Daten für Bildschirmdarstellung und Druckerausgabe verwendet werden.

> Mir ist da immer noch einiges unklar... Z.B. wie in so einer Umgebung mit Pixelgrafiken umgegangen wird.

Eine Pixelgrafik wird m.W. als Matrix aus einfarbigen kleinen Flächen repräsentiert. Bei einer einfachen GUI mit Buttons macht das keinen Unterschied, Spiele sollten sowas vermutlich nicht verwenden. Wenn dich Fresco bisher nicht sehr beeindruckt hat, liegt das wohl z.B. auch daran, dass AFAIK bisher der komplette Bildschirm neu gerendert wird, selbst wenn es nur für ein einziges Fenster notwendig wäre. Hier gibt es also noch viel Optimierungspotential.

> Wenn der Port auf GNU/Hurd bereits geplant ist, wie soll in diesem Fall die Grafikhardware angesprochen werden? Wird Fresco das uebernehmen wie X? *graus*

Ich bin kein Experte für Fresco, am besten du fragst dazu mal Tobias Hunger selbst. Meine Vermutung wäre, dass es zumindest anfänglich ähnlich wie bei X gemacht würde.

Cheers,
GNU/Wolfgang

spark
Posts: 272
Joined: 08. Jul 2000 9:00
Location: Solingen, NRW
Contact:

Re: Hurd eine Option fuer den Desktop?

#6 Post by spark »

Hallo!

> Dass dadurch proprietäre Treiber ermöglicht werden, ist genau das Problem. Natürlich ist es keine gute Idee, proprietäre Software mit technsichen Mitteln fernzuhalten, viel sinnvoller ist es, die Benutzer davon zu überzeugen, dass sie ihre Freiheit schätzen sollten und sie deshalb von selbst keine proprietäre Software einsetzen. Allerdings muss man es proprietärer Software ja auch nicht unnötig einfach machen. Dahger halte ich Quellcodekompatiblität für den besseren Weg, denn hierbei geht keine Flexibilität verloren.

Fuer den Benutzer schon! Lass mich dir erklaeren was ich meine... Fuer mich ist die Flexibilitaet des Systems sehr wichtig damit es _mich_ nicht einschraenkt. Dazu gehoert, dass es mir alle Aufgaben abnimmt, die ich nicht uebernehmen moechte. Das ist immerhin Sinn und Zweck eines Computers. Mir macht es im Grunde auch Spass an allen moeglichen Dingen herrumzubasteln, aber irgendwann frustriert es mich dann auch wenn ich merke, dass ich mehr Zeit damit verbringe als damit, womit _ich_ eigentlich vorhatte meine Zeit zu verbringen. Ich moechte mich spontan fuer etwas entscheiden koennen und es dann auch machen koennen. Mein System soll mich bei allem so gut es geht unterstuetzen, es war nicht einfacher machen als sinnvoll, aber so einfach und effizient wie moeglich. Einen neuen Kernel kompilieren zu muessen sobald ich eine neue Hardware installiere oder einfach einen neuen Treiber installieren moechte ist definitiv kein Beispiel fuer Effizienz. Es ermuntert mich eher dazu mich in der Wahl meiner Hardware einzuschraenken oder gar auf Aenderungen zu verzichten einfach weil ich gerade keine Lust habe mich damit zu beschaeftigen. Sowas ist kappes und voellig unnoetig. Freie Software unterstuetze ich lieber indem ich Hardwarehersteller bevorzuge die ihre Spezifikationen freigeben, nicht indem ich es mir und anderen umstaendlicher mache...

> Die Größe von Partition ist egal und war auch schon immer egal. Relevant ist die Größe von Dateisystemen, und ich kann dir garantieren, dass ein 4 GB großes Dateisystem nicht funktioniert. Eigentlich müsste der Dateisystemserver aber schon beim Starten abbrechen. Dass Mach bis vor einiger Zeit irgendwelche Probleme (zu denen mir gar nichts näheres bekannt ist) mit Festplatten hatte, die größer als 10 GB waren, hat damit überhaupt nichts zu tun. Kann es sein, dass da jemand die Installationsanleitung nicht genau gelesen hat?

Hoppla... ;) Da habe ich wohl im uebermuedeten Zustand falsch kombiniert, als ich die News au der Hurd-Seite gelesen habe. Gut dann versuche ich es mal mit einer kleineren Partition (und Dateisystem :p), werde dann berichten.Er hat ja quasi beim Starten abgebrochen, mit kurz darauf meinte ich nur kurz nach der Erkennung der Netzwerkkarte. ;)

> Ich sehe nicht, aus welchem konzeptionellen Grund etwas im Kernel sein muss, damit Treiber einfach hinzugefügt werden können.

Was ich viel mehr meinte war, dass Videotreiber genauso realisiert sein sollten wie andere Treiber auch (Netzwerkkartentreiber, Soundkartentreiber, etc) um sowas wie Konsistenz zu erreichen und von einer <b>hoffentlich vorhandenen</b> ;) Binaerkompatibilitaet und konsistenten Hardwareerkennung zu profitieren. Als Beispiel sei mein Debian Progeny Test genannt von damals, jegliche Hardware wurde kommentar- und problemlos erkannt und eingebunden, bis auf die Grafikkarte, fuer die musste noch die X Konfiguration durchgefuehrt werden. Nicht schoen, gar nicht schoen.

> Vom Konzept her wäre das für Grafik-Treiber, die eine GUI darstellen sollen, ähnlich zu realisieren, aus Effizienzgründen müsste man Details natürlich anders machen.

Hmm, ich meinte ja jetzt nicht direkt eine GUI sondern erstmal nur einen generellen Grafiktreiber, sowas wie den Linux Framebuffer (beginnen sollte man hier immer mit einem VESA Treiber denke ich). Also etwas das Programme ansprechen koennen um Grafikdarstellung auf dem Monitor zu erzeugen. Die Grafikschnittstelle wuerde die GUI dann verwenden. Also genau das, was bei Linux der Framebuffer unter /dev/fb0 ist. Ideal waere es natuerlich wenn man dieses /dev/fb0 Geraet auch unter Hurd bereitstellen koennte, so dass Programme gar kompatibel sind und gar nicht gross umgeschrieben werden muessen. Aber ich weiss nicht ob das moeglich ist. Zumindest braucht es als ersten Schritt so einen VESA Treiber und eine Moeglichkeit fuer Programme diesen anzusprechen ueber eine Geraetedatei oder irgendeine API oder gar einen Hurd Translator (wenn ich das nun richtig verstanden habe). Wenn so etwas erstmal existiert, dann waere es ein leichtes diverse GUI's wie z.B. die von AtheOS (die unter Cosmoe bereits auf dem Linux Framebuffer laeuft) zu portieren und zu erweitern.

spark
Posts: 272
Joined: 08. Jul 2000 9:00
Location: Solingen, NRW
Contact:

Re: Hurd eine Option fuer den Desktop?

#7 Post by spark »

Hurd laeuft nun. =) Allerdings ging es nicht mit denen im Original Tutorial angegebenen Grub Bootparametern, dafuer mit dem was im Debian Beispiel stand, naemlich nur ein einziges Modul, dieses bootservers.gz oder so aehnlich.
Am Ende der Installtion gab es noch einen Fehler des Installscripts als fdisk erstellt werden sollte... Also habe ich das mal von Hand gemacht, mal schauen ob's funktioniert. ;)
Der Fehler war uebrigens (beides in ./native-install):
line 191: unexpected EOF while looking for matching ``'
line 207: syntax error: unexpected end of file

Spark@Hurd

Re: Hurd eine Option fuer den Desktop?

#8 Post by Spark@Hurd »

Hello GNU/World! (powered by lynx <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle">

Na das ging ja jetzt richtig gut. :) Groesstes Problem im Moment ist, dass er beim Aufloesen eines Domainnamens rund eine halbe Minute braucht. Das ist sicher nicht normal?
Vielleicht muss ich noch irgendwo meinen Nameserver eintragen (dieser ist mein Gateway). Da muss ich nur noch rausfinden wo. Zweites Problem ist, dass ich weder vim noch vi in der Paketliste finde. =) Gibt's da einen bestimmten Grund zu?

Also wenn ich mal unsere kleine Diskussion da oben zusammenfasse, waere Hurd wohl prinzipiell gut geeignet fuer ein solches Desktopsystem. Das einzige was sich beisst IMO ist der Verzicht auf eine Binaer-Schnittstelle fuer Treiber. Hm. Ich weiss noch nicht, ob ich damit leben kann. <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle">

bakunin
Posts: 597
Joined: 16. Aug 1999 6:44
Location: Lorsch (Südhessen)
Contact:

Re: Hurd eine Option fuer den Desktop?

#9 Post by bakunin »

Hi!

> Hurd laeuft nun. =) Allerdings ging es nicht mit denen im Original Tutorial angegebenen Grub Bootparametern, dafuer mit dem was im Debian Beispiel stand, naemlich nur ein einziges Modul, dieses bootservers.gz oder so aehnlich.

Die serverboot-Methode wird eigentlich nur noch für Neighbourhurds verwendet (und selbst da bin ich nicht ganz sicher). Wenn es bei dir dennoch geklappt hat, hast du riesiges Glück gehabt, denn es ist seit einiger Zeit offiziell "unsupported". Wenn es nach Neal Walfields Install-Guide nicht ging, liegt das erfahrungsgemäß meistens am User. Welche Kommandos hast du denn exakt angegeben?

> Der Fehler war uebrigens (beides in ./native-install):
> line 191: unexpected EOF while looking for matching ``'
> line 207: syntax error: unexpected end of file

Ist vor einiger Zeit gemeldet worden (inklusive Patch ;)). Siehe Mailinglistenarchiv. Im Moment ist es noch eine Voraussetzung, dass jeder Benutzer auf den Mailinglisten ist.

Cheers,
GNU/Wolfgang

spark
Posts: 272
Joined: 08. Jul 2000 9:00
Location: Solingen, NRW
Contact:

Re: Hurd eine Option fuer den Desktop?

#10 Post by spark »

Was ich _genau_ eingegeben habe kann ich gar nicht mehr sagen, weil ich die Eintraege aus Grub schon geloescht habe.
Aber ich habe wirklich peinlich genau darauf geachtet dieses kryptische Zeugs da 1:1 zu kopieren. =)
Also das hier (der Abschnitt fehlt uebrigens komplett in deinem Installationsbericht wenn ich mich nicht taeusche):

kernel /boot/gnumach.gz -s root=device:hd2s1
module /hurd/ext2fs.static --multiboot-command-line=${kernel-command-line} --host-priv-port=${host-port} --device-master-port=${device-port} --exec-server-task=${exec-task} -T typed ${root} $(task-create) $(task-resume)
module /lib/ld.so.1 /hurd/exec $(exec-task=task-create)

Ich kann's ja nochmal mit Copy&Paste versuchen, vielleicht hatte sich da doch noch irgendwo ein Fehler eingeschlichen... Aber ist das ernsthaft die _empfohlene_ Methode den Kernel zu booten? ;) Mir erscheint das etwas kryptisch... Wenn ich den Kernel damit booten wollte hat er sich uebrigens bei "start /hurd/ext2fs.stat" erhaengt aber ich versuch's gleich nochmal.

In die Mailingliste werde ich mich dann auch mal eintragen... Wenn man das muss. Sobald ich mich wieder an mein Passwort erinnere. :)

bakunin
Posts: 597
Joined: 16. Aug 1999 6:44
Location: Lorsch (Südhessen)
Contact:

Re: Hurd eine Option fuer den Desktop?

#11 Post by bakunin »

Hi!

Den Nameserver trägt man in /etc/resolv.conf ein. VIM 6.0 muss noch jemand portieren, aber es gibt ein inoffizielles Paket eines etwas älteren VIM, schau mal im Archiv der Mailingliste nach. Aber du kannst nano (der Default-Editor von Debian) verwenden oder den Emacs von alpha.gnu.org saugen (der mit der gleichen Version im Debian-Archiv ist kaputt, oder war es zumindest). Na, merkst du jetzt, warum man die Liste lesen sollte? <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle">

> Aber ist das ernsthaft die _empfohlene_ Methode den Kernel zu booten?

Das ist die empfohlene Methode, den Kernel zu booten und die essentiellen Server zu starten. Natürlich sieht das etwas kryptisch aus, aber dazu gibt es ja Grub, der ein wunderschönes Menü hat, sodass man die Kommandos nicht jedes mal von Hand eingeben muss. <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle">

Cheers,
GNU/Wolfgang

bakunin
Posts: 597
Joined: 16. Aug 1999 6:44
Location: Lorsch (Südhessen)
Contact:

Re: Hurd eine Option fuer den Desktop?

#12 Post by bakunin »

Hi!

> Verzicht auf eine Binaer-Schnittstelle fuer Treiber.

Wo liest du etwas davon? Dass ich persönlich wenig Wert auf Binärkompatiblität lege, hat nichts zu bedeuten.

Cheers,
GNU/Wolfgang

spark
Posts: 272
Joined: 08. Jul 2000 9:00
Location: Solingen, NRW
Contact:

Re: Hurd eine Option fuer den Desktop?

#13 Post by spark »

Sodele...

Ich habe es nun nochmal mit den "kryptischen" Kommandos versucht und zwar per Copy&Paste, es geht dennoch nicht. Die Module werden offensichtlich geladen und er bleibt dann so stehen:
<blockquote><pre><font size="1" face="">code:</font><hr><font face="Courier New" size="2">start /hurd/ext2fs.static:</font><hr></pre></blockquote>
und reagiert dann auf keine Eingabe mehr.


> Den Nameserver trägt man in /etc/resolv.conf

Argh, stimmt ja. Da stand irgendein mir unbekannter Nameserver drin, das wird dann wohl der Grund sein fuer die Verzoegerung.


> Na, merkst du jetzt, warum man die Liste lesen sollte?

Bisher klappte es doch ganz gut. ;) Ich wollte mir das nur erstmal anschauen bevor ich die Liste abonniere. Aber jetzt spricht nichts mehr dagegen.


> Wo liest du etwas davon? Dass ich persönlich wenig Wert auf Binärkompatiblität lege, hat nichts zu bedeuten.

Sehr gut. ;)


Kennst du dich eigentlich ein bisschen mit der Theorie hinter dem Linuxframebuffer aus? Glaubst du dass es moeglich ist, so etwas aehnliches bereits mit Hurd zu realisieren (zumindest einen VESA Treiber)? Ich haette Interesse mich damit zu beschaeftigen, einfach um mal zu lernen wie das auf der Ebene so funktioniert. Hardwarenahe Programmierung ist immer noch ein Mysterium fuer mich.

Post Reply