> Ever try to use a dbus service from the shell? From any language that _doesn't_ rely on a binding to the C library Therein lies your answer. There are many l

> Ever try to use a dbus service from the shell? From any language that _doesn't_ rely on a binding to the C library Therein lies your answer. There are many libraries that do not bind to libdbus. GLib’s, QT’s and outside of C/C++ you have native python (txdbus), native javascript (node-dbus, which is btw powering the dbusfs you linked) and native C#/mono. That’s just off the top of my head, I’m sure there are many more. As for shell, I am not a fan, obviously, but qt-dbus (and the glib one) has existed for a long time and busctl is even nicer. Works just fine if you just need the client functionality. DBus lends itself to something much more powerful like Microsoft’s Powershell (but without the CLR). Bash is obviously designed for filesystem interface, it also is not a great fit for SQL. Doesn’t mean SQL is shit. > Which goes to show how flexible the open/read/write/close model truly is. It‘s useless, not flexible. Everything has some ad-hoc implied interface, documented who knows where, if at all, and this giant hack is somehow something to admire? Garbage-in, garbage-out. I’ll take DBus any day. > Theoretically you could expose dbus through the filesystem namespace using something like FUSE. You can expose the filesystem via DBus as well (e.g. org.gtk.vfs). Shows you how flexible DBus is.