# Sinn und Zweck von D-Bus?

## Carminox

Ich nutze schon fast ein Jahr Gentoo und damit Linux generell. Das OS hat mir wegen seiner Offenheit aber vor allem auch Schlankheit sehr zugesagt.

Von den großen WM-Frameworks wie Gnome oder KDE habe ich mich inzwischen abgewandt (nutze immo Fluxbox), weil die teilweise langsamer reagieren als die Windows-Oberfläche...  :Confused: 

Was mich vor allem stört - und was mir überhaupt nicht einleuchtet - ist diese D-Bus- und HAL-Geschichte.

Soweit ich herausfinden konnte hat HAL fast alle Fähigkeiten wie UDEV, mit dem Unterschied, dass es eingelegte, noch nicht gemountete CDs erkennt, was UDEV seltsamerweise garnicht protokolliert.

Also ist HAL genau genommen doch ein völliger Kas.

Für was D-Bus nun gut ist, konnte ich mich im Internet auch nicht ausreichend schlau machen. Ständig wird von Kommunikation zwischen Applikationen geredet, dabei haben die Programme ohne D-Bus auch ganz gut funktioniert und die Kommunikation lief eben über das IPC vom Kernel.

Mir macht Sorgen, dass Linux immer mehr Windows NT ähnlich wird, vorallem wegen der immer größer werdenden Anzahl von Daemons (wie in Windows mit seinen Diensten), die nicht wirklich gebraucht werden.

Kann mir jemand einen driftigen Grund nennen, was für Probleme mit D-Bus und HAL gelöst werden?

(Mir scheint so, als dadurch mehr Probleme verursacht als gelöst werden...)

Gruß|Carminox

----------

## nikaya

http://de.wikipedia.org/wiki/Dbus

----------

## firefly

Also hal und udev sind 2 paar stiefel, udev ist nur dafür das verwalten der device-nodes in /dev da und besitzt auch coldplug funktionalität. Sprich udev ist es wurscht ob im DVD-laufwerk sich eine Medium befindet oder net.

HAL dagegen bietet eine definierte Schnittstelle an, um auf verschiedene "Hardware" events(z.b. im CD/DVD-Laufwerk wurde ein medium eingelegt oder ein USB Massenspeicher wurde angeschlossen) zu reagieren.

Das hat den Vorteil, das die Anwendungen, die dann darauf reagieren, z.b. automatisch das CD/DVD-Laufwerk zu mounten, nicht selbst die abfragen auf vorhandensein der verschiedenen Geräte implementieren müssen.

Z.B. ein Automounter muss nur eins implementieren und zwar die dbus "nachrichten" von hal über mountable geräte. Ohne hal müsste der automounter selbst die ganzen abfragen implementieren um festzustellen, das sich was am CD/DVD-Laufwerk geändert hat oder das ein neues USB-Massenspeicher eingesteckt oder abgesteckt wurde.

Ist ja schön un gut, das bisherige anwendungen sich über ipc unterhalten können, aber diese schnittstellen sind leider nicht universell bzw. standartisiert (ipc selbst schon). Sprich eine Software, welche über ipc verschiedene Anwendungen steuern/abfragen möchte(z.b. zum Steuern des gerade laufenden Audioplayers) müsste für jeden audio-player, welche sich per ipc steuern läßt deren kompletten ipc funktionalität implementieren.

Wenn aber diese audio-player eine standartisierte dbus schnittstelle anbieten würden, müsste diese Software nur einmal diese Schnittstelle implementieren. Das hat den vorteil, das man dann diese Software leicht, sogar ohne neu übersetzen, an neue audio-player anpassen kann.

----------

## xces

 *Carminox wrote:*   

> Soweit ich herausfinden konnte hat HAL fast alle Fähigkeiten wie UDEV, mit dem Unterschied, dass es eingelegte, noch nicht gemountete CDs erkennt, was UDEV seltsamerweise garnicht protokolliert.

 

Nein. UDEV stellt die Geräte unter /dev zur Verfügung und erstellt sie bei Bedarf. Nicht mehr, nicht weniger. HAL (Hardware Abstraction Layer) erkennt, wenn z. B. ein neues USB-Gerät eingesteckt oder eine CD eingelegt wurde und gibt diese Nachricht an UDEV weiter.

Jetzt können die beiden nicht direkt miteinander kommunizieren, sondern benötigen eine Schnittstelle zur IPC (Inter process communication). Diese Lücke schließt DBUS.

 *Carminox wrote:*   

> Mir macht Sorgen, dass Linux immer mehr Windows NT ähnlich wird, vorallem wegen der immer größer werdenden Anzahl von Daemons (wie in Windows mit seinen Diensten), die nicht wirklich gebraucht werden.

 

Unter Linux hast du die Freiheit, das System nach deinen Wünschen einzurichten. Wenn du udev, dbus, hald nicht benutzen willst, kannst du immer noch auf ein statisches /dev wechseln, die Devices selbst anlegen und die einzelnen Wechseldatenträger immer von Hand mounten.

 *Carminox wrote:*   

> Kann mir jemand einen driftigen Grund nennen, was für Probleme mit D-Bus und HAL gelöst werden?

 

Netzwerktransparentes IPC und Hardware-Abstraktion...

----------

## firefly

 *xces wrote:*   

>  *Carminox wrote:*   Soweit ich herausfinden konnte hat HAL fast alle Fähigkeiten wie UDEV, mit dem Unterschied, dass es eingelegte, noch nicht gemountete CDs erkennt, was UDEV seltsamerweise garnicht protokolliert. 
> 
> Nein. UDEV stellt die Geräte unter /dev zur Verfügung und erstellt sie bei Bedarf. Nicht mehr, nicht weniger. HAL (Hardware Abstraction Layer) erkennt, wenn z. B. ein neues USB-Gerät eingesteckt oder eine CD eingelegt wurde und gibt diese Nachricht an UDEV weiter.
> 
> 

 

Falsch udev erkennt auch ohne hal ob ein neues USB-gerät angesteckt wurden, denn diese "Nachricht" kommt über das hotplug interface vom kernel  :Wink: 

Nur hal probagiert diese Nachricht über dbus an andere Anwendungen, die auf so ein event reagieren möchten.

----------

## Knieper

 *Carminox wrote:*   

> Kann mir jemand einen driftigen Grund nennen, was für Probleme mit D-Bus und HAL gelöst werden?

 

Es gibt keinen triftigen "Grund". Dein System funktioniert locker ohne. Es ist nur die uebliche: "Wir abstrahieren noch mehr und erschlagen alle Fliegen mit einer Klappe. Rechenleistung wird ja billiger."-Masche. Die Anfaenger wird's freuen, die Stoepselprogrammierer auch, aber ansonsten ist es unnuetzes Geraffel.

----------

## xraver

Unter KDE war ich von dcop begeistert. In KDE4 soll ja dbus verwendet werden. Ich hoffe es macht dann genauso viel Spass wie unter dcop.

Wenn solche Schnittstellen in dbus standarisiert werden, dann kanns doch nur gut sein. gnome und andere Anwendungen nutzen dbus ja auch schon.

----------

## Carminox

thx für die vielen Antworten.

Scheinbar gibt es zu diesem Thema auch keine einstimmige Meinung.  :Very Happy: 

 *firefly wrote:*   

> Falsch udev erkennt auch ohne hal ob ein neues USB-gerät angesteckt wurden, denn diese "Nachricht" kommt über das hotplug interface vom kernel 
> 
> Nur hal probagiert diese Nachricht über dbus an andere Anwendungen, die auf so ein event reagieren möchten.

 

Dem muss ich zustimmen, denn mit UDEV kann man nicht nur Geräteknoten erstellen, sondern auch je nach der ermittelten IDs oder anderer Gerätemerkmale auch mounten. Nur das mit den eingelegten Medien ist in UDEV scheinbar nicht implementiert.

Insofern erkenne ich den Sinn in HAL nur, wenn ein Programm die Gerätekonfiguration des Computers ermitteln will oder, wie oben erwähnt, auf etwas reagieren will, wie etwa K3B. Sowas grundlegendes wie Hardwareabstraktion müsste aber eigentlich im Kernel integriert sein.  :Confused: 

 *Knieper wrote:*   

>  *Carminox wrote:*   Kann mir jemand einen driftigen Grund nennen, was für Probleme mit D-Bus und HAL gelöst werden? 
> 
> Es gibt keinen triftigen "Grund". Dein System funktioniert locker ohne. Es ist nur die uebliche: "Wir abstrahieren noch mehr und erschlagen alle Fliegen mit einer Klappe. Rechenleistung wird ja billiger."-Masche. Die Anfaenger wird's freuen, die Stoepselprogrammierer auch, aber ansonsten ist es unnuetzes Geraffel.

 

Der Tropfen, der das Fass zum Überlaufen gebracht hatte war, als ich GIMP nicht mehr starten konnte, da D-Bus nicht lief. Dabei kann man im EBuild von GIMP DBUS nicht deaktivieren.

Ein normales Grafikprogramm, dass D-Bus braucht? Eigentlich schwachsinnig.

Letztendlich ist man wegen der Rechenleistung-wird-billiger-Masche genauso gut mit einem Atari bedient. Und der konnte sich bei so einer geringen Rechenleistung mit Windows 95 behaupten.

Gruß|Carminox

----------

## franzf

Das Argument "Rechenleistung wird billiger-Masche" kann ich hier irgendwie nicht so nachvollziehen, betreffend dbus + hal. Die laufen hier beide standardmäßig. CPU ist immer brav auf 0. Da wird mehr Rechenleitung verbraten, wenn ich ne DVD guck oder Musk hör oder mal ein Fensterchen verschieb, oder eben kompilier  :Wink: . Nur wenn man eine CD einlegt / Speicherstick anklemmt, dann geht die CPU-Auslastung kurz mal hoch (aber auch nicht wirklich schlimm).

So wie unter Windows, wo ich ungefragt zig daemons am laufen hab und mit jeder neu installierten Software ein Eintrag mehr im Autostart (wohlgemerkt OHNE MEINER ERLAUBNIS!) steht, ist es unter Linux (zumindest Gentoo) definitiv noch lange nicht.

Zu deinem Problem mit Gimp:

Dann nimm dbus und hal aus deinen USE-Flags. Auch wenn gimp selbst kein dbus-flag hat, irgend eine darunter liegende Lib wird sich schon finden.

Außerdem hab ich grad mal schnell dbus gestoppt: gimp tut ohne Probleme...

Grüße

Franz

----------

## Carminox

HAL und DBUS hab ich überhaupt nicht in meinen USE-Flags. Das lustige ist, dass sich GIMP genau genommen nicht über das nicht gestartete D-Bus beschwert, sondern über eine nicht existente Lock-Datei, die im var-Verzeichnis liegen sollte.

Es hat aber wirklich eine Tendenz zur Überladung von Daemons. Gnome und KDE packen ständig irgendwelche Daemons in das System, einige laufen sogar noch weiter, wenn der X-Server beendet ist...

----------

## Finswimmer

 *Carminox wrote:*   

> HAL und DBUS hab ich überhaupt nicht in meinen USE-Flags. Das lustige ist, dass sich GIMP genau genommen nicht über das nicht gestartete D-Bus beschwert, sondern über eine nicht existente Lock-Datei, die im var-Verzeichnis liegen sollte.
> 
> Es hat aber wirklich eine Tendenz zur Überladung von Daemons. Gnome und KDE packen ständig irgendwelche Daemons in das System, einige laufen sogar noch weiter, wenn der X-Server beendet ist...

 

Beispiele? Bei mir läuft nur das, was wirklich sinnvoll ist...

----------

## Carminox

Da ich KDE und Gnome nicht mehr benutze, kann ich nur etwas ungenaue Namen nennen, die nach Beendigung des X-Servers und damit auch des gesamten Frameworks verschwunden sein müssten, jedoch noch laufen, z.B. kio-http, kio-file, wobei beide manchmal in mehrfacher Ausfertigung meinen Arbeitsspeicher belasten. Bei Gnome käme dieser gconf-Dienst in Frage.

----------

## oscarwild

 *Carminox wrote:*   

> Nur das mit den eingelegten Medien ist in UDEV scheinbar nicht implementiert.

 

Die Medien sollen ja auch keine Device-Nodes erzeugen!

 *Carminox wrote:*   

> Sowas grundlegendes wie Hardwareabstraktion müsste aber eigentlich im Kernel integriert sein. 

 

Der Kernel beinhaltet Treiber, die natürlich auch die Hardware abstrahieren. Die Abstraktion, für die HAL zuständig ist, liegt allerdings eine Ebene höher, und hat ein ganz anders Ziel:

 *http://freedesktop.org/wiki/Software_2fHalFAQ wrote:*   

> HAL is simply just a piece of user-space software that maintains a list of device with well-defined properties for each device. In addition, HAL provides space for application defined properties per device.
> 
> HAL is *not* concerned with how to use the hardware, nor is HAL concerned with configuring the hardware. However, HAL can be used in applications that needs the hardware by providing the list of devices and space for storing configuration values. One example is configuration files for display servers. 

 

 *Carminox wrote:*   

> Letztendlich ist man wegen der Rechenleistung-wird-billiger-Masche genauso gut mit einem Atari bedient.

 

Ich wüsste nicht, was an einer sinnvollen Abstraktion und Aufgabenteilung auszusetzen ist, ebenso wenig wäre mir bekannt, dass udev/hal/dbus in irgend einer spürbaren Form Rechenleistung verbraten würden.

Gruß

OscarWild

----------

