OSNews

Euh, don't forget KDE please, Dbus has borrowed an awfull lot of dcop.

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?)

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. :-P

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

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.

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.

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.