Sun . 19 May 2019

D-Bus

d-bus = 1.6 is required, d-bus interface
In computing, D-Bus or DBus for "Desktop Bus"3, 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 machine45 D-Bus was developed as part of the freedesktoporg project, initiated by Havoc Pennington from Red Hat to standardize services provided by Linux desktop environments such as GNOME and KDE67dead link

The freedesktoporg project also developed a free and open-source software library called libdbus, as a reference implementation of the specification This library is often confusedby whom with the D-Bus itself Other implementations of the D-Bus client library also exist, such as GDBus GNOME,8 QtDBus Qt/KDE,9 dbus-java10 and sd-bus part of systemd11

Contents

  • 1 Overview
  • 2 D-Bus Specification
    • 21 Bus model
    • 22 Object model
    • 23 Communications model
  • 3 Internals
  • 4 History and adoption
  • 5 Implementations
    • 51 libdbus
    • 52 GDBus
    • 53 QtDBus
    • 54 sd-bus
    • 55 kdbus
    • 56 Language bindings
  • 6 See also
  • 7 References
  • 8 External links

Overviewedit

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 respectively1213 The components of these desktop environments are normally distributed in many processes, each one providing only a few —usually one— service These services may be used by regular client applications or by other components of the desktop environment to perform their tasks

Processes without D-Bus The same processes with D-Bus Large groups of cooperating processes demand a dense mesh of individual communication channels using one-to-one IPC methods between them D-Bus simplifies the IPC requirements with one single shared channel

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 unreliablecitation needed approach Instead, D-Bus provides a software-bus abstraction that gathers all the communications between a group of processes over a single shared virtual channel5 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 instancing not one bus but many14515:

  • a single system bus, available to all users and processes of the system, that provides access to system services ie services provided by the operating system and also by any system daemons
  • a session bus for each user login session, that provides desktop services to user applications in the same desktop session, and allows the integration of the desktop session as a whole

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 users' 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 bus16

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 finished17

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 Specificationedit

Bus modeledit

Every connection to a bus is identified in the context of D-Bus by what is called a bus name4 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 orgfreedesktopNetworkManager5

When a process sets up a connection to a bus, the bus assigns to the connection a special bus name called unique connection name155 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 lifetime4155 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 character155 An example of a unique connection name is :11553 the characters after the colon have no particular meaning15

A process can ask for additional bus names for its connection,15 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 name415 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 process45

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 name155 For instance, the service that reports the current time and date in the system bus lies in the process whose connection owns the orgfreedesktoptimedate1 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 taken15 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 termination15

Object modeledit

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 libdbus is written in C, a procedural programming language

Browsing the existing bus names, objects, interfaces, methods and signals in a D-Bus bus using D-Feet

In D-Bus, a process offers its services exposing objects These objects have methods that can be invoked, and signals that the object can emit15 Methods and signals are collectively referred as the members of the object4 Any client connected to the bus can interact with an object by using its methods, making requests or commanding the object to perform actions15 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 them5

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 paths415 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 /org/kde/kspread/sheets/3/cells/4/515 However, it's not enforced —but also not discouraged— to form hierarchies within object paths5 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 eg /org/kde15

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 bus4 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 interface15 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 notation155 An example of a valid interface name is orgfreedesktopIntrospectable5 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 type415

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 object415 —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 interfaces14 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 introspection5 These standard interfaces are:145

  • orgfreedesktopDBusPeer: provides a way to test if a D-Bus connection is alive5
  • orgfreedesktopDBusIntrospectable: provides an introspection mechanism by which a client process can get in run-time a description in XML format of the interfaces, methods and signals that the object implements1514
  • orgfreedesktopDBusProperties: allows a D-Bus object to expose the underlying native object properties or attributes, or simulate them if it doesn't exist14
  • orgfreedesktopDBusObjectManager: when a D-Bus service arranges its objects hierarchically, this interface provides a way to query an object about all sub-objects under its path, as well as their interfaces and properties, using a single method call14

The D-Bus specification defines a number of administrative bus operations called "bus services" to be performed using the /org/freedesktop/DBus object that resides in the orgfreedesktopDBus bus name14 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 orgfreedesktopDBus These operations are used for example to provide information about the status of the bus,4 or to manage the request and release of additional well-known bus names145

Communications modeledit

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"415 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 marshaling4

Example of one-to-one request-response message exchange to invoke a method over D-Bus Here the client process invokes the SetFoo method of the /org/example/object1 object from the service process named orgexamplefoo or :114 in the bus

The bus supports two modes of interchanging messages between a client and a service process4:

  • One-to-one request-response: This is the way for a client to invoke an object's method The client sends a message to the service process exporting the object, and the service in turn replies with a message back to the client process15 The message sent by the client must contain the object path, the name of the invoked method and optionally the name of its interface, and the values of the input parameters if any as defined by the object's selected interface The reply message carries the result of the request, including the values of the output parameters returned by the object's method invocation, or exception information if there was an error415
  • Publish/subscribe: This is the way for an object to announce the occurrence of a signal to the interested parties The object's service process broadcasts a message that the bus passes only to the connected clients subscribed to the object's signal15 The message carries the object path, the name of the signal, the interface to which the signal belongs, and also the values of the signal's parameters if any The communication is one-way: there are no response messages to the original message from any client process, since the sender knows neither the identities nor the number of the recipients415

Every D-Bus message consists of a header and a body15 The header is formed by several fields that identifies 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, etc1514 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, 14 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

Internalsedit

Most existing D-Bus implementations follow the architecture of the reference implementation This architecture consists of two main components:4

  • a point-to-point communications library that implements the D-Bus wire protocol in order to exchange messages between two processes In the reference implementation this library is libdbus In other implementations libdbus may be wrapped by another higher-level library, language binding, or entirely replaced by a different standalone implementation that serves the same purpose18 This library only supports one-to-one communications between two processes15
  • A dbus-daemon process acting as a D-Bus message bus daemon Every process connected to the bus keeps one D-Bus connection with it a special daemon process that plays the bus role and to which the rest of the processes connect using any D-Bus point-to-point communications library This process is also known as the message bus daemon,17 since it is responsible for routing messages from any process connected to the bus to another In the reference implementation this role is performed by dbus-daemon, and so it is in all other implementations since no one has developed an alternative dbus-daemon itself is built on top of libdbus
Process A and B have a one-to-one D-Bus connection using libdbus over an Unix domain socket They can use it to exchange messages directly19 In this scenario bus names are not required15 Process A and B both connected to a dbus-daemon using libdbus over an Unix domain socket They can exchange messages sending them to the message bus process, which in turn will deliver the messages to the appropriate process In this scenario bus names are mandatory to identify the destination process

The 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 libdbus typically uses Unix domain sockets as the underlying transport method, but it also supports TCP sockets415

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 address515 Unix-domain socket are filesystem objects, and therefore they can be identified by a filename, so a valid address would be unix:path=/tmp/hiddensocket414 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 pairs514 This way, for example, it can provide authentication information to a specific type of connection that supports it

When a message bus daemon like 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 process415 In this scenario, the message bus daemon selects the bus address and the remainder processes must pass that value to their corresponding libdbus or equivalent libraries 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 them19, but this is not the way in which D-Bus is normally intended to use The usual way is to always use a message bus daemon ie 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 process15 The recipient process is determined by the destination bus name in the message's header field,14 or by the subscription information to signals maintained by the message bus daemon in the case of signal propagation messages5 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 name15

dbus-daemon improves the feature set already provided by D-Bus itself with additional functionality For example, service activation allows to automatically start services only when they are needed —when the first request to any bus name of such service arrives to the message bus daemon4 This way, service processes neither need to be launched during the system initialization or user initialization stage nor they consume memory or another resources if they are not actually used This feature was originally implemented using setuid helpers,20 but nowadays it can also be provided by systemd's service activation frameworkcitation needed Service activation is an important feature that facilitates the management of the process lifecycle of services for example when a desktop component should start or stop15

History and adoptionedit

D-Bus was started in 2002 by Havoc Pennington and Alex Larsson Red Hat and Anders Carlsson7 The version 10 —considered API stable— was released in November 20062122

The dbus-daemon plays a significant role in modern Linux graphical desktop environments Binder, also depicted above, is its counterpart used on Android

Heavily influenced by the DCOP system used by versions 2 and 3 of KDE, D-Bus has replaced DCOP in the KDE 4 release2223 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 computer7

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 logind24 Another heavy user of D-Bus is Polkit, whose policy authority daemon is implemented as a service connected to the system bus25

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 agnostic26

Implementationsedit

libdbusedit

Although there are several implementations of D-Bus, the most widely used is the reference implementation libdbus, developed by the same freedesktoporg 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 freedesktoporg project itself recommends applications authors to "use one of the higher level bindings or implementations" instead27 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

GDBusedit

GDBus8 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 protocol28

QtDBusedit

QtDBus9 is an implementation of D-Bus included in the Qt library since its version 42 This component is used by KDE applications, libraries and components to access the D-Bus services available in a system

sd-busedit

In 2013, the systemd project rewrote libdbus in an effort to simplify the code,29 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%30 As of version 221 of systemd, the sd-bus API has been declared stable31

kdbusedit

kdbus is implemented as a character device driver3233 All communication between processes take place over special character device nodes in /dev/kdbus cf devfs

kdbus was a project that aimed to reimplement D-Bus as a kernel-mediated peer-to-peer inter-process communication mechanism Beside performance improvements, kdbus would have advantages arising from other Linux kernel features such as namespaces and auditing,3034 security from the kernel mediating, closing race conditions, and allowing D-Bus to be used during boot and shutdown as needed by systemd35 kdbus inclusion in the Linux kernel was proved controversial,36 and was dropped in favor of BUS1, as a more generic inter-process communication37

Language bindingsedit

Several programming language bindings for D-Bus have been developed,38 such as those for Java, C# and Ruby

See alsoedit

  • Free software portal
  • Linux on the desktop
  • Common Language Infrastructure
  • Common Object Request Broker Architecture
  • Component Object Model
  • Distributed Component Object Model
  • Foreign function interface
  • Java remote method invocation
  • Remote procedure call
  • XPCOM

Referencesedit

  1. ^ "Announcing D-Bus 1100 new stable branch" 2015-08-25 Retrieved 2015-08-25 
  2. ^ Havoc's Blog July, 2007
  3. ^ Ward, Brian 2014 2004 "14: A brief survey of the Linux desktop" How Linux Works: What Every Superuser Should Know 2 ed San Francisco: No Starch Press p 305 ISBN 9781593275679 Retrieved 2016-11-07 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  
  4. ^ a b c d e f g h i j k l m n o p q r s t u Vermeulen, Jeroen 14 Jul 2013 "Introduction to D-Bus" FreeDesktoporg Retrieved 22 October 2015 
  5. ^ a b c d e f g h i j k l m n o p q r s t Cocagne, Tom August 2012 "DBus Overview" pythonhostedorg Retrieved 22 October 2015 
  6. ^ Vermeulen, Jeroen 14 Jul 2013 "Introduction to D-Bus" FreeDesktoporg Retrieved 3 October 2015 D-Bus is designed for use as a unified middleware layer underneath the main free desktop environments 
  7. ^ a b c Palmieri, John January 2005 "Get on D-BUS" Red Hat Magazine Retrieved 3 November 2015 
  8. ^ a b "gdbus" GNOME developer Retrieved 4 January 2015 
  9. ^ a b "QtDBus module" Qt Project Retrieved 1 June 2015 
  10. ^ "DBus-Java Documentation" FreeDesktoporg Retrieved 4 January 2015 
  11. ^ Poettering, Lennart 19 June 2015 "The new sd-bus API of systemd" Retrieved 21 October 2015 
  12. ^ Pennington, Havoc; Wheeler, David; Walters, Colin "D-Bus Tutorial" Retrieved 21 October 2015 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 
  13. ^ Vermeulen, Jeroen 14 Jul 2013 "Introduction to D-Bus" FreeDesktoporg Retrieved 3 October 2015 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 
  14. ^ a b c d e f g h i j k l m Pennington, Havoc; Carlsson, Anders; Larsson, Alexander; Herzberg, Sven; McVittie, Simon; Zeuthen, David "D-Bus Specification" Freedesktoporg Retrieved 22 October 2015 
  15. ^ a b c d e f g h i j k l m n o p q r s t u v w x y z aa ab ac ad ae af ag ah ai Pennington, Havoc; Wheeler, David; Walters, Colin "D-Bus Tutorial" Retrieved 21 October 2015 
  16. ^ Poettering, Lennart 19 June 2015 "The new sd-bus API of systemd" Retrieved 21 October 2015 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 
  17. ^ a b Love, Robert 5 January 2005 "Get on the D-BUS" Linux Journal Retrieved 14 October 2014 
  18. ^ "What is D-Bus" FreeDesktoporg Retrieved 29 October 2015 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 
  19. ^ a b "What is D-Bus" FreeDesktoporg Retrieved 29 October 2015 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 
  20. ^ "D-BUS System Activation" FreeDesktoporg Retrieved 18 February 2016 
  21. ^ Palmieri, John 9 Nov 2006 "announce D-Bus 100 "Blue Bird" released" dbus Mailing list 
  22. ^ a b Molkentin, Daniel 12 November 2006 "D-Bus 10 "Blue Bird" Released" KDE News Retrieved 3 November 2015 
  23. ^ Seigo, Aaron "Introduction To D-BUS" KDE TechBase Retrieved 3 November 2015 
  24. ^ Poettering, Lennart 19 June 2015 "The new sd-bus API of systemd" Retrieved 21 October 2015 Since systemd's inception it has been the IPC system it exposes its interfaces on 
  25. ^ "Polkit reference manual" FreeDesktoporg Retrieved 3 November 2015 
  26. ^ "Archived copy" Archived from the original on 2015-07-21 Retrieved 2015-06-16 
  27. ^ "What is D-Bus" FreeDesktoporg Retrieved 5 January 2015 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 
  28. ^ "Migrating to GDBus" GNOME Developer Retrieved 21 October 2015 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 
  29. ^ Poettering, Lennart 20 Mar 2013 "HEADSUP libsystemd-bus + kdbus plans" systemd-devel Mailing list 
  30. ^ a b Edge, Jake 30 May 2013 "ALS: Linux inter-process communication and kdbus" LWNnet Retrieved 21 October 2015 
  31. ^ Poettering, Lennart 19 Jun 2015 "ANNOUNCE systemd v221" systemd-devel Mailing list 
  32. ^ "The unveiling of kdbus" LWNnet 2014-01-13 
  33. ^ "Documentation/kdbustxt from the initial patch set" LWNnet 2014-11-04 
  34. ^ Corbet, Jonathan 13 January 2014 "The unveiling of kdbus" LWNnet Retrieved 11 April 2014 
  35. ^ Kroah-Hartman, Greg 13 Apr 2015 "GIT PULL kdbus for 41-rc1" linux-kernel Mailing list 
  36. ^ Corbet, Jonathan 22 April 2015 "The kdbuswreck" LWNnet Retrieved 29 June 2015 
  37. ^ "Keynote: A Fireside Chat with Greg Kroah-Hartman, Linux Foundation Fellow" YouTube 18 October 2016 
  38. ^ "D-Bus Bindings" FreeDesktoporg Retrieved 5 January 2015 

External linksedit

  • D-Bus home page at Freedesktoporg
  • D-Bus specification
  • Introduction to D-Bus on the Freedesktoporg wiki
  • D-Bus Tutorial
  • DBus Overview

d-bus = 1.6 is required, d-bus interface, d-bus library, d-bus library appears to be incorrectly set up, d-bus subsystem, d-bus tutorial, d-bus: jack server could not be started, d-business, d-business entertainment, dbus api


D-Bus Information about

D-Bus


  • user icon

    D-Bus beatiful post thanks!

    29.10.2014


D-Bus
D-Bus
D-Bus viewing the topic.
D-Bus what, D-Bus who, D-Bus explanation

There are excerpts from wikipedia on this article and video

Random Posts

La Porte, Indiana

La Porte, Indiana

La Porte French for "The Door" is a city in LaPorte County, Indiana, United States, of which it is t...
Fernando Montes de Oca Fencing Hall

Fernando Montes de Oca Fencing Hall

The Fernando Montes de Oca Fencing Hall is an indoor sports venue located in the Magdalena Mixhuca S...
My Everything (The Grace song)

My Everything (The Grace song)

"My Everything" was Grace's 3rd single under the SM Entertainment, released on November 6, 2006 Unli...
Turkish Straits

Turkish Straits

The Turkish Straits Turkish: Türk Boğazları are a series of internationally significant waterways in...