[modular-debian] Re: Replace dbus with per-service filesystems (was: Re: Humor With A Message: dbus)

  • From: Jude Nelson <judecn@xxxxxxxxx>
  • To: Marty <martyb@xxxxxxxxxxxxx>, modular-debian@xxxxxxxxxxxxx
  • Date: Sat, 6 Dec 2014 23:15:27 -0500

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!
>>>
>>>
>>>
>>
>
>

Other related posts: