Das läuft doch zu 99% über udev und dbus, die eigentliche Arbeit wird vom Basissystem übernommen. Das ist ne simple Schnittstelle und keine tiefe Integration.
udev ist ein Low-Level System welche das Hotplugging übernimmt, es macht nicht viel mehr als die benötigten Devices anzulegen, Rechte zusetzten, und bei bedarf ein anderes Tool anzustoßen.
dbus ist eine IPC Implementierung, es definiert wie man Nachrichten versenden und empfangen kann. Der Inhalt und Zweck interessiert dbus überhaupt nicht.
Anderes gesagt: die von dir genannten Systeme sind zwar für viele Dienste grundlegende Technologien, aber mit diesen alleine kannst du so gut wie gar nichts machten. Mit 4 Rädern und einem Lenkrad hast du auch noch kein Auto.
udev ist ein Low-Level System welche das Hotplugging übernimmt, es macht nicht viel mehr als die benötigten Devices anzulegen, Rechte zusetzten, und bei bedarf ein anderes Tool anzustoßen.
Ganz genau, also können wir festhalten: Das Einbinden der Geräte wird von Low-Level-Systemen übernommen und der Desktop wird dafür nicht benötigt. Also hier haben wir schon mal keine tiefe Integration des Desktops in das Basissystem.
dbus ist eine IPC Implementierung, es definiert wie man Nachrichten versenden und empfangen kann. Der Inhalt und Zweck interessiert dbus überhaupt nicht.
Auch richtig. Der Desktop erhält über D-Bus Nachriten, dass bestimmte Systeme jetzt verfügbar sind und kann darauf reagieren und mit diesen kommunizieren.
Von deiner ach so tiefen Integration des Linux-Desktops bleibt also unterm Strich nichts mehr übrig. Linux Desktops sind einfach nur aufgesetzte Systeme, die auf Nachrichten des Basissystems reagieren. Dementsprechend leicht ist es auch eine Desktopumgebung unter Linux auszutauschen.
Das Einbinden der Geräte wird von Low-Level-Systemen übernommen und der Desktop wird dafür nicht benötigt.
Genau man muss aber auch festhalten dass ein vom Kernel geladenes Modul noch nicht bedeutet dass es Gerät konfiguriert und Funktionsfähig ist.
Der Desktop erhält über D-Bus Nachriten, dass bestimmte Systeme jetzt verfügbar sind und kann darauf reagieren und mit diesen kommunizieren.
Korrekt.
Von deiner ach so tiefen Integration des Linux-Desktops bleibt also unterm Strich nichts mehr übrig.
Falsch.
Wir sind seit dem letzten Post keinen Millimeter weiter gekommen. Wir haben erst ein Kernel Modul geladen welches ein Low-Level-Device zur Verfügung, und ein IPC System welches erlaubt von einem Prozess Nachrichten an einen anderen Prozess zu senden.
Bleiben wir beim Beispiel VPN über eine Wlan Verbindung, diese kannst du in Gnome problemlos mit 2 Klicks aktivieren. Was hat uns dbus und udev bis jetzt gebracht? Nicht viel! Wir haben ein Netzwerk Device welches nicht konfiguriert ist, welches nicht am Router angemeldet ist. Sind wir nicht mehr in Reichweite des Routers bekommen wir davon gar nichts mit, und mit VPN hat das alles gar nichts zu tun. Nun wie funktioniert das nun unter Gnome? Einfache Antwort: da gibt es noch jede Menge Code dazwischen. Das bequeme herumklicken ermöglicht dir NetworkManager. Dieser wird von udev angestoßen, dieser kommuniziert mit Low-Level-Devices und generiert dbus-Events auf welche das UI reagieren kann. Von wo kommt der NetworkManager? Überraschung! Er wurde im Rahmen des Gnome-Desktop Projekts entwickelt. Das UI muss natürlich auch verstehen welchen Nachrichten NetworkManager versendet, und wissen welche Nachrichten Networkmanger versteht. Damit hat das UI trotz der Nutzung von dbus eine direkte Abhänigigkeit zu Network-Manager, zwischen einzelnen Versionen kann sich die Bedeutung der Nachrichten ändern, es können welche wegfallen und es können neue hinzukommen.
Jetzt haben wir nur eine Komponente betrachtet, ähnliches gibt es für alle anderen Subsysteme: Sound, Bluetooth, Power-Management, ...
Wie du siehst ein recht komplexes System mit jeder Menge an Abhängigkeiten. Jedes mal wenn du einen neue Version des Desktop Systems veröffentlichtst musst du sicher stellen dass es in dem ganzen Stack keine Inkompatibilitäten gibt, und immensen Test-Aufwand betreiben.
Ganz im Gegenteil zu simplen, autonomen Anwendungen wie Firefox oder Libreoffice. Wobei du verhältnismäßig wenigen Abhängigkeiten auch problemlos statisch linken kannst.
Damit sollte Klar sein: ein moderner Desktop ist tief ins System integriert!
Damit sollte Klar sein: ein moderner Desktop ist tief ins System integriert!
Was du hier als tiefe Integration verkaufen willst ist ein ganz simple DBUS-API. Das hat mit einer tiefen Integration nicht wirklich was zu tun.
Sobald dem NetworkManager einmal die Konfiguration übergeben wurde, macht er den Rest von alleine. Eine GUI, die Konfigurationsparameter erfasst und diese nach unten durchgibt ist die absolut einfachste Form eines UI. Egal wie du es drehst und wendest, das ist keine tiefe Integration. Das ist die simpelste Form einer Kommunikation zwischen zwei Subsystemen.
udev ist ein Low-Level System welche das Hotplugging übernimmt, es macht nicht viel mehr als die benötigten Devices anzulegen, Rechte zusetzten, und bei bedarf ein anderes Tool anzustoßen.
dbus ist eine IPC Implementierung, es definiert wie man Nachrichten versenden und empfangen kann. Der Inhalt und Zweck interessiert dbus überhaupt nicht.
Anderes gesagt: die von dir genannten Systeme sind zwar für viele Dienste grundlegende Technologien, aber mit diesen alleine kannst du so gut wie gar nichts machten. Mit 4 Rädern und einem Lenkrad hast du auch noch kein Auto.
Ganz genau, also können wir festhalten: Das Einbinden der Geräte wird von Low-Level-Systemen übernommen und der Desktop wird dafür nicht benötigt. Also hier haben wir schon mal keine tiefe Integration des Desktops in das Basissystem.
Auch richtig. Der Desktop erhält über D-Bus Nachriten, dass bestimmte Systeme jetzt verfügbar sind und kann darauf reagieren und mit diesen kommunizieren.
Von deiner ach so tiefen Integration des Linux-Desktops bleibt also unterm Strich nichts mehr übrig. Linux Desktops sind einfach nur aufgesetzte Systeme, die auf Nachrichten des Basissystems reagieren. Dementsprechend leicht ist es auch eine Desktopumgebung unter Linux auszutauschen.
Genau man muss aber auch festhalten dass ein vom Kernel geladenes Modul noch nicht bedeutet dass es Gerät konfiguriert und Funktionsfähig ist.
Korrekt.
Falsch.
Wir sind seit dem letzten Post keinen Millimeter weiter gekommen. Wir haben erst ein Kernel Modul geladen welches ein Low-Level-Device zur Verfügung, und ein IPC System welches erlaubt von einem Prozess Nachrichten an einen anderen Prozess zu senden.
Bleiben wir beim Beispiel VPN über eine Wlan Verbindung, diese kannst du in Gnome problemlos mit 2 Klicks aktivieren.
Was hat uns dbus und udev bis jetzt gebracht? Nicht viel!
Wir haben ein Netzwerk Device welches nicht konfiguriert ist, welches nicht am Router angemeldet ist. Sind wir nicht mehr in Reichweite des Routers bekommen wir davon gar nichts mit, und mit VPN hat das alles gar nichts zu tun.
Nun wie funktioniert das nun unter Gnome?
Einfache Antwort: da gibt es noch jede Menge Code dazwischen. Das bequeme herumklicken ermöglicht dir NetworkManager. Dieser wird von udev angestoßen, dieser kommuniziert mit Low-Level-Devices und generiert dbus-Events auf welche das UI reagieren kann.
Von wo kommt der NetworkManager? Überraschung! Er wurde im Rahmen des Gnome-Desktop Projekts entwickelt.
Das UI muss natürlich auch verstehen welchen Nachrichten NetworkManager versendet, und wissen welche Nachrichten Networkmanger versteht. Damit hat das UI trotz der Nutzung von dbus eine direkte Abhänigigkeit zu Network-Manager, zwischen einzelnen Versionen kann sich die Bedeutung der Nachrichten ändern, es können welche wegfallen und es können neue hinzukommen.
Jetzt haben wir nur eine Komponente betrachtet, ähnliches gibt es für alle anderen Subsysteme: Sound, Bluetooth, Power-Management, ...
Wie du siehst ein recht komplexes System mit jeder Menge an Abhängigkeiten. Jedes mal wenn du einen neue Version des Desktop Systems veröffentlichtst musst du sicher stellen dass es in dem ganzen Stack keine Inkompatibilitäten gibt, und immensen Test-Aufwand betreiben.
Ganz im Gegenteil zu simplen, autonomen Anwendungen wie Firefox oder Libreoffice. Wobei du verhältnismäßig wenigen Abhängigkeiten auch problemlos statisch linken kannst.
Damit sollte Klar sein: ein moderner Desktop ist tief ins System integriert!
Was du hier als tiefe Integration verkaufen willst ist ein ganz simple DBUS-API. Das hat mit einer tiefen Integration nicht wirklich was zu tun.
Sobald dem NetworkManager einmal die Konfiguration übergeben wurde, macht er den Rest von alleine. Eine GUI, die Konfigurationsparameter erfasst und diese nach unten durchgibt ist die absolut einfachste Form eines UI. Egal wie du es drehst und wendest, das ist keine tiefe Integration. Das ist die simpelste Form einer Kommunikation zwischen zwei Subsystemen.