Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“DBus is seriously screwed up”

thread.gmane.org

Post reply on HN
Print view View original

201–209 of 209 posts

Re: “DBus is seriously screwed up”

#201

Post by mcguire »

mburns wrote: post #48
kryptiskt wrote: post #46

Earlier quoted context omitted.

I don't get the use case, why can't the programs use DBus to negotiate the streaming over some low-overhead transport? Why are people so insistent on ramming a square peg into a round hole?

because they want the square hole for a reason, the square hole being a unified in-kernel IPC system. Greg KH has given a few talks/blogs about the design goals of kdbus. https://lwn.net/Articles/551969/

"because they want the square hole for a reason, the square hole being a unified in-kernel IPC system."

Another one?

Re: “DBus is seriously screwed up”

#202

Post by coldtea »

jude- wrote: post #189
coldtea wrote: post #107

Earlier quoted context omitted.

> With shared memory (IPC) or sockets (RPC), applications can talk to each other. The whole idea is the "standard" part, not merely the "talk to each other part".

I think what you're looking for is API standardization? If so, dbus does nothing more to help you than POSIX IPC, since each dbus-speaking application can define arbitrary methods with arbitrary signatures and arbitrary side-effects. Dbus is basically a way to do library calls across address spaces--it doesn't help me write programs that are loosely-coupled to one another.

No, looking for a standard message bus that works across applications.

I don't mind that "each dbus-speaking application can define arbitrary methods with arbitrary signatures and arbitrary side-effects", as that's the whole point.

Re: “DBus is seriously screwed up”

#203

Post by bitwize »

mcguire wrote: post #200
bitwize wrote: post #80

Earlier quoted context omitted.

X is going to be migrated into the recycling bin. Lennart wants to migrate PA to dbus, and the possibility exists for doing the same for some future version of Wayland.

Ah, Wayland. Yet another example of the successor to a system being less capable than the system it replaces. " Wayland does not currently provide network transparency, but it may in the future. It was attempted as a Google Summer of Code project in 2011, but was not successful. Adam Jackson has envisioned providing remote access to a Wayland application by either 'pixel-scraping' (like VNC) or getting it to send a "…

It turns out that in this day and age, desktop users much prefer pixel-perfect tear-free rendering to network transparency. Wayland is X11 without the legacy cruft -- and it turns out that the only thing left in X11 that's not legacy cruft -- like seriously, bleeding-edge tech for 1986 -- is a centralized way to hand out direct-rendering frame buffers to user processes and composite them together for the final image. Which is exactly the extent to which modern apps use X11.

Remote access can be achieved by running a special Wayland server on the remote side that connects to a Wayland client on the local side and exchanges framebuffer and event data with that client. In this setup, apps can talk Wayland and not even be aware that their display is being networked; they are also completely decoupled from the remoting protocol which can be anything. RDP and streaming h.264 would be good choices, certainly better than legacy X protocol.

Wayland is objectively a huge win.

Re: “DBus is seriously screwed up”

#204

Post by mcguire »

bitwize wrote: post #203
mcguire wrote: post #200

Earlier quoted context omitted.

Ah, Wayland. Yet another example of the successor to a system being less capable than the system it replaces. " Wayland does not currently provide network transparency, but it may in the future. It was attempted as a Google Summer of Code project in 2011, but was not successful. Adam Jackson has envisioned providing remote access to a Wayland application by either 'pixel-scraping' (like VNC) or getting it to send a "…

It turns out that in this day and age, desktop users much prefer pixel-perfect tear-free rendering to network transparency. Wayland is X11 without the legacy cruft -- and it turns out that the only thing left in X11 that's not legacy cruft -- like seriously, bleeding-edge tech for 1986 -- is a centralized way to hand out direct-rendering frame buffers to user processes and composite them together for the final image.…

"It turns out that in this day and age, desktop users much prefer pixel-perfect tear-free rendering to network transparency."

People keep telling me that.

Re: “DBus is seriously screwed up”

#205

Post by mburns »

mcguire wrote: post #201
mburns wrote: post #48

Earlier quoted context omitted.

because they want the square hole for a reason, the square hole being a unified in-kernel IPC system. Greg KH has given a few talks/blogs about the design goals of kdbus. https://lwn.net/Articles/551969/

" because they want the square hole for a reason, the square hole being a unified in-kernel IPC system. " Another one?

No, a first one. The others aren't unified, they are niche solutions. Those specific shortcomings are covered in those KDBus talks.

If the existing solutions were sufficient, why would the 'new' way ever get merged into mainline?

Re: “DBus is seriously screwed up”

#206

Post by FeepingCreature »

DannyBee wrote: post #184
FeepingCreature wrote: post #83

Earlier quoted context omitted.

Somebody should modify perf to log "time spent in call", "time spent in stackframe setup", "time spent in mov", "time spent in branches", etc.

So, you can get some of these kinds of cycle counts by changing the event that gets used for record. https://perf.wiki.kernel.org/index.php/Tutorial#Events So you could use record -e branch_instructions, for example. Past that, things like "time spent in stackframe setup" is not sane to measure on an optimized binary, because the instructions hat set up the stack frame may be all over the place (due to shrink wrappin…

> Past that, things like "time spent in stackframe setup" is not sane to measure on an optimized binary, because the instructions hat set up the stack frame may be all over the place (due to shrink wrapping, etc).

Doesn't debug info already account for stuff like this? So we can give line number info if you break on any instruction? Seems to me you'd "just" need to augment debug info with performance classes, then let the profiler display worry about classification after the fact.

Re: “DBus is seriously screwed up”

#207

Post by fulafel »

bitwize wrote: post #203
mcguire wrote: post #200

Earlier quoted context omitted.

Ah, Wayland. Yet another example of the successor to a system being less capable than the system it replaces. " Wayland does not currently provide network transparency, but it may in the future. It was attempted as a Google Summer of Code project in 2011, but was not successful. Adam Jackson has envisioned providing remote access to a Wayland application by either 'pixel-scraping' (like VNC) or getting it to send a "…

It turns out that in this day and age, desktop users much prefer pixel-perfect tear-free rendering to network transparency. Wayland is X11 without the legacy cruft -- and it turns out that the only thing left in X11 that's not legacy cruft -- like seriously, bleeding-edge tech for 1986 -- is a centralized way to hand out direct-rendering frame buffers to user processes and composite them together for the final image.…

Why do you say X has tearing and pixel errors?

I know some hardware (eg. nvidia optimus) have tearing but these are driver bugs and not a property of X (or freedesktop's implementation thereof).

Re: “DBus is seriously screwed up”

#208

Post by bitwize »

fulafel wrote: post #207
bitwize wrote: post #203

Earlier quoted context omitted.

It turns out that in this day and age, desktop users much prefer pixel-perfect tear-free rendering to network transparency. Wayland is X11 without the legacy cruft -- and it turns out that the only thing left in X11 that's not legacy cruft -- like seriously, bleeding-edge tech for 1986 -- is a centralized way to hand out direct-rendering frame buffers to user processes and composite them together for the final image.…

Why do you say X has tearing and pixel errors? I know some hardware (eg. nvidia optimus) have tearing but these are driver bugs and not a property of X (or freedesktop's implementation thereof).

It's historically been basically impossible to guarantee a tear- or glitch-free display under X because it was impossible in the protocol to sync display updates to vblank.

The XPresent extension may ameliorate this, but adding yet another extension to a protocol already lousy with them, such that they have to be tested for at runtime, is pretty much polishing a turd at this point. Starting from scratch is the correct approach and even the X.Org foundation advocates Wayland as X's replacement.

Re: “DBus is seriously screwed up”

#209

Post by byuu »

coldtea wrote: post #202
jude- wrote: post #189

Earlier quoted context omitted.

I think what you're looking for is API standardization? If so, dbus does nothing more to help you than POSIX IPC, since each dbus-speaking application can define arbitrary methods with arbitrary signatures and arbitrary side-effects. Dbus is basically a way to do library calls across address spaces--it doesn't help me write programs that are loosely-coupled to one another.

No, looking for a standard message bus that works across applications. I don't mind that "each dbus-speaking application can define arbitrary methods with arbitrary signatures and arbitrary side-effects", as that's the whole point.

If you don't know the API the application uses, you can't speak with it anyway. D-bus or not. If you want to talk to an entirely separate application, use a header for that application with its IPC/RPC functions defined in it. That's the same thing you'd do with or without D-bus.

All D-bus gets you is an official version of the header I spoke of. Along with so much overhead that you can't use it for any kind of media streaming, apparently. And now they want kdbus; and I definitely don't want their code in my BSD kernel.

Post reply on HN