Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
Look: You may take your D-BUS, your D-TRAIN and you D-TUBE/D-SUBWAY (depending on your side of the pond) as much as you like. I prefer to avoid them. Let's just agree to differ.
Of course, I try to keep a usable niche in my preferred distro which doesn't force me into D-BUS. Scratch my own itch it's called.
Now: can we just get along? Remember: we have (I hope) more in common than what separates us.
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel
Posted Feb 9, 2013 13:46 UTC (Sat) by drago01 (subscriber, #50715)
Posted Feb 9, 2013 18:37 UTC (Sat) by Wol (guest, #4433)
DISPLAY=192.168.2.5:0 dbus-launch kate
will, I understand, crash and burn pretty spectacularly. I dunno, I haven't really played with it.
Plus the fact that dbus was born as part of Gnome ... I gather the KDE equivalent was network-aware and didn't not work on a network.
Hence my comment elsewhere about wanting stuff to work over the network ...
Posted Feb 10, 2013 3:39 UTC (Sun) by ovitters (subscriber, #27950)
Posted Feb 10, 2013 8:25 UTC (Sun) by krake (subscriber, #55996)
Of course this isn't an option for something that also needs to be able to provide the equivalent to the D-Bus system bus.
D-Bus, however, could make use of other techniques, e.g. certificate based authentication over TCP, etc. but on the other hand that would limit the feature set available to clients which wanted to support that (might be OK for the majority of clients though).
Posted Feb 10, 2013 19:36 UTC (Sun) by hp (subscriber, #5220)
it's just a matter of someone caring enough to do the work. in around a decade not a single person has wanted this enough to code it or pay to code it. That's why it didn't get coded.
Posted Feb 10, 2013 16:20 UTC (Sun) by oldtomas (guest, #72579)
Of course your arguments are thoroughly rational and those disagreeing just Haven' Seen The Light (TM).
It's that kind of argument what makes me sad (it's on both sides of the rift, mind you).
It's about time that both sides accept that the other side might have perfectly valid arguments (which I (for any value of "I") jut don't get or which don't apply to me).
As a corollary, extreme positions ("X should be the default/only option everywhere" vs. "X should die already", for any value of "X", e.g. D-BUS, Systemd whatever) won't make anything better.
And your position "You disagree with me: that must be irrational" doesn't help (neither the opponents nor the proponents).
Posted Feb 10, 2013 23:39 UTC (Sun) by raven667 (subscriber, #5198)
Posted Feb 11, 2013 13:21 UTC (Mon) by drago01 (subscriber, #50715)
Posted Feb 9, 2013 13:54 UTC (Sat) by ovitters (subscriber, #27950)
It is just an way to do IPC. The original comment was not really after the d-bus, but more the reaction it gives (lack of argumentation).
I for one do not mind d-bus, but if I can turn it off on a server, then I highly prefer that (avoids security bugs). D-bus provides a lot of features and that will have bugs. With time though anything you write yourself will likely have more bugs than just using d-bus. That and because enterprise distributions are also heading towards systemd (thus d-bus) results that you cannot avoid it anymore.
Regarding getting along: less caps, more arguments and all is well ☺
What about binder?
Posted Feb 10, 2013 6:04 UTC (Sun) by alison (✭ supporter ✭, #63752)
But seriously, why doesn't anyone mention binder in this context? It's already in staging, last I checked. Binder is a kernel interface for what is widely viewed as a simpler, lighter weight replacement for D-Bus. Binder's native communication is pub-sub, with userspace programs registering for events for which they define handlers. Assuredly pub-sub and multicast have some similarities, although I don't know if binder (which is intended for a fairly narrow set of use cases) will scale well, since scalability along with speed appear to be the main goals of AF_DBUS.
Posted Feb 10, 2013 13:08 UTC (Sun) by ovitters (subscriber, #27950)
Posted Feb 10, 2013 21:32 UTC (Sun) by alison (✭ supporter ✭, #63752)
Posted Feb 10, 2013 21:57 UTC (Sun) by rahulsundaram (subscriber, #21946)
search for binder. Took a couple of seconds to google it.
Posted Feb 10, 2013 22:36 UTC (Sun) by alison (✭ supporter ✭, #63752)
Posted Feb 14, 2013 7:22 UTC (Thu) by mmarq (guest, #2332)
One of the main motives for kernel Dbus for now is "Linux Apps"(it will have many more for sure)... but i definitely don't like the model at all...too much sandboxing you end up sandboxing the user out lol...
To me it would be much better to implement "capabilities" in the style of EROS http://www.eros-os.org/eros.html
..portal or bind only what shouldn't definitely be allowed, but that the FS permissions and ACL already do... so its a duplication... it could have minimal additional usability, but definitely this shouldn't be a "police OS", or it will became so secure that nobody could use it for desktop, specially there, where users make a lot of mistakes and crazy things that should be allowed to do and that don't pose any considerable security risk.
The masses are ignorant of this tech wonders... they aren't as savvy or seasoned developers as you gentlemen.
Posted Feb 11, 2013 8:34 UTC (Mon) by ovitters (subscriber, #27950)
Posted Feb 10, 2013 16:29 UTC (Sun) by oldtomas (guest, #72579)
I assume by shouting you mean this "OMG...". I wasn't. I was just paraphrasing the article upthread.
> It is just an way to do IPC.
> The original comment was not really after the d-bus, but more the reaction it gives (lack of argumentation).
And that was exactly what I was answering to: we've got a situation where both sides (for the moment) seem to be convinced of their thing. Let's deal with it. That's why my post ended with the plea to just get along and agree to differ.
Posted Feb 10, 2013 17:12 UTC (Sun) by rahulsundaram (subscriber, #21946)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds