Announcement

Collapse
No announcement yet.

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

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

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

    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

  • #2
    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.

    Comment


    • #3
      Originally posted by Candy View Post
      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.

      Comment


      • #4
        Originally posted by Candy View Post
        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.

        Comment


        • #5
          Originally posted by mskarbek View Post

          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.

          Comment


          • #6
            Originally posted by hreindl View Post

            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.

            Comment


            • #7
              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.

              Comment


              • #8
                Originally posted by Candy View Post
                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.

                Comment


                • #9
                  dbus-broker depends on systemd libraries (for sd-bus, etc) which are also provided by the elogind project. Otherwise, it only depends on systemd itself through the org.freedesktop.systemd1.Manager interface for starting bus-activatable units.

                  It shouldn't be difficult to adapt to non-systemd systems.

                  Comment


                  • #10
                    Originally posted by hreindl View Post

                    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
                    Are you trying to prove to the rest of us just how hateful you can be?

                    It sounds like you believe in "free choice" so long as that "choice" agrees with your views. Again, you sound very hateful of others, and that is sad.

                    Comment

                    Working...
                    X