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.Why? Cause you lack the skills to do so? So "modern" programmers are incompetent?
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.
It's a requirement because you are NOT the one implementing the software that uses it. Modern means not
banging sticks and rocksusing 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.
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.
Sorry to be captain obvious here, but C and UNIX were not designed with objects in mind.
But I agree with you. Bespoke IPC is not useful ... crowd around an alternative to dbus.
"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.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...
None of those are message buses.Similar technologies on these platforms are COM, DDE, WCF, NSNotification, XPC.
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.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.
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'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.
Andrew Tanenbaum noted in several of his books that concepts do get recycled. A direct quote from his Modern Operating Systems, Second Edition:"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.
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).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.
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.What is Windows' message bus? Apple's?
~ % 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
Objects doesn't necessarily mean OOP. You might want to count the usage of the word "object" in the C language standard documents.C and UNIX were not designed with objects in mind.
This is just Qt's adapter to easily use d-bus. There's only one d-bus.Perhaps qt5-dbus is better implemented than regular dbus?
Same with GNOME. Good memories of:
waiting for bonobo activation server ... retrying ... bobobo activation failed
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"'
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.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?
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
chmod +sis easier than trying to write a safe / stable message bus.
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.Can all of these not be achieved with a suid-exec helper binary with specific groups for the authorized users?
You could just as well argue X11 is "trash". With screen locking, problems exist for sure: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