Announcement

Collapse
No announcement yet.

BUS1: A New Linux Kernel IPC Bus Being Made By Systemd Developers

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

  • #11
    Originally posted by nslay View Post
    Sure, why not? You've made your own shell, sound API, display server and protocol, your own init system, what harm is there adding yet another non-Unix technology to Linux?
    I dont see any major Unix versions taking the lead either it be servers or desktops. Linux as a kernel and the entire ecosystem tied to it now has a league of its own. I dont see why Linux should compete with any Unix versions out there as long as it keeps its stride.

    Comment


    • #12
      Originally posted by sarfarazahmad View Post
      I dont see any major Unix versions taking the lead either it be servers or desktops. Linux as a kernel and the entire ecosystem tied to it now has a league of its own. I dont see why Linux should compete with any Unix versions out there as long as it keeps its stride.
      It is competing with Unix-like systems by embracing Unix, extending it, and then extinguishing it. It's becoming so different that even applications like NetworkManager are literally impossible to port to other Unix-like systems (not a hyperbole). And even many large software projects have entire OS-specific teams dedicated to removing all the stupid Linuxisms developers put in the code.

      It's in a league of its own because it's not Unix anymore. And making your own non-standard IPC will ensure future applications written for Linux will never work on anything but Linux. It was more sensible for systemd developers to try to base their work off of DBUS.

      Comment


      • #13
        Originally posted by Naib View Post
        Why not just use TIPC... It's in-kernel now
        Yes, I agree. I don't understand why the systemd team is going about reinventing the wheel here. There is a capible, well tested, kernel IPC bus already in the kernel, USE IT.

        To me this just seems like NIH syndrome, further proving the ridiculous ego some members of the systemd team have.

        Comment


        • #14
          Originally posted by dangerousHobo View Post

          Yes, I agree. I don't understand why the systemd team is going about reinventing the wheel here. There is a capible, well tested, kernel IPC bus already in the kernel, USE IT.

          To me this just seems like NIH syndrome, further proving the ridiculous ego some members of the systemd team have.
          yep
          even more so considering that for all their needs UDS is just fine

          Comment


          • #15
            Originally posted by nslay View Post

            It is competing with Unix-like systems by embracing Unix, extending it, and then extinguishing it. It's becoming so different that even applications like NetworkManager are literally impossible to port to other Unix-like systems (not a hyperbole). And even many large software projects have entire OS-specific teams dedicated to removing all the stupid Linuxisms developers put in the code.

            It's in a league of its own because it's not Unix anymore. And making your own non-standard IPC will ensure future applications written for Linux will never work on anything but Linux. It was more sensible for systemd developers to try to base their work off of DBUS.
            When has Linux ever been a Unix kernel?

            Comment


            • #16
              Well, i was worried all systemd haters were gone, it was weird seeing phoronix forum's without the usual classy astroturfing from systemd haters.

              1.) this project is not an internal fight between systemd developers, is simply 2 approaches on the same problem(probably a third could come, so you have something to look forward to astroturf in the future) since an effective IPC system is hard to come by, this diversity is very good.

              a.) KDBUS: as drop in replacement as possible to current DBUS to make user space developers life easier but so far proven too hard and is too verbose.
              b.) BUS1: close enough to DBUS but is not even targeting user space compatibility with current DBUS. promise to be leaner but will require migration on user space apps.
              c.) KDBUS+ or something: could target a middle point between the first two.

              2.) To all the UNIX whiners, UNIX died in the 90's and linux had nothing to do with it, Unix was killed by this backward mentality and the few developers left trying to do something with the old bones of Unix can't even agree between themselves. Probably the only Unix group trying to break free of this mentality and look a bit into the future were Sun Solaris and now FreeBSD

              a.) Not even all BSD's share code between themselves and in some cases need "Porting", Awesome
              b.) UFS still exists, i mean linux have its issues with too much filesystems but UFS come on, Hammer promises but is DragonFly only so far, Hammer2 looks decent on paper but its development speed is only second to Hurd, ZFS is kinda only for FreeBSD, Opensolaris survivors as far as i know
              c.) Graphics is a bigger mess that was ever on linux, some BSD still use mergeFB, some have some intel DRM, some have some Radeon one, some work with nVidia's others not, obviously awesome
              d.) Some BSD got SMP support in the last 2 years WWWWOOOWWWW and some even got SATA support OMG.
              e.) No BSD community ever has ever ported software to Linux, Linux developers pick the code of port it themselves, so why in the fragging hell BSD devs can't??????

              Sure i agree BSD has some cool technologies and useful features but don't come and make it sound like BSD is better than linux and is dead because some astroturf Linux conspiracy theory when is not true at all

              3.) We are in the 21st century, is been long gone the 80's people, we don't have use anymore for text passing IPC we need structured complex data passing systems with with marshalling and proper binding types and a fragging API, for passing text around and polling them Pipes and Sockets/ poll combo are enough.

              Try to think a bit ahead instead of look only backwards

              Comment


              • #17
                Originally posted by jrch2k8 View Post
                a.) Not even all BSD's share code between themselves and in some cases need "Porting", Awesome
                b.) UFS still exists, i mean linux have its issues with too much filesystems but UFS come on, Hammer promises but is DragonFly only so far, Hammer2 looks decent on paper but its development speed is only second to Hurd, ZFS is kinda only for FreeBSD, Opensolaris survivors as far as i know
                c.) Graphics is a bigger mess that was ever on linux, some BSD still use mergeFB, some have some intel DRM, some have some Radeon one, some work with nVidia's others not, obviously awesome
                d.) Some BSD got SMP support in the last 2 years WWWWOOOWWWW and some even got SATA support OMG.
                e.) No BSD community ever has ever ported software to Linux, Linux developers pick the code of port it themselves, so why in the fragging hell BSD devs can't??????

                3.) We are in the 21st century, is been long gone the 80's people, we don't have use anymore for text passing IPC we need structured complex data passing systems with with marshalling and proper binding types and a fragging API, for passing text around and polling them Pipes and Sockets/ poll combo are enough.
                Try to think a bit ahead instead of look only backwards
                a) all native things need to be ported against another platform, this is obvious.
                b) i really don't understand why Linux does not use XFS as default.
                c) this is true.
                d) i think the SATA case was political.
                e) completely false, mostly BSD things are made to work on System V and Linux, Linux is the only one wanting fuck the others. look the relaunchd project as example, ZFS, stated, tcp/ip implementation, bhyve, cloudabi and others i don't remember.

                it's not about look only backward, it's about software quality. you can do whatever complex thing you want, but keep it simple, stupid!

                Comment


                • #18
                  Originally posted by Dharc View Post

                  a) all native things need to be ported against another platform, this is obvious.
                  b) i really don't understand why Linux does not use XFS as default.
                  c) this is true.
                  d) i think the SATA case was political.
                  e) completely false, mostly BSD things are made to work on System V and Linux, Linux is the only one wanting fuck the others. look the relaunchd project as example, ZFS, stated, tcp/ip implementation, bhyve, cloudabi and others i don't remember.

                  it's not about look only backward, it's about software quality. you can do whatever complex thing you want, but keep it simple, stupid!
                  a.) i meant here between BSD's, i get solaris, SCO, Caldera, Irix, HP unix kernels are different enough to need porting. All BSD systems have a turf war to decide which one is the truer BSD and ended somewhat incompatible with each other(OpenBSD, FreeBSD, NetBSD, DragonFlyBSD, etc) to the point each BSD offer a random selection of features which several are unique to each.
                  b.) i agree here, the last revamp was awesome
                  d.) yep, still sata support among BSDs is a shooting gallery even this days
                  e.) nope, BSD internal are not compatible with linux at all, all pure BSD software require a linux layer to compile and in many case an ABI breaks and this is done by linux developers(mostly) not BSD ones, even cases like OpenSSH(originally for OpenBSD) require checks for other BSDs and even FreeBSD has to make their own openssh implementation like linux did

                  1.) ZFS require an extensive translation layer to work on linux (SPL)
                  2.) tcp/ip implementation is close enough but is not the Unix one internally
                  3.) bhyve don't compile or run on linux but can run a linux Guest as any other Hypervisor, otherwise is market dead
                  4.) cloudabi is focused on cloud hence linux support is a must but ok i give you this one
                  5.) stated and relaunch can't even find them on Arch/gentoo repos, so I'm not sure here

                  Comment


                  • #19
                    Originally posted by nslay View Post
                    It's in a league of its own because it's not Unix anymore.
                    Linux stands for Linux Is Not UNIX. Because it's not UNIX.

                    Comment


                    • #20
                      Oh, I'm sorry, did I say "UNIX(tm)"? Or "Unix" which everyone understands means Unix-like? Two of you deserve to be called names and laughed at.

                      Half the stuff in this thread about BSD is a bunch of misinformation. To put it nicely...

                      And to remind you, Unix culture has always embraced simplicity, portability and standards. Linux has been increasingly deviating from this thinking over the past decade. Creating a brand new IPC for Linux is just more deviation from that sort of thinking.

                      And there's a difference between between annotating small pieces of code with C preprocessors for different platforms and having to rewrite large chunks of it (or all of it).

                      Comment

                      Working...
                      X