Announcement

Collapse
No announcement yet.

It Doesn't Look Like KDBUS Will Make It For Linux 4.1

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

  • #41
    Originally posted by TheBlackCat View Post
    Learn what ad hominem means. Pointing out that you were lying about what they said is not an ad hominem. Whether you agree with their reasons or not, they still gave them, despite your repeated assertion that they didn't.


    Please read the explanation in the thread. Currently dbus cannot guarantee passed buffers are not altered by the sender while being read. kdbus can.


    *sigh* Again, please read the explanation in the thread. They give an example, "exit-on-idle", which cannot be done safely in userspace.


    The fact that you don't want to use it doesn't make it "bullshit". Yeah, we got it, you don't like systemd. But until your magical systemd replacement is released, a lot of people are using systemd.


    Simply false.




    Yeah, great, lets have several completely different ways to do similar things. That is a great way to make software more reliable and less buggy.


    No, it wasn't. There was a discussion about whether it was as easy as it could be, but it is still easier than what is currently the case with dbus.


    Which was promptly addressed by the devs and ultimately shot down by Linus.


    Who said anything about streaming video? https://plus.google.com/+gregkroahha...ts/bYZxmbNXAZX
    calling someone out as a liar = ad hominem

    "Wayland uses unix sockets for control data, and passes DRM or SHM file-descriptors for buffers. It is trivial to change this to use kdbus for control data."
    passing drm or memfd is faster, more light weight with same security "level"
    just because you *can* do something doesn't mean you should do it

    making kdbus with containers "slighty less awful" then dbus means that it is still awful


    for the rest; you read the thread again as you seem to have missed the things that weren't "debunked"
    you know, the things that were written by people who don't want "dbus in kernel over anything else"

    PS please use the numbering system as it makes reading more condensed and replying much easier, ty

    Comment


    • #42
      Originally posted by gens View Post
      calling someone out as a liar = ad hominem
      No, it simply isn't. If I said you were wrong because you are a liar, that would be an ad hominem. But demonstrating that the evidence shows you were lying is not.

      Originally posted by gens View Post
      "Wayland uses unix sockets for control data, and passes DRM or SHM file-descriptors for buffers. It is trivial to change this to use kdbus for control data."
      passing drm or memfd is faster, more light weight with same security "level"
      It is also much more difficult with things like containers. And you conveniently ignore that memfd was created for kdbus in the first place.

      Originally posted by gens View Post
      making kdbus with containers "slighty less awful" then dbus means that it is still awful
      It is a benefit of kdbus over dbus.

      Originally posted by gens View Post
      for the rest; you read the thread again as you seem to have missed the things that weren't "debunked"
      you know, the things that were written by people who don't want "dbus in kernel over anything else"
      None of the things that I listed were debunked, as I explained, but you ignored. Some people disagreed with some parts, until Havoc came along and explained why they were the way they were. But none of have been debunked, and some of the ones you claim were debunked were explicitly endorsed by Linus.

      Comment


      • #43
        Originally posted by TheBlackCat View Post
        No, it simply isn't. If I said you were wrong because you are a liar, that would be an ad hominem. But demonstrating that the evidence shows you were lying is not.


        It is also much more difficult with things like containers. And you conveniently ignore that memfd was created for kdbus in the first place.


        It is a benefit of kdbus over dbus.


        None of the things that I listed were debunked, as I explained, but you ignored. Some people disagreed with some parts, until Havoc came along and explained why they were the way they were. But none of have been debunked, and some of the ones you claim were debunked were explicitly endorsed by Linus.
        to get down to the same level:
        No, you !

        Comment


        • #44
          Originally posted by mickrussom View Post
          First off - systemd is being handle improperly in general. Somehow an init package is making itself a requirement to run applications which should be cross platform portable - while systemd is linux-only, not portable and breaks *nix philosophy badly.
          IPC should not be cross platform portable. Why would we want applications to be cross platform portable? I want people to use Linux and those that write applications for Linux to be able to easily leverage the capabilities of the Linux kernel.

          As for the Unix philosophy, what was that? Make AT&T rich? Achieve corporate dominance through vendor lock in. The old Unix ecosystem was full of proprietary solutions, but sought to leach off the commons of publicly funded academia. The purpose of Linux is not to worship Unix but to bury it.

          Comment


          • #45
            Originally posted by Rich Oliver View Post
            The purpose of Linux is not to worship Unix but to bury it.
            No... The purpose of Linux is to be a free hobby OS for 386 AT Clones. That it grew beyond it's purpose is typical for a software project to the point where there are many adages about it happening. Now you could say that Red Hat or SUSE's purpose is that, but not Linux itself.
            From: [email protected] (Linus Benedict Torvalds)
            Newsgroups: comp.os.minix
            Subject: What would you like to see most in minix?
            Summary: small poll for my new operating system
            Message-ID: <[email protected]>
            Date: 25 Aug 91 20:57:08 GMT
            Organization: University of Helsinki

            Hello everybody out there using minix –

            I’m doing a (free) operating system (just a hobby, won’t be big and
            professional like gnu) for 386(486) AT clones. This has been brewing
            since april, and is starting to get ready. I’d like any feedback on
            things people like/dislike in minix, as my OS resembles it somewhat
            (same physical layout of the file-system (due to practical reasons)
            among other things).

            I’ve currently ported bash(1.08) and gcc(1.40), and things seem to work.
            This implies that I’ll get something practical within a few months, and
            I’d like to know what features most people would want. Any suggestions
            are welcome, but I won’t promise I’ll implement them :-)

            Linus ([email protected])

            PS. Yes – it’s free of any minix code, and it has a multi-threaded fs.
            It is NOT protable (uses 386 task switching etc), and it probably never
            will support anything other than AT-harddisks, as that’s all I have :-(.
            Last edited by Luke_Wolf; 29 April 2015, 07:01 AM.

            Comment


            • #46
              Originally posted by Rich Oliver View Post
              IPC should not be cross platform portable. Why would we want applications to be cross platform portable? I want people to use Linux and those that write applications for Linux to be able to easily leverage the capabilities of the Linux kernel.

              As for the Unix philosophy, what was that? Make AT&T rich? Achieve corporate dominance through vendor lock in. The old Unix ecosystem was full of proprietary solutions, but sought to leach off the commons of publicly funded academia. The purpose of Linux is not to worship Unix but to bury it.
              I don't really want to trade a walled garden for a different walled garden, thank you. Achieving *whatever* dominance through vendor lock-in is bad for the end-user, because of reduced reuse and reduced competition. It does not matter who does the lock-in or who ends up dominating.
              Now, leveraging platform specific capabilities is good when it's done because they are useful, but doing it to segregate platforms is awful practice.

              Comment

              Working...
              X