Why do we need d-bus?

Jose said:
Why? Cause you lack the skills to do so? So "modern" programmers are incompetent?
Click to expand...
Someone whose expertise is frankly is web programming would know stuff like XSS, session cookies, HTML5, security certs, and headless browsers. They'd be up to date on that topic. Someone whose expertise is frankly databases - they'd know how to create a usable query, how to connect to a database server with one client or another, how to figure out the schema of the tables, the benefits of having a real RDBMS vs using flat files, and how to stay up to date on that. Both would qualify as "Modern Programmers", if they are up to date in their respective areas of expertise. Both would qualify as "Competent Programmers" if they have at least some degree of familiarity with a versioning system like Git, and with chores that programmers have to do like testing the code, making sure it works for the customer, and other stuff I'm not even thinking of right now.

But asking a DBA to analyze a web design - that's asking for trouble. A DBA has enough on his plate making sure the database works, and is up to snuff. They may have no sense of UI design, or what it takes to produce a good UI in a browser. If you lack the resources to hire someone to put a pretty web interface on a database - then the DBA will be tasked with that chore. The results may be workable, but not eye candy that you can proudly display.

The point of my post is that it's OK to not have the expertise to evaluate the design of dBUS. It's just that screaming that 'dBUS has to be changed at the source, look, I'm doing fine without it!' ends up being just noise that gets ignored. This thread is a good place to learn a little about dBUS, but probably not for getting emotional, judgemental, and personal.
 
I suppose I made a mistake by assuming Jose was asking a good-faith question about the definition of "modern" but I'll answer this whataboutism for the people in the back:
You can support old standards and new ones at the same time. Everything has limitations. "Modern" design takes ideas from the past and improves on them. Improved ideas can be implemented badly. Simple primitives does not mean perfect or even easy to use. Just because you can develop a sophisticated IPC mechanism from primitives doesn't mean this is a good use of developer time. Finally: Bespoke IPC is not useful for interoperability since only your programs would be using it.
 
A lot of arguing over what is and isn't "modern". Let me specifically put in my .02 on that. I don't consider "Modern" to be about eye-candy, such as text rendering, or transparency, or superficial things like "snapping".

No, what separates modern from not-modern, and this is no slight against the people who prefer these styles, just a statement of objectivity from this viewpoint (I used to use i3!) is the following to me:

1. Window controls that include a drop-down menu, easily understandable widgets and elements (i.e. does a widget either have a self-explanatory visual or does it have a label that says what it does) and ways to resize and drag the window with the mouse by clicking a border, topbar, or some other part of the window that isn't the actual content of the window, as opposed to more primitive/older tiling, reparenting and nonreparenting window managers.

2. Does the desktop have an easily usable menu that can launch programs, either by clicking on the desktop or on the menu itself?

3. Does the desktop have a way to minimize or get windows out of the way, such as via a taskbar, iconifier, dock etc?

Those are the hallmarks. Not age, not eye candy.

hardworkingnewbie said:
I guess we should come back discussing that point when your idea about "modern DE" is not from the last millenium, and roughly 30 years old.
Click to expand...

See above. IMHO, Windows 2000's UI is no less modern than Windows 10's or macOS's, and avoids many of the flaws of those. I should be able to render a basic desktop with a bottom bargain bin GPU.

msplsh said:
It's a requirement because you are NOT the one implementing the software that uses it. Modern means not banging sticks and rocks using named pipes for IPC and re-implementing object serialization.

I mean, seriously, this is a bunch of whining over nothing. Don't like it, don't use it. Move on with your life. Turn it off if you want to, who cares, it's your machine. Just don't go crying when you can't do something "simple" like drag and drop or handle URLs. Nobody is actually making programming decisions about which IPC to use between differing pieces of software here.
Click to expand...

Sorry to be captain obvious here, but C and UNIX were not designed with objects in mind. If you want that, use IBM i, macOS, or Haiku or something built either in a modern OOP language with actual bindings for those things at the very core level of the OS, or that is designed for object-based programming (as IBM i is)

I'm not gonna argue it's against the UNIX philosophy, but there's a reason people hate stuff like GObject, and disliked Bonobo and DCOP and other stuff that came before dbus. Object models do not belong on UNIX in that manner.

STREAMS is not sticks and rocks. It is point-to-point, but you'll notice it allows for stacks. What does that mean? you can share sockets, drivers, and such between different streams, using a mutex or other means of serializing access between them.

msplsh said:
I suppose I made a mistake by assuming Jose was asking a good-faith question about the definition of "modern" but I'll answer this whataboutism for the people in the back:
You can support old standards and new ones at the same time. Everything has limitations. "Modern" design takes ideas from the past and improves on them. Improved ideas can be implemented badly. Simple primitives does not mean perfect or even easy to use. Just because you can develop a sophisticated IPC mechanism from primitives doesn't mean this is a good use of developer time. Finally: Bespoke IPC is not useful for interoperability since only your programs would be using it.
Click to expand...

Jose is being sarcastic, but not unprofessional. He has his points, and while he's being flippant, you're the only one squawking about how he's in bad faith. If you smelt it, maybe you dealt it, as the saying goes.

But I agree with you. Bespoke IPC is not useful. My argument is FreeBSD, or maybe the BSDs as a whole, should crowd around an alternative to dbus. Clearly, there's security issues, let's not mince words or deny it. Clearly, it's not designed with us in mind. Clearly, it's a bodged together project on non-Linux platforms. Ok, so we've identified the issue. Maybe someone (not myself, because of my position and the fact I'm hated by several openbsd devs for speaking like Theo, which amuses me to no end) should start a dialogue, come up with a reasonable standard. I would propose STREAMS plus a message protocol, and make sure our STREAMS implementation is thread-safe by way of ensuring serialization at every step of the way. For as much as Ritchie hated it, having things like this in kernel DOES have advantages, especially with less context switching.
 
i3wm-- obviously. I was saying that I've used it. I just made the statement that tiling wms are inherently more primitive -- that doesn't make them bad however. Just "older" technology-wise.
 
BSD-Kitsune said:
Sorry to be captain obvious here, but C and UNIX were not designed with objects in mind.
Click to expand...

Yet somehow a company built a very successful desktop and mobile OS on top of it that uses objects everywhere (Apple). You rattled off a bunch of things people "hate" but that have eventually succumbed to the pressure consolidate around a single standard that is now DBus.

BSD-Kitsune said:
But I agree with you. Bespoke IPC is not useful ... crowd around an alternative to dbus.
Click to expand...

1. That's seemingly contradictory
2. Who's going to do it?
3. Once you have it, why would anyone implement it? Particularly if you're anti-objects, why would people working on projects that use DBus to send objects use it? Why would people working on projects that DON'T send objects use something that's "supposed to replace DBus" when they could use older IPC methods?

DBus is not going away and UNIX software is going to target Linux first and FreeBSD if it's easy. If DBus works on Linux just fine and it's terrible on FreeBSD, then it's up to the FreeBSD community to fix DBus. We're not in the drivers seat on this one.
 
I didn't cave to anything so I don't understand why you think that I am against a unified standard. I'm not, but I'm against one that has GNU/Linux at the forefront. Clearly you have different priorities.

As far as macOS goes, significant portions of it were written in objective C and are probably now written in Swift. XNU isn't UNIX, neither is macOS. The open group certifications don't mean anything to me when the entire design philosophy is descended from Mach, not UNIX. No what constitutes Unix in my book is based on lineage and continued usage of the same conventions that were established. Apple has chosen to break with all those and on top of that is neglectful of its open source counterpart Darwin.
 
msplsh said:
I suppose I made a mistake by assuming Jose was asking a good-faith question about the definition of "modern" but I'll answer this whataboutism for the people in the back...
Click to expand...
"Modern" is a word deployed to shut down technical debate. Once something is deemed "modern" it is beyond criticism, and once something is found to be not "modern" it's not worth talking about any more.

What's new is not necessarily good and what's old is not necessarily bad. This much should be obvious, but apparently it still has to be said.

msplsh said:
Similar technologies on these platforms are COM, DDE, WCF, NSNotification, XPC.
Click to expand...
None of those are message buses.

BSD-Kitsune said:
But I agree with you. Bespoke IPC is not useful. My argument is FreeBSD, or maybe the BSDs as a whole, should crowd around an alternative to dbus.
Click to expand...
And yet the two most popular computer desktops of our day do not have a message bus. They're simply not necessary. Heck, Dbus support is at most optional in all the desktop software I want to use. Saddle yourself with that unnecessary Redhat Linux crapware if you like, but don't try to convince me it's indispensable.
 
Jose I think we're on the same side here. What I'm advocating for is a sane alternative. Something that is designed with the constraints in mind and can offer a little bit of what people might be looking for without having to deal with that stupid object model crap that is constantly shut down our throats in the forms of gobject, dbus, etc.

I've stated my piece here but I don't want to start having people pick fights with me just over minor details when we all have the same goal: no dbus, no polkit, no Linux shovelware.
 
BSD-Kitsune said:
I've stated my piece here but I don't want to start having people pick fights with me just over minor details when we all have the same goal: no dbus, no polkit, no Linux shovelware.
Click to expand...
I didn't mean to pick a fight. I'm actually a fan of OOP, but I agree that it's not for everyone.

I don't think that's the biggest problem with Dbus. I'm not sure something like Dbus is actually needed for a desktop. I'm not allergic to message buses, I use and like Kafka at my day job, but I'm not convinced that it's the best design for desktop app intercommunication. I can see the arguments for it, but the fact is some pretty good desktops get along fine without it, and the one implementation we do have is pretty bad.
 
Jose said:
"Modern" is a word deployed to shut down technical debate. Once something is deemed "modern" it is beyond criticism, and once something is found to be not "modern" it's not worth talking about any more.
Click to expand...
Andrew Tanenbaum noted in several of his books that concepts do get recycled. A direct quote from his Modern Operating Systems, Second Edition:
Early computers had hardwired instruction sets. The instructions were executed directly by the hardware and could not be changed. Then came microprogramming, in which an underlying interpreter carried out instructions in the software. Hardware execution became obsolete. Then RISC computers were invented, and microprogramming (i.e., interpreted execution) became obsolete, because direct execution was faster. Now we are seeing a resurgence of interpretation in the form of Java applets that are sent over the Internet and are interpreted upon arrival. Execution speed is not always crucial because network delays are so great they tend to dominate. But that could change, too, some day.
Click to expand...
Things sure did change, with YT. So it's kind of pointless to bash things as "modern" or "not modern". There probably are alternatives to dBUS available. If dBUS was really not needed, then it would not have the critical mass of popularity that is needed to keep it under maintenance and in use (even if some people quibble with implementation details).
 
Goalpost moving on what UNIX is, redefining words, "it doesn't have bus in the name so it can't be achieving the same goals." Ok, whatever, I tried to make this grounded in reality, I'm out.
 
Jose said:
What is Windows' message bus? Apple's?
Click to expand...
As I said, a message bus is one architectural pattern to solve this. There are others of course. Windows uses COM and its descendants heavily. This kind of serves the purpose in allowing cross-process access to objects, decoupling is done by using interfaces only.

For a bit of history, KDE used something very similar, CORBA, in the past. They later decided to drop it and introduced DCOP instead, which was already a message bus/broker architecture (and was then dropped in favor of d-bus, to support a common standard).

IMHO, the message bus architecture is superior to something based on "remote objects". You get the publisher/subscriber mechanism for free, you can easily add queueing, etc...

I have no idea what Apple is doing, I really don't care about their software. Surely, they do something for common communication between many components/processes.
 
I was going to make a point about why there are so many kinds of dbus installs in ports tree. Then, I honestly couldn't make as strong a case as I thought I would, about this particular one.
Code: 
~ % psearch dbus | grep -vi api | grep -vi interface | grep -vi binding
comms/libmodbus           Modbus library
devel/dbus                Message bus system for inter-application communication
devel/dbus-sharp-glib     D-Bus for .NET: GLib integration module
devel/dee                 Model to synchronize multiple instances over DBus
devel/kf5-kdbusaddons     KF5 addons to QtDBus
devel/libdbusmenu         GLib and Gtk Implementation of the DBusMenu protocol
devel/libdbusmenu-qt      Qt5 implementation of the DBusMenu protocol
devel/linux-c7-dbus-libs  Libraries for accessing D-BUS (Linux CentOS 7.9.2009)
devel/ndesk-dbus          C# implementation of D-Bus
devel/ndesk-dbus-glib     GLib main loop integration for Managed D-Bus
devel/p5-AnyEvent-DBus    Seamlessly integrate Net::DBus into AnyEvent
devel/p5-Net-DBus         Perl extension for the DBus message system
devel/py-jeepney          Low-level, pure Python DBus protocol wrapper
devel/py-python-dbusmock  Mock D-Bus objects for tests
devel/py-qt5-dbussupport  Qt event loop support for dbus-python
devel/qt5-dbus            Qt D-Bus inter-process communication module
ports-mgmt/packagekit     DBUS packaging abstraction layer
x11/appmenu-registrar     Appmenu DBusMenu registrar
Perhaps qt5-dbus is better implemented than regular dbus? Now, I don't use Linux emulation on FreeBSD, at least not the way it is now. As if I were going to use it, I would use a separate Linux desktop or hardisk/partition for purposes that I don't use on FreeBSD. However, devel/linux-c7-dbus-libs is ridiculous, that they don't use regular devel/dbus, and build the rest of Linux on FreeBSD on top of those kinds of dependencies. It's redundant. Also, this isn't just dbus, there's lots of duplicates for Linux emulation. It's like riding a bike with no hands, so the person can hold two other bikes, where those two other bikes don't need to go anywhere.

It's missing the point, the reason a lot of people use FreeBSD is because the base system has the essentials about once, and not duplicated 50,000 times. Then, it's like people want to defeat the purpose of having an operating system that's designed well at its base. If there's going to be Linux emulation, shouldn't it be something like Alpine that a lot of people say is good? Then again, the ones using Alpine Linux aren't porting their emulation.
 
BSD-Kitsune said:
C and UNIX were not designed with objects in mind.
Click to expand...
Objects doesn't necessarily mean OOP. You might want to count the usage of the word "object" in the C language standard documents.

sidetone said:
Perhaps qt5-dbus is better implemented than regular dbus?
Click to expand...
This is just Qt's adapter to easily use d-bus. There's only one d-bus.

linux-c7-dbus-libs are also client libraries for using d-bus. A Linux binary can't use a FreeBSD library, the libraries have to be built for Linux as well. So, there's nothing redundant here.
 
I thought they used elf on them. Maybe that was for binaries [, perhaps not relating to libraries]. Even if they could, the actual content, aside from the type of file, must be different enough or different versions.
 
ELF is the binary format. Yes, that's used on both systems. Just the format doesn't make a FreeBSD library compatible with a Linux binary. The FreeBSD kernel exposes a completely different ABI (syscalls) to Linux processes. Trying to use a FreeBSD library from a Linux binary would already fail for that reason, cause it would expect (and not find) the FreeBSD ABI.
 
kpedersen I don't think d-bus is "pointless". Sure, it doesn't have to be a message bus (see above), but there's definitely a need for many peers to communicate without tight coupling in a "desktop" system. I personally think a message bus is well suited to satisfy this need. But, as I said, I can't say anything about the quality of d-bus. I never used it myself (from the programmer's perspective).

edit: Maybe I misunderstood your wording? Did you mean bonobo is "pointless" because d-bus is used now? 😳

edit2: One thing I like about d-bus (although maybe slightly off-topic here) is that it comes with command-line tools, so you can use it from scripting as well. This enabled me to have "shutdown" and "reboot" menu entries using consolekit in my FVWM menu with these commands:
Code: 
DestroyFunc Shutdown
AddToFunc Shutdown
+ I PipeRead 'dbus-send --system --print-reply --dest="org.freedesktop.ConsoleKit" /org/freedesktop/ConsoleKit/Manager org.freedesktop.ConsoleKit.Manager.Stop >/dev/null 2>&1; echo "Quit"'

DestroyFunc Reboot
AddToFunc Reboot
+ I PipeRead 'dbus-send --system --print-reply --dest="org.freedesktop.ConsoleKit" /org/freedesktop/ConsoleKit/Manager org.freedesktop.ConsoleKit.Manager.Restart >/dev/null 2>&1; echo "Quit"'
 
Zirias said:
but there's definitely a need for many peers to communicate without tight coupling in a "desktop" system.

edit: Maybe I misunderstood your wording? Did you mean bonobo is "pointless" because d-bus is used now? 😳
Click to expand...
Well I suppose bonobo *is* pointless now we have dbus but mainly I don't feel that there is such a need for peers to communicate.

Can you suggest any use-cases? The only ones I can (copy/paste, window automation) is handled by X11's Atom message system. For example, why should my calculator app be able to send messages to my file manager? Has anything been done that you can't live without?

As far as my experiences have been, all the broken-ness in the FreeBSD ports of Xfce, KDE and Gnome stem from failed IPC. We should do what the OpenBSD guys do and rip it out of most of the ports and replace it with fake stubs.
 
Zirias said:
I have a few generic ones in my first post to this thread: https://forums.freebsd.org/threads/why-do-we-need-d-bus.78868/post-525052
Click to expand...

Can all of these not be achieved with a suid-exec helper binary with specific groups for the authorized users? Xfce4 used to do this and it honestly worked better than the sudo fallback and then that Polkit crud that it moved to. It really does seem that chmod +s is easier than trying to write a safe / stable message bus.

The window manager and screen locker stuff should almost certainly be X11 messages by definition. Things like xlock / xlockmore seem to work fine. Is there a specific functionality you find is missing that can only be improved with dbus (or other)?

I imagine one valid reason for IPC is because many Wayland compositors fail to support X11 style messages. But... well Wayland is trash ;)
 
kpedersen said:
Can all of these not be achieved with a suid-exec helper binary with specific groups for the authorized users?
Click to expand...
Just for the example of shutdown, it's a pretty common requirement that you want to allow a local user to do so (if logged in and running a session), but not the same user when connected from remote.

kpedersen said:
The window manager and screen locker stuff should almost certainly be X11 messages by definition. Things like xlock / xlockmore seem to work fine. Is there a specific functionality you find is missing that can only be improved with dbus (or other)?

I imagine one valid reason for IPC is because many Wayland compositors fail to support X11 style messages. But... well Wayland is trash ;)
Click to expand...
You could just as well argue X11 is "trash". With screen locking, problems exist for sure:

XScreenSaver: On Toolkit Dialogs

XScreenSaver is a collection of free screen savers for X11, Linux, macOS, iOS and Android.
www.jwz.org www.jwz.org
blog.martin-graesslin.com

Why screen lockers on X11 cannot be secure

Today we released Plasma 5.2 and this new release comes with two fixes for security vulnerabilities in our screen locker implementation. As I found, exploited, reported and fixed these vulnerabilit…
blog.martin-graesslin.com

I don't use wayland (yet?), maybe it isn't a good solution, we will see. I think the basic idea isn't all that bad (remove a lot of cruft nobody uses any more, focus on the main job…)

edit: btw, talking about X11 style messages IMHO kind of underlines the need for communication :cool:
 
You must log in or register to reply here.
Back
Top