On Nov 11, 2007 3:23 PM, Ted Roche <[EMAIL PROTECTED]> 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 _______________________________________________ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/