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.
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.