MAR
7
2005

The "Foie Gras" syndrom or the force fed technology syndrom

The day that I feared the most is near. The day were my use of linux will be decided by marketing drones but this time they are not force feeding me proven technology but unproven ones and for what? Symply for the sake of interoperability between Gnome and KDE and also probably others Desktop. Well it's a noble goal but why using an unproven technology instead of taking an existing one that works which might only need some fixes and adapt it to satisfy the need of everybody?

But first what does interoperability mean? From The Free On-line Dictionary of Computing (27 SEP 03) :

interoperability

The ability of software and hardware on multiple machines from
multiple vendors to communicate.

The definition is clear to be able to interoperate the linux desktop don't need to use all the same tecnology but have a bridge between their corresponding technology.
Now people are pushing use to use D-Bus instead of DCOP and even g-conf for configuration. We all know that DCOP, which is battlefield tested, need libICE to work, which is not maintened anymore. So the question is: What need to be done to addres
s this problem?
Here some possible way
1) leave it in the current state and pray that nothing break
2) reimplement libICE
3) reimplement DCOP using another mechanism like shared memory
4) ditch dcop and using something else

I personnaly prefers the third option because I don't need a networked ipc 99.999999% of the time and if we really need to interoperate with gnome let just use a bridge. And if people prefers to go with option 4 why use D-BUS? why not use DCE which is now Opensource and which will enable us to interoperate with more systems.

I must also add that marketing driven technology choice gave us Microsoft and Java ... and this is enough to make me ponders about the well founded of the use of D-BUS. No in reality I'm scared that we will repeat the same mistake that was made in the 90's by destroying what in my imho is a superior platform by using technologies that are not able to fix the problem of an inferior platform, just because someone with more marketing drones told us to do so for the sake of interoperability.

Some might wonder why I choose this title? It's simple I have the impression I'm a goose or duck that get force fed so they can produce better "foie gras"

Comments

I would caution people to look around. Absolutely no Gnome developer is talking about interoperability with KDE. This is all one-way traffic. If people are talking like that then they'll probably kill KDE off through silly touchy, feely decisions.

The issue of a communication mechanism for a desktop environment is huge, and the fact of the matter is that DCOP has been around for years, is embedded heavily in KDE and it is now largely stable. Replacing one IPC system for another is not going to get anyone anwhere. Netscape anyone? It will take many years, which no one has got, to put that right and there is the question of stability for those who are using KDE and DCOP out there. Providing backwards compatibility is of paramount importance if open source desktops are to get anywhere, and no one is filled with confidence if a whole IPC system gets dropped - major version or not. Re-writing major components like that is never, ever a good idea.

And GConf?! Where did that one come from. Give people KConfigXT and have done with it.


By segedunum at Mon, 03/07/2005 - 22:02

KDE needs to be compliant with as many standards as it possibly can be. GNOME might be using D-BUS, but they're not controlling it. Freedesktop.org is. Can DCOP provide us with good, stable, automatic hardware detection? If it can, it doesn't look like the project is going that direction. D-BUS is. The people working on D-BUS are trying to create an IPC mechanism that can be used by many and various projects. I don't see any problem with KDE getting on board, as long as the costs are carefully weighed.

Sometimes a major component needs to be rewritten, if it's flawed. UNIX has been "re-written" multiple times, and Linux, one of the latest "re-writes" is arguably the most popular UNIX.


By Joshua Keel at Mon, 03/07/2005 - 23:48

wow!!! what did you smoke?
Hardware detection is usually handled by the kernel not an IPC


By Mathieu Chouinard at Mon, 03/07/2005 - 23:56

What he was talking about is the ability to communicate things like hardware changes from other parts of the system to the desktop. This is something D-BUS is good at and I see no reason why KDE shouldn't be able to communicate with software outside of the desktop environment in that manner.

My main point was that internally, inside KDE, automatically dumping DCOP for D-BUS is simply not a good idea simply because of the complexity and upheaval involved. Gnome dumping Bonobo (and everything else) for wholesale D-BUS is pretty much the same kettle of fish. This is not trivial, and if we really want open source desktops to get anywhere no one can be dumping IPC systems, even at major versions, for the sake of it. That's where Microsoft have scored over the years, and where they're actually waning if they keep pushing the .Net route.

Cynically, I get the impression as an outsider looking in that this looks like an attempt (certainly judging by some of the people who've pushed it) to appease some of the apparent divisions that have gone on inside Novell/Suse. I'm not interested in politics - I'd be interested in doing it right.


By segedunum at Tue, 03/08/2005 - 13:59

The question really boils down how the Linux Desktop as a platform should look like. Should it be based on a combination of the best of KDE and Gnome technology standardized via freedesktop.org, or should distributions just pick one out of the two? Novell currently thinks the first approach is a better one, and I agree, but maybe you can convince them that they should pursue the second approach.


By Waldo Bastian at Fri, 03/11/2005 - 16:05

Wow, I honored the great Zogje commented one of my blog.

I have against a desktop that might use the best of kde and/or gnome
technology (we can argue that the gnome will never use something made by kde ... ;) ) but my point is more why change something that work, granted that we might need to extend by something that is unproven, unfinished and let just say it a buzzword (for now)

Ceci dit on est vendredi soir et j'ai grandement besoin d'une biere.


By Mathieu Chouinard at Fri, 03/11/2005 - 22:14

I agree with the standard part but since when D-BUS is a standard?


By Mathieu Chouinard at Tue, 03/08/2005 - 00:07

> GNOME might be using D-BUS, but they’re not controlling it. Freedesktop.org is.

Really? Did you take a look at the commit messages from Feb./March 2005? (http://lists.freedesktop.org/archives/dbus-commit/)

GNOME
------
John Palmieri
Havoc Pennington
Colin Walters
Joe Shaw

KDE
----
*none*

> Sometimes a major component needs to be rewritten, if it’s flawed.

DCOP might have problems, but the KDE 3.x series definitely showed that it's not flawed.


By Christian Loose at Tue, 03/08/2005 - 09:26

Sometimes a major component needs to be rewritten, if it’s flawed.

No, no, no. It's the worst possible mistake you can make with complex software like DCOP and KDE. Did you not read the part where I mentioned Netscape (version 5 and 6) and where I mentioned software stability if we are to get open source desktops anwhere? You simply can't go re-writing things every three or four years - it all still has to work. This is where Microsoft has done well with Windows over the years, as awful as some things have been. Microsoft's IPC system is still based on COM despite .Net, and probably will be for a very long time.

Sun, to their credit, understood this as they were justifiably concerned when they adopted Gnome.


By segedunum at Tue, 03/08/2005 - 14:12

Is is to some extend our own fault.

When our technolgies get useful, they are still bound to our frameworks.
When we want them by outsides someone has to provide them with some adapter that doesn't

For example DCOP: our implementation obivously depends on Qt, which is a no-go for non Qt software stacks.
I read that there are DCOP implementations not depending on Qt, but they are very likely just some small projects, one man shows, not something you would rely on.

Enter D-BUS: it takes the good ideas from DCOP, sees that others would like to use it as well.
Implements its protocol stack mostly toolkit independend but just in case, explicitly specifies the wire format.

KDE is often the first project with decent market share that implements some new cool technology, but they stay KDE-only technologies because nobody want to put time into implementing some adapter if they are not going to use it.
Thus the other projects will go on and implement something similar, marketing it as something independend and universal, and KDE ends up writing adapters, only this time the other way around.


By krake at Tue, 03/08/2005 - 19:00

Pages