Was muss an GNU, Linux, X11 usw. noch verbessert werden?

Post Reply
Message
Author
peterm
Posts: 287
Joined: 16. Sep 2000 15:35

Was muss an GNU, Linux, X11 usw. noch verbessert werden?

#1 Post by peterm »

Hi Leute!

Ich versuche, mich möglichst kurz zu halten.

In den letzten Jahren hat die Freie Software gewaltige
Fortschritte gemacht. Mit KDE 2.x haben wir ein komfortables
Desktop Environment bekommen, das device filesystem ist dabei,
mknod zu ersetzen, durch das GNOME Accessibilty Framework können
bald auch Menschen mit Behinderungen PC`s mit minimaler Einschränkung
benutzen, kernel 2.4 zeigt extreme Stabilität, XFree86 4.x ist mit seiner
Modularisierung schneller geworden, unter XFree86 können Mäuse-Drehräder verwendet
werden und und und ...

Es gibt aber noch Bereiche, in denen GNU, Linux, X11, (BSD) etc. noch
Mängel aufweisen. XFree86 ist mit seiner TCP/IP-Kommunikation nicht gerade
der Geschwindigkeits-Hammer, der Kernel kann noch keine binären Treiber verwenden,
manche Spezial-Anwendungen sind noch nicht verfügbar, etliche Spiele laufen noch nicht native,
es gibt AFAIK keine Standardisierte Interprozess-Kommunikation, die ein gutes, vom Betriebssystem
unabhängiges kommunizieren erlaubt (also auf HURD und BSD auch funktioniert), das Laden von shared objects
dauert im Schnitt 0.5 sec, Freetype lässt sich schlecht in XFree86 integrieren usw.

Für viele dieser Probleme existieren bereits Ansätze, wie z.B. das AFAIK glibc-basierte pre-linking, das nächstes
Jahr(?) kommen soll...

Aus diesen Gründen dachte ich mir, dass jeder hier in diesen Thread schreiben könnte, was ihn/sie momentan stört.
Wir könnten das dann in Form von E-Mails an die verschiedenen wishlists schicken. Gut, die werden sicher
nicht jeden einzelnen Wunsch gleich bearbeiten, und manche Wünsche sind auch sehr schwer zu realisieren, aber
vielleicht gibt das dem einen oder anderen Entwickler einen Ruck, um die Software dementsprechend zu verbessern.

Denkt daran, die Freie Software lebt vom den Usern, und nur so kann sie verbessert werden, indem die Vorstellungen und Wünsche der Benutzer mit den Programmier-Fähigkeiten der Programmierer verbunden werden.

Kritiken nehme ich natürlich auch gerne entgegen, das wird mir nicht erspart bleiben, solange sie einen gewissen Grad an
Höflichkeit nicht unterschreiten.

Gruß und eine (hoffentlich) angeregte Diskussion wünscht
PeterM
Last edited by peterm on 01. Sep 2001 0:04, edited 1 time in total.

marc
Posts: 444
Joined: 20. Apr 2001 23:31
Location: Arnsberg

Re: Was muss an GNU, Linux, X11 usw. noch verbessert werden?

#2 Post by marc »

Ich befürchte, daß Du gerade einen Riesenthread ins Rollen gebracht hast... <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle">

Na dann wollnwer mal. Neben den Punkten die Du schon genannt hast, fallen mir noch einige Sachen ein, die das Linux-Leben leichter machen könnten, aber einiges klingt wahrscheinlich auch ein bißchen utopisch.

- Eine im Kernel integrierte automatische Hardware-Erkennung wäre nicht schlecht. Damit meine ich, ich lade mir n aktuellen Kernelsource runter, und klicke auf installieren. Daraufhin wird die Hardware untersucht und die notwendigen Module werden erkannt, kompiliert und installiert. Kein stundenlanges Rumgesuche mehr unter menuconfig oder xconfig. Selbstverständlich wäre die Hardware-Erkennung nur eine Option und kein Zwang. Wer will kann eben noch alles selbermachen. Aber für Einsteiger wäre das doch hervorragend, wenn man neue Hardware hat, und die Distri, die man nutzt hat einen älteren Kernel, der die Hardware noch nicht unterstützt. Also nur neuen Kernel runterladen und automatisch installieren mit dem was man braucht, fertig.

- Allgemein bessere automatisierte Konfigurationen, z.B. bei XFree und 3D, Sound, usw.

- Einheitliche Konfigurationstools. Immer ein paar xterms aufhaben und in .conf-Files rumeditieren macht zwar Spaß, aber einheitliche Tools wären für viele Leute einfacher, da man nicht erst die ganzen Optionen und Parameter in den Man-Pages nachschlagen muß. So etwas wie Webmin, SWAT, usw. sind da schon sehr gute Ansätze und das geht auch in etwa in die Richtung, wie ich das meine.

- Vereinfachte Installation von Programmen. Damit meine ich nicht die Installation an sich (es gibt ja checkinstall, eine GUI ist dafür glaube ich auch in Planung), sondern das was danach kommt. Also automatische Integration der Programme in die Desktopumgebungen. Ich hätte dann gerne das Icon für meinen neuen Browser auch unter der Kategorie in der Startleiste, wo die anderen Browser sind. Und das eben bis hin zur Deinstallation, daß das Icon auch wieder gelöscht wird.

- Automatische Updatefunktionen. Jaja werden jetzt einige sagen, gibts doch schon (apt-get, urpmi,...), aber ich meine was anderes, einfacheres. <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle">
Das Problem bei den bisherigen Lösungen, ist eben, daß es nur für die jeweilige Distri gilt, und die Updates auch von den Distributoren erst fertiggestellt werden müssen.
Es wäre doch viel einfacher, wenn es da eine Schnittstelle gäbe, auf die die Programme zugreifen könnten, gepaart mit einer Online-Datenbank.
Also ich hätte gerne eine aktuelle Version von Programm xyz. Ich starte Programm xyz. Ich klicke im Menü auf die Option Update. Daraufhin verbindet sich das Programm zu einer Online-Datenbank (Freshmeat?) und schaut nach, ob es eine aktuelle Version gibt. Wenn ja, wird der Source runtergeladen, und z.B. per Checkinstall installiert, bzw. upgedatet. Ist auch praktisch für Security-Updates, da man das eventuell auch automatisieren könnte, also alle 2 Tage nach Updates für die Server-Software suchen...

Das wärs erstmal, was mir da so spontan einfällt. Aber wahrscheinlich werden das Wunschträume bleiben <img src="http://www.pl-forum.de/UltraBoard/Images/Happy.gif" border="0" align="middle">

Gruß
Marc

peterm
Posts: 287
Joined: 16. Sep 2000 15:35

Re: Was muss an GNU, Linux, X11 usw. noch verbessert werden?

#3 Post by peterm »

Hi!

Mir fällt da noch etwas ein:

XFree86 kann während des Betriebs automatisch auf andere Eingabegeräte umschalten,
ein einheitliches Paket-System muss her, alle X-Window-Programme wie z.B. KDE und GNOME
greifen automatisch auf alle X­Fonts zu, das muss nicht extra konfiguriert werden.

Gruß PeterM

Spark

Re: Was muss an GNU, Linux, X11 usw. noch verbessert werden?

#4 Post by Spark »

Marc, ich finde es wirklich komisch Vereinfachungen zu fordern, aber von Quellcodes zu reden.
Jaja, selber kompilieren hat auch seine Vorteile, aber keine wirklich nennenswerten und keine, die nicht sowieso verloren gehen wuerden, wenn man den Prozess automatisiert.

- Kernel kompilieren sollte einfach nicht mehr notwendig sein, anstatt das zu vereinfachen. Es ist doch Schwachfug, sich fuer jede Hardware einen Kernel kompilieren zu muessen. Eine Schnittstelle fuer Binary Module waere die Loesung, aber das wird von Mister Torvalds ja anscheinend nicht gewollt...

- Programme ins Startmenue ein und wieder austragen geschieht mit RPM und DPKG bereits automatisch.

- Upgradefunktion in die Anwendung integriert? Wo ist da der Sinn?
Das hat vor allem KEINE Vorteile fuer die Sicherheit, da wichtige Programme i.d.R. eh nicht mit eigener GUI daherkommen, also kann es da sowas nicht geben.
Um ein System auf dem laufenden Stand zu halten, dafuer ist APT bereits optimal. Auch und gerade fuer einzelne Anwendungen.
"apt-get install bind" und wieder ein Sicherheitsloch geschlossen. ;)
Warum ist es ein Nachteil, dass die Distributoren das erst zur Verfuegung stellen muessen?
Ansonsten waere es gar nicht moeglich, das Paket so sauber ins System zu integrieren.
Alternative waere also, dass einfach das neueste Binary Paket installiert und die Datenbank der Distribution voellig umgangen wird.

Zum Thema:
Es gibt einiges an GNU/Linux, was mich stoert, aber das sind groesstenteils fundamentale Dinge, die kann man nicht einfach "fixen"... muss auch nicht.

marc
Posts: 444
Joined: 20. Apr 2001 23:31
Location: Arnsberg

Re: Was muss an GNU, Linux, X11 usw. noch verbessert werden?

#5 Post by marc »

> Marc, ich finde es wirklich komisch Vereinfachungen zu fordern, aber von Quellcodes zu reden.
> Jaja, selber kompilieren hat auch seine Vorteile, aber keine wirklich nennenswerten und keine, die nicht sowieso verloren gehen wuerden, wenn man den Prozess automatisiert.

Das Problem, was ich hiermit ansprechen wollte, sind die Inkompatibilitäten der verschiedenen Paketformate für die jeweiligen Distris. Man kann das zwar alles über Umwege installieren, indem man die Pakete umkonvertiert und was weiß ich noch wie, aber das ist eben umständlich. Wenn man stattdessen direkt automatisch den Source kompiliert, und dabei das jeweilige Paket generiert (Checkinstall), dann hätte man das Problem nicht mehr.
Aber dieser Punkt wird sich wahrscheinlich demnächst sowieso mehr oder weniger erledigt haben, wenn sich die Distris mehr an die LSB halten.

> Eine Schnittstelle fuer Binary Module waere die Loesung, aber das wird von Mister Torvalds ja anscheinend nicht gewollt...

Verzeihe mir meine Unkenntnisse bezüglich der Linux-Treiber-Technik. Ich vermute mal, daß Du nicht die bisherige Möglichkeit, mittels modprobe Module zu laden, meinst...

> Upgradefunktion in die Anwendung integriert? Wo ist da der Sinn?
> Das hat vor allem KEINE Vorteile fuer die Sicherheit, da wichtige Programme i.d.R. eh nicht mit eigener GUI daherkommen, also kann es da sowas nicht geben.

Ja gut, man könnte das auch über ein externes Programm machen, und die jeweiligen Proggis auswählen.

> Um ein System auf dem laufenden Stand zu halten, dafuer ist APT bereits optimal.

Ja schon, wenn man Debian nutzt. Aber da wartest Du auch erstmal darauf, daß es deb-Pakete gibt.
Wenn man das eben über ein einheitliches Update-Programm machen würde, daß von allen Distris genutzt werden könnte, wo dann eben direkt der Source runtergeladen und für das jeweilige System das Paket erstellt wird (Checkinstall), dann braucht man nicht zu warten, bis für die Distri, die man nutzt, das Paket von den Distributoren erstellt wird.

Gruß
Marc

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

Re: Was muss an GNU, Linux, X11 usw. noch verbessert werden?

#6 Post by bakunin »

Hi!

Eine Schnittstelle für binäre Module existiert doch, wo ist das Problem damit? Ich kann einen Treiber-Code schreiben, compilieren, mit modprobe laden und es läuft, ohne auch nur den Kernel-Quellcode auf der Platte zu haben. Nur die Kernel-Header braucht man natürlich. Erzähle mir jetzt keiner, dass das nicht ginge, schließlich habe ich das selbst schon gemacht.

Alles was mich an Unix stört, wird durch Hurd gelöst. Den Mach-Kernel sollte man vielleicht dann irgendwann korrigieren oder durch L4 o.ä. ersetzen, aber sonst stört mich daran prinzipiell nichts. Müsste es nur noch stabil sein, etwas schneller sein und irgendwann ein Fenstersystem haben, durch das die Vorteile von Hurd nutzbar werden. Dann bin ich im Paradies. ;)

Es wäre dann noch schön (wenn auch nicht zwingend notwendig für mich), eine brauchbare grafische Oberfläche zu haben. Wie so oft trifft Alan Cox hier den Punkt: "How come the .44 magnum is the worlds only usable point and click interface?". XFce ist das Beste, was ich bisher gesehen habe (Alan benutzt das auch ;)), aber vollkommen zufrieden bin ich damit auch nicht. Eine brauchbare grafische Oberfläche ist für mich eine, die mir produktives arbeiten ermöglicht; dazu muss eine Oberfläche vor allem übersichtlich sein (und auch bei intensiver Benutzung bleiben) und schnellen Zugriff auf alles Wichtige ermöglichen. Diese Forderung ist natürlich nicht besonders konkret, aber mir ist es nicht sehr wichtig, wie eine Oberfläche nun exakt realisiert ist, sofern sie diese allgemeinen Anforderungen so erfüllt, wie ich das gerne hätte.

Cheers,
GNU/Wolfgang

Spark

Re: Was muss an GNU, Linux, X11 usw. noch verbessert werden?

#7 Post by Spark »

Wolfgang, sind diese Header generisch? Also angenommen, ich habe irgendeinen vor Jahren kompilierten Kernel 2.4.2 auf meiner Platte und will dafuer nun die NVidia Treiber kompilieren.
Den Kernel habe ich aber nur noch als Binary Paket rumfliegen.
Kann ich mir jetzt die 2.4.2 Header runterladen (von wo auch immer), das NVidia Modul dafuer kompilieren und es laeuft?
Das kann ich mir nicht vorstellen, denn wenn das ginge, dann muesste es doch auch gehen ein allgemeines 2.4.2 (oder sonstwas) Modul bereitzustellen, welches dann jeder verwenden kann, oder nicht?
Das ist es was mich so aufregt. Ich will nicht kompilieren, also spiele ich mit RedHat. Warum? Weil RedHat einen festen Kernel hat, fuer den ich auch das NVidia Modul kriege. Mit Debian muesste ich so oder so kompilieren. Und das bedeutet, mich durch die komplette Kernel Konfiguration zu wurschteln, in der nichtmal vernuenftige Defaults eingestellt sind. Ergebnis ist dann meistens, dass erstmal anscheinend das meiste laeuft, ich dann aber irgendwann feststellen, dass noch etwas wichtiges fehlt. Meistens dann, wenn die Sourcen verlorengegangen sind oder etwas in der Art.
Ich sauge mir das alles jetzt nicht aus den Fingern, das war in etwa die Zusammenfassung meiner Erlebnisse der letzten Monate mit dem Linux Kernel. ;)
Kurz gesagt: Es nervt und ich habe wenig Lust, mich gross mit so etwas aufzuhalten. Vor allem, wenn andere Systeme so schoen vormachen, wie es gehen koennte... Einfach Modul runterladen, an eine Stelle kopieren, neu booten, Geraet wird erkannt und der entsprechende Treiber geladen. Fertig.
Jetzt habe ich das Problem, ich wuerde gerne unter Debian programmieren, weil mich RedHat hier schon wieder ankotzt mit dem Paketmanagment. Red-Carpet ist das einzig vernuenftige, aber jedesmal das Ding zu laden und mich da durchzuklicken ist nicht so toll. Und dann funktioniert das nichtmal immer. :(
Bei KDevelop sagte er mir einfach, dass er Qt-Designer nicht finden kann... bei einem anderen Paket gab es einen RPM Fehler... etc.
Also brauche ich wieder Debian und Apt-Get und darf mich dann wohl erneut mit Kernelkompilieren herumschlagen...
Das waere ja nicht sooo tragisch, wenn ich wenigstens einen Source laden koennte, der genauso konfiguriert ist wie der Debian Binary Kernel (der funzt naemlich ganz gut), so dass ich mich dann nicht wieder durch alle Optionen hangeln muesste sondern einfach nur kompilieren und dann das Modul kompilieren (Debianer hat ja gluecklicherweise nicht nur ein Kernel Kompilationsscript, sondern auch ein automatisches NVidia-Treiber-saug-kompilier-und-installier-Script, also waere das nicht so das Problem :)).
Ach und Xfree ist auch so ein Ding... die 3D Performance ist verdammt geil! Warum zum Henker, geht das nicht im 2D Modus? Ohne Scheiss laufen bei mir die simpelsten 2D Spiele schlechter, als Quake3 mit allen Details. :(
Koennte es sein, dass er fuer OpenGL die TCP/IP Kommunikation umgeht? Warum kann er das nicht auch fuer 2D Spiele? Oder gar ueberhaupt?
Dann haette ich wirklich kaum noch ein Problem mit X (zumindest als Spieleplattform).

Marc R: Eigentlich kann ich damit leben, ein oder zwei Tage auf ein Debian Paket zu warten, wenn es dann dafuer auch perfekt ins System eingebunden ist (bei Debian werden die Pakete nicht einfach zusammenschustert, sondern muessen ziemlich kritische Richtlinien erfuellen, damit eine gewisse Qualitaet garantiert ist. Das mag ich).

marc
Posts: 444
Joined: 20. Apr 2001 23:31
Location: Arnsberg

Re: Was muss an GNU, Linux, X11 usw. noch verbessert werden?

#8 Post by marc »

> Koennte es sein, dass er fuer OpenGL die TCP/IP Kommunikation umgeht?

Soweit ich weiß schon. Das "D" in DRI steht ja nicht umsonst für "Direct". Ist eben hardware-näher. Für 2D, bzw. Video I/O usw. ist glaube ich beim DRI-Projekt auch was in Planung.
(Sollte ich mich hier irren, bitte laut rufen)

> Eigentlich kann ich damit leben, ein oder zwei Tage auf ein Debian Paket zu warten,

Ein, zwei Tage sind nicht die Welt. Da brech ich mir auch keinen ab.
Ich hätte aber trotzdem gerne so eine Update-Funktion wie ich das beschrieben hab, die ich auf jeder Distri (unter Umständen sogar LFS) gleichermaßen nutzen könnte. Und so schlecht ist die Systemintegration bei selbstkompilierten Programmen auch nicht.
Vielleicht setz ich mich da mal dran, wenn ich mein C++-Buch durchhab <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle">

Gruß
Marc

Leander Hanwald

Re: Was muss an GNU, Linux, X11 usw. noch verbessert werden?

#9 Post by Leander Hanwald »

>Für 2D, bzw. Video I/O usw. ist glaube ich beim DRI-Projekt auch was in Planung.
(Sollte ich mich hier irren, bitte laut rufen)<

Ich glaube sowas gibt es in Form der XV , der X Video Extension schon.

So wie ich das verstanden habe wird da direkt in den Grafikkartenspeicher das Bild reingeschrieben.
Damit er weiss was er zeichnen soll wird mit einer Markierungsfarbe vorgezeichnet.

Öffne mal ein Video z.B. mit mplayer und starte es mit vx Support. Dann starte das Video und bewege das Fenster. Bei mir bleibt dann das Bild immer etwas hinter dem fenster zurück (ist langsamer beim Verschieben) und an den nicht gemalten stellen wird ein Blauer Hintergrund sichtbar.
Das gleiche ist auch unter Windows der fall. (Dort ist Hardware beschleunigtes Video abspielen normal).

Das schöne daran: Unter Linux ist das ganze bis zu 60% schneller als unter Windows :D

Spark

Re: Was muss an GNU, Linux, X11 usw. noch verbessert werden?

#10 Post by Spark »

Leander, ich vermute mal, dass das die Videofunktionen der Hardware anspricht und nicht ganz allgemein dazu da ist, 2D Grafiken direkt auf den Screen auszugeben.
So etwas faende ich wirklich klasse und es sollte am besten noch optional sein, ob man Xfree mit TCP/IP Support oder ohne verwendet.
Die Frage ist, ob das geht...
Aber es wuerde mir schon reichen, wenn man das fuer Spiele aktivieren koennte, z.B. ueber SDL.
Schaut euch mal DirectFB an, das ist richtig cool fuer 2D Grafiken.
Nur leider verwendet das keiner und es gibt kaum Unterstuetztung. Wer kauft schon ein Spiel, wenn er dafuer vorher seinen Framebuffer einrichten muss. ;)
Von Treibern ganz zu schweigen...
Wenn X hier irgendwie die gleiche Performance erreichen koennte, das waere was feines. Dann noch Hardwaresupport fuer Alphablending, Antialiasing, u.s.w... *traeum*
Ausserdem sollte es moeglich sein, bestimmten Programmen zu erlauben, die Bildschirmaufloesung beliebig zu wechseln, auch wenn die gewuenschte Aufloesung nicht in der XF86Config angegeben wurde.
Das waere praktisch fuer einige Spiele mit sehr exotischen Aufloesungen, damit ich die Werte nicht immer nachtragen muss in die Konfigdatei! Und ich traue den Spielen eigentlich, dass sie nicht irgendetwas einstellen, was meinen Monitor zerstoert.

demon
Pro-Linux
Posts: 389
Joined: 24. Nov 1999 0:05
Location: Wörth am Rhein
Contact:

Re: Was muss an GNU, Linux, X11 usw. noch verbessert werden?

#11 Post by demon »

Na gut, dann werde ich wohl auch zu dieser interessanten Diskussion mein Senft dazu geben.

Das vom Marc angesprochene Treiber-Problem kann ich nur als Kernel-Hacker unterstreichen. Im Prinzip existiert in der Tat eine Schnitstelle, die eine Anbindung von bereits compilierten Treibern ermöglicht. Leider ist es eben nur Prinzip und die Praxis sieht anders aus. Die Praxis sieht so aus, dass ich fast für jede Kernel-Version einen neuen Treiber erstellen müsste, sollte dieser nur als Binary-Version verfügbar gemacht werden. Sicherlich ist der Kernel nicht dazu bestimmt Binary-Only Treiber zu unterstützen, aber leider geht manchmal an dieser Lösung kein Weg vorbei. Gründe ein Treiber nicht unter der GPL zu veröffentlichen gibt es viele. Benutzt man einen ASIC eines Chip-Herstellers, der die Specs nicht freigeben will, so darf in der Regel der Code und die Internes des Chips nicht veröffentlicht werden. Sobald ich aber auf Register zugreife oder den Chip initialisiere, gebe ich diese Infos Preis und riskiere eine Vertragsstrafe. Die einzige Lösung wäre nun ein Binary-Only-Treiber zu veröffentlichen, oder Linux nicht zu unterstützen. Und da haben wir die Probleme... Nicht das ich die Probleme hätte, aber sehr oft musste ich komplette Funktionen neu schreiben, weil der Chiphersteller seine nicht veröffentlichen wollte.

Leider ist auch der Linux-Kernel zum Teil nicht sonderlich flexibel. Der integrierte Kernel-Debugger ist im Vergleich zu HP, Solaris oder AIX mit Verlaub eine Zumutung. Nicht umsonst heißt es unter Linux »The best friend is printk«. Das Speichermanagement des neuen Kernels kann ebenfalls als nicht sonderlich glücklich bezeichnet werden. Oft sind mehrere Funktionen im Kernel integriert, die das selbe bewirken. Das bläht die Größe der Sources und des Kernels unnötig auf.

Nichts desto trotz vertrete ich die Meinung, dass der Kernel an sich ein gutes Stück Arbeit ist. Es wird immer Schwächen geben und es werden immer neue Ideen geboren und auch der Kernel wird noch besser. Was mir aber sorgen macht ist der Umfang dieses. Sollten keine erkennbaren Konzepte entstehen dem Kernel zu entrümpeln und in der Größe zu reduzieren, so dürfen wir uns schon bald auf ein Download von 200MB an Sources freuen, wenn wir Kernel 3.x.x kompilieren wollen. Vielleicht wäre eine Trennung in mehrere Kernels nicht schlecht wie z.B. Consumer- und Embended-Kernel?

Gruss

demon

Post Reply