When would you use D-Bus vs a raw Unix socket?

D-Bus is a message bus system — a daemon (dbus-daemon) that routes messages between processes using a publish-subscribe and method-call model. Processes connect to the bus, register named services (e.g., org.freedesktop.NetworkManager), and expose objects with interfaces. Other processes can call methods, read properties, and subscribe to signals without knowing the service's PID or socket path. D-Bus provides introspection (you can query what interfaces a service exposes), access control policies, and automatic service activation (launching a service on demand when someone calls it).

Raw Unix domain sockets give you a direct point-to-point channel with no intermediary. You define your own wire protocol (framing, serialization, message types), manage connections yourself, and handle all routing logic. This is lower overhead — no bus daemon, no XML introspection, no policy engine — and gives you full control over the data format and transport behavior.

Use D-Bus when you have multiple processes that need to discover and communicate with each other dynamically, especially if you are integrating with existing Linux system services (systemd, NetworkManager, BlueZ) that already expose D-Bus APIs. D-Bus is the standard IPC for Linux system services. Use raw sockets when you have only two or three processes with well-defined communication patterns, when you need minimal latency and overhead (D-Bus adds serialization and routing overhead), or when your embedded system is too resource-constrained for the D-Bus daemon (it consumes a few megabytes of RAM). Many embedded Linux products use raw Unix sockets for their own application IPC while still using D-Bus to interact with system services like BlueZ for Bluetooth.