3 ms·

Look, you're a smart and accomplished person and you have some developed ideas of how thing should be done, please don't hate on other open source developers or

Look, you're a smart and accomplished person and you have some developed ideas of how thing should be done, please don't hate on other open source developers or accuse them of being "idiots" or "CADT" when you yourself acknowledge that you don't fully understand their work. If you have an idea you think is better then you can just do it, you don't need to trash talk other people's work and use insults like "attention deficit teenager" to get your point across. If you want your X programs to continue working, you don't need to write a Wayland compositor, you can just keep using X. The only reason to write a Wayland compositor would be if you wanted to use Wayland clients, which would not have access to any of the X protocol features anyway. If you don't care about policies then all those things in X can be a good thing, but if you do care about policies then Wayland could allow for a better design, at least it seems that's what GNOME and KDE are aiming for anyway since their policies are very well established at this point, and they don't really seem to care about breaking ICCCM and other such things. As for dbus, your solutions would work for some things, but would not have exactly the same semantics as dbus and would come with their own set of issues, and requires building several more infrastructure pieces, some of which you just described. You could build those but it likely wouldn't fit the same use cases as dbus. If you're sending messages that you expect other clients to parse then you still need to agree on a wire format and marshaling library, you can't get around that. If you ask me dbus itself doesn't require much infrastructure at all, you should consider reading the source code for the dbus reference implementation at some point because it's actually pretty small and stable. And I don't understand what you mean by re-implement POSIX IPC analogues, dbus is essentially just a wire format for Unix domain sockets and a message bus that routes the messages, it doesn't re-implement anything. If you want to use dbus from shell scripts, you can use tools like dbus-send and busctl, or you can try to use something like that dbus fuse filesystem -- the nature of dbus makes it map pretty well to that, there's no reason you can't have both a message bus and an easy interface to access from shell scripts. (Also just another nitpick here, the systemd developers are not the dbus developers, and systemd-logind doesn't take over the init process, that is its own smaller daemon) If you want to read more, see some comments from the original dbus author: https://news.ycombinator.com/item?id=8649459 https://news.ycombinator.com/item?id=8649459 https://news.ycombinator.com/item?id=8648995 https://news.ycombinator.com/item?id=8648995

jude- 6y ago
Can you think of even a single thing dbus can do that my approach cannot do? Emphasis on cannot here -- if you do reply to this, I expect you to prove that the thing cannot be done by any simpler means. If not, then why does dbus need to exist? Better question -- why are people who insist on writing software that doesn't need to exist given decision-making powers in fd.o? Software is like a form of pollution -- more code means more bugs and more security holes (and dbus isn't immune [1]). Any greenhorn developer can write lots and lots of code; it takes wisdom and experience to avoid writing code. So if people who don't grok this are running fd.o, why should I trust anything fd.o produces? Before you try and tone-police the above, you should know that it is fd.o that needs to convince me to venerate their software artifacts. People writing more code isn't by itself praiseworthy -- code is a goddamn liability, so it had better have a good reason to exist and (in dbus's case) have a very good reason to be widely depended-on. Just because you happen to like or use someone's code doesn't mean that it is any good. > And I don't understand what you mean by re-implement POSIX IPC analogues, dbus is essentially just a wire format for Unix domain sockets and a message bus that routes the messages, it doesn't re-implement anything. I guess if you didn't understand POSIX IPC, you wouldn't see how this sentence is an oxymoron. The kernel itself gives you all the trappings of a message bus for free. You don't need a wholly-separate daemon and wire format spec. Also, the only people who seem to use dbus's wire format are dbus clients. Even when dbus was new, there were already widely-used and well-understood formats for representing structured data (e.g. ASN.1, typed netstrings, S-expressions) that could have been leveraged to make interacting with the service that much more straightforward. But then again, we're talking about people who wanted to re-invent POSIX IPC, so I guess I shouldn't be surprised they also wanted to impose their own wire format on the world. > If you don't care about policies then all those things in X can be a good thing I know better than anyone else on Earth what graphical policies are good for me, so I'm going to take this as your affirmation that X is indeed the right tool for the job for people like me who know what they want out of their computers. I stopped using DEs years ago because I got tired of having to fight them all the time to get them to do the things I needed. [1] https://security-tracker.debian.org/tracker/source-package/dbus https://security-tracker.debian.org/tracker/source-package/d...
- cycloptic 6y ago

jude- 6y ago

Can you think of even a single thing dbus can do that my approach cannot do? Emphasis on cannot here -- if you do reply to this, I expect you to prove that the thing cannot be done by any simpler means. If not, then why does dbus need to exist? Better question -- why are people who insist on writing software that doesn't need to exist given decision-making powers in fd.o? Software is like a form of pollution -- more code means more bugs and more security holes (and dbus isn't immune [1]). Any greenhorn developer can write lots and lots of code; it takes wisdom and experience to avoid writing code. So if people who don't grok this are running fd.o, why should I trust anything fd.o produces? Before you try and tone-police the above, you should know that it is fd.o that needs to convince me to venerate their software artifacts. People writing more code isn't by itself praiseworthy -- code is a goddamn liability, so it had better have a good reason to exist and (in dbus's case) have a very good reason to be widely depended-on. Just because you happen to like or use someone's code doesn't mean that it is any good. > And I don't understand what you mean by re-implement POSIX IPC analogues, dbus is essentially just a wire format for Unix domain sockets and a message bus that routes the messages, it doesn't re-implement anything. I guess if you didn't understand POSIX IPC, you wouldn't see how this sentence is an oxymoron. The kernel itself gives you all the trappings of a message bus for free. You don't need a wholly-separate daemon and wire format spec. Also, the only people who seem to use dbus's wire format are dbus clients. Even when dbus was new, there were already widely-used and well-understood formats for representing structured data (e.g. ASN.1, typed netstrings, S-expressions) that could have been leveraged to make interacting with the service that much more straightforward. But then again, we're talking about people who wanted to re-invent POSIX IPC, so I guess I shouldn't be surprised they also wanted to impose their own wire format on the world. > If you don't care about policies then all those things in X can be a good thing I know better than anyone else on Earth what graphical policies are good for me, so I'm going to take this as your affirmation that X is indeed the right tool for the job for people like me who know what they want out of their computers. I stopped using DEs years ago because I got tired of having to fight them all the time to get them to do the things I needed. [1] https://security-tracker.debian.org/tracker/source-package/dbus https://security-tracker.debian.org/tracker/source-package/d...

cycloptic 6y ago