[darklajid]

Wait a moment. DBus is not a 'gui thing'. It is a protocol for inter-process communication. I'm not in bed with it in any way, but it seems to do a good job. You can use it from ~every~ language of your choice. Its adoption cannot (just?) be blamed on politics, it's just dead easy to use for a programmer.

Lately (and that seems to be something the author of the blog post resents) it pushed further into the system layer, for example with dbus activated services (systemd, but I'm pretty sure upstart had that as well). For as long as I can remember your distribution always started a system-level dbus instance and (only here we're talking gui/desktop environment heavy) one per session/login/user.

If you have problems with dependencies between a couple of programs that talk different protocol levels:

- Someone messed up packaging. Or you installed something in a ~weird~ way

- The same could easily happen with any other 'let's make these processes from totally unrelated projects and running using different underlying technology communicate' solution. Dbus cannot protect you from changing interfaces.

- .. except, maybe it _wouldn't_ easily happen, because without an easy way to do what dbus offers I guess you'd have fewer software and less integration points. Which you might label a Good Thing and I'd disagree.

Ubuntu still is easily manageable from the command line. It might be different from your LFS/Gentoo/Arch etc. solutions, but it's closer than FreeBSD and others. I've no love for Ubuntu, but claiming that you cannot easily (okay - define that) learn its ways and how to fix or customize it yourself? I think you should reconsider that part..

[bergie]

Yep, we've used DBus also on the server end: http://bergie.iki.fi/blog/interprocess_communications_in_mid...

[jay-pinkman]

> Wait a moment. DBus is not a 'gui thing'. yeah, you are right. i just meant to say that it's deeply connected with gui stuff and not that much with cli. the only thing i desperately needed DBus for was hardware management. i don't mind at all having dbus daemon running in background for that very purpose. when it gets to managing system daemons DBus makes me a little bit nervous - compared to dead simple bash scripts used in Arch DBus is a quite complex beast. mostly when it comes to debugging. but i can eat that.

what i can't stand is when an app that's only supposed to display image files depends on a whole lot of other completely unrelated components exposed via DBus and buried into some desktop so deeply that you need to install a huge part of that desktop just in order to make that little app happy.

what the hell is wrong with 'do one thing and do it well'? i don't need 'less integration points' - i need integration implemented on a higher, not lower level of abstraction. let me clarify this. let's suppose you want your image viewer to add paths to recently viewed pics to some database and also let you post them to your twitter account. you can write a viewer that depends on zeitgeist for storing paths and on some other funky DBus interface to work with twitter. you'll probably end up with a program that works in Ubuntu but not in another environment that doesn't provide zeitgeist or that funky twitter interface or DBus. but you could go another way:

1. write a program that only displays images passed to it as command-line arguments 2. write a wrapper that passes paths to zeitgeist 3. write a twitter app that handles posting

now your viewer works on systems with no DBus - good. the wrapper can be extended to handle any program - when the user selects a file it passes the path to that file to zeitgeist and invokes the program registered to handle files of that type. to post your pics to twitter you could write a program that displays a form for posting and uses your viewer (or any other program registered for image/png|jpg|etc) to display a preview on it. anyway just viewing and just posting are different actions and you don't need those mixed up. if while viewing an image you suddenly decide to post it you could close the viewer and open the app for posting - the path to the image file (recent file) can be read from zeitgeist. you can even integrate the 'recent documents' thing into the zeitgeist wrapper. or use some other approach to streamline things.

that's the unix way and that's how DEs could implement their reach interfaces. this would make it easy to integrate programs into desktops and preserve their 'freedom'. but DEs guys decided it's much better to trap apps into their DEs. i see it as a failure to introduce proper abstractions.

> I've no love for Ubuntu, but claiming that you cannot easily (okay - define that) learn its ways and how to fix or customize it yourself? I think you should reconsider that part..

man, just stick with Arch for a while:) you'll know what i'm talking about. system configuration via simple plain text files, simple daemon management, nothing is forced on you, if you edit some configuration file there's little chance that some gui (or non-gui) tool will mess with that file without warning you... well, let's just leave it at that. now i'll go get some sleep. no, wait! one more thing:

i gave up trying to manage any system-level stuff the way i want. i don't care anymore how things are managed underthehood in Ubuntu, Fedora, OpenSUSE, etc. i just stick with my development tools that work everywhere and try not to write programs that depend on DBus interfaces (except hardware-related ones). for all the rest i just use what's provided by the distro.