Dbus Broker 17 Released - No Longer Depends On Glib, Better Isolation With Systemd

[phoronix]

Phoronix: Dbus Broker 17 Released - No Longer Depends On Glib, Better Isolation With Systemd

Red Hat's systemd team who also work on BUS1 and D-Bus Broker announced a new version of Dbus-Broker to kick off 2019...

http://www.phoronix.com/scan.php?pag...er-17-Released

[Candy]

Better Isolation With Systemd

Is this sentence equal to:
The new dbus broker is mandatory linked to systemd. It's not breakable, not splitable and will be enforced to everyones throath during 2019 ?
Please correct me if I am wrong.

[tildearrow]

Is this sentence equal to:
The new dbus broker is mandatory linked to systemd. It's not breakable, not splitable and will be enforced to everyones throath during 2019 ?
Please correct me if I am wrong.

It is breakable but hasn't been done.

[mskarbek]

Is this sentence equal to:
The new dbus broker is mandatory linked to systemd. It's not breakable, not splitable and will be enforced to everyones throath during 2019 ?
Please correct me if I am wrong.

Nobody will enforce anything on you, you can happily still use dbus-daemon with whatever init you want.

[nanonyme]

Nobody will enforce anything on you, you can happily still use dbus-daemon with whatever init you want.

Iirc dbus-broker and dbus-daemon had subtly different guarantees in corner-cases of Dbus so that may start hurting if we don't manage to move everyone away from dbus-daemon.

[hreindl]

Is this sentence equal to:
The new dbus broker is mandatory linked to systemd. It's not breakable, not splitable and will be enforced to everyones throath during 2019 ?
Please correct me if I am wrong.

so what?

sounds like https://devuan.org/ don't work that well, likely because just a few clowns don't realize that there is no point in continue with old-style initscripts and even if you can take enough other clowns to make it happen but leave the rest of the world in peace - everybody else benefis from the use of cgroups and namespaces

[malkavian]

so what?

sounds like https://devuan.org/ don't work that well, likely because just a few clowns don't realize that there is no point in continue with old-style initscripts and even if you can take enough other clowns to make it happen but leave the rest of the world in peace - everybody else benefis from the use of cgroups and namespaces

Sorry for harrasing you with my liberty of choice, but systemd fucked my system a lot of times and I am happier with OpenRC since then. Maybe when they stop adding features to systemd and worry more about solving bugs, could be used again. I won't even try it for some time by now. Be happy.

[hreindl]

Sorry for harrasing you with my liberty of choice, but systemd fucked my system a lot of times and I am happier with OpenRC since then. Maybe when they stop adding features to systemd and worry more about solving bugs, could be used again. I won't even try it for some time by now. Be happy.

no idea what you are doing wrong but i run 40 systems with systemd for 7 years now and it never fucked up any of them, it solved only a ton of issues with crappy initscripts from their proper ordering to missing snippets for customization and introduced a ton of easy to use security features and monitoring capabilities

addditionally early boot logging, services/initscripts stip stuff to stdout get logged proerply , no longer leftover process at restart/stop of services and so on

nobody is touching your liberty of choice, if nobody out there want to maintain things the way you like you are free to change it at your own or pay someone

[Girolamo_Cavazzoni]

For me as an end user a good init system stays as long out of my way as I don't want to mess around with it - and when I want to do that is has to be comfortable. Systemd has served me well in this regard for some years now, but I either didn't have problems with Runit from Void Linux (for a very short period of time in which I used that, I admit).

In the same manner dbus-broker served me well. It has just stayed quiet and dicrete from the day I swapped it with dbus-daemon.

[tomegun]

Is this sentence equal to:
The new dbus broker is mandatory linked to systemd. It's not breakable, not splitable and will be enforced to everyones throath during 2019 ?
Please correct me if I am wrong.

You are wrong. If you had followed the link to the announcement, that would have been obvious.

The meaning is that when systemd launches dbus-broker, it is now doing so with more sandboxing features than before. It does not at all change the coupling between systemd and dbus-broker.

systemd depends on a dbus implementation, but not a specific one. dbus-broker must be integrated with the init system (to launch services using name activation), currently only systemd integration exists, but there is nothing stopping anyone from integrating with other init systems.