J5’s Blog

Well, I’ve gone and done it. Thanks to David Malcolm’s excellent 2to3c tool and some hand wrangling with PyUnicode objects I was able to get D-Bus Python compiling and working on Python 3. Grab the patch and start testing it out.

I’ve also tested this under Python 2.6 but it would be nice to see if it also works under Python versions < 2.6 since 2.6 has a couple of compatibility layers built in.

It is nice and balmy out here in Gran Canaria so I decided to release another version of d-feet out into the wild. This is a release of a couple of fixes which have been hanging around in git but never found their way into a tarball.

D-feet is a basic D-Bus debugger used for visualizing the API of running D-Bus applications.

What’s Changed?

• pretty print output added (Will Thompson)
• quit item added to file menu (Will Thompson)
• UI improvements (J5)
• fix for d-bus methods that return 0 (J5)
• all basic types now supported correctly (Marcel Holtmann)

Latest Tarball: http://johnp.fedorapeople.org/downloads/d-feet/d-feet-0.1.10.tar.bz2 (sha1)
Project Page: https://fedorahosted.org/d-feet/
Fedora Community Page: https://admin.fedoraproject.org/community/package_maintenance?package=d-feet

They have the details up on their web site.  Apparently it is a way of creating local applications using either Gecko or WebKit.  The remote part of the equation isn’t there and it isn’t clear if they will be perusing this angle. Right now the code only supports clients but by the look of their documentation, they are planning on creating the ability for JavaScript services which would be cool.

I just found this out after reading and article about the GNOME Mobile release.  Apparently Movial joined LiMo sometime in August and have pledged to release their Browser D-Bus Bridge as open source.  Perhaps this went over the D-Bus mailing list and I missed it but I am eager to look at the code and documentation to make sure remote sandboxed code doesn’t now have a way of breaking out of its jail.  In other words I hope they have added a permissions based system much like we have for the system bus. If they have a sane system this could really be a powerful tool.

In a local world where all your applications are installed by the user, security on the session bus doesn’t have to be tight as the application will already have all the capabilities that they might gain from using the session bus. They even have more such as rm -rf ~.  However, if web pages are now able to access the bus without a failsafe security model for access rights you would be allowing remote applications access to whatever the session bus exposes.  They would be first class citizens in a very bad way.  Depending on what services are running on the bus, information could be stolen, files added and deleted as well as other exploits.  Already gVFS runs over D-Bus and hopefully in the future we will be moving from a corba based accessibility layer to a D-Bus one which means every UI element would be exposed via the bus.

That is not to say it is all doom and gloom.   Having a browser/D-Bus bridge is very important towards moving the desktop experience forward, so much so that I was considering writing one until I saw this.  Of course there is no open code or documentation yet, at least what I could find.  I do trust them to do the right thing but it would have been nice if the development was done in the open from the start.  Can someone working with LiMo point me to the source or information of when it will be released?

We’ll I’m going to dive into the deep end (flames welcome) because I have been talking to people about the Qt “possibility” since Nokia bought Trolltech and GNOME was considering what to do for the future of its toolkit.  I can see the headlines of yet another GNOME developer advocating using Qt4 as the basis of future releases but this simply is not the case.  It is, in its basic form, an exercise in “what ifs?” and an iterative process of looking inward at our ecosystem and seeing the pros and cons of certain directions we could take.

Is this going to happen?

First off this is a highly unlikely scenario. The planets would have to align, Qt would have to go LGPL, Nokia would have to loosen controls on contributions to avoid a fork, the Qt team would have to accept a community which has slightly different goals and the GTK+ team would have to signal their willingness to move. We are not going to turn our back on the great work the GTK+ teams are doing and most certainly the base libraries we use such as GStreamer wouldn’t change.

What are the possible advantages?

• Less confusion for the non-insiders on what to learn and program for
• We can get rid of the whole Freedesktop common widgets talk (e.g. Print and File dialogs) which is nonsense and a distraction anyway
• Hopefully less bickering in the community meaning a more unified and focused front against larger threats
• Focus can move from the lower toolkit layers to the higher level desktop layer which really define the value differences between GNOME and KDE
• Easier technology sharing

Note that these are all only possible advantages and may not even happen even if there was a move.

 What are the possible disadvantages?

• More bickering on how to write applications (who’s approach to usability wins out?)
• Less focus and a return to writing applications without a shared guideline (just look at old XLib interfaces – almost like snowflakes)
• A loss of identity
• Loss of amazing GTK+ developers who may feel abandoned
• Splintering of the community so we have parallel GTK+ GNOME and Qt4 GNOME development
• Screwing ISV’s who bank on GTK+’s stable interface
• GTK+ isn’t just a license – we would be losing a lot by switching away from the codebase
• Falling into the growing pains GTK+ 2.0 brought GNOME and Qt4 is still bringing KDE
• A loss of activity at Freedesktop.org which is actually sometimes useful in producing dialogue and shared practices
• A loss of control over the direction of the toolkit effecting the quality and feel of the GNOME desktop
• Really a lot of development is moving to the web – will toolkits be important enough to warrant the pain of the move

What this wouldn’t be

This wouldn’t be a merging of GNOME and KDE.  Each community has a different idea of what constitutes a usable desktop and Qt would simply be an implementation detail bellow GNOME.

Conclusion

This is pretty much a pipe dream.  It solves some issues while creating a whole host of different ones.  I’m not going to advocate it other than seeing what peoples reactions are.  On the flip side if the work was put behind it, the planets aligned, and both communities came to an agreement I wouldn’t object to the arrangement.  Needless to say, I’m not holding my breath nor would I be elated or saddened if it did or did not happen. To me it is all what is best for Linux, GNOME, Free Software and the wider market. It is unclear what direction would be best (any claims to that knowledge would be suspect) but honestly and actively looking at the possibilities is a useful activity, however remote. People reading should not put their “hopes and dreams” on this or believe it to be more than it is.

That’s right, in order to support the upcomming release of GNOME 3.0 which is introducing a new tabbed interface, we’ve totally made D-Bus HIG compliant by adding tabs to the API.  No longer do you have to select a system or session bus while connecting.  Now all you have to do is select the correct tab and you are connected.  Now you might be saying, I can’t see these tabs.  Because of constraints of the D-Bus system, namely not having a GUI, we had to add virtual tabs.  Don’t worry, they are there, you just have to randomly click and eventually you will select the right bus.  Or you can simply use the new D-Bus Gtk+ bindings which exist to provide a GUI in which to display the tabs.  A word of warning though, because of Qt4’s abstraction layers when using the D-Bus Qt4 library they will show up as plasmoids.  We here at Freedesktop.org hopes this makes your D-Bus hacking a much more enjoyable experience.

Due to issues putting the re-licensing effort on hold indefinitely, it has been decided to move to 1.2.x versioning scheme. Being that 1.1.20 is considered to also be 1.2.0 and this being the second release in the 1.2.x stable series we have versioned this release 1.2.1. This release contains a number of bug fixes identified after 1.1.20:

• compiles under some older versions of glibc
• compiles without X support once again
• fix stuck server grab if dbus-launch is run in an existing D-Bus X session
• various Mac OSX build fixes added
• don’t use the broken poll call on Mac OSX
• better checks for linker flag support should allow D-Bus to link under various linkers
• exit_on_disconnect is set after the connection registers with a bus so we don’t exit if we get a disconnect during the handshake
• dicts now work correctly with dbus-send
• inotify backend is now less aggressive
• pending calls expire correctly
• memleak of uuid when the bus is autolaunched fixed

D-Bus is a message bus system, a simple way for applications to talk to one another. In addition to interprocess communication, D-Bus helps coordinate process lifecycle; it makes it simple and reliable to code a “single instance” application or daemon, and to launch applications and daemons on demand when their services are needed.

Get it now at:

http://dbus.freedesktop.org/releases/dbus/dbus-1.2.1.tar.gz

All stable development will now happen on the “dbus-1.2-branch” branch and all unstable development should happen on the “master” branch.

I got back from the BOSSA conference last week. It still is my favorite conference for just talking to people and getting things rolling. The organizers keep it small and limit the number of talks so that people can get to what they do best and just talk to each other. While I am no longer directly involved in embedded development I still feel this should be the target of most developers. A win on current generation embedded devices means improvements across the board from those devices to the desktop and even the server room. Most of my debugging and optimization techniques for D-Bus, the focus of my BOSSA talk, were gained from working with it on embedded devices. I continue to gear my work with the idea that in the near future a large portion of the people consuming those technologies will be doing so on devices that are considered to be “embedded”.

I’m currently in the miami airport having a Boston Lager to celebrate St. Patrick’s day while waiting for my flight to San Paulo, Brazil. BOSSA will be a blast but I do regret not being able to celebrate with my friends back in Boston.

A little over a year after releasing D-Bus 1.0.0 I am proud to announce the beginning of a new series of stable releases. This is effectively the 1.2.x stable series though the version does not reflect that yet due to non-technical reasons discussed in the release notes bellow. This replaces the 1.0.x series while still staying ABI compatible. What this means is that applications written for the 1.0.x versions of D-Bus should still run unmodified using the 1.2.x library and bus.

D-Bus is a message bus system, a simple way for applications to talk to one another. In addition to interprocess communication, D-Bus helps coordinate process lifecycle; it makes it simple and reliable to code a “single instance” application or daemon, and to launch applications and daemons on demand when their services are needed.

Major Version Feature List

• Features
  • The system bus now supports starting services on demand. This uses a setuid helper program because system bus daemon runs as a nobody user, while services it launches may need to run as a different user.
    • A design doc is available in doc/system-activation.txt
  • The TCP address format has been enhanced, such that TCP may be actually usable.
    • The dbus-daemon man page describes the new elements in the address format.
  • Support ANONYMOUS mechanism for authentication, which allows a client to authenticate as nobody in particular
    • The ANONYMOUS support means you can now use D-Bus (without a bus daemon) as a protocol for a network service provided to anonymous Internet or LAN clients.
  • Autolaunched busses now save their parameters in X11 if possible making them behave closer to busses launched through the normal mechanisms
  • inotify is now the default backend for watching configuration file changes
  • Better thread support.
  • The bus daemon now generates a globally-unique ID for itself.
    • Use this as a unique ID for a user’s session, for example.
  • Support for message serialization added for use with external transports like TUBES!!!
  • Better eavesdropping support now picks up reply messages for debugging
• Library API additions
  • dbus_connection_set_allow_anonymous() – allow the message stream to begin if the client auths as anonymous (otherwise, the client will be dropped unless they auth as a user).
  • dbus_watch_get_unix_fd() – replaces dbus_watch_get_fd
  • dbus_watch_get_socket() – replaces dbus_watch_get_fd
  • dbus_server_get_id() – available to access the unique ID of a particular address
  • dbus_connection_get_server_id() – available to access the unique ID of a particular address
  • dbus_message_marshal() – serializes a message into a byte array
  • dbus_message_demarshal() – de-serializes a byte array into a message
• Library API deprecations
  • dbus_watch_get_fd() – had unclear cross-platform semantics
• Protocol additions
  • Argument path matching of the type arg0path=’/aa/bb/’ is now supported
  • New error org.freedesktop.DBus.Error.ObjectPathInUse added
  • ANONYMOUS auth support added
  • GetAll call added to the properties interface for getting a list of properties an object exports

Release Notes

• This is the next generation supported STABLE release of D-Bus. For all intents and purposes this is the 1.2.0 release WITHOUT the planned X11/MIT license change due to a couple of license holders who have yet to respond. For the most part this license change is being pursued to simplify licensing issues and fix a couple of licensing corner cases. When this happens D-Bus will be released under the 1.2.0 version.
• D-Bus 1.0.x effectively goes into security fix mode and will only be updated for major issues.
• Fixed CVE-2008-0595 – security policy of the type <allow send_interface= “some.interface.WithMethods“/> work as an implicit allow for messages sent without an interface bypassing the default deny rules and potentially allowing restricted methods exported on the bus to be executed by unauthorized users.
• Fixes dbus-launch so the session bus goes away so does D-Bus
• Builds against latest gcc/glibc changes
• Correctly unref connections without guids during shutdown
• About the name: Submitted by Greg K Nicholson, Coniston Water is a lake in Cumbria, England where several water speed records have been broken. Between 1956 and 1959 Sir Malcolm’s son Donald Campbell set four successive records on the lake in Bluebird K7, a hydroplane. Wikipedia

Get D-Bus 1.1.20 “Coniston Water”!!!

Go to the D-Bus web site for more information.