BUS1 Is Working On A D-Bus Broker

[phoronix]

Phoronix: BUS1 Is Working On A D-Bus Broker

BUS1 remains in-development as an in-kernel IPC mechanism and the spiritual successor to the never-merged KDBUS...

http://www.phoronix.com/scan.php?page=news_item&px=BUS1-dbus-broker

[Azrael5]

a further failure.

[TumultuousUnicorn]

Will be BUS1 merged one day? It looks like the KDBUS story.

[tildearrow]

So BUS1 just becomes a second KDBUS. Uhhh, Linus, don't merge this.

[Brane215]

a further failure.

Why do you deem it to be a failure ?
To me , this seems like a good thing. They have spinned a couple of cycles, trying to ties things up on all levels and make sure whole thing is technically sound, before presenting it to public by going for kernel inclusion.

[Azrael5]

Why do you deem it to be a failure ?
To me , this seems like a good thing. They have spinned a couple of cycles, trying to ties things up on all levels and make sure whole thing is technically sound, before presenting it to public by going for kernel inclusion.

simple: because otherwise they would have already reached the aim. bus1 is another failure.

[pal666]

simple: because otherwise they would have already reached the aim

do you have anything to back up this random assertion?

[AsuMagic]

simple: because otherwise they would have already reached the aim. bus1 is another failure.

I love how your argument applies on literally anything. Try again.

[bregma]

Well, there isn't an awful lot of there there, but if this is just a userland layer sitting on top of BUS1 (maybe to replace dbus-daemon), I don't imagine there being much problem.

On the other hand, if this is intended to act as an in-kernel D-Bus broker, I can see it spawning controversy. One the one hand the advantage of fewer context switches and the possibility of better authorization. On the other hand is the philosophy that the kernel should be minimal and if it can be in userspace, it should be, and the problem of continuing kernel bloat. On the gripping hand, it could be a backdoor for serious kernel exploits.

I'm reserving judgement on this until we know what it actually is, and until then I'll trust Linus to the the right thing.

[notanoob]

Roll call for all haters. Please speak up now so we can laugh at you when you soon use bus1 and the dbus-broker to get a faster and more secure userland.

Just like you use systemd and wayland today.

You do realize that there are distro's that offer another choice than systemd and wayland. Now I do not see why anyone would want to switch back to xorg because of speed, security, and features(eventually). Using sway today and you have a more secure and faster DE than lxde or xfce.

But systemd is a overreaching peice of poorly written software that does many jobs not in the description of "initialization system" it is more likend to "control everything system". That is fine if it floats your boat but it is not the only option. Also bus1 is of debatable usage anyways.

Why do you need ipc? Especially why do you need it in the kernel? I can tell you that IPC in android is used mainly by google for determining when to render and remove rendered stuff and by hackers for exploits. It is buggy in android and serves little good outside of rendering order. Wayland already has ipc for rendering order and the linux kernel also has ipc from systemv and a form to itself for whatever data transfer your heart desires.

Also getting to the heart of the problem is that many servers do not need another ipc for their programs as they already use systemv ipc which works fine.