Zitat von
foobar
So ungefähr. Jedenfalls ist das mein Verständnis. Ich bin mir sicher, wenn du die Entwickler fragst, sind CSDs das beste seit der Erfindung von geschnittenem Brot und absolut notwendig.
Eine wesentliche Rolle scheint Wayland dabei zu spielen. Der alte X-Server ist schon länger recht unbeliebt. Der wurde halt ursprünglich mal in den 80ern für Mainframes und sowas entwickelt und arbeitet mehr oder weniger nach dem Prinzip, dass das Programm Zeichenbefehle an ihn schickt und der die dann ausführt. Male hier ein Rechteck und da eine Linie und dort den Text „foobar rocks” in Helvetica 12pt rot. Und so weiter. Das gab dann Oberflächen im Stile des alten TWM und sah in etwa
so aus. Und das hat auch gereicht. Damals war ja alles kleiner, auch RAM und Speicherplatz. Farbige Grafik war unbezahlbar und unter hochauflösenden Monitoren verstand man solche mit dreistelliger Pixelzahl pro Achse.
Letzten Sonntagvormittag musste ich die Thematik grob überfliegen (hast mich angefixt), für mich hilfreiche Links:
https://www.x.org
https://www.x.org/wiki/guide/
https://www.x.org/wiki/guide/concepts/#xisclientserver
https://www.x.org/releases/X11R7.7/d...1protocol.html
https://en.wikipedia.org/wiki/Mesa_(computer_graphics)
https://en.wikipedia.org/wiki/Waylan...rver_protocol)
Als X11 entwickelt wurde, kannte Unix noch keine Shared Libraries. Damit nicht jedes Programm seine eigenen Routinen zum Rendern von GUIs statisch gelinkt einbinden musste, hat man sich halt entschieden, das alles in einem Server zu bündeln, welchem die Programme dann nur noch ihre Instruktionen schicken müssen.
Das leuchtet ein.
Rebasing, Relocation, PIC, MMU fallen nicht vom Himmel. Irgendeine Kombination von dem Kram wird man brauchen. Sobald man mehr als einen Prozess im RAM halten will, kann man etwas davon nötig haben, mit Shared Libraries eher mehr.
Man kann zum Sparen von RAM herumtricksen, indem man solche statischen Datensegmente, deren Daten konstant sind (z.B.: .text, .rodata), nur einmal vorhält und solche, die schreibbar sind (z.B.: .data, .bss), je Prozess separat anlegt. Man kann das Einsparen von RAM noch mit Copy-on-write auf die Spitze treiben, indem man es, wo es "schon" eine MMU gibt, auf einen Page-fault ankommen lässt und erst daraufhin die nötige Kopie anlegt. Aber wegen Lags und u.U. auch Speicherfragmentierung ist das bei Prozessen, die sofort laufen sollen, eher ungünstig. Es eignet sich eher für viele ruhende Prozesse, die später mal aufgeweckt werden könnten.
Schon wieder so ein verdammter, (vermeintlich!) realitätsferner, Exkurs. Könnte man vielleicht meinen, aber es ist ja z.B. bereits dann wichtig, wenn man ein Linkerskript überprüfen oder modifizieren muss oder wenn man doch mal wissen muss, was passiert, bevor die Funktion main aufgerufen wird. Den Assembler-Output würde man schlechter verstehen, wenn man keine Vorstellung davon hätte, welchen Sinn manche hinzuaddierten Offsets haben könnten. Viele Kniffe werden nicht nur bei Shared Libraries verwendet.
Es scheint tatsächlich zu helfen, ein wenig die Historie zu beleuchten, z.B. wie man von einem Unix, bei dem noch der ruhende Prozess auf der Festplatte gespeichert sein musste, während der andere läuft (wie ich mal irgendwo gelesen habe, vermutlich weißt du mehr darüber, mehr als ich sowieso), schrittweise zu einem modernen Betriebssystem gekommen ist ("modern" natürlich nicht im Sinne von komischen UX-Experimenten zu verstehen).
Als netter Bonus fiel Netzwerktransparenz dabei ab, also dass man die Grafikausgabe eines Programms auf eine andere Maschine umleiten kann, ohne dass die Anwendung es überhaupt mitkriegt.
Not macht wohl erfinderisch.
So arbeitet aber heute kaum noch was. Heutzutage hat man Shared Libraries und die Leute erwarten Farbverläufe und komplexe geometrische Formen mit Schatten und Pipapo. Und das alles in Zeichen-Instruktionen zu zerlegen, würde zu viel Leistung kosten. Statt dessen nutzen die Programme lokale Toolkits (GTK, Qt, etc). Die abstrahieren noch stärker als X11 und das Programm sagt nur noch: Hier einen Knopf und da ein Eingabefeld und dort eine Dropdown-Box und so weiter. Das Toolkit entscheidet dann, wie die auszusehen haben. Es rendert die gesamte GUI (stark vereinfacht) lokal und schickt dann nur noch das fertige Bitmap an den Server. Der hat zwar inzwischen auch ein paar Erweiterungen gekriegt, die dabei mithelfen, aber im Prinzip läuft es so ab.
Und dann dachten sich die Leute halt: Es wird Zeit, den alten X-Server abzulösen. Vorhang auf für Wayland, welcher deutlich einfacher gestrickt ist und sich wirklich nur noch um das Darstellen von Bitmaps kümmert. Außerdem erledigt er noch das Compositing (z.B. für Schattenwurf und solchen Schnickschnack), was beim alten X11 auch nicht unkompliziert war. Der muss dazu ständig aufwendig mit dem Compositor Daten austauschen.
Weg mit dem performancekillenden und verkomplizierenden Nadelöhr auf lokaler Ebene! Damit ist ein richtiges Desktopbetriebssystem entstanden, könnte man sagen.
Ich bin ja durchaus dafür zu haben, überflüssige Komplexität zu entfernen. Und das alte X11 hatte wirklich so seine Probleme, aber hier ist man IMHO einfach zu weit gegangen. So bliebt auch die Netzwerktransparenz bei Wayland auf der Strecke. Soll man halt Fernwartungsprotokolle wie VNC oder RDP benutzen, sagen die Entwickler. Auch wenn das natürlich kein echter Ersatz ist. Und Wayland erzwingt bei der Gelegenheit auch CSDs. Wenn die Anwendungen (über die Toolkits) eh alles lokal rendern, können sie das ja auch gleich für die Fenster-Dekos mit machen. Dass das für uneinheitlichen Wildwuchs sorgt und zu den bereits genannten Problemen führt, ist halt Pech.
So ganz verstehe ich noch nicht, was es bedeutet, dass Wayland CSDs erzwingt. Gibt es denn kein Messaging? Vielleicht D-Bus (nur geraten)? Dann müsste es doch, wie bei Windows, egal sein, woher die Messages kommen, solange das Programm richtig darauf reagiert.
Es könnte z.B., falls nötig, die eintrudelnden Messages übersetzen, damit sie zum neuen System passen. Dann bräuchte man nur noch eine richtige Taskleiste oder brauchbare Tastatur-Shortcuts (wie z.B. Alt-F4 unter Windows), damit man ohne großen Aufwand Nachrichten an das Programm schicken kann.
Also sind diese Linux-Distributionen, von denen gelegentlich Leute erzählen, doch noch keine richtigen Desktopbetriebssysteme?