Comments inline... On Sat, Dec 6, 2014 at 10:03 AM, Marty <martyb@xxxxxxxxxxxxx> wrote: > Hi Jude, > > On 12/06/2014 03:36 AM, Jude Nelson wrote: > >> I'm convinced that per-service filesystems encourage modularity better >> than >> dbus to the point that I've gone ahead and created a library, called fskit >> [1], that makes it easy to embed them into services. >> > > As I mentioned in my other message, this looks like what Plan 9 is > doing. I think this is a natural solution to the problem, and history > bears that out. I agree. To me, the beauty of the "everything is a file" design principle in Plan 9 is that it enforces a common structured interfacing discipline for OS components, thereby encouraging a loosely-coupled OS design. Dbus doesn't do this. > > > Unlike FUSE, fskit > >> handles all the bookkeeping required to maintain a POSIX-y directory >> hierarchy, and lets the service programmer define WSGI-style routes to >> handle I/O operations over sets of paths (a multi-threaded RAM filesystem >> can be had in about 200 lines of C). It's almost ready for a stable >> release--it's only missing symlink and hard-link support at this >> point--but >> I've already used it to create a special RAM filesystem, called runfs [2], >> that automatically removes files once the process that created them dies >> (i.e. no more stale PID files). I use it every day to avoid polluting my >> /tmp with files generated (but not cleaned up) by software I work on at >> $DAYJOB. >> > > How does this compare to tmpfs? Unlike tmpfs, runfs automatically removes inodes from the filesystem once the process that created them dies. For example, if a daemon writes a PID file in runfs but then crashes, the PID file disappears from runfs on its own. > > > Before I dive off the deep end into doing something big like >> re-implementing udev, I'm looking for a sanity check. Is what I'm trying >> to do a desirable, or even a sensible, approach towards encouraging a more >> modular debian? To be clear, it's not that I dislike dbus; it's that the >> lack of generic interfaces between dbus components makes it difficult for >> me to avoid tightly coupling multiple dbus services together. I think >> this >> can be avoided if services stuck to generic conventions for interacting >> with the rest of the system (such as the POSIX filesystem API), since then >> existing tools would not need to be designed around the services' >> otherwise-arbitrary methods and their arbitrary side-effects. I think >> making it easy for services to expose functionality through the filesystem >> is a big step in this direction. >> > > As I mentioned, this appears to be what Plan 9 is doing with the > "everything is a file" paradigm. It looks very much like a step in the > right direction, but I am just learning (just in the last few weeks). > > Any thoughts or feedback welcome :) >> > > IPC touching everything in the system (and kernel through kdbus, > eventually) means this is a big reorganization of userspace, maybe on > the order of what systemd is trying to do. It probably puts you in > head-to-head competition with systemd. > Honestly, I hope not. I don't want to stop people from using systemd if systemd is the best tool for the job (even though I have some reservations about systemd). However, I would prefer a more UNIX-y (Plan 9-y?) suite of tools that lets me address the same problems that systemd tries to solve; hence my reaching out to like-minded Debian users :) > > I think everyone is coming to grips with the scale of the problem, > but you seem ahead of the game in terms of a possible solution. > > > Regards, >> Jude >> >> [0] >> http://gentooexperimental.org/~patrick/weblog/archives/2014- >> 11.html#e2014-11-23T09_26_01.txt >> [1] https://github.com/jcnelson/fskit >> [2] https://github.com/jcnelson/runfs >> >> >> >> On Thu, Dec 4, 2014 at 5:36 PM, Martinx - ジェームズ < >> thiagocmartinsc@xxxxxxxxx> >> wrote: >> >> On 4 December 2014 at 14:03, David L. Craig <dlc.usa@xxxxxxxxx> wrote: >>> > Can we agree dbus is to be avoided? >>> >>> I'm using Linux since 1996 (Debian since Potato), never used dbus (on >>> servers) in my entire life. >>> >>> I see no reason to start using now. >>> >>> Cheers! >>> >>> >>> >> > >