A plague of daemons and the Unix Philosophy

[Ben Scott]

On Nov 11, 2007 3:23 PM, Ted Roche <tedroche at tedroche.com> wrote:
> I believe ConsoleKit was introduced to support multiple user desktop
> switching.

  From what I found, ConsoleKit was introduced to replace pam_console.
 Reportedly, pam_console was buggy and could not handle multi-headed
systems.  Why, exactly, "Improve pam_console" was not an acceptable
solution was never explained.

  Multi-headed systems being a system with multiple KVM
(keyboard/video/mouse) stations.

> Your Google-Foo is powerful ...

  I did go looking for information.  What I found suggests the
architects just don't get it, and are not interested in getting it.

  Example: When PulseAudio (which also apparently depends on D-BUS)
was made the default on Fedora, it was stated that people who didn't
like sound servers should go back to hiding under their rock.

http://www.redhat.com/archives/rhl-devel-list/2007-August/msg01196.html

> I think it's the "Fast" part of User Switching that's the issue; stuff
> resident in memory tracking each session?

  Why does it need to be a daemon in memory?  One that took up
megabytes of RAM on my system, I might add.  Disk files -- namely,
wtmp and utmp -- have served Unix well for 30 or so years.  It seems
reasonable to conclude that disk files would serve equally well for
this.  If it's a single-user system, the impact is nil; if they're
getting hit all the time the kernel will cache them anyway.

http://en.wikipedia.org/wiki/Unix_philosophy

> Could there be stateful stuff (excuse the technical terms)
> that wouldn't be appropriate to script?

  Script?  I never mentioned scripting.  Irrelevant, anyway.  When
logins happen (or user switches, or anything else), standard library
calls get invoked.  With this scheme, calls to the ConsoleKit daemon
via the D-Bus daemon are part of the library calls.  I submit that one
could more easily, more reliability, and with less resources simply
update a disk file.

> "In a f-u-s scenario with two users logged in, A and B, the last one
> to log in wins. Hence, when switching back to the first session, some
> devices are now not accessible."

  Yes, pam_console had a similar limitation, although I believe it was
that the first to login won.

  But I'm not talking about user switching; I'm talking about a single
user -- me.  Runing startx.  Apparently ConsoleKit is adding an ACL
entry when I login on the tty1, but then removing it when the X server
switches to tty7.  If I switch back to tty1, it puts the ACL entry
back.  If I switch back to tty7 again, it removes it again.  The end
result is, I can only play sound from tty1, not from my X session.

  In other words, it's broken for just me, let alone multiple users.

> "Proposed fix is to use ACL's on device nodes; hence more than one user
> can own the device node."

  It does appear to be using ACL's now.  Just not in a way that makes sense.

> Is this a case of "Those who fail to learn from Windows are doomed to
> reinvent it?"

  It does remind me of MS-Windows, where to do anything, you need a
running Service and a slew of registry entires some DLLs and a COM
library.  Ick.

  Maybe they *are* turning Linux into MS-Windows.  If so, for the love
of light, why?!?

> It does look like they're trying to lift the OS X feature ...

  OS X feature?  Unix and the X Window System have been multi-headed
and multi-user for 20 years.  I was doing "Fast User Switching" by
running multiple X servers on different virtual consoles back in 1999.
 I gather they're trying to enable FUS on a single VC, which isn't a
bad thing in and of itself, but they're doing a horrible job at it.

"Those who do not understand Unix are condemned to reinvent it, poorly."
                             -- Henry Spencer

-- Ben