“D-Bus 1.0 was officially released last week. Developed by FreeDesktop.org, D-Bus is an open source interprocess communication system created to promote interoperability between various Linux desktop environments by providing a cohesive common platform for internal system and application messaging. D-Bus, which has been under active development for four years, is already used extensively in the GNOME environment and will eventually replace DCOP in KDE.”
Thank you Red Hat/GNOME developers for such as great tool
Euh, don’t forget KDE please, Dbus has borrowed an awfull lot of dcop.
KDE and Gnome works on other “UNIX like” systems also not just GNU/Linux and Hardware Abstraction Layer (HAL) is already ported to FreeBSD recently. Linux developers tend to forget that part easily.
I imagine what patents are secured with Microsoft/Novell deal? They know something we don’t know?
I imagine what patents are secured with Microsoft/Novell deal?
Novell has lots of directory and SMP scalability patents. They just might be interested in non getting sued by Novell. Or something like that. I can think of thousand of reasons why Novell would like to sign an agreement with MS that doesn’t involve Novell becoming the devil.
I’m impressed at the huge amount of unproved, nosense paranoid theories the interweb is capable of generate. Commercial deals happen all the time. Sun has also signed a patent and a interoperatibility agreement with Microsoft, why nobody is critizing Sun for such agreement and nobody fears using the GPLed Java? Maybe because the agreement doesn’t necesarily means Sun is going to become 3vil and everybody understands that? Why people takes a different stance with Novell? It’s because it’s trendy? I just don’t understand people
Edited 2006-11-14 21:33
why nobody is critizing Sun for such agreement and
There are huge differences between the two deals, but I’ll only mention one: the SUN-MS deal covered software developed by either SUN or MS. The Novell-MS deal covers software developed by MS and … well 99% someone other than Novell.
That’s why so many “nonsense paranoid theories” are cropping up lately (do you regard the Samba team as nonsensical or paranoid, or groklaw, Perens, Eben Moglen, Bradly M. Kuhn and the SFLC … don’t you think that there is a reason that so many folks are pissed about Novell right now?)
According to Keith Packard, X.org 7.3 shouldn’t even require an xorg.conf — everything should be autodetected at run time. X.org will receive information about new devices dynamically from D-Bus.from http://www.linux.com/article.pl?sid=06/11/13/2112259
Now that news.
As a side note. I messed up my xorg.conf, and had to enter console mode and edit the config file from there. I do wonder if it would be easy to do such a thing in future.
Off topic
=========
Is it really the place for Novell vs Red Hat or GPL vs BSD. I think with an Opera vs Firefox these should be stickied somehow.
I also think that posts should replace “zealot” with “devoted individual”, and fanboy replace with “passionate individual”
Edited 2006-11-14 21:46
That’s excellent!
I haven’t had to mess with an xorg.conf file in forever, but a dynamically loaded one would be even better. Much easier to deal with.
With as easy as linux has gotten in the past few years I must admit that I’ve gotten very lazy.
That’s excellent!
Yes, this is excellent as long as it works.
The problem is that it also adds complexity that will make it harder for a somewhat skilled person to fix minor errors. e.g. by manually edit modlines in xorg.conf.
To easily be able to change things have long been the major advantage for Linux/Unix over windows. If you install something in windows, and it doesn’t work, there are usually not much you can do to fix it.
The problem could be as simple as the hardware is not identified properly, it doesn’t matter if you know what hardware you have and what configuration values to use, you still can’t do a thing.
I really hope that future Linux will provide easy ways to circumvent stupid non working autoconfiguration procedures.
Well, if it gets the data from dbus, I would expect it possible to feed it data manually through there with a script.
One question…
How can software autodetect the Xinerama (or TwinView) head layout?
The same way monitors are detected, through VGA.
Well, it’s not as easy as that. For example, how to determine which monitor is left, which right?
So there is stuff left, which has to be configured. But this is the easy, fun part of configuring.
What is not funny, and from the user’s view, should also not be necessary, is to tell the system what parts it has. This is something the system should find out itself, and it’s a shame, that after there exist monitor querying techniques for years, xorgconfig still asks for horizontal & vertical refresh rates
You cannot automatically detect that because it depends on your setup. That’s not a problem, because you will configure it in your desktop and when your session starts the desktop would talk to X server through D-Bus to set default preferences like resolution. It obviously cannot read your mind, so user interaction is needed for those things that cannot be detected. I don’t think it’s really that hard. If you ever configured an nVidia card for TV output or desktop cloning you probably won’t have problem configuring the next X.org
well.. perhaps xorgconfig asks because still LOTS of freaking monitors have wrong edid information. and also, nvidia kindly decided to break edid detection in >7676. (though it may be fixed in 9xxxx)
aent caught more of what I was asking but forgot to say… I meant to ask how it could detect layout.
It (well the hardware) can autodetect that there are two monitors plugged in and do something with that fact (even cloning automatically is better then doing nothing) or possibly, via dbus, ask the user what the orientation of the monitors are. Also, some stuff CAN be figured out automatically via the information monitors provide, such as if its a projector, the person probably always wants to clone it (there should of course be a UI in case its a special use case).
I have nothing against auto-configuration if they make it in a way that the hand made can be done and, once done, not messed.
I would imagine it might be something as simple as if exists /etc/X11/xorg.conf then use those custom settings. otherwise it would be autoconfigured.
Hardware that D-Bus doesn’t deal with elegantly like most Audio Cards with ALSA Drivers.
I can’t get my Echo Gina3G running because of Firmware loading issues under Ubuntu. As a result my ASLA modules get loaded all over the place and don’t load the right ones for the required audio components needed to function. This isn’t just a problem I have had but seems to be a problem under audio full stop given the threads online.
Linux without Audio is a no go for me hence I won’t use it for more than my regular I want to pull my teath out sessions. Might not be important for Word Processing but for everything else….
Hardware that D-Bus doesn’t deal with elegantly like most Audio Cards with ALSA Drivers.
You hopefully realise by now that D-Bus has nothing to do with drivers.
D-Bus provides communication channels between clients. Whatever these clients do is none of its business.
The drivers I believe aren’t the issue it is the way in which the system is communicating and allocating what driver does what that is the issue.
Seems more to be a firmware loading issue.
It’s a bit of a pity that dbus was started as a pure Gnome project and then extended to other APIs rather than written as a generic object interface and then specialized around gnome/gtk/kde/qt.
The low-level C api isn’t pretty, but to get around that you have to choose to write a gnome app or a qt one; if you don’t have any interest in going GUI work (just writing a few console apps that use dbus to communicate) you either have to use a toolkit designed for GUI work and ignore the windowing bits, or use the C api.
Under python, you don’t even have a choice – if you want to expose an object over dbus, you need to use gobject.mainloop (or the gtk equivalent). All my programs already have mainloops that work really nicely, so to expose them over the bus, I’m just adding a gobject mainloop in another thread. It just seems like that sort of thing shouldn’t be necessary…
If I remember right, qt is being moved over to use the same mainloop for 4.x
If I remember right, qt is being moved over to use the same mainloop for 4.x
I don’t think the whole mainloop is being moved (wouldn’t be wise), but you can tap into the gobject mainloop when needed – mostly transparently.
t’s a bit of a pity that dbus was started as a pure Gnome project and then extended to other APIs
That’s not true.
While the both the original maintainer (Havoc) and the current on (John) are both also GNOME developers, the D-Bus projects has always been a low-level project, specifically avoiding any desktop dependencies and even platform dependencies.
The low-level C api isn’t pretty, but to get around that you have to choose to write a gnome app or a qt one
The low-level C-API is not intended to be used directly, it is recommend to use one of the bindings instead.
The two toolkit related bindings, i.e. Qt and GLib, are the likely most used ones, however both are implemented in the non-GUI part of each toolkit stack, i.e. on GLib level and on the Qt side below QtGUI
Additionally there are other bindings with less dependecies, for example someone is working on a plain-C++ bindings and recently the need for plainC binding seems to rise as well.
Under python, you don’t even have a choice – if you want to expose an object over dbus, you need to use gobject.mainloop
This is true for the current Python bindings, however there is consensus that these are not the optimal solution and a team of developers is therefore working on a replacement.
With the Qt bindings TrollTech *again* show their API design skills.
with this, and the fact that D-BUS is used by KDE and GNOME as well, this could be a major step forwards in good desktop integration…
“D-Bus, which has been under active development for four years, is already used extensively in the GNOME environment”
Apart from some use with things like HAL, and some muted migrations of things like GConf to using it, it is not extensively used within Gnome at all:
http://log.ometer.com/2006-11.html#6 :-
“Integration into the GTK+/GNOME API. Lots of things in GNOME can be cleaned up and made simpler with D-Bus available. For example, the bat**** insane lifecycle-management/activation code in libgconf/gconfd-2 can be nuked. (please save us – it’s so simple and things are so broken.)”
“…and will eventually replace DCOP in KDE.”
It already has, and remember; DCOP is, and was, basically everything to KDE. That shows you how seriously they’re taking DBUS. I thought this might have caused more problems than it actually has.
Give KDE its fair due on this.
Edited 2006-11-15 09:26
I personally happen to think that DBUS is possibly the most important thing that has happened to Linux, and Unix, since the year dot. Forget about Mono or various other things that have generated a considerable amount of noise. The things that DBUS potentially enables is huge. It’s not going to solve everything, and no you can’t just take two apps and plug them together via DBUS (what objects are you passing?), but it’s a big step forwards. Huge, in fact.
For the first time on a Linux, or a Unix system, we potentially have a central point where every piece of software on a system can communicate with one another, sing from the same hymnsheet and not have to guess or do excruciating things to find out what is happening elsewhere. Additionally, for scripters and programmers you actually have a chance of getting a decent API for doing all this without having to arbitrarily send out shell commands and parse the ‘stuff’ that comes back – if anything does come back.
This is what Linux, as a coherent system, badly needs, both as a desktop and a server. The fact that people are even talking about getting configuration information for X.org through DBUS, a centrally accessible service, is a big thing. What Linux, and Unix, has badly needed was a central service and a central API for programmers. This is potentially Linux’s Win32 API and Windows’ COM components (WMI etc.) – except better. I’d also like to see DBUS work remotely, over a network, which would also be a big thing for administration.
All this should have been done ten years ago or more, but better late than never.
Edited 2006-11-15 10:06
Like first I very much like the convergence of KDE and Gnome projects. It should not be what separates us, but what unites us.
Then, segedunum, I’d like to ask you this: why do you use the word ‘Linux’ next to ‘Unix’? Isn’t ‘Unix’ a superset that includes the first one? If not, what expression should one use to describe all Unix-like oses? Unix-like
, Unix derivated, Posix compliant, Linux… I can imagine ie ‘Unix clone Debian’, but ‘OpenSolaris Linux’ would make many people puke 
Aha, what about ‘Debian NIX’, ‘OpenSolaris NIX’? NIX community? Please share your ideas, let’s have some fun…
Then, segedunum, I’d like to ask you this: why do you use the word ‘Linux’ next to ‘Unix’?
Because you can potentially use all this stuff that is currently focused on a Linux-based platform on any of the BSDs, Solaris, AIX – basically any Unix like system. I just used the name ‘Unix’ to state that using DBUS doesn’t need to be Linux specific.
If not, what expression should one use to describe all Unix-like oses? Unix-like
, Unix derivated, Posix compliant, Linux…
I have absolutely no idea. Everybody has borrowed something from everybody else at some point, and strictly speaking you can only call an approved system Unix. Of course, some people get really pedantic about what people call a Linux based operating system :-).
I personally happen to think that DBUS is possibly the most important thing that has happened to Linux, and Unix, since the year dot
This doesn’t makes sense, as Dbus is a natural evolution of lots of other stuff before it, and was made possible because of many errors made before it.
The things that DBUS potentially enables is huge. It’s not going to solve everything, and no you can’t just take two apps and plug them together via DBUS (what objects are you passing?)
Huh ? Why you can’t do that ? Actually you can. Introspection is there for a reason too.
For the first time on a Linux, or a Unix system, we potentially have a central point where every piece of software on a system can communicate with one another, sing from the same hymnsheet and not have to guess or do excruciating things to find out what is happening elsewhere
That’s not true at all. You could do that with most of other communication systems too. The truth is that DBus came at a time where several methods have been tested (ORBit, DCOP, …) and a clear winner was found, and initiatives like freedesktop.org were successful, and the kernel dev could finally dedicate some time to kernel – user space information passing, and they knew a low-level enough system was necessary, and more desktops meant more hardware autodiscovering necessity, and devfs was obsoleted intoducing udev, and …
It’s the first time it seems such a system will be universally adopted on Linux OS, not the first time these have existed.
Additionally, for scripters and programmers you actually have a chance of getting a decent API for doing all this without having to arbitrarily send out shell commands and parse the ‘stuff’ that comes back – if anything does come back
This is another nonsense you’re saying there. You sound like the shell commands and parsing is not good enough. News for you : you still will have to “send out shell commands and parse the ‘stuff’ that comes back”. That is, if you do shell programming. Or you thought perhaps there was some kind of shell binding ?
Shell commands works just fine thanks, and dbus has its share of them. And for all other shell commands you seem to despise, there was already decent API for doing what they were doing. You seem to be confused between the shell and what DBus is.
This is what Linux, as a coherent system, badly needs, both as a desktop and a server
No, this is only needed on an easy home desktop. This won’t get you anywhere on a server, that needs to be locked down.
The fact that people are even talking about getting configuration information for X.org through DBUS, a centrally accessible service, is a big thing
Notice the context in which people talk about this : the average user’s desktop. This was always the problem with X.
This can also help the dynamic configuration of X.org, which is the biggest thing. Until now, XOrg has to do redundant things with the kernel, which was always causing all kind of problems. Now, XOrg just has to ask DBus what the kernel says, or when sth changes.
What Linux, and Unix, has badly needed was a central service and a central API for programmers. This is potentially Linux’s Win32 API and Windows’ COM components (WMI etc.) – except better
This is even more nonsense. DBus is not a central API for programmers, and is no more a central service than init, inetd, nfs or others.
We would believe DBus is some magic by reading you. DBus is just a communication way between apps.
It has nothing to do with Win32 API or Windows COM (you’re comparing apples and oranges there), or even WMI.
DBus allows for all kind of dynamic stuff, like notifications. KDE and Gnome could do that better than Windows before DBus.
For example, you could look at your file grow while it was being downloaded on both KDE and Gnome, but it still is impossible on Windows.
I’d also like to see DBUS work remotely, over a network, which would also be a big thing for administration
I wonder what would be the benefit of DBus for administration !!
All this should have been done ten years ago or more, but better late than never
BS. This could never have been done 10 years ago, and sure enough should not have ! Not so long ago, devs where divided as to what comm system to use (Corba or a more efficient derived Corba ?). 10 years ago, we didn’t even have good event loop systems. Kernel comm did not exist as powerfully as now with /sys, inotify, we didn’t have freedesktop, such a project wasn’t driven by devfs or XFree86, … We couldn’t focus on bonuses things like DBus. Most of the time in FOSS, people try to make the theory work before improving. That’s why DBus is still unoptimised and really slow. It’s slower than ORBit2/Bonobo !!
This doesn’t makes sense, as Dbus is a natural evolution of lots of other stuff before it
There hasn’t been lots of other stuff before DBUS at all.
Huh ? Why you can’t do that ? Actually you can.
No you can’t. You can get some basic communication going, but if you’re passing objects, collections etc. then both apps need to know what they are. That’s based on what framework you use, which DBUS doesn’t specify.
That’s not true at all. You could do that with most of other communication systems too. The truth is that DBus came at a time where several methods have been tested (ORBit, DCOP, …)
They failed, and ORBit was a disaster for programmers. It never got beyond the bounds of the desktop.
This is another nonsense you’re saying there. You sound like the shell commands and parsing is not good enough. News for you : you still will have to “send out shell commands and parse the ‘stuff’ that comes back”. That is, if you do shell programming.
No, you’re talking out of your backside. Parsing shell commands is not good enough – what a programmer wants is to use a function and get something definitive back. Of course that means creating an API, but DBUS has gone a long way to making it possible.
No, this is only needed on an easy home desktop. This won’t get you anywhere on a server, that needs to be locked down.
Utter rubbish. Ever heard of WMI on Windows? Organisations use this stuff all the time.
Notice the context in which people talk about this : the average user’s desktop.
I didn’t mention the desktop. I just mentioned X.
This is even more nonsense. DBus is not a central API for programmers
I never said it was, but it has gone a long, long way to getting to one.
We would believe DBus is some magic by reading you. DBus is just a communication way between apps.
Considering just how utterly woeful communication between apps on Linux is and has been, it is magic in comparison.
It has nothing to do with Win32 API or Windows COM (you’re comparing apples and oranges there), or even WMI.
Hmmmm, no. Functionally speaking you’re talking about the beginnings of an equivalent, or something better.
I wonder what would be the benefit of DBus for administration !!
Administration applications would actually work in a universal way and you could actually have proper remote applications.
BS. This could never have been done 10 years ago, and sure enough should not have !
Errrr, yes it could.
That’s why DBus is still unoptimised and really slow. It’s slower than ORBit2/Bonobo !!
I doubt whether you’d see an appreciable difference, and you’re fogetting one thing – no one uses Bonobo.
Just out of curiousity (and notice that NO I am no GnuStep user (at least not yet, I’m giving it some thought, though)) but how is that DBus so extremely ahead (in terms of functionality than what those guys at NeXT had with NeXTStep System Services those long days ago?
Sure DBus is great, but stop talking like it is the revolutionary do-all-solve-all because it is just a new way to do an old thing. (Only thing is, now it is probably going to be a standard way to do that the same way everywhere in Linux and some others)
This is potentially Linux’s Win32 API and Windows’ COM components (WMI etc.) – except better. I’d also like to see DBUS work remotely, over a network, which would also be a big thing for administration.
I don’t really get these lines…Win32 API is so completely different thing altogether. DBUS is just plain and simple a framework for apps to send data back and forth. And what would it benefit in a network? It isn’t even meant to be exposed to such, and besides, what would you do with it?
I don’t really get these lines…Win32 API is so completely different thing altogether. DBUS is just plain and simple a framework for apps to send data back and forth.
DBUS can actually now enable these things to happen.
And what would it benefit in a network?
Clearly you’ve never used or written an application to do administration over a network.
It isn’t even meant to be exposed to such, and besides, what would you do with it?
Everything people do with something like DCOM and remote WMI today – which is a hell of a lot.
I never cease to be amazed by people who don’t understand this stuff.