Announcement

Collapse
No announcement yet.

BUS1 Is Working On A D-Bus Broker

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

  • #31
    Originally posted by eigenlambda View Post
    The difference between systemd and the old way of doing things is performance benefits which are presumably important to someone - certainly not to desktop users - but now systemd includes a bunch of reimplementations of daemons that I used to know what they did, who implemented them, and most importantly, what protocols they used, how to configure them, and what they could be expected to do.
    That the systemd project now also includes dns-cache, ntp-client and some other daemons does not mean that you have to use any of them. They are implemented because #1 in order to provide a common toolset (as in available daemons and not as in "forced to use") among distributions and #2 in order to make life easier for people using containers.

    Why care that there might be a small daemon installed that can work as a local dns resolver when #1 it's disabled by default, and #2 if not you can disable it "systemctl disable <x>" and "apt install" / "yum install" the daemon that you are used to. Myself I use systemd everywhere but prefer i.e chronyd over systemd-timesync so that is what I use on all our servers.

    Comment


    • #32
      Originally posted by bregma View Post
      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 [...]
      II just followed the link in the article and it gave Apache 2.0 License, this seems to indicate it's userspace It also looks like a strange choice by RedHat(?) to me, as that license is compatible to GPLv3 but not GPLv2 - why not go for GPLv2+? OK, if it is a standalone daemon, the license is "irrelevant" as long as it is open source, but in case it's a library that would be a problem.

      Comment


      • #33
        Originally posted by W.Irrkopf View Post

        II just followed the link in the article and it gave Apache 2.0 License, this seems to indicate it's userspace It also looks like a strange choice by RedHat(?) to me, as that license is compatible to GPLv3 but not GPLv2 - why not go for GPLv2+? OK, if it is a standalone daemon, the license is "irrelevant" as long as it is open source, but in case it's a library that would be a problem.
        Correct, this is a user-space daemon. Red Hat did not choose the license, apart from (as always) mandating that what we work on must be open source. This will not be a library, but a stand-alone daemon.

        Comment


        • #34
          Originally posted by waxhead View Post

          Can you please link to the bugreport(s)?!
          If this manage to irritate enough people sooner or later it will be fixed either by the systemd guys or someone else.

          I think systemd have lots of benefits, but I am not a fan boy. I dislike that systemd (as a suite) is taking over more and more ,but on the other hand it is not that bad either.
          It's already been fixed... it's just that systemd seems to be in a constant state of "you've tripped over a bug that was discovered recently enough for the fix to still be on its way back down to distro end users."

          ...so my issue is more about what that says about their development methodology and its appropriateness to PID 1 than about any specific set of bugs.

          Comment


          • #35
            Originally posted by ssokolow View Post

            It's already been fixed... it's just that systemd seems to be in a constant state of "you've tripped over a bug that was discovered recently enough for the fix to still be on its way back down to distro end users."

            ...so my issue is more about what that says about their development methodology and its appropriateness to PID 1 than about any specific set of bugs.
            Okay, so it's really just another internets rant about a non-existent bug. That's a relief: we'd worried you'd really upset the apple cart there, for a minute.

            /joke

            Comment


            • #36
              Originally posted by ssokolow View Post

              ... it's just that systemd seems to be in a constant state of "you've tripped over a bug that was discovered recently enough for the fix to still be on its way back down to distro end users."
              Is that the fault of systemd, or is that the fault of the distro maintainers?

              Comment


              • #37
                Originally posted by tomegun View Post

                Correct, this is a user-space daemon.
                That is interesting, do you have any idea of how it is to work with D-bus?

                Comment


                • #38
                  Originally posted by ssokolow View Post

                  It's already been fixed... it's just that systemd seems to be in a constant state of "you've tripped over a bug that was discovered recently enough for the fix to still be on its way back down to distro end users."

                  ...so my issue is more about what that says about their development methodology and its appropriateness to PID 1 than about any specific set of bugs.
                  So your main complaint is that it's actively maintained?

                  Comment


                  • #39
                    Originally posted by Duve View Post

                    That is interesting, do you have any idea of how it is to work with D-bus?
                    Sure.

                    Comment


                    • #40
                      Originally posted by ssokolow View Post
                      It's already been fixed... it's just that systemd seems to be in a constant state of "you've tripped over a bug that was discovered recently enough for the fix to still be on its way back down to distro end users."

                      ...so my issue is more about what that says about their development methodology and its appropriateness to PID 1 than about any specific set of bugs.
                      What that says about their development methodology and its appropriateness to PID1?

                      Because most opensource projects do the same, Linux kernel included.

                      Comment

                      Working...
                      X