Announcement

Collapse
No announcement yet.

KDBUS Won't Be Pushed Until The Linux 4.3 Kernel

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

  • KDBUS Won't Be Pushed Until The Linux 4.3 Kernel

    Phoronix: KDBUS Won't Be Pushed Until The Linux 4.3 Kernel

    KDBUS was once again heavily debated on the Linux kernel mailing list this week and Linus Torvalds said he looked forward to merging it when ready (and also had some choice words about performance). However, Greg KH has confirmed today that KDBUS isn't ready for merging this cycle...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    I think their asking distros to test this is a great idea. If it's in the official kernel, it can't change too significantly, that's the professional promise being in the kernel entails. However if distros and users can decide to use it and get wide feedback, then it will have the time and testing needed to know when its *design* is hardened enough to rarely change again.

    Comment


    • #3
      D-Bus seems really dumb and complicated.

      Just use Plumber, the IPC system from Plan 9 from Bell Labs (aka Unix 2.0).
      Then any application can easily use IPC by just reading or writing to a virtual file on the file system.
      Dead easy, no special APIs, just plain virtual files that can be used by sh, Python, Ruby, Perl, or whatever!

      Comment


      • #4
        Good, good, let the optimizations flow through you!

        Comment


        • #5
          Originally posted by uid313 View Post
          D-Bus seems really dumb and complicated.

          Just use Plumber, the IPC system from Plan 9 from Bell Labs (aka Unix 2.0).
          Then any application can easily use IPC by just reading or writing to a virtual file on the file system.
          Dead easy, no special APIs, just plain virtual files that can be used by sh, Python, Ruby, Perl, or whatever!
          I'm looking forward to seeing your pull request.

          Comment


          • #6
            Originally posted by uid313 View Post
            D-Bus seems really dumb and complicated.

            Just use Plumber, the IPC system from Plan 9 from Bell Labs (aka Unix 2.0).
            Then any application can easily use IPC by just reading or writing to a virtual file on the file system.
            Dead easy, no special APIs, just plain virtual files that can be used by sh, Python, Ruby, Perl, or whatever!
            How do they do access control? If it's only via posix file access rights, then it's way to coarse.

            Also, do they have a protocol for writing and reading to/from those files?

            Comment


            • #7
              Originally posted by uid313 View Post
              D-Bus seems really dumb and complicated.

              Just use Plumber, the IPC system from Plan 9 from Bell Labs (aka Unix 2.0).
              Then any application can easily use IPC by just reading or writing to a virtual file on the file system.
              Dead easy, no special APIs, just plain virtual files that can be used by sh, Python, Ruby, Perl, or whatever!
              Yes, please go and rewrite all the already working linux desktop environments and software so that they use your unimpemented ipc.
              As a developer I don't want to parse fucking text messages for my IPC, I want to do fucking method calls.
              Last edited by doom_Oo7; 26 June 2015, 06:17 PM.

              Comment


              • #8
                Originally posted by doom_Oo7 View Post
                As a developer I don't want to parse fucking text messages for my IPC, I want to do fucking method calls.
                ...or, at the very least, have enforced standardization on the data format so the library can handle serialization/deserialization of something "JSON or better". (D-Bus qualifies, since it's got a type system that's a superset of what JSON offers.)

                Serialization and deserialization is one of the most important pieces of drudgework to have automated when you want to write IPC-using code productively.

                ...and, once you've got that, RPC is a trivial leap since it's just structured messages that both endpoints agree on special behaviour for.
                Last edited by ssokolow; 26 June 2015, 07:24 PM.

                Comment


                • #9
                  Originally posted by uid313 View Post
                  D-Bus seems really dumb and complicated.

                  Just use Plumber, the IPC system from Plan 9 from Bell Labs (aka Unix 2.0).
                  Then any application can easily use IPC by just reading or writing to a virtual file on the file system.
                  Dead easy, no special APIs, just plain virtual files that can be used by sh, Python, Ruby, Perl, or whatever!
                  This is one of those thought-trains that seem simple and straight forward in theory, but once you get down to implement it, you get cut by 1000 corner cases and complications, until you realize you actually had no idea about the problem case at all.

                  Comment


                  • #10
                    Originally posted by uid313 View Post
                    D-Bus seems really dumb and complicated.

                    Just use Plumber, the IPC system from Plan 9 from Bell Labs (aka Unix 2.0).
                    Then any application can easily use IPC by just reading or writing to a virtual file on the file system.
                    Dead easy, no special APIs, just plain virtual files that can be used by sh, Python, Ruby, Perl, or whatever!
                    Agreed, the IPC protocols need to be kept simple yet secure and the only API should consist of read, write calls, along with a simple message passing protocol that's solid and secure. Why junk up something as important as the kernel with overly complicated IPC mechanisms when the old-style IPC (with some modernization) "just works".

                    Not to start a flamewar here but systemd is just as bad for being a complicated and overthought init system when SystemV has worked well for ages. Seems that keeping it simple (yet secure, I may add) has gone by the wayside.

                    Comment

                    Working...
                    X