It Doesn't Look Like KDBUS Will Make It For Linux 4.1

[pininety]

First off - systemd is being handle improperly in general. Somehow an init package is making itself a requirement to run applications which should be cross platform portable - while systemd is linux-only, not portable and breaks *nix philosophy badly. Basically a really poor take on SMF imho. I wish it was optional and I wish the rats that wrote it would keep "the old way" of doing things available so people who want to try and ignore this nightmare can.

What are you talking about?
How is systemd making itself a requirement?

If at all, developers of software choose to add systemd as a dependency for their software. But that is not systemd making itself an requirement.
Is systemd forcing Gnome to depend on it? No. systemd provides functions the Gnome people want so they choose not to write all of this code themselves and instead depend on systemd to do it for them.

[valeriodean]

Here is Alan, who has probably written more Linux than most anyone else, trying to explain to this guy http://sixgun.org/files/greg-kh.jpg why kdbus is a mess.

Ahahahahah. I especially love the part "to this guy". Why not add also "unknown"?

[gens]

Uh.. no. Some protocols are specifically made to work like this (especially in the show control world)

you are right, but those should not use a heavy protocol like dbus

[Awesomeness]

Hmm. Still trolling

To quote a person you apparently respect too much:

....................../??/) 
....................,/?../ 
.................../..../ 
............./??/'...'/???`?? 
........../'/.../..../......./??\ 
........('(...?...?.... ?~/'...') 
.........\.................'...../ 
..........''...\.......... _.?? 
............\..............( 
..............\.............\...

[MoonMoon]

Somehow an init package is making itself a requirement

How would they even do that? Put a gun to the heads of other developers and force them to be dependent on systemd components? And that is exactly the second point, no software I know of relies on the init part, they all use other systemd components.

I wish it was optional and I wish the rats that wrote it would keep "the old way" of doing things available so people who want to try and ignore this nightmare can.

If you want to use "the old way" then it your responsibility to keep "the old way" alive, not the responsibility of those that are developing alternatives. The only rats are those that demand software being maintained for them for free without contributing anything themselves.

[TheBlackCat]

i read the whole thing
1. multimedia
2. programs sending over 1k requests per second

1. shouldn't be done over dbus
2. bad programming

You are a liar. Either you are lying about having read it, or lying about the justification. Either way, besides that the justification includes:

3. Security. The kernel guarantees that data and metadata are not tampered with.
4. Avoiding race conditions.
5. It is available much earlier during boot and much later during shutdown
6. It can serve as a more basic framework to build other IPC mechanisms on top of (for example Android's binder can use this behind-the-scenes).
7. Increased performance for existing applications.
8. Easier handling of containers.
9. More metadata.

As for 1 and 2, I am sure you know much more about this sort of thing than, say, the Wayland developers.

[gens]

You are a liar. Either you are lying about having read it, or lying about the justification. Either way, besides that the justification includes:

3. Security. The kernel guarantees that data and metadata are not tampered with.
4. Avoiding race conditions.
5. It is available much earlier during boot and much later during shutdown
6. It can serve as a more basic framework to build other IPC mechanisms on top of (for example Android's binder can use this behind-the-scenes).
7. Increased performance for existing applications.
8. Easier handling of containers.
9. More metadata.

As for 1 and 2, I am sure you know much more about this sort of thing than, say, the Wayland developers.

what's your problem ?

[gens]

You are a liar. Either you are lying about having read it, or lying about the justification. Either way, besides that the justification includes:

3. Security. The kernel guarantees that data and metadata are not tampered with.
4. Avoiding race conditions.
5. It is available much earlier during boot and much later during shutdown
6. It can serve as a more basic framework to build other IPC mechanisms on top of (for example Android's binder can use this behind-the-scenes).
7. Increased performance for existing applications.
8. Easier handling of containers.
9. More metadata.

As for 1 and 2, I am sure you know much more about this sort of thing than, say, the Wayland developers.

well, i guess i can reply properly
just didn't expect this kind of stupidity and ad hominem this early in the morning

3. the protocol guarantees that; if the dbus programs memory space can be tampered with then you don't have security
4. the protocol is asynchronous by itself
5. not needed really, just bullshit talk by some devs (you know who)
6. it is too complex to serve as a basic anything, what you read is some other devs thinking of implementing a protocol that would be a basis for something like dbus
7. apps that use dbus shouldn't use it for performance sensitive things, as 1. and 2. point out already (those apps should use ring-buffers or even AF_UNIX)
8. that was rebutted on the mailing list by the creator of dbus himself
9. too much metadata sharing is something a couple devs brought up as a security hole


anything else ?
maybe some quote from wayland devs about how great it would be to stream video over dbus ?
(the only example of streaming media over dbus GKH mentioned is PA, and that is a shit idea)

[gens]

7. apps that use dbus shouldn't use it for performance sensitive things, as 1. and 2. point out already (those apps should use ring-buffers or even AF_UNIX)

theblackcat, don't read the mailing list today
just a friendly advice

[TheBlackCat]

well, i guess i can reply properly
just didn't expect this kind of stupidity and ad hominem this early in the morning

Learn what ad hominem means. Pointing out that you were lying about what they said is not an ad hominem. Whether you agree with their reasons or not, they still gave them, despite your repeated assertion that they didn't.

3. the protocol guarantees that; if the dbus programs memory space can be tampered with then you don't have security

Please read the explanation in the thread. Currently dbus cannot guarantee passed buffers are not altered by the sender while being read. kdbus can.

4. the protocol is asynchronous by itself

*sigh* Again, please read the explanation in the thread. They give an example, "exit-on-idle", which cannot be done safely in userspace.

5. not needed really, just bullshit talk by some devs (you know who)

The fact that you don't want to use it doesn't make it "bullshit". Yeah, we got it, you don't like systemd. But until your magical systemd replacement is released, a lot of people are using systemd.

6. it is too complex to serve as a basic anything, what you read is some other devs thinking of implementing a protocol that would be a basis for something like dbus

Simply false.

The binder developers at Samsung have stated that the implementation we have here works for their model as well, so I guess that is some kind of verification it's not entirely tied to D-Bus. They have plans on dropping the existing binder kernel code and using the kdbus code instead when it is merged.

7. apps that use dbus shouldn't use it for performance sensitive things, as 1. and 2. point out already (those apps should use ring-buffers or even AF_UNIX)

Yeah, great, lets have several completely different ways to do similar things. That is a great way to make software more reliable and less buggy.

8. that was rebutted on the mailing list by the creator of dbus himself

No, it wasn't. There was a discussion about whether it was as easy as it could be, but it is still easier than what is currently the case with dbus.

9. too much metadata sharing is something a couple devs brought up as a security hole

Which was promptly addressed by the devs and ultimately shot down by Linus.

maybe some quote from wayland devs about how great it would be to stream video over dbus ?

Who said anything about streaming video? https://plus.google.com/+gregkroahha...ts/bYZxmbNXAZX

Wayland uses unix sockets for control data, and passes DRM or SHM file-descriptors for buffers. It is trivial to change this to use kdbus for control data.