Skip navigation.
KDE Developer's Journals

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

chouimat's picture

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"

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
segedunum's picture

I would caution people to loo

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.

krake's picture

Marketing technologies

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.

chouimat's picture

huh

DCOP doesn't depend on qt

krake's picture

That's what I said

Well, this is what I said, isn't it?

Our implementation depends on Qt (using QDataStream for marshalling), there are some that don't but nobody knows about them, so everyone else thinks "DCOP depends on Qt"

That's what I mean with bad marketing, a lot of people think our technologies are KDE-only, NIH Syndrom, etc.

I actually wager a bet that once D-BUS is wide spread, people will bash KDE for "re-inventing the wheel with DCOP"

joshua's picture

D-BUS is a Freedesktop.org project

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.

segedunum's picture

Sometimes a major component n

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.

cloose's picture

> GNOME might be using D-BUS,

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

chouimat's picture

standard

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

chouimat's picture

hardware detection in an IPC????

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

segedunum's picture

What he was talking about is

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.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.