[jay-pinkman]

honestly i didn't get the NetworkManager thing either. since my Arch Linux days i remember that it's manageable from cli. although i never used that cli.

but the thing that touched me is that there are standards like POSIX for the cli world and there are standards like DBus for the gui world and lack of any sane standards for both of them. POSIX-based software and DBus-based software took quite different paths in their evolution. so different that they look now like creatures from two different universes. it's always nice to see how devs from GNOME and KDE develop standards that help interoperability. i wish someone would look into interoperability between the gui world and the cli world too. i originally moved to Arch from Ubuntu because the latter looked quite noisy to me - too many desktop components that i never used, to many system resources waisted on activities that i consider useless or harmful. i've created a very minimalistic environment built around some cli tools and a few very simple gui components that didn't depend on a whole desktop. and it worked quite well until it started to fall apart - every program that didn't belong to the cli world tended to either crash or work with some limitations. mostly because of the problems with DBus. most of these problems were caused by differences between the actual DBus interfaces provided and what those programs were expecting to see. and of course there were some missing components that depended on a ton of other components from either GNOME or KDE. so now i'm back to square one - i'm back on Ubuntu and i feel like an alien. most things indeed work out of the box but it's not a linux that i understand, can easily learn, fix and customize myself.

[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.

[repsilat]

> honestly i didn't get the NetworkManager thing either

I'm on Arch and I get by well enough with wicd (at the command line) for my network management needs. It could be that my needs aren't as great as the author's, though.

As for DBUS... A couple of years ago I started using wmii and missed having email notifications in my status bar. I didn't want to run a stand-alone status bar, so I tried to hack up something with dmenu and my GUI mail client via DBUS. It was horrible, just awful. A lot of the problem was a poor and undocumented interface, but using DBUS itself wasn't great.

I've heard people mention 9P as an alternative that's ready to play nicely with the rest of the landscape, but I can't believe a sensible UNIX-like solution will ever gain mainstream adoption.