>>68981>Fefe regt sich öfters über DBus, polkit, freedesktop etc. auf.
Dieser Felix auch.
>Ich kann mich aber nicht erinnern, mal eine Lösung/Alternative von ihm gehört zu haben.
Die zwei Alternativen zu D-Bus, von denen Felix gehört hat, sind KDBUS und BUS1. Waren beides Kernel-Implementierungen von D-Bus, so dass zumindest keine Benutzermodusprozesse meer herumgeistern. Beide sind gescheitert/eingeschlafen. Es gibt noch dbus-Broker als "leichtgewichtigere" Alternative zu dbus, aber es ist im Grunde das Gleiche, als dass man weiterhin die Abhängigkeiten hat und dafür weiterhin Prozesse dauerhaft am Laufen halten muss.
>>68987>Es hat Felix noch nie jemand erklären können, wozu der Ranz gut sein soll. Löst nur Probleme, die es ohne DBus niemals gegeben hätte.
D-Bus ist Interprozesskommunikation. Genauer: Eine bestimmte Art, Interprozesskommunikation zu lösen, via einem Client-Server-Modell, wobei die Clients Anfragen an den Server schicken können, welcher dann die Anfragen (calls) an einen oder mehrere andere Clients weiterleitet, und die Antworten (returns) dann den umgekehrten Weg zurück nehmen. Daneben gibt es noch Fehler (errors). Die verschickten calls/returns simulieren dabei Methodenaufrufe.
Der Server-Prozess kann mehrere Namensräume (="Busse" wie in D-"Bus") definieren, und Clients sehen Dinge aus ihrem Namensraum, nicht aus anderen Namensräumen. Jeder Bus hat eine "Adresse", in der Regel ist das ein Pfad im Dateisystem zu einem Unix domain socket.
Wenn man selbst eine Client-Anwendung schreibt, die D-Bus benutzen sollen, dann wird sich die Anwendung als erstes (mittels libdbus) zu einer solchen bestimmten D-Bus-Adresse verbinden - das ist in der Regel ein Unix domain socket irgendwo im Dateisystem. Welche D-Bus-Adresse wird genommen und woher kriegt man den Dateinamen her? Es wird in der Regel der Session-D-Bus genommen, d.h. jede laufende Benutzersession hat einen Unix domain socket für D-Bus im Dateisystem. Der Dateiname dafür steht in der Regel in irgendeiner Umgebungsvariablen. Die Anwendung verbindet sich also mit dem Unix domain socket und kann nun Pakete über den Socket schicken/empfangen.
Den Inhalt der zu sendenden/empfangenen Pakete wird dabei von D-Bus spezifiziert und man klöppelt sich diese natürlich nicht per Hand zusammen (könnte dies aber tun), sondern dafür gibt es auch Funktionen in libdbus. D-Bus hat sich das vermeintliche Ziel gesetzt, "wie objektorientierte Programmierung" verwendbar zu sein (kein Witz). Also so ziemlich genauso wie bei CORBA, nur dass Fefe irgendwie viel meer auf CORBA rumhackt als auf D-Bus.
Kurzum, man macht dabei sowas:
send_message("/de/codeblau/KnorkerTexteditor", "set_background_color", 0x00fefe);Dabei ist "/de/codeblau/KnorkerTexteditor" der wohlbekannte Name, die die Anwendung hat, mit der man kommunizieren will. Z.B. will man hierbei die Hintergrundfarbe von Fefes Knorkem Texteditor auf 0x00fefe setzten. Alle Anwendungen, die sich mit "/de/codeblau/KnorkerTexteditor" registriert haben, kriegen nun die Anfrage rein, die Hintergrundfarbe auf Bayrisch Blau zu setzten. Statt "KnorkerTexteditor" kann man auch noch D-Bus-Prozessnummer-Strings benutzten, welche für jeden Prozess einzigartig sind.
Wenn man obige Funktion ausführt, verpacken die Bibliotheksfunktionen der libdbus die Parameter dann in ihre Datenstrukturen (braucht Interfacespezifikation gemäß einer XML-Konfigurationsdatei, kein Witz), schicken es über den Socket an den D-Bus-Server, und der schickt das dann an die Clients, welche dann mittels der libdbus die Datenstrukturen wieder entpacken und die Anfrage verarbeiten können.
So, das macht D-Bus im Großen und Ganzen.
>die Alternative zu DBus ist einfach kein DBus
Felix hat auch versucht, sein ARSCH-Linux möglichst ohne D-Bus aufzusetzen. Klappt natürlich nicht weil
>Bei Arsch ist halt alles immer mit --kitchensink kompiliert.
Konkret startet sich der dbus-Dämon z.B. wenn man im Feuerfox mittels Strg+O eine Datei öffnen will, und sich der GTK-Dateiauswähler startet, welcher natürlich die GLib benutzt, welche dann D-Bus benutzt, wie schon oben mit dem Accessibility-Krams erklärt wurde.
Die Alternative zu D-Bus ist, dass die Anwendungen einfach die Interprozess-Primitive des Betriebsystems benutzen oder gar nichts benutzt, d.h. die Funktionalität rausreißt. Also Selbstkompilieren und einen Haufen Patches vorhalten. -_-
>>69056>früher war opensource immer auch datenschutzfreundlich und hat im gegensatz zu wdoof den user nicht ausspioniert. pöttering arbeitet jetzt aber aktiv an der zerstörung davon. die microsoftifizierung von GNU/Linux, damit das genauso schlecht ist.
Ein halbes Jahr später ist das noch viel aromatischer geworden.