4 ms·

And this is better how exactly?

by deno 9y ago

wahern 9y ago
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. It's like ioctl. The ioctl interface is an abomination precisely because it breaks the open/read/write/close interface. Ever try to use an ad hoc ioctl interface from any language other than C or C++? If all the world used the same programming language with the same control flow constructs then a strongly typed RPC interface would make a ton of sense. But it doesn't. The everything-is-a-file contract works well for the same reason that IP works well: because it pushes the complexity to the edges, and when the technology changes you don't need to upgrade every piece of middleware. Almost every modern language supports open, read, write, and close from day 1, giving you the necessary primitives to communicate with anything supporting that model. Of course, maybe batteries aren't included and you have to do some grunt work. But that's often the interface designers fault. Opening a TCP connection on Plan 9 is as easy as a single open call, vs multiple complex system calls using a more typed interface like the BSD Sockets API. Even dbus can be exported through the file model. Theoretically you could expose dbus through the filesystem namespace using something like FUSE. And, actually, here's an attempt at that: https://github.com/sidorares/dbusfs https://github.com/sidorares/dbusfs Which goes to show how flexible the open/read/write/close model truly is.
- deno 9y ago
  > 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.
  - cyphar 9y ago
    > Everything has some ad-hoc implied interface, documented who knows where, if at all, and this giant hack is somehow something to admire? Jumping ship to DBus is not the solution to this problem. The problem is that the current incarnation of everything-is-a-file is not radical enough. Reiser4 had some very interesting ideas with regards to unifying the many different information namespaces, it's a shame they never became mainstream. I'm hoping that future innovation won't be disinfranchised by people who want to abandon filesystems entirely and switch to another ad-hoc model that isn't really much better.
  - JdeBP 9y ago
    At this point in the discussion, I am reminded of http://gentooexperimental.org/~patrick/weblog/archives/2014-11.html#e2014-11-23T09_26_01.txt http://gentooexperimental.org/~patrick/weblog/archives/2014-...

And this is better how exactly?

by deno 9y ago

And this is better how exactly?

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. It's like ioctl. The ioctl interface is an abomination precisely because it breaks the open/read/write/close interface. Ever try to use an ad hoc ioctl interface from any language other than C or C++? If all the world used the same programming language with the same control flow constructs then a strongly typed RPC interface would make a ton of sense. But it doesn't. The everything-is-a-file contract works well for the same reason that IP works well: because it pushes the complexity to the edges, and when the technology changes you don't need to upgrade every piece of middleware. Almost every modern language supports open, read, write, and close from day 1, giving you the necessary primitives to communicate with anything supporting that model. Of course, maybe batteries aren't included and you have to do some grunt work. But that's often the interface designers fault. Opening a TCP connection on Plan 9 is as easy as a single open call, vs multiple complex system calls using a more typed interface like the BSD Sockets API. Even dbus can be exported through the file model. Theoretically you could expose dbus through the filesystem namespace using something like FUSE. And, actually, here's an attempt at that: https://github.com/sidorares/dbusfs https://github.com/sidorares/dbusfs Which goes to show how flexible the open/read/write/close model truly is.

deno 9y ago
> 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.
- cyphar 9y ago
  > Everything has some ad-hoc implied interface, documented who knows where, if at all, and this giant hack is somehow something to admire? Jumping ship to DBus is not the solution to this problem. The problem is that the current incarnation of everything-is-a-file is not radical enough. Reiser4 had some very interesting ideas with regards to unifying the many different information namespaces, it's a shame they never became mainstream. I'm hoping that future innovation won't be disinfranchised by people who want to abandon filesystems entirely and switch to another ad-hoc model that isn't really much better.
- JdeBP 9y ago
  At this point in the discussion, I am reminded of http://gentooexperimental.org/~patrick/weblog/archives/2014-11.html#e2014-11-23T09_26_01.txt http://gentooexperimental.org/~patrick/weblog/archives/2014-...