This is an application issue, not a brokre/daemon issue. The broker will (as dbus-daemon(1)) does, deliver all signals that clients subscribe to. If they subscribe to things they don't care about, that is something that should be fixed in the clients. During the kdbus times, quite some time was spent on fixing clients to avoid too broad subscriptions exactly to fix the issue described in that blog post.

Not every page on the WWW is a blog post, nor even every WWW site a web log to have blog posts on.

My apologies, it read like a blog. Seeing the parent page I see that it is not. Either way, my comment stands.

Please note that this is still an implementation of the D-Bus specification, but trying to adhere to the principle of distinct peers. As is explained, this is not entirely possible when implementing D-Bus, so it is nothing more than a guiding principle.

Not sure what you mean here. dbus-broker(1) supports SELinux exactly to the same extent as dbus-daemon(1) does. Also; remove what?

> Just noticed that this lives under bus1 github organization; does that imply that eventually it will be using bus1?

That is something we intend to explore. The idea would be to let bus1 be used under the hood by dbus libraries to do peer-to-peer communication where possible (circumventing the broker) but still stay compatible to the D-Bus semantics.

> Btw, whats happening at bus1, haven't heard about it lately?

We spent half a year working on dbus-broker ;)

bus1 is very much not dead. We intend to work on the next RFC soon.

If bus1 magically landed tomorrow, what would that mean for dbus-broker? Are the projects related at all, or mostly doing different things?

At the moment dbus-broker does not have code to take advantage of bus1, but we intend to explore adding bus1 support to dbus-broker, so that peers (if their libraries support it), would seamlessly communicate peer-to-peer (circumventing the broker) when possible.

Great to hear! Keep up the good work Tom and friends!

Yes, for the time being we do not support reexecution.

For the record: dbus-broker has full SELinux support.

Well, I don't mind either way. https://github.com/bus1/dbus-broker/wiki#using-dbus-broker says it has to be disabled.

Indeed, thanks for the pointer! Removed that now (it was left-over from before we got SELinux support).

Indeed that is how we break ties (not exactly the PID, but you get the idea).

The reason this works is that the only time we can have a tie is if there can be no causality between the events. I.e., the two sending events happen concurrently: the two ioctl calls overlap in time, so there would be no way for one to have caused the other.

What problem do you see with this?

I foresee a problem where people confuse the wording of "total order on all messages" in the wiki to mean there is a "global total order" - in other words, that bus1 solves distributed systems and we can all go home - and building buggy systems on this assumption. I'm not saying the concept is flawed or the implementation buggy, or anything like that.

PS. Neil Brown in the LWN article already conflates "global" and "total" order.

I'd suggest reading the hybrid logical clocks paper.

I have - I'm actually working with it on a multi-version IPC provider (totally unrelated to bus1 & friends). Is it relevant here? I know they're the latest and greatest, but they're not without problems either.

Based on your comments about lamport clocks, etc, I thought you'd find it interesting.

It is indeed. Cool applications too. I remember at least GUN - a graph db engine - uses them to great effect, and its author hangs out here, iirc.

> They are claiming there's no global synchronization and a global order.

Need to update your textbook ;) http://research.microsoft.com/en-us/um/people/lamport/pubs/t...

In particular, what we did is described here: https://github.com/bus1/documentation/wiki/Message-ordering

If anything is unclear or misleading, please let me know and I'll try to clarify.

I've read both, thanks. I clearly remember the fact the total ordering is "somewhat arbitrary" in Lamport's own words, which is what I pointed out here [https://news.ycombinator.com/item?id=12803907], too.

I admit I haven't read the implementation to see what kind of bounds you derive, and I couldn't find them in the wiki either. So, I think I'll go with "accidentally exaggerated" instead of "manipulative".

"[S]omewhat arbitrary" is a correct description. We take something that is fundamentally partially ordered (real-world events that may happen exactly at the same time), respect the partial order and extend it to a total order. The extension is arbitrary, but I fail to see the problem with that, or how it contradict anything we wrote?

Could you explain what bounds you are interested in and in what way you think anything is exaggerated? I would like to update the docs if necessary.

I could. I would rather put it in an email or PR. I'll try to put it together as soon as I have some time.

Thanks.

> What, bothers me is what the fuck is an iovec!

https://www.gnu.org/software/libc/manual/html_node/Scatter_0...