Creshal schriebDBus hat außerdem yet another Socketaktivierung (nein, systemd und inetd waren noch nicht genug), sodass DBus-Dienste automatisch gestartet (und beendet) werden können, und nicht als Daemons im Hintergrund laufen müssen.
Interessant. Gibt's da denn auch den Vorteil der Sockets, im laufenden Betrieb Komponenten zu wechseln, die man eigentlich nicht im laufenden Betrieb wechseln kann, oder ist das systemd vorbehalten?
Apropos Socketaktivierung: Bringt es eigentlich einen (wenn auch vielleicht theoretischen) Sicherheitsgewinn, wenn der Prozess hinterm Socket sich beendet und damit nicht mehr im Speicher liegt? So von wegen weil er dann "nur über den vorgesehenen Weg angesprochen werden kann" oder so? Ich weiß zwar nicht, wie man einen Prozess sonst ansprechen können sollte, ob's da irgendwelche Kanäle gibt, aber die Idee kam mir mal.
Creshal schriebSprich: Es ist eine eierlegende Wollmilchsau, die alles unterstützt und von außen nur ein großer, intransparenter Blob ist. Du kannst wunderbar DBus-Anwendungen schreiben, ohne das System auch nur im Ansatz zu verstehen.
Prinzipiell eine Eigenschaft einer guten Bibliothek, dennoch werde ich das mal zum Anlass nehmen, mir DBus bei Gelegenheit genauer anzusehen, hätte ich eigentlich schon früher machen sollen.
Creshal schrieb
> Aber doch nur, für bekannte Geräte, oder kann man in der fstab mit Wildcards arbeiten?
Njet, nur mit bekannten Gerätenamen. Reicht meiner Erfahrung aber für 90% aller Anwendungsfälle …
Asche auf mein Haupt für den Typo. Damit ist der fstab-Weg natürlich für Laptops, an denen immer mal wieder Fremdsticks angesteckt werden, nur wenig brauchbar, ich hatte sowas befürchtet.