“D-Bus”的意思、由来-开放百科全书

is a software bus, is an inter-process communication (IPC) and remote procedure call (RPC) mechanism that allows communication between multiple computer programs (that is, processes) concurrently running on the same machine.{{r|intro dbus}}{{r|Cocagne 2012}} D-Bus was developed as part of the freedesktop.org project, initiated by Havoc Pennington from Red Hat to standardize services provided by Linux desktop environments such as GNOME and KDE.{{r|intro dbus q1}}{{r|Palmieri 2005}}{{dead link|date=November 2016}}

The freedesktop.org project also developed a free and open-source software library called libdbus, as a reference implementation of the specification. This library should not be confused with the D-Bus itself; indeed, other implementations of the D-Bus client library also exist, such as GDBus (GNOME),{{r|gdbus}} QtDBus (Qt/KDE),{{r|qtdbus}} dbus-java{{r|dbus-java}} and sd-bus (part of systemd).{{r|Poettering 2015}}

Overview

D-Bus is an IPC mechanism initially designed to replace the software component communications systems used by the GNOME and KDE Linux desktop environments (CORBA and DCOP respectively).{{r|dbus tut q1}}{{r|intro dbus q2}} The components of these desktop environments are normally distributed in many processes, each one providing only a few —usually one— services. These services may be used by regular client applications or by other components of the desktop environment to perform their tasks.{{multiple image

Due to the large number of processes involved —adding up processes providing the services and clients accessing them— establishing one-to-one IPC communications between all of them becomes an inefficient and quite unreliable{{Citation needed|reason=Comparative evaluation of reliability should be provided for this claim|date=October 2016}} approach. Instead, D-Bus provides a software-bus abstraction that gathers all the communications between a group of processes over a single shared virtual channel.{{r|Cocagne 2012}} Processes connected to a bus don't know how it is internally implemented, but D-Bus specification guarantees that all processes connected to the bus can communicate with each other through it.

Linux desktop environments take advantage of the D-Bus facilities by instantiating not one bus but many{{r|dbus spec}}{{r|Cocagne 2012}}{{r|dbus tut}}:

A process can connect to any number of buses, provided that it has been granted access to them. In practice, this means that any user process can connect to the system bus and to its current session bus, but not to another user's session buses, or even to a different session bus owned by the same user. The latter restriction may change in the future if all user sessions are combined into a single user bus.{{r|Poettering 2015 q1}}

D-Bus provides additional or simplifies existing functionality to the applications, including information-sharing, modularity and privilege separation. For example, information on an incoming voice-call received through Bluetooth or Skype can be propagated and interpreted by any currently-running music player, which can react by muting the volume or by pausing playback until the call is finished.{{r|Love 2005}}

D-Bus can also be used as a framework to integrate different components of a user application. For instance, an office suite can communicate through the session bus to share data between a word processor and a spreadsheet.

D-Bus specification

Bus model

Every connection to a bus is identified in the context of D-Bus by what is called a bus name.{{r|intro dbus}} A bus name consists of two or more dot-separated strings of letters, digits, dashes, and underscores. An example of a valid bus name is {{code|org.freedesktop.NetworkManager}}.{{r|Cocagne 2012}}

When a process sets up a connection to a bus, the bus assigns to the connection a special bus name called unique connection name.{{r|dbus tut}}{{r|Cocagne 2012}} Bus names of this type are immutable—it's guaranteed they won't change as long as the connection exists—and, more importantly, they can't be reused during the bus lifetime.{{r|intro dbus}}{{r|dbus tut}}{{r|Cocagne 2012}} This means that no other connection to that bus will ever have assigned such unique connection name, even if the same process closes down the connection to the bus and creates a new one. Unique connection names are easily recognizable because they start with the—otherwise forbidden—colon character.{{r|dbus tut}}{{r|Cocagne 2012}} An example of a unique connection name is {{code|:1.1553}} (the characters after the colon have no particular meaning{{r|dbus tut}}).

A process can ask for additional bus names for its connection,{{r|dbus tut}} provided that any requested name is not already being used by another connection to the bus. In D-Bus parlance, when a bus name is assigned to a connection, it is said the connection owns the bus name.{{r|intro dbus}}{{r|dbus tut}} In that sense, a bus name can't be owned by two connections at the same time, but, unlike unique connection names, these names can be reused if they are available: a process may reclaim a bus name released —purposely or not— by another process.{{r|intro dbus}}{{r|Cocagne 2012}}

The idea behind these additional bus names, commonly called well-known names, is to provide a way to refer to a service using a prearranged bus name.{{r|dbus tut}}{{r|Cocagne 2012}} For instance, the service that reports the current time and date in the system bus lies in the process whose connection owns the {{mono|org.freedesktop.timedate1}} bus name, regardless of which process it is.

Bus names can be used as a simple way to implement single instance applications (second instances detect that the bus name is already taken).{{r|dbus tut}} It can also be used to track a service process lifecycle, since the bus sends a notification when a bus name is released due to a process termination.{{r|dbus tut}}

Object model

Because of its original conception as a replacement for several component oriented communications systems, D-Bus shares with its predecessors an object model in which to express the semantics of the communications between clients and services. The terms used in the D-Bus object model mimic those used by some object oriented programming languages. That doesn't mean that D-Bus is somehow limited to OOP languages —in fact, the most used implementation ({{mono|libdbus}}) is written in C, a procedural programming language.

In D-Bus, a process offers its services exposing objects. These objects have methods that can be invoked, and signals that the object can emit.{{r|dbus tut}} Methods and signals are collectively referred as the members of the object.{{r|intro dbus}} Any client connected to the bus can interact with an object by using its methods, making requests or commanding the object to perform actions.{{r|dbus tut}} For instance, an object representing a time service can be queried by a client using a method that returns the current date and time. A client can also listen to signals that an object emits when its state changes due to certain events, usually related to the underlying service. An example would be when a service that manages hardware devices —such as USB or network drives— signals a "new hardware device added" event. Clients should instruct the bus that they are interested in receiving certain signals from a particular object, since a D-Bus bus only passes signals to those processes with a registered interest in them.{{r|Cocagne 2012}}

A process connected to a D-Bus bus can request it to export as many D-Bus objects as it wants. Each object is identified by an object path, a string of numbers, letters and underscores separated and prefixed by the slash character, called that because of their resemblance to Unix filesystem paths.{{r|intro dbus}}{{r|dbus tut}} The object path is selected by the requesting process, and must be unique in the context of that bus connection. An example of a valid object path is {{code|/org/kde/kspread/sheets/3/cells/4/5}}.{{r|dbus tut}} However, it's not enforced —but also not discouraged— to form hierarchies within object paths.{{r|Cocagne 2012}} The particular naming convention for the objects of a service is entirely up to the developers of such service, but many developers choose to namespace them using the reserved domain name of the project as a prefix (e.g. {{mono|/org/kde}}).{{r|dbus tut}}

Every object is inextricably associated to the particular bus connection where it was exported, and, from the D-Bus point of view, only lives in the context of such connection. Therefore, in order to be able to use a certain service, a client must indicate not only the object path providing the desired service, but also the bus name under which the service process is connected to the bus.{{r|intro dbus}} This in turn allows that several processes connected to the bus can export different objects with identical object paths unambiguously.

Members —methods and signals— that can be used with an object are specified by an interface.{{r|dbus tut}} An interface is a set of declarations of methods (including its passing and returning parameters) and signals (including its parameters) identified by a dot-separated name resembling the Java language interfaces notation.{{r|dbus tut}}{{r|Cocagne 2012}} An example of a valid interface name is {{code|org.freedesktop.Introspectable}}.{{r|Cocagne 2012}} Despite their similarity, interface names and bus names should not be mistaken. A D-Bus object can implement several interfaces, but at least must implement one, providing support for every method and signal defined by it. The combination of all interfaces implemented by an object is called the object type.{{r|intro dbus}}{{r|dbus tut}}

When using an object, it's a good practice for the client process to provide the member's interface name besides the member's name, but is only mandatory when there is an ambiguity caused by duplicated member names available from different interfaces implemented by the object{{r|intro dbus}}{{r|dbus tut}} —otherwise, the selected member is undefined or erroneous. An emitted signal, on the other hand, must always indicate to which interface it belongs.

The D-Bus specification also defines several standard interfaces that objects may want to implement in addition to its own interfaces.{{r|dbus spec}} Although technically optional, most D-Bus service developers choose to support them in their exported objects since they offer important additional features to D-Bus clients, such as introspection.{{r|Cocagne 2012}} These standard interfaces are:{{r|dbus spec}}{{r|Cocagne 2012}}

The D-Bus specification defines a number of administrative bus operations (called "bus services") to be performed using the {{mono|/org/freedesktop/DBus}} object that resides in the {{mono|org.freedesktop.DBus}} bus name.{{r|dbus spec}} Each bus reserves this special bus name for itself, and manages any requests made specifically to this combination of bus name and object path. The administrative operations provided by the bus are those defined by the object's interface {{mono|org.freedesktop.DBus}}. These operations are used for example to provide information about the status of the bus,{{r|intro dbus}} or to manage the request and release of additional well-known bus names.{{r|dbus spec}}{{r|Cocagne 2012}}

Communications model

D-Bus was conceived as a generic, high-level inter-process communication system. To accomplish such goals, D-Bus communications are based on the exchange of messages between processes instead of "raw bytes".{{r|intro dbus}}{{r|dbus tut}} D-Bus messages are high-level discrete items that a process can send through the bus to another connected process. Messages have a well-defined structure (even the types of the data carried in their payload are defined), allowing the bus to validate them and to reject any ill-formed message.

In this regard, D-Bus is closer to an RPC mechanism than to a classic IPC mechanism, with its own type definition system and its own marshaling.{{r|intro dbus}}

The bus supports two modes of interchanging messages between a client and a service process{{r|intro dbus}}:

Every D-Bus message consists of a header and a body.{{r|dbus tut}} The header is formed by several fields that identify the type of message, the sender, as well as information required to deliver the message to its recipient (destination bus name, object path, method or signal name, interface name, etc.).{{r|dbus tut}}{{r|dbus spec}} The body contains the data payload that the receiver process interprets —for instance the input or output arguments. All the data is encoded in a well known binary format called the wire format which supports the serialization of various types, such as integers and floating-point numbers, strings, compound types, and so on,{{r|dbus spec}} also referred to as marshaling.

The D-Bus specification defines the wire protocol: how to build the D-Bus messages to be exchanged between processes within a D-Bus connection. However, it does not define the underlying transport method for delivering these messages.

Internals

Most existing D-Bus implementations follow the architecture of the reference implementation. This architecture consists of two main components:{{r|intro dbus}}

The {{mono|libdbus}} library (or its equivalent) internally uses a native lower-level IPC mechanism to transport the required D-Bus messages between the two processes in both ends of the D-Bus connection. D-Bus specification doesn't mandate which particular IPC transport mechanisms should be available to use, as it's the communications library that decides what transport methods it supports. For instance, in Linux and Unix-like operating systems {{mono|libdbus}} typically uses Unix domain sockets as the underlying transport method, but it also supports TCP sockets.{{r|intro dbus}}{{r|dbus tut}}

The communications libraries of both processes must agree on the selected transport method and also on the particular channel used for their communication. This information is defined by what D-Bus calls an address.{{r|Cocagne 2012}}{{r|dbus tut}} Unix-domain socket are filesystem objects, and therefore they can be identified by a filename, so a valid address would be unix:path=/tmp/.hiddensocket.{{r|intro dbus}}{{r|dbus spec}} Both processes must pass the same address to their respective communications libraries to establish the D-Bus connection between them. An address can also provide additional data to the communications library in the form of comma-separated key=value pairs.{{r|Cocagne 2012}}{{r|dbus spec}} This way, for example, it can provide authentication information to a specific type of connection that supports it.

When a message bus daemon like {{mono|dbus-daemon}} is used to implement a D-Bus bus, all processes that want to connect to the bus must know the bus address, the address by which a process can establish a D-Bus connection to the central message bus process.{{r|intro dbus}}{{r|dbus tut}} In this scenario, the message bus daemon selects the bus address and the remainder processes must pass that value to their corresponding {{mono|libdbus}} or equivalent libraries. {{mono|dbus-daemon}} defines a different bus address for every bus instance it provides. These addresses are defined in the daemon's configuration files.

Two processes can use a D-Bus connection to exchange messages directly between them{{r|what is dbus q2}}, but this is not the way in which D-Bus is normally intended to be used. The usual way is to always use a message bus daemon (i.e. {{mono|dbus-daemon}}) as a communications central point to which each process should establish its point-to-point D-Bus connection. When a process —client or service— sends a D-Bus message, the message bus process receives it in the first instance and delivers it to the appropriate recipient. The message bus daemon may be seen as a hub or router in charge of getting each message to its destination by repeating it through the D-Bus connection to the recipient process.{{r|dbus tut}} The recipient process is determined by the destination bus name in the message's header field,{{r|dbus spec}} or by the subscription information to signals maintained by the message bus daemon in the case of signal propagation messages.{{r|Cocagne 2012}} The message bus daemon can also produce its own messages as a response to certain conditions, such as an error message to a process that sent a message to a nonexistent bus name.{{r|dbus tut}}

History and adoption

D-Bus was started in 2002 by Havoc Pennington, Alex Larsson (Red Hat) and Anders Carlsson.{{r|Palmieri 2005}} The version 1.0 —considered API stable— was released in November 2006.{{r|dbus 1.0}}{{r|Molkentin 2006}}

Heavily influenced by the DCOP system used by versions 2 and 3 of KDE, D-Bus has replaced DCOP in the KDE 4 release.{{r|Molkentin 2006}}{{r|KDE dbus intro}} An implementation of D-Bus supports most POSIX operating systems, and a port for Windows exists. It is used by Qt 4 and GNOME. In GNOME it has gradually replaced most parts of the earlier Bonobo mechanism. It is also used by Xfce.

One of the earlier adopters was the (nowadays deprecated) Hardware Abstraction Layer. HAL used D-Bus to export information about hardware that has been added to or removed from the computer.{{r|Palmieri 2005}}

The usage of D-Bus is steadily expanding beyond the initial scope of desktop environments to cover an increasing amount of system services. For instance, NetworkManager network daemon, BlueZ bluetooth stack and Pulseaudio sound server use D-Bus to provide part or all of its services, and systemd is promoting traditional system daemons to D-Bus services, such as logind.{{r|Poettering 2015 q2}} Another heavy user of D-Bus is Polkit, whose policy authority daemon is implemented as a service connected to the system bus.{{r|polkit doc}}

It is also used as the Wire protocol for the AllJoyn protocol for home automation, to this end AllJoyn adds discovery, session management, security, header compression, embedded device support and makes it transport agnostic.^[5]

Implementations

{{Anchor|LIBDBUS}} libdbus

Although there are several implementations of D-Bus, the most widely used is the reference implementation libdbus, developed by the same freedesktop.org project that designed the specification. However, libdbus is a low-level implementation that was never meant to be used directly by application developers, but as a reference guide for other reimplementations of D-Bus (such as those included in standard libraries of desktop environments, or in programming language bindings). The freedesktop.org project itself recommends applications authors to "use one of the higher level bindings or implementations" instead.{{r|what is dbus q3}} The predominance of libdbus as the most used D-Bus implementation caused the terms "D-Bus" and "libdbus" to be often used interchangeably, leading to confusion.

GDBus

GDBus{{r|gdbus}} is an implementation of D-Bus based on GIO streams included in GLib, aiming to be used by GTK+ and GNOME. GDBus is not a wrapper of libdbus, but a complete and independent reimplementation of the D-Bus specification and protocol.{{r|gdbus2}} MATE Desktop, which is also based on GTK+ 3, also uses GDBus.^[6]

QtDBus

QtDBus{{r|qtdbus}} is an implementation of D-Bus included in the Qt library since its version 4.2. This component is used by KDE applications, libraries and components to access the D-Bus services available in a system.

sd-bus

In 2013, the systemd project rewrote libdbus in an effort to simplify the code,{{r|Poettering 2013}} but it also resulted in a significant increase of the overall D-Bus performance. In preliminary benchmarks, BMW found that the systemd's D-Bus library increased performance by 360%.{{r|Edge 2013}} By version 221 of systemd, the sd-bus API was declared stable.{{r|systemd 221}}

libnih-dbus

The libnih project provides a light-weight "standard library" of C support for D-Bus. Additionally, it has good support for cross compiling.

{{Anchor|KDBUS}} kdbus

Language bindings

Several programming language bindings for D-Bus have been developed,{{r|dbus bindings}} such as those for Java, C# and Ruby.

See also

References

1. ^{{cite web |url= https://cgit.freedesktop.org/dbus/dbus/tree/NEWS?h=dbus-1.12|title= D-Bus 1.12.x changelog|accessdate=5 August 2018}}
2. ^{{cite web|url=https://cgit.freedesktop.org/dbus/dbus/tree/NEWS?h=master|title=NEWS file for current branch|accessdate=14 November 2018}}
3. ^Havoc's Blog July, 2007
4. ^{{cite book| last1 = Ward| first1 = Brian| author-link1 = | url = https://books.google.com/books?id=fP5WBQAAQBAJ| orig-year = 2004| chapter = 14: A brief survey of the Linux desktop| title = How Linux Works: What Every Superuser Should Know| edition = 2| location = San Francisco| publisher = No Starch Press| publication-date = 2014| page = 305| isbn = 9781593275679| access-date = 2016-11-07| quote = One of the most important developments to come out of the Linux desktop is the Desktop Bus (D-Bus), a message-passing system. D-Bus is important because it serves as an interprocess communication mechanism that allows desktop applications to talk to each other [...].}}
5. ^{{cite web|url=https://allseenalliance.org/developer-resources/forum/developers/difference-d-bus |title=Archived copy |accessdate=2015-06-16 |deadurl=yes |archiveurl=https://web.archive.org/web/20150721005141/https://allseenalliance.org/developer-resources/forum/developers/difference-d-bus |archivedate=2015-07-21 |df= }}
6. ^{{cite web|title=MATE: Roadmap|url=http://wiki.mate-desktop.org/roadmap|accessdate=31 January 2019}}
7. ^{{cite web |url=https://lwn.net/Articles/580194/ |title=The unveiling of kdbus |date=2014-01-13 |publisher=LWN.net}}
8. ^{{cite web |url=https://lwn.net/Articles/619069/ |title=Documentation/kdbus.txt (from the initial patch set) |date=2014-11-04 |publisher=LWN.net}}
9. ^{{cite web |url=https://www.youtube.com/watch?v=s2I_7uCto5Q&t=20m34s |title=Keynote: A Fireside Chat with Greg Kroah-Hartman, Linux Foundation Fellow |date=18 October 2016 |publisher=YouTube}}
10. ^{{cite web|last1=Vermeulen|first1=Jeroen|title=Introduction to D-Bus|url=http://www.freedesktop.org/wiki/IntroductionToDBus/|website=FreeDesktop.org|date=14 Jul 2013|accessdate=3 October 2015|quote="D-Bus [...] is designed for use as a unified middleware layer underneath the main free desktop environments."}}
11. ^{{cite web|last1=Vermeulen|first1=Jeroen|title=Introduction to D-Bus|url=http://www.freedesktop.org/wiki/IntroductionToDBus/|website=FreeDesktop.org|date=14 Jul 2013|accessdate=3 October 2015|quote=" D-Bus was first built to replace the CORBA-like component model underlying the GNOME desktop environment. Similar to DCOP (which is used by KDE), D-Bus is set to become a standard component of the major free desktop environments for GNU/Linux and other platforms."}}
12. ^{{cite web|last1=Pennington|first1=Havoc|last2=Carlsson|first2=Anders|last3=Larsson|first3=Alexander|last4=Herzberg|first4=Sven|last5=McVittie|first5=Simon|last6=Zeuthen|first6=David|title=D-Bus Specification|url=http://dbus.freedesktop.org/doc/dbus-specification.html|website=Freedesktop.org|accessdate=22 October 2015}}
13. ^{{cite web|last1=Pennington|first1=Havoc|last2=Wheeler|first2=David|last3=Walters|first3=Colin|title=D-Bus Tutorial|url=http://dbus.freedesktop.org/doc/dbus-tutorial.html|accessdate=21 October 2015}}
14. ^{{cite web|last1=Pennington|first1=Havoc|last2=Wheeler|first2=David|last3=Walters|first3=Colin|title=D-Bus Tutorial|url=http://dbus.freedesktop.org/doc/dbus-tutorial.html|accessdate=21 October 2015|quote="For the within-desktop-session use case, the GNOME and KDE desktops have significant previous experience with different IPC solutions such as CORBA and DCOP. D-Bus is built on that experience and carefully tailored to meet the needs of these desktop projects in particular."}}
15. ^{{cite web|title=What is D-Bus?|url=http://www.freedesktop.org/wiki/Software/dbus/|website=FreeDesktop.org|accessdate=29 October 2015|quote="There are also some reimplementations of the D-Bus protocol for languages such as C#, Java, and Ruby. These do not use the libdbus reference implementation"}}
16. ^{{cite web|title=What is D-Bus?|url=http://www.freedesktop.org/wiki/Software/dbus/|website=FreeDesktop.org|accessdate=29 October 2015|quote="is built on top of a general one-to-one message passing framework, which can be used by any two apps to communicate directly (without going through the message bus daemon)"}}
17. ^{{cite web|title=What is D-Bus?|url=http://www.freedesktop.org/wiki/Software/dbus/#index1h1|website=FreeDesktop.org|accessdate=5 January 2015|quote="It should be noted that the low-level implementation is not primarily designed for application authors to use. Rather, it is a basis for binding authors and a reference for reimplementations. If you are able to do so it is recommended that you use one of the higher level bindings or implementations."}}
18. ^{{cite web|last1=Seigo|first1=Aaron|title=Introduction To D-BUS|url=https://techbase.kde.org/Development/Tutorials/D-Bus/Introduction|website=KDE TechBase|accessdate=3 November 2015}}
19. ^{{cite web|title=D-Bus Bindings|url=http://www.freedesktop.org/wiki/Software/DBusBindings/|website=FreeDesktop.org|accessdate=5 January 2015}}
20. ^{{cite web|title=D-BUS System Activation|url=https://dbus.freedesktop.org/doc/system-activation.txt|website=FreeDesktop.org|accessdate=18 February 2016}}
21. ^{{cite web|last1=Cocagne|first1=Tom|title=DBus Overview|url=https://pythonhosted.org/txdbus/dbus_overview.html|date=August 2012|website=pythonhosted.org|accessdate=22 October 2015}}
22. ^{{cite web|last1=Corbet|first1=Jonathan|title=The unveiling of kdbus|url=https://lwn.net/Articles/580194/|date=13 January 2014|publisher=LWN.net|accessdate=11 April 2014}}
23. ^{{cite web|last1=Corbet|first1=Jonathan|title=The kdbuswreck|url=https://lwn.net/Articles/641275/|date=22 April 2015|publisher=LWN.net|accessdate=29 June 2015}}
24. ^{{cite web|last1=Edge|first1=Jake|title=ALS: Linux inter-process communication and kdbus|url=https://lwn.net/Articles/551969/|date=30 May 2013|publisher=LWN.net|accessdate=21 October 2015}}
25. ^{{cite mailing list|mailing-list=linux-kernel|title=[GIT PULL] kdbus for 4.1-rc1|first=Greg|last=Kroah-Hartman|authorlink=Greg Kroah-Hartman|date=13 Apr 2015|url=http://lkml.iu.edu/hypermail/linux/kernel/1504.1/03936.html}}
26. ^{{cite web|last1=Love|first1=Robert|title=Get on the D-BUS|url=http://www.linuxjournal.com/article/7744|date=5 January 2005|publisher=Linux Journal|accessdate=14 October 2014}}
27. ^{{cite web|last1=Molkentin|first1=Daniel|title=D-Bus 1.0 "Blue Bird" Released|url=https://dot.kde.org/2006/11/12/d-bus-10-blue-bird-released|date=12 November 2006|website=KDE News|accessdate=3 November 2015}}
28. ^{{cite web|last1=Palmieri|first1=John|title=Get on D-BUS|url=https://www.redhat.com/magazine/003jan05/features/dbus/|date=January 2005|publisher=Red Hat Magazine|accessdate=3 November 2015|deadurl=yes|archiveurl=https://web.archive.org/web/20151023072022/http://www.redhat.com/magazine/003jan05/features/dbus/|archivedate=23 October 2015|df=}}
29. ^{{cite mailing list|mailing-list=systemd-devel|title=[HEADSUP] libsystemd-bus + kdbus plans|first=Lennart|last=Poettering|authorlink=Lennart Poettering|date=20 Mar 2013|url=http://lists.freedesktop.org/archives/systemd-devel/2013-March/009797.html}}
30. ^{{cite web|last1=Poettering|first1=Lennart|title=The new sd-bus API of systemd|url=http://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html|date=19 June 2015|accessdate=21 October 2015}}
31. ^{{cite web|last1=Poettering|first1=Lennart|title=The new sd-bus API of systemd|url=http://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html|date=19 June 2015|accessdate=21 October 2015|quote="we are working on moving things to a true user bus, of which there is only one per user on a system, regardless how many times that user happens to log in"}}
32. ^{{cite web|last1=Poettering|first1=Lennart|title=The new sd-bus API of systemd|url=http://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html|date=19 June 2015|accessdate=21 October 2015|quote="Since systemd's inception it has been the IPC system it exposes its interfaces on."}}
33. ^{{cite web|title=gdbus|url=https://developer.gnome.org/gio/stable/gdbus.html|website=GNOME developer|accessdate=4 January 2015}}
34. ^{{cite web|title=Migrating to GDBus|url=https://developer.gnome.org/gio/stable/ch35.html|website=GNOME Developer|accessdate=21 October 2015|quote="dbus-glib uses the libdbus reference implementation, GDBus doesn't. Instead, it relies on GIO streams as transport layer, and has its own implementation for the D-Bus connection setup and authentication."}}
35. ^{{cite web|title=QtDBus module|url=http://doc.qt.io/qt-5/qtdbus-index.html|website=Qt Project|accessdate=1 June 2015}}
36. ^{{cite web|title=DBus-Java Documentation|url=http://dbus.freedesktop.org/doc/dbus-java/|website=FreeDesktop.org|accessdate=4 January 2015}}
37. ^{{cite web|title=Polkit reference manual|url=http://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html|website=FreeDesktop.org|accessdate=3 November 2015}}
38. ^{{cite mailing list|mailing-list=dbus|title=[announce] D-Bus 1.0.0 "Blue Bird" released|first=John|last=Palmieri|date=9 Nov 2006|url=http://lists.freedesktop.org/archives/dbus/2006-November/006337.html}}
39. ^{{cite mailing list|mailing-list=systemd-devel|title=[ANNOUNCE] systemd v221|first=Lennart|last=Poettering|authorlink=Lennart Poettering|date=19 Jun 2015|url=http://lists.freedesktop.org/archives/systemd-devel/2015-June/033170.html}}