Linus Is Looking Forward To Merging KDBUS, But Not Convinced By Performance

[finalzone]

...

Reading your comments sound like you are uninterested to read the post that responded to your question as long they don't fit your own view. In that case, it means you wasted those people time honestly.

[gens]

The D-Bus _protocol_ isn't complex. But you miss the point about the speed of kdbus/D-bus completely. It is the ability to use the same framework for both control mechanisms and data at a much higher speed than previously possible, that is the point about the data speed up for kdbus.

It is quite possible to make very fast data side-channels to dbus, but then you have to duplicate D-Bus functionality for the data channel, which is an error prone mess and which leads to proprietary hack jobs.

With kdbus, everybody can easily add data payloads to D-Bus, which is useful and will reduce both developing complexity and errors for such users.

And that really is the whole point and philosophy behind kdbus; make complex things easy by abstracting the complexity away with an easy to use API, and make developing fast with libs and features.

this is dbus
it is complex

it was made to be a generic bus to make writing desktop applications easier
it was not made to transport audio or be used for real-time interactive processes

if you want to transport large amounts of data between two processes with low latency you are way better off using a plain ringbuffer+sync protocol
or even just plain sockets, be it custom or TCP

people want to use whatever they know how to use for everything
but that is not always the best solution
for example just because java is one of the more popular programming languages today does not mean we should design everything around java
so just because desktop app programmers know dbus well does not mean that it should be used for everything

i hope you can agree with this

[interested]

ofc, msg passing and synchronization needed for a micro kernel make it clear that they will never be faster then monolitic ones

then again dbus is a complex protocol
that means it carries plenty of overhead by itself and should not be used where performance is needed

The D-Bus _protocol_ isn't complex. But you miss the point about the speed of kdbus/D-bus completely. It is the ability to use the same framework for both control mechanisms and data at a much higher speed than previously possible, that is the point about the data speed up for kdbus.

It is quite possible to make very fast data side-channels to dbus, but then you have to duplicate D-Bus functionality for the data channel, which is an error prone mess and which leads to proprietary hack jobs.

With kdbus, everybody can easily add data payloads to D-Bus, which is useful and will reduce both developing complexity and errors for such users.

And that really is the whole point and philosophy behind kdbus; make complex things easy by abstracting the complexity away with an easy to use API, and make developing fast with libs and features.

[psychoticmeow]

PS
"You make it sound like some kind of conspiracy." makes it sound like you want to discredit my opinion, again
don't, i don't like politics
if you have something to say, say it

You go around talking like this is one big conspiracy, and you have ignored anything anyone has ever posted to refute it. You never accept arguments if that means moving an inch towards "oh maybe systemd isn't trying to ruin linux for everyone" and instead keep repeating the same tired old points.

You are a conspiracy theorist and you make as poor arguments, only relying on logic if it benefits you and never applying it to your own arguments. We've been going backwards and forwards on this for at least a year now, and in that time your arguments have not improved in the slightest.

[psychoticmeow]

k, i can be that dumb too

i demand you prove what you just said
and by prove i don't mean c/p from a blog, i mean prove me the benefits of what you claim

numbers, graphs, you know real data
not buzzords and comparisons to the shell

hell, id be satisfied with a proper boot speed benchmark (proper, as in detailed, extensive and fair)


otherwise "you don't understand" is a red herring
and its a shitty one at best

I see. Because you've just forgotten the thousand previous times people have tried to convince you and you've basically just said "nuh-uh".

[gens]

i don't see any point you are trying to make with that response (which is not unusual for people who haven't yet researched/understood the benefits the systemd project brings and i guess you are in that camp). It always ends up in conspiracy theories or personal abuse of the developers as they run out any arguments that have not been refuted.

k, i can be that dumb too

i demand you prove what you just said
and by prove i don't mean c/p from a blog, i mean prove me the benefits of what you claim

numbers, graphs, you know real data
not buzzords and comparisons to the shell

hell, id be satisfied with a proper boot speed benchmark (proper, as in detailed, extensive and fair)


otherwise "you don't understand" is a red herring
and its a shitty one at best

[rtfazeberdee]

"At a recent GNOME hackfest, Kay Sievers, Lennart Poettering, Kroah-Hartman, and some other GNOME developers sat down to discuss a new messaging scheme, which is what kdbus is."

systemd, gnome, same thing

i don't see any point you are trying to make with that response (which is not unusual for people who haven't yet researched/understood the benefits the systemd project brings and i guess you are in that camp). It always ends up in conspiracy theories or personal abuse of the developers as they run out any arguments that have not been refuted.

[gens]

So that time that some Gnome developers sat down with Canonical developers to discuss Gnome 3, does that make Gnome and Canonical the same thing too?

Or could it just be that the Gnome developers are already using dbus extensively and therefore have a natural interest in its successor? You make it sound like some kind of conspiracy.

"and some other GNOME developers" implies that these 3 are

that gnome and systemd devs are practically one and the same should be obvious to everyone
so saying "you need to do some research if you are saying that gnome was forced to use systemd/logind", while true, is misleading

PS
"You make it sound like some kind of conspiracy." makes it sound like you want to discredit my opinion, again
don't, i don't like politics
if you have something to say, say it

[psychoticmeow]

"At a recent GNOME hackfest, Kay Sievers, Lennart Poettering, Kroah-Hartman, and some other GNOME developers sat down to discuss a new messaging scheme, which is what kdbus is."

systemd, gnome, same thing

So that time that some Gnome developers sat down with Canonical developers to discuss Gnome 3, does that make Gnome and Canonical the same thing too?

Or could it just be that the Gnome developers are already using dbus extensively and therefore have a natural interest in its successor? You make it sound like some kind of conspiracy.

[gens]

See the classic Tannenbaum vs Linus discussion about that. Linus wants speed and effiency in his kernel. He wants speed because that is what the users want. Linux have always been 100% user demand driven: That fact and the GPL license is the reason why Linux have succeded while other non-user driven micro-kernels like Minix and Hurd have failed.

ofc, msg passing and synchronization needed for a micro kernel make it clear that they will never be faster then monolitic ones

then again dbus is a complex protocol
that means it carries plenty of overhead by itself and should not be used where performance is needed