5 ms·

It's more about dbus, really. They are trying to get rid of 'everything is a file' and move to a pub/sub service model.

by 5ilv3r 9y ago

deleted 9y ago
[deleted]
rsync 9y ago
"They are trying to get rid of 'everything is a file' and move to a pub/sub service model." I thought we were trying to move towards "everything is a file" ... isn't that the goal of the plan9/Inferno movement ? I thought that was the progressive direction in UNIX design. We want to move away from "everything is a file" ?
- deno 9y ago
  Everything is a file ≠ everything is a blob/adhoc plaintext interface. DBus is a much superior “everything is a file” abstraction, except DBus calls files objects and doesn’t special-case directories. Quick comparison: Inode — Client address .. e.g. 3597293 — :1.32 Mount points — Well-known addresses .. e.g. /proc/subsystem — org.foo.subsystem1 Directory/file hierarchy — Object hierarchy .. e.g. /foo/bar/xyz — /foo/bar/xyz Implicit RPC — Explicit RPC .. e.g. IOctl or echo "foo" > /foo/bar — org.foo.Interface1.methodFoo(int, int, string) Security .. sudo vs Polkit etc.
  - wahern 9y ago
    > Everything is a file ≠ everything is a blob/adhoc plaintext interface. Actually, yes, it more or less means exactly that. Everything is a file means your interfaces (i.e. object methods) are generally limited to open, read, write, and close. Of course you can synthesize whatever you want on top of that, but the basic contract relies on those primitives exclusively.
    - deno 9y ago
      And this is better how exactly?
      - 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
    [ I could've sworn I already replied to this comment before. Weird. ] > DBus is a much superior “everything is a file” abstraction, except DBus calls files objects and doesn’t special-case directories. The benefit of "everything is a file" is not any of the things you listed about the API and concepts, because as you noted all of them are applicable to basically any way of structuring information in a database or message bus. The argument for "everything is a file" is that you can create complicated processes without the need for any programming, by grouping together many small programs that all operate on the same interface (the filesystem) and thus you can chain together pipelines. Effectively every UNIX program operates on the filesystem at some level, so these benefits translate to almost any program unless the developers specifically work to make it difficult. So, DBus will always be poorer as an "everything is a file" abstraction as long as it doesn't have the equivalent of the coreutils (and every other program buys into it as well). There are many other problems with DBus, but if you're going to go about it from the "well, DBus is basically like a better filesystem" angle then this is the main issue with that argument. > Implicit RPC — Explicit RPC .. e.g. IOctl or echo "foo" > /foo/bar — org.foo.Interface1.methodFoo(int, int, string) I think most people will agree that ioctls are a very bad tool for implementing filesystem concepts in an out-of-band way to avoid making them consistent with the filesystem. The problem is that operating systems (and filesystems) haven't gone far enough with the everything-is-a-file concept. And personally I think that the best way forward for everything-is-a-file is that more and more things get put into the filesystem namespace. Reiser4 was a very interesting concept because the idea was to make it so that various different things could be combined so that any random UNIX tool could operate on other namespaces. Effectively you could use `cat` and `tee` to change the owners of files and things like that because the metadata namespace was part of the filesystem. Plan9 has some unrelated improvements to the filesystem namespace which also improves the coverage of the filesystem to be more cohesive. Moving away from the filesystem would be the death of the UNIX vision of having everything pass through one interface and everything being able to interact with that interface. UNIX made many mistakes, plan9 made some mistakes (though less), and I'm hoping that operating systems continue to innovate on these concepts. It's a shame that POSIX is stifling this sort of innovation by making everyone complacent in coming up with new improvements to the base set of abstractions we're using.

It's more about dbus, really. They are trying to get rid of 'everything is a file' and move to a pub/sub service model.

by 5ilv3r 9y ago

It's more about dbus, really. They are trying to get rid of 'everything is a file' and move to a pub/sub service model.

deleted 9y ago

[deleted]

rsync 9y ago

"They are trying to get rid of 'everything is a file' and move to a pub/sub service model." I thought we were trying to move towards "everything is a file" ... isn't that the goal of the plan9/Inferno movement ? I thought that was the progressive direction in UNIX design. We want to move away from "everything is a file" ?

deno 9y ago
Everything is a file ≠ everything is a blob/adhoc plaintext interface. DBus is a much superior “everything is a file” abstraction, except DBus calls files objects and doesn’t special-case directories. Quick comparison: Inode — Client address .. e.g. 3597293 — :1.32 Mount points — Well-known addresses .. e.g. /proc/subsystem — org.foo.subsystem1 Directory/file hierarchy — Object hierarchy .. e.g. /foo/bar/xyz — /foo/bar/xyz Implicit RPC — Explicit RPC .. e.g. IOctl or echo "foo" > /foo/bar — org.foo.Interface1.methodFoo(int, int, string) Security .. sudo vs Polkit etc.
- wahern 9y ago
  > Everything is a file ≠ everything is a blob/adhoc plaintext interface. Actually, yes, it more or less means exactly that. Everything is a file means your interfaces (i.e. object methods) are generally limited to open, read, write, and close. Of course you can synthesize whatever you want on top of that, but the basic contract relies on those primitives exclusively.
  - deno 9y ago
    And this is better how exactly?
    - 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
  [ I could've sworn I already replied to this comment before. Weird. ] > DBus is a much superior “everything is a file” abstraction, except DBus calls files objects and doesn’t special-case directories. The benefit of "everything is a file" is not any of the things you listed about the API and concepts, because as you noted all of them are applicable to basically any way of structuring information in a database or message bus. The argument for "everything is a file" is that you can create complicated processes without the need for any programming, by grouping together many small programs that all operate on the same interface (the filesystem) and thus you can chain together pipelines. Effectively every UNIX program operates on the filesystem at some level, so these benefits translate to almost any program unless the developers specifically work to make it difficult. So, DBus will always be poorer as an "everything is a file" abstraction as long as it doesn't have the equivalent of the coreutils (and every other program buys into it as well). There are many other problems with DBus, but if you're going to go about it from the "well, DBus is basically like a better filesystem" angle then this is the main issue with that argument. > Implicit RPC — Explicit RPC .. e.g. IOctl or echo "foo" > /foo/bar — org.foo.Interface1.methodFoo(int, int, string) I think most people will agree that ioctls are a very bad tool for implementing filesystem concepts in an out-of-band way to avoid making them consistent with the filesystem. The problem is that operating systems (and filesystems) haven't gone far enough with the everything-is-a-file concept. And personally I think that the best way forward for everything-is-a-file is that more and more things get put into the filesystem namespace. Reiser4 was a very interesting concept because the idea was to make it so that various different things could be combined so that any random UNIX tool could operate on other namespaces. Effectively you could use `cat` and `tee` to change the owners of files and things like that because the metadata namespace was part of the filesystem. Plan9 has some unrelated improvements to the filesystem namespace which also improves the coverage of the filesystem to be more cohesive. Moving away from the filesystem would be the death of the UNIX vision of having everything pass through one interface and everything being able to interact with that interface. UNIX made many mistakes, plan9 made some mistakes (though less), and I'm hoping that operating systems continue to innovate on these concepts. It's a shame that POSIX is stifling this sort of innovation by making everyone complacent in coming up with new improvements to the base set of abstractions we're using.