4 ms·

you will want some extra layers of abstraction that aren't available if you limit yourself to FDs and Unix-style permissions. I have yet to see a single case w

by moe 12y ago

you will want some extra layers of abstraction that aren't available if you limit yourself to FDs and Unix-style permissions. I have yet to see a single case where FDs and unix-permissions wouldn't have been perfectly sufficient. I think the real problem is that we are facing a generation of developers who never learned how to properly use them.

swhipple 12y ago
There are cases where you want to be notified when an event occurs or the success of your application's action (in more detail than the error codes from a write(2) to a FD). You can solve the problem by using socket FDs, but you have to roll your own format for registration, communication, error checking, making sure the appropriate applications can read, etc. I think many developers would prefer using DBus as an abstraction for these types of problems.
- moe 12y ago
  Why not a library that speaks a simple[1] line based protocol over pipes and/or sockets? Or even just plain old files? That's how unix used to work before the desktop people took over. [1] Yes, DBus is "sort of" line based. But from all I've heard it's the opposite of simple and... well, let's just say people don't seem to have much good to say about it.
  - swhipple 12y ago
    It's true that DBus is somewhat of a complex solution if you have a simple enough use case, and I think most of the criticism is the documentation rather than the design (or, rather, criticism of the design is mostly that it isn't Unix-like). But having a daemon that relays your messages to other applications based on a standardized protocol has some merit of its own, even if it isn't strictly Unix-like. I might have some bias, since I think the Unix-way is oversimplified for some problems, even though there are often ways to make it work.
    - moe 12y ago
      But having a daemon that relays your messages I agree, and I'm not opposed to the idea of a daemon. DBus just seems to be (from my perception) rather poorly designed on every level. And the more pervasive it becomes the more of its bad design bleeds into more or less unrelated other software packages. the Unix-way is oversimplified for some problems The unix-way of course has limits, but it's usually worth to explore it as far as possible and only then divert to more baroque designs. In the majority of cases you'll find that pure, file-based approaches are a lot more elegant, efficient, discoverable and debuggable than the alternatives (see e.g. qmail vs postfix, or runit). There's a lot to be said for being able to use the standard unix cutlery to inspect and interact with the guts of your application. Imagine DBus was just a directory with one or two files per pid. Imagine you could read past messages with 'cat', follow them with 'tail' and inject new ones with 'echo'.
- deong 12y ago
  The kernel has had inotify for 10 years or so.
rodgerd 12y ago
I guess you've never used networking on a Unix system then.
- moe 12y ago
  Yes I have.
caf 12y ago
I think the only thing really missing from the "file descriptor" model is revoke() - and that's been the case from very early on (hang-up for tty devices works like a device-specific revoke()).
- jude- 12y ago
  revoke() is potentially harmful, since an application not written to check the error code after each interaction with each file descriptor will break when one of its file descriptors is revoke()'ed out from under it. Why not instead use fuser(1) to find programs using the file descriptor you want closed, and then take program-specific actions (kill(1), restart, signal) to ensure that they sanely release the descriptor?
  - caf 12y ago
    Any interaction with a file descriptor can already fail (eg. pretty much anything can potentially give you EIO). Using fuser() in that way is racy, and how is kill() any better than returning a possibly-ignored error anyway? You can't do program-specific actions because the point is to enforce "You did have permission to open that, but now you don't and you aren't allowed to keep using it".
    - moe 12y ago
      I agree. And actually in my book revoke() is also unnecessary, for the same reason. Why not simply close the fd and let the regular transport error handling (retry/backoff) do its job? If you find yourself needing any more ceremony than that then that almost certainly hints at a higher level mistake in your protocol design.
      - caf 12y ago
        You can't externally asynchronously close a file descriptor within a process, because of the way file descriptors are re-used. revoke() basically works like closing it on the "other side" - the process still has an open file descriptor, but any IO on it will error.

by moe 12y ago

swhipple 12y ago

There are cases where you want to be notified when an event occurs or the success of your application's action (in more detail than the error codes from a write(2) to a FD). You can solve the problem by using socket FDs, but you have to roll your own format for registration, communication, error checking, making sure the appropriate applications can read, etc. I think many developers would prefer using DBus as an abstraction for these types of problems.

moe 12y ago
Why not a library that speaks a simple[1] line based protocol over pipes and/or sockets? Or even just plain old files? That's how unix used to work before the desktop people took over. [1] Yes, DBus is "sort of" line based. But from all I've heard it's the opposite of simple and... well, let's just say people don't seem to have much good to say about it.
- swhipple 12y ago
  It's true that DBus is somewhat of a complex solution if you have a simple enough use case, and I think most of the criticism is the documentation rather than the design (or, rather, criticism of the design is mostly that it isn't Unix-like). But having a daemon that relays your messages to other applications based on a standardized protocol has some merit of its own, even if it isn't strictly Unix-like. I might have some bias, since I think the Unix-way is oversimplified for some problems, even though there are often ways to make it work.
  - moe 12y ago
    But having a daemon that relays your messages I agree, and I'm not opposed to the idea of a daemon. DBus just seems to be (from my perception) rather poorly designed on every level. And the more pervasive it becomes the more of its bad design bleeds into more or less unrelated other software packages. the Unix-way is oversimplified for some problems The unix-way of course has limits, but it's usually worth to explore it as far as possible and only then divert to more baroque designs. In the majority of cases you'll find that pure, file-based approaches are a lot more elegant, efficient, discoverable and debuggable than the alternatives (see e.g. qmail vs postfix, or runit). There's a lot to be said for being able to use the standard unix cutlery to inspect and interact with the guts of your application. Imagine DBus was just a directory with one or two files per pid. Imagine you could read past messages with 'cat', follow them with 'tail' and inject new ones with 'echo'.
deong 12y ago
The kernel has had inotify for 10 years or so.

rodgerd 12y ago

I guess you've never used networking on a Unix system then.

moe 12y ago
Yes I have.

caf 12y ago

I think the only thing really missing from the "file descriptor" model is revoke() - and that's been the case from very early on (hang-up for tty devices works like a device-specific revoke()).

jude- 12y ago
revoke() is potentially harmful, since an application not written to check the error code after each interaction with each file descriptor will break when one of its file descriptors is revoke()'ed out from under it. Why not instead use fuser(1) to find programs using the file descriptor you want closed, and then take program-specific actions (kill(1), restart, signal) to ensure that they sanely release the descriptor?
- caf 12y ago
  Any interaction with a file descriptor can already fail (eg. pretty much anything can potentially give you EIO). Using fuser() in that way is racy, and how is kill() any better than returning a possibly-ignored error anyway? You can't do program-specific actions because the point is to enforce "You did have permission to open that, but now you don't and you aren't allowed to keep using it".
  - moe 12y ago
    I agree. And actually in my book revoke() is also unnecessary, for the same reason. Why not simply close the fd and let the regular transport error handling (retry/backoff) do its job? If you find yourself needing any more ceremony than that then that almost certainly hints at a higher level mistake in your protocol design.
    - caf 12y ago
      You can't externally asynchronously close a file descriptor within a process, because of the way file descriptors are re-used. revoke() basically works like closing it on the "other side" - the process still has an open file descriptor, but any IO on it will error.