[ 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 obj

[ 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.