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

[gens]

you need to do some research if you are saying that gnome was forced to use systemd/logind, LPoettering wrote a library for Gnome to sidestep systemd/logind but Gnome decided not to use it.

"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

[interested]

Why push all to kernel space? Minix has only 4000 code lines, all the rest is in user space.- It even claims to be self healing, ie when a driver dies it gets restarted etc.

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.

[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

[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]

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

[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]

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

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

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

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