[809] in athena10
Re: Changes to debathena-gdm-config
daemon@ATHENA.MIT.EDU (William Cattey)
Fri Jan 9 16:42:59 2009
In-Reply-To: <alpine.DEB.2.00.0901091625250.959@vinegar-pot.mit.edu>
Mime-Version: 1.0 (Apple Message framework v753.1)
Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed
Message-Id: <E89B367B-B51D-43BE-954B-34F739E7DDEB@mit.edu>
Cc: Anders Kaseorg <andersk@mit.edu>, athena10@mit.edu
From: William Cattey <wdc@MIT.EDU>
Date: Fri, 9 Jan 2009 16:41:16 -0500
To: Tim Abbott <tabbott@mit.edu>
Content-Transfer-Encoding: 8bit
There was one amendment I took. The canonical action plan is at:
https://jira.mit.edu/jira/browse/ATN-1
The amendment is:
5. Continue with the plan to de-support $WINDOW_MANAGER in dot files
and document for users they should, "Choose one from the list of
sessions on offer, and say yes to making it your default, or write
your own .xsession if your preferred window manager is not listed."
-Bill
On Jan 9, 2009, at 4:34 PM, Tim Abbott wrote:
> The important part of this is presumably the action plan:
>
> 1. divert /usr/share/gdm/BuiltInSessions/default.desktop to contain
> "System Default Session" as the name in english instead of "Run
> Xclient Script."
>
> 2. Open an upstream bug to get this change in, and to collaborate
> in moving it forward.
>
> 3. Report that "Secure Remote Connection" is broken and divert it
> until it is fixed.
>
> 4. Leave in place the existing "Last Session" and session search
> path behavior.
>
> 5. Continue with the plan to de-support $WINDOW_MANAGER in dot
> files but instead of telling people to write their own .xsession,
> we tell them to select the window manager they like from the
> session list, and to agree to make it their default.
>
> I think that the didn't materially change after being first stated
> in this form, but please correct me if this is wrong.
>
> -Tim Abbott
>
> On Fri, 9 Jan 2009, Anders Kaseorg wrote:
>
>> Here is a log of our Zephyr conversation today.
>>
>> debathena / xsession / wdc 11:17 (rubber_ducky.sysdaemon)
>> So conversations have finally started on the Athena 10 list
>> about
>> the X session, but I feel we are no closer to consensus on
>> what to do
>> to remedy the problems I have reported.
>> debathena / xsession / wdc 11:19 (rubber_ducky.sysdaemon)
>> In a related note, Athena Release team has agreed that
>> desupporting
>> WINDOW_MANAGER is the right thing, but implicit in that is
>> that we'll
>> instruct users to create their own .xsession file to specify
>> session,
>> and window manager. We are apparently not yet all agreed
>> that a user
>> generated .xsession will work, or is the right approach.
>> debathena / xsession / geofft 11:20 (Our Slogan :
>> Vulnerability Is Possible !!!)
>> I have a suspicion that there are two types of sessions -
>> one that
>> call session managers like gnome-session, and one that calls
>> window
>> managers themselves, and that only one of them is problematic.
>> debathena / xsession / quentin 11:24 (Quentin Smith)
>> wdc: I think I missed something. I know you reported
>> problems, but I
>> didn't actually see a description of the problems you had.
>> debathena / xsession / quentin 11:24 (Quentin Smith)
>> (other than the user confusion, which was already responded
>> to on the
>> list)
>> debathena / xsession / wdc 11:29 (rubber_ducky.sysdaemon)
>> Can you see what's in MIT Jira?
>> The most detailed analysis I made is there at:
>> https://jira.mit.edu/jira/browse/ATN-1
>> I apologize for not doing it in the debathena trac, but
>> ended up
>> creating an issue tracker for Athena 10 distinct from
>> debathena.
>> This was the first issue I really worked there because it
>> seemed
>> most relevant to cluster Athena 10 systems, and least
>> relevant to
>> debathena.
>> debathena / xsession / geofft 11:33 (Our Slogan :
>> Vulnerability Is Possible !!!)
>> I'd be okay putting this _just_ in the Athena 10 cluster
>> config, but
>> I suspect this doesn't fully address Anders' concerns about
>> staying
>> close to upstream.
>> debathena / xsession / geofft 11:36 (Our Slogan :
>> Vulnerability Is Possible !!!)
>> I'm heading afk for most of the rest of the day.
>> debathena / xsession / andersk 13:06 (Anders Kaseorg)
>> wdc: I still don’t think there is a clear explanation of
>> exactly what
>> the problems are.
>> debathena / xsession / andersk 13:07 (Anders Kaseorg)
>> You have described that there may vaguely be some confusion
>> related
>> to the presence of different options, but nobody has
>> described what
>> actual problems this confusion leads to.
>> debathena / xsession / andersk 13:07 (Anders Kaseorg)
>> The presence of multiple options is not, in itself, a bug.
>> debathena / xsession / andersk 13:09 (Anders Kaseorg)
>> If one of these options leads to certain doom for the
>> unsuspecting
>> user, then we should fix that option, not remove it.
>> debathena / xsession / andersk 13:10 (Anders Kaseorg)
>> Does this make sense?
>> debathena / xsession / wdc 14:17 (rubber_ducky.sysdaemon)
>> andersk: Does the stuff in https://jira.mit.edu/jira/browse/
>> ATN-1
>> provide a rich enuf sense of the problem, or am I still not
>> making sense.
>>
>> Perhaps to summarize:
>>
>> There is no indication to someone seeing the list of
>> sessions for the first time
>> that choosing one of the Failsave options needs NOT be
>> undone by choosing
>> one of the other options. From that starting point, someone
>> who knows
>> "Gee we use GNOME" causes them to pick the GNOME option
>> which isn't the
>> right option to choose. After they choose that option the
>> GNOME standard
>> login session not the Athena Standard login session is what
>> they get.
>>
>> Yes, changing from "run X Client" session to "Athena" will
>> help.
>>
>> But it is unclear if the stock Gnome session that happens to
>> be laying
>> around in what's installed is actually useful. The "Secure
>> Remote Connection"
>> option is also what happens to be laying around. Again,
>> it's non-toxic,
>> but it's also non-useful.
>>
>> <continued next z-gram>
>> debathena / xsession / andersk 14:18 (Anders Kaseorg)
>> As ghudson pointed out, the “Run X Client” and “GNOME”
>> options are
>> now identical, so this doesn’t matter.
>> debathena / xsession / wdc 14:18 (rubber_ducky.sysdaemon)
>> Good design means pruning away superfluous choice.
>> What we have now is bad design. It is more glaring a bad
>> design
>> because the crufty session options that nobody uses are not
>> sitting in
>> an obscure menu hanging off a button nobody presses like in
>> the stock
>> Ubuntu greeter. The cruft is now first-class options in a
>> button many
>> are expected to press.
>> debathena / xsession / andersk 14:22 (Anders Kaseorg)
>> If we were designing the sessions menu from scratch, then I
>> might
>> agree with you. (There are some additional details that
>> necessitate
>> these different options under some circumstances, though.)
>> debathena / xsession / andersk 14:22 (Anders Kaseorg)
>> However, that is not our job.
>> debathena / xsession / andersk 14:23 (Anders Kaseorg)
>> If you think that the sessions menu is poorly designed, you
>> should
>> file an Ubuntu bug report.
>> debathena / xsession / andersk 14:23 (Anders Kaseorg)
>> Even if there is a problem, I do not think that the design
>> is _so_
>> bad that we need to take it upon ourselves to replace it.
>> debathena / xsession / jdreed 14:24 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> Hrm, I just sent mail before I noticed we were chatting online
>> debathena / xsession / ghudson 14:24 (Steel and circuits will
>> make me whole)
>> My current thinking is that (1) someone should file a bug
>> report to
>> get the name "run Xclient script" changed to "System default
>> session"
>> or something, and (2) the remaining problems are not subtantial
>> enough to warrant a local change.
>> debathena / xsession / wdc 14:24 (rubber_ducky.sysdaemon)
>> The usability red flag I'm waving is this:
>> How the session options list gets populated was pre-existing
>> design.
>> When we chose to implement the Athena greeter interfacing
>> trivially
>> to that method, we populated very visible menus with
>> superfluous,
>> and difficult to understand options.
>>
>> I agree that its not our job to re-design how the sessions
>> menu gets populated
>> per se, but our greeter design has optimized us into a bad
>> place. Can
>> we improve on where we've landed?
>> debathena / xsession / wdc 14:26 (rubber_ducky.sysdaemon)
>> Ghudson: if the GNOME option is identical to the one we
>> have crafted,
>> can we get rid of ours?
>>
>> This also begs the question: can we get rid of that useless
>> and distracting
>> "Secure Terminal Session" that is discovered in the default
>> directory
>> next to the GNOME session?
>> debathena / xsession / andersk 14:26 (Anders Kaseorg)
>> We have not crafted any of those options.
>> debathena / xsession / andersk 14:26 (Anders Kaseorg)
>> They are _all_ upstream.
>> debathena / xsession / ghudson 14:26 (Steel and circuits will
>> make me whole)
>> Anders is correct.
>> debathena / xsession / andersk 14:27 (Anders Kaseorg)
>> Also, even though the Ubuntu default GDM theme hides the
>> Session menu
>> behind another menu, the upstream GNOME GDM theme does not,
>> IIRC.
>> debathena / xsession / jdreed 14:27 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> I think calling this a menu "redesign" is a poor choice of
>> words. We're
>> essentially commenting out a few broken session options that
>> don't work
>> in our environment. It takes like 2 seconds to re-enable
>> them, it's
>> not like we're deleting the files or packages.
>> debathena / xsession / andersk 14:29 (Anders Kaseorg)
>> None of the options are broken in our environment (with the
>> possible
>> exception of Secure Remote Connection?).
>> debathena / xsession / jdreed 14:29 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> Secure Remote Connection is the one I was thinking of.
>>
>> And what about the "Failsafe" ones. Do they actually mean
>> "don't run my
>> dotfiles" now? because they didn't, for a while
>> debathena / xsession / andersk 14:29 (Anders Kaseorg)
>> And if Secure Remote Connection is broken, I find it
>> unlikely that
>> our environment is responsible for breaking it. We should
>> investigate.
>> debathena / xsession / wdc 14:30 (rubber_ducky.sysdaemon)
>> Secure Remote Connection is not "broken" per se.
>> For the 4 systems on campus that offer you a Sun X terminal
>> session,
>> it will dutifully negotiate a connection and let you begin
>> the process of logging in.
>> debathena / xsession / jdreed 14:30 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> Bill: Wait, what? Secure Remote Connection is ssh, not XDMCP
>> debathena / xsession / wdc 14:32 (rubber_ducky.sysdaemon)
>> Perhaps I'm mistaken. I thought it was XDMCP.
>> debathena / xsession / jdreed 14:32 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> There is an XDMCP login option, but it's elsewhere
>> debathena / xsession / jdreed 14:34 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> "Secure Remote Connection" appears to only work with stock
>> Ubuntu machines.
>> I cannot use it to ssh into Athena or OS X, for example.
>> That is broken.
>> debathena / xsession / andersk 14:34 (Anders Kaseorg)
>> Okay. That’s a bug, then.
>> debathena / xsession / jdreed 14:34 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> I understand and agree with the philosophy of "If it's a
>> bug, report it
>> upstream.", but that does not necessarily imply "If it's not
>> a bug, suck it up."
>> debathena / xsession / wdc 14:36 (rubber_ducky.sysdaemon)
>> I just read /usr/lib/gdm/gdm-ssh-session
>> I was mistaken and it is ssh, not XGMCP, sorry.
>> However, it wants to run /etc/X11/Xsession on the remote side.
>> I'm not sure that's the right thing for it to be wanting to do
>> in a general case.
>> debathena / xsession / andersk 14:36 (Anders Kaseorg)
>> If it’s not a bug, there’s nothing to suck up. The previous
>> discussion seemed to be running with the assumption that the
>> “GNOME”
>> option just plain didn’t work. This is not the case.
>> debathena / xsession / andersk 14:37 (Anders Kaseorg)
>> If there is a usability bug, that is a different argument.
>> debathena / xsession / jdreed 14:37 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> Out of curiousity, are wdc and I the only people who run -
>> workstation as
>> their primary machine. Because we're the only people who
>> seem to run into
>> these things.
>> debathena / xsession / andersk 14:37 (Anders Kaseorg)
>> The SIPB office has several Debathena workstations.
>> debathena / xsession / wdc 14:38 (rubber_ducky.sysdaemon)
>> We may have gotten into this "bug/not-bug" discussion
>> because my
>> concern that we have a usability problem kept getting
>> replied to with,
>> "That's not a bug." "Yes it is." "No it isn't." (see
>> Argument Clinic).
>> debathena / xsession / jdreed 14:38 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> The SIPB office has a Vax too. It just seems like everyone
>> is using -standard
>> or -login
>> debathena / xsession / andersk 14:40 (Anders Kaseorg)
>> wdc: Well, you said, for example:
>> > Knowing I needed to run GNOME, I picked #2, broke things,
>> and never
>> > really clued into how, "You're just supposed to know to
>> Run Xclient
>> > Script".
>>
>> This is why I continued to press for clarification about
>> what exactly
>> broke.
>> debathena / xsession / amb 14:40 (xyloid xanthops)
>> I use -workstation on one of my two desktops (cithotr), but
>> it's broken in
>> a whole bunch of ways due to random testing and probably
>> wants a reinstall.
>> I'm still not sure I'd see login problems without looking
>> for them.
>> (We're going to switch part of the W92 test cluster to
>> debathena, though.)
>> debathena / xsession / tabbott 14:40 (Timothy G Abbott)
>> I think -login without -workstation is basically only used
>> on Linerva
>> and some hall dialups. A lot of people's personal desktops
>> and hall
>> workstations are -workstation.
>>
>> Of course, it may be the case that most people don't click
>> around on
>> the session types except to run a different session (e.g. I
>> run the
>> "Window Maker" session on the SIPB machines)
>> debathena / xsession / jdreed 14:41 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> I'm refering to Anders' assertion that we should not be in
>> the business
>> of disabling functionality because it's confusing or
>> incompatible with our
>> environment.
>> debathena / xsession / tabbott 14:41 (Timothy G Abbott)
>> most people just type their username and password, and it
>> works for
>> them.
>> debathena / xsession / wdc 14:41 (rubber_ducky.sysdaemon)
>> If I were approaching the Athena Greeter from first principles,
>> I would say offer only Failsafe logins and the one Athena
>> default
>> we know about. Interestingly, geofft's elimination of
>> members in the
>> search path did precisely that.
>> debathena / xsession / kaduk 14:41 (very subtle joke)
>> Looking in from outside, it really seems like you are talking
>> past each other.
>> Whether or not something is a "bug" or "broken" is mostly
>> independent
>> of whether it is a configuration setting that is not
>> appropriate
>> for the intended environment.
>> debathena / xsession / andersk 14:42 (Anders Kaseorg)
>> Okay, let’s move forward. I think we’ve identified two
>> potential
>> issues.
>> debathena / xsession / andersk 14:42 (Anders Kaseorg)
>> Firstly, “Run Xclient script”, “GNOME”, and possibly “Last
>> session”
>> may be mostly redundant with each other.
>> debathena / xsession / andersk 14:43 (Anders Kaseorg)
>> Secondly, “Secure remote connection” doesn’t work.
>> debathena / xsession / andersk 14:43 (Anders Kaseorg)
>> Is that correct?
>> debathena / xsession / jdreed 14:44 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> Ugh, Unicode.
>>
>> Yes, I believe those are correct.
>> debathena / xsession / wdc 14:45 (rubber_ducky.sysdaemon)
>> That is pretty much what I see, yes.
>>
>> We also need to verify that the Failsafe options on offer
>> actually
>> do something that matches Athena user expectations.
>> debathena / xsession / andersk 14:45 (Anders Kaseorg)
>> Okay. So three potential issues.
>> debathena / xsession / andersk 14:47 (Anders Kaseorg)
>> The SSH option really does seem to be broken, and is harmful
>> because
>> it hangs the GDM session. I propose dealing by selectively
>> diverting
>> either /usr/share/xsessions/ssh.desktop or
>> /usr/lib/gdm/gdm-ssh-session.
>> debathena / xsession / andersk 14:47 (Anders Kaseorg)
>> Also, reporting some kind of bug upstream.
>> debathena / xsession / jdreed 14:47 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> 3) Failsafe GNOME still runs .cshrc.mine, which it does not
>> on Athena 9.
>> debathena / xsession / andersk 14:49 (Anders Kaseorg)
>> Okay. The failsafe options need closer investigation and
>> probably
>> some fixes. That would seem to be basically orthogonal to the
>> session directories question, because the failsafe options
>> are not
>> generated from session files.
>> debathena / xsession / wdc 14:49 (rubber_ducky.sysdaemon)
>> Are you proposing to divert it until the bug is fixed?
>> If so then we should plan what we're going to do about the
>> "Last Session"
>> issue.
>> debathena / xsession / andersk 14:50 (Anders Kaseorg)
>> I was proposing to deal with the three issues separately. I
>> have
>> proposed solutions to the second and third issues, leaving
>> the first
>> issue for last because I believe it is the most controversial.
>> debathena / xsession / wdc 14:50 (rubber_ducky.sysdaemon)
>> Ah. Ok. Continue.
>> debathena / xsession / jdreed 14:51 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> The solutions for #2 and #3 seem fine to me. So, on to #1
>> debathena / xsession / tabbott 14:51 (Timothy G Abbott)
>> Bill: Yeah, we'd be diverting it until the bug is fixed.
>> debathena / xsession / jdreed 14:52 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> In addition to Secure Remote Connection not working, I
>> believe having
>> "Make Default" be the default button on the session
>> selection dialog is
>> a usability bug.
>> debathena / xsession / andersk 14:54 (Anders Kaseorg)
>> The Last Session option can be also somewhat separated from
>> the first
>> issue and discussed independently of the other two redundant
>> options.
>> So let’s do that.
>> debathena / xsession / andersk 14:55 (Anders Kaseorg)
>> Are we really going to remove a bunch of functionality just
>> because
>> it pops up a clear dialog box with a non-optimal default
>> button?
>> debathena / xsession / jdreed 14:56 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> I didn't say remove it. We're removing it because it's
>> broken. But while
>> we're reporting the bug about it being broken, it might be
>> worth reporting
>> a usability bug
>> debathena / xsession / andersk 14:56 (Anders Kaseorg)
>> The user was almost certainly using the mouse to select a
>> session
>> from the list, anyway, and the default button only matters for
>> keyboard navigation.
>> debathena / xsession / andersk 14:57 (Anders Kaseorg)
>> It’s a separate issue. The dialog with the Make Default
>> button is
>> shown for all sessions, not just SSH.
>> debathena / xsession / andersk 14:57 (Anders Kaseorg)
>> Or are you saying that the default on that dialog should be
>> different
>> for SSH and, say, KDE?
>> debathena / xsession / wdc 14:58 (rubber_ducky.sysdaemon)
>> We could just avail ourselves of the xsesssion config option
>> to stop offering
>> the "Last Session" option.
>>
>> My problem with "Last Session" was I didn't know it didn't
>> apply to
>> Failsafe options. But maybe I was exhibiting above-average
>> cluelessness
>> to assume that any option I selected would become the
>> default when
>> I saw that "Last Session" option. Thinking about it some
>> more, I guess
>> I still don't understand what "Last Session" is supposed to
>> be for.
>> Is it there because without it, one really MUST choose a
>> session from
>> the proffered list, and it can't just highlight the last one
>> for you
>> as a default?"
>> debathena / xsession / jdreed 14:58 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> Oh, I didn't realize it was a gdm thing. That's fine. I
>> still think it's
>> a usability bug, but we're keeping GDM, so it's moot
>> debathena / xsession / andersk 14:59 (Anders Kaseorg)
>> If you just log in using a username and password, you get
>> the same
>> result as using the Last Session option.
>> debathena / xsession / wdc 15:00 (rubber_ducky.sysdaemon)
>> Re: Make Default: It could be that I said to myself, "What?
>> This isn't
>> already the default?" and got myself into trouble.
>> debathena / xsession / andersk 15:00 (Anders Kaseorg)
>> But there is a clear dialog box that prompts you before
>> making any
>> changes to what this result is.
>> debathena / xsession / andersk 15:01 (Anders Kaseorg)
>> This is why Last Session is preselected in the sessions menu
>> as the
>> default option.
>> debathena / xsession / andersk 15:01 (Anders Kaseorg)
>> If you don’t make any change to the default option, you
>> won’t affect
>> your session.
>> debathena / xsession / wdc 15:01 (rubber_ducky.sysdaemon)
>> If we turn off the "offer Last Session" option, what happens?
>> debathena / xsession / andersk 15:03 (Anders Kaseorg)
>> I think that will cause it to never offer to remember a
>> change to
>> your session type.
>> debathena / xsession / andersk 15:04 (Anders Kaseorg)
>> I’m not sure whether that means that KDE users would have to
>> manually
>> select KDE every time they want to log in.
>> debathena / xsession / jdreed 15:06 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> Where is the "last session" data stored, anyway? The user's
>> homedir?
>> debathena / xsession / wdc 15:06 (rubber_ducky.sysdaemon)
>> I'm trying to guess at what the "solution of least surprise"
>> would be.
>> debathena / xsession / wdc 15:06 (rubber_ducky.sysdaemon)
>> jdreed: I think its .dmrc in the user's home dir.
>> debathena / xsession / wdc 15:07 (rubber_ducky.sysdaemon)
>> I think it would be bad if KDE users had always to hand-
>> select that option.
>> But how do they get KDE now? We don't offer it to them in
>> any greeter option.
>> Wouldn't they be setting their own .xsession in their home dir?
>> debathena / xsession / jdreed 15:08 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> wdc: I believe installing KDE adds a session option for it.
>> For example,
>> after installing twm, I now have a "TWM" session option
>> debathena / xsession / andersk 15:08 (Anders Kaseorg)
>> We don’t install KDE now. If KDE was installed, it would be
>> available in the sessions menu next to GNOME.
>> debathena / xsession / wdc 15:09 (rubber_ducky.sysdaemon)
>> Ah. And that is an argument against lobotomizing the
>> xsession search
>> path.
>> debathena / xsession / andersk 15:09 (Anders Kaseorg)
>> Right.
>> debathena / xsession / wdc 15:09 (rubber_ducky.sysdaemon)
>> In passing I'll note that I didn't know that BOTH GNOME and
>> "Run X Session"
>> were from upstream.
>> debathena / xsession / wdc 15:10 (rubber_ducky.sysdaemon)
>> twm becomes an X session option?
>> But I thought we put twm into the list of stuff now installed
>> by default with debathena-extras. Or was that just a
>> "recommends".
>> debathena / xsession / jdreed 15:11 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> I installed twm by hand on my machine
>> debathena / xsession / jdreed 15:11 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> and yes, TWM becomes an xsession option
>> debathena / xsession / ghudson 15:12 (Steel and circuits will
>> make me whole)
>> That's interesting, insofar as I think we had plans to
>> install a
>> bunch of window managers.
>> debathena / xsession / wdc 15:12 (rubber_ducky.sysdaemon)
>> My notes say tabbot checked in a change that causes
>> twm, mwm, wmaker, and ratpoison to be dependencies of
>> debathena-extra-software.
>> debathena / xsession / wdc 15:12 (rubber_ducky.sysdaemon)
>> s/tabbot/tabbott/
>> debathena / xsession / tabbott 15:12 (Timothy G Abbott)
>> Right, but that may not yet have been built in the Athena 10
>> repositories
>> debathena / xsession / andersk 15:12 (Anders Kaseorg)
>> It hasn’t been built in the Debathena repository at least.
>> debathena / xsession / jdreed 15:13 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> TWM provides /usr/share/xsessions/twm.desktop
>> debathena / xsession / andersk 15:15 (Anders Kaseorg)
>> After disabling the Last Session option, it seems the .dmrc
>> file is
>> ignored, even if it was edited by hand.
>> debathena / xsession / tabbott 15:15 (Timothy G Abbott)
>> hmm. For some reason I thought broder had uploaded
>> debathena-extra-software 0.7 in Debathena.
>> debathena / xsession / broder 15:15 (Evan Broder)
>> I've done very few uploads lately, so that's pretty unlikely
>> debathena / xsession.d / andersk 15:16 (Anders Kaseorg)
>> We should have a script that fetches all the source packages
>> from the
>> repository and compares them with svn.
>> debathena / xsession / tabbott 15:16 (Timothy G Abbott)
>> well, it is clear I was wrong.
>> debathena / xsession.d / tabbott 15:16 (Timothy G Abbott)
>> isn't that what ood-packages does?
>> debathena / xsession.d / broder 15:16 (Evan Broder)
>> Yes
>> debathena / xsession.d / broder 15:16 (Evan Broder)
>> I'm looking at its output now
>> debathena / xsession.d / tabbott 15:16 (Timothy G Abbott)
>> Can we set up a cron job that runs ood-packages and emails
>> debathena@
>> with the results?
>> debathena / xsession.d / tabbott 15:16 (Timothy G Abbott)
>> whenever there are any
>> debathena / xsession.d / broder 15:17 (Evan Broder)
>> Only if I can punt the obsolete packages from both repos first
>> debathena / xsession.d / tabbott 15:17 (Timothy G Abbott)
>> (or zephyrs the class, if we want it to be less annoying)
>> debathena / xsession / jdreed 15:18 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> If removing LastSession causes it to break for users who
>> want to install
>> something else (KDE), then we should keep it. I can live
>> with that.
>> However, we should do something to avoid having N window
>> managers in the
>> session window. Something that could easily be reverted by
>> local sysadmins
>> for example. It seems that changing the gdm search path is
>> the easiest, but
>> maybe there's a better way
>> debathena / xsession / andersk 15:19 (Anders Kaseorg)
>> Here’s the thing. Removing sessions from the GDM search
>> path means
>> that you can _never_ use those sessions, even by manually
>> editing
>> .dmrc.
>> debathena / xsession / ghudson 15:19 (Steel and circuits will
>> make me whole)
>> What about adding sessions earlier in the search path and
>> disabling them?
>> debathena / xsession / ghudson 15:19 (Steel and circuits will
>> make me whole)
>> (This came up as an option in yesterday's conversation.)
>> debathena / xsession / andersk 15:20 (Anders Kaseorg)
>> .dmrc uses the same search path as the Sessions menu. So if
>> you put
>> a fake session earlier in the search path with the same
>> name, .dmrc
>> will point to the fake session.
>> debathena / xsession / jdreed 15:22 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> Sure, but gdm.conf is a config file. It's designed to be
>> edited. So we
>> disable it as per geofft, and then create the following
>> stock answer:
>>
>> Q: How do I get other sessions, like KDE, GNOME, TWM, etc to
>> show up in the
>> GDM Greeter?
>>
>> A: Edit this one line in /etc/gdm.conf and reboot.
>> debathena / xsession / jdreed 15:22 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> /etc/gdm/gdm.conf, whatever
>> debathena / xsession / jdreed 15:23 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> It's not like we're hardcoding the search path in gdm.
>> debathena / xsession / andersk 15:24 (Anders Kaseorg)
>> It isn’t just about having those options show up in the GDM
>> greeter.
>> If the extra sessions aren’t in the path, that completely
>> prevents
>> those sessions from being used.
>> debathena / xsession / jdreed 15:25 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> Which path? I thought geofft's changes only affected
>> gdm.conf.debathena.
>> debathena / xsession / andersk 15:26 (Anders Kaseorg)
>> geofft’s change to gdm.conf was to replace
>>
>> SessionDesktopDir=/usr/share/gdm/BuiltInSessions/:/usr/share/
>> xsessions/:
>> /var/lib/menu-xdg/xsessions/:/etc/dm/Sessions/
>>
>> with a path that only consists of one directory that we
>> control.
>> debathena / xsession / andersk 15:26 (Anders Kaseorg)
>> This removes the alternative sessions from the menu, and also
>> prevents them from ever being used.
>> debathena / xsession / jdreed 15:26 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> So if someone wants to use them, they comment out our PATH
>> and uncomment
>> the default one. What's wrong with that?
>> debathena / xsession / andersk 15:27 (Anders Kaseorg)
>> Even then, they can only use that session on a machine they
>> control.
>> They won’t be able to use it on a cluster machine.
>> debathena / xsession / jdreed 15:27 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> And if they use it on a cluster machine, does gdm fail
>> miserably, or does it
>> give them the Athena session on a cluster machine? I really
>> don't care if
>> people can't use KDE on cluster machines, that's not what
>> cluster machines
>> are for.
>> debathena / xsession / wdc 15:28 (rubber_ducky.sysdaemon)
>> To add to confusion: We were going to tell people "Write
>> your own
>> .xsession file if you wanted a special window manager," by way
>> of de-supporting the WINDOW_MANAGER .environment variable.
>> debathena / xsession / jdreed 15:29 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> Let's not add to confusion right now, since we've just
>> narrowed everything
>> down
>> debathena / xsession / jdreed 15:30 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> I have confirmed that if I select a session type which is
>> not installed,
>> I get a prompted that says "What do you want to do." One of
>> the buttons is
>> "Just log in", and that works.
>> debathena / xsession / wdc 15:30 (rubber_ducky.sysdaemon)
>> Alas, the confusion is relevant because we're debating now
>> whether or not
>> it's ok for new window managers, slated to land in the
>> Cluster config,
>> should show up in the session menu.
>> debathena / xsession / andersk 15:30 (Anders Kaseorg)
>> > I really don't care if people can't use KDE on cluster
>> machines
>>
>> Is this just because we don’t install KDE? What about
>> WindowMaker,
>> which we do (will?) install?
>> debathena / xsession / jdreed 15:31 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> Then we put it in the directory which we control.
>> debathena / xsession / wdc 15:31 (rubber_ducky.sysdaemon)
>> jdreed: Sorry I don't understand that last comment by you.
>> debathena / xsession / jdreed 15:32 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> I was responding to Anders.
>> debathena / xsession / andersk 15:32 (Anders Kaseorg)
>> So you do want the window managers that we do install to be
>> in the
>> session menu?
>> debathena / xsession / amb 15:32 (xyloid xanthops)
>> Did I miss something? What new window managers are these?
>> We added some to the release,
>> but I don't think there was any intention of putting twm,
>> ratpoison, etc. into the login
>> menu.
>> debathena / xsession / jdreed 15:33 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> amb: Installing the twm package puts it in the menu, whether
>> we intend to or not
>> debathena / xsession / andersk 15:34 (Anders Kaseorg)
>> jdreed, what exactly are you proposing, then?
>> debathena / xsession / andersk 15:34 (Anders Kaseorg)
>> I think that what you’ve described is the upstream default,
>> which I
>> am arguing we should keep: all the window managers that are
>> installed
>> appear in the sessions menu.
>> debathena / xsession / jdreed 15:37 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> So, my proposal is the following:
>>
>> Change gdm.conf to look like this:
>>
>> #SessionDesktopDir=/usr/share/gdm/BuiltInSessions/:/usr/
>> share/xsessions/:\
>> /var/lib/menu-xdg/xsessions/:/etc/dm/Sessions
>> SessionDesktopDir=/usr/share/debathena-gdm-config/sessions
>>
>> Then /usr/share/debathena-gdm-config/sessions contains:
>>
>> athena.desktop (provides the word "Athena" in the login menu)
>> terminal.desktop (provides "Terminal-only" in hte login menu)
>>
>> and the failsafes.
>>
>> And then we tell people who want things like KDE, TWM, etc
>> in there on
>> their private workstations to uncomment the line in
>> gdm.conf, and comment
>> out our line.
>> debathena / xsession / jdreed 15:38 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> People who, say, have a .dmrc that refers to KDE, will get
>> asked what to do
>> on the cluster workstations. I think that's fine. People
>> may disagree with
>> me, however.
>> debathena / xsession / jdreed 15:38 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> The other option I see is to keep it as is, and leave all
>> the window managers
>> in the login menu, but then I still think we need to do
>> something about
>> "Xclient" vs "GNOME", since they're the same thing.
>> debathena / xsession / wdc 15:40 (rubber_ducky.sysdaemon)
>> An alternative is to embrace what upstream is doing, but to
>> divert
>> "run XClient Session" until its name changes, and let what
>> gets installed
>> actually affect the menus.
>> debathena / xsession / jdreed 15:40 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> bill: that's pretty much what I was suggesting for "the
>> other option"
>> debathena / xsession / andersk 15:40 (Anders Kaseorg)
>> The failsafe options are not session files. That is not
>> under the
>> scope of this issue.
>> debathena / xsession / jdreed 15:41 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> Right, i realized that after I sent it. Forget the
>> failsafes then
>> debathena / xsession / andersk 15:41 (Anders Kaseorg)
>> So that means that, even though TWM is installed on the cluster
>> machines, a user that has manually customized their session
>> to use
>> TWM will not be able to use TWM on the cluster machines.
>> debathena / xsession / wdc 15:41 (rubber_ducky.sysdaemon)
>> The problem with saying the failsafes are not in scope of
>> what we're talking
>> about is that they're presented as if they were persistent
>> sessions in
>> the UI we have. So we do nead to deal witn them in some way.
>> debathena / xsession / andersk 15:42 (Anders Kaseorg)
>> I did not say that we don’t need to deal with the failsafe
>> options in
>> some way. We do. That just isn’t what we’re talking about
>> right now.
>> debathena / xsession / wdc 15:42 (rubber_ducky.sysdaemon)
>> ok.
>> debathena / xsession / jdreed 15:43 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> anders: I don't understand why the TWM user fails in the
>> scenario you
>> described
>> debathena / xsession / andersk 15:44 (Anders Kaseorg)
>> Because their .dmrc points to the twm session, and under your
>> proposal, the twm session is not in the path on uncustomized
>> cluster
>> machines.
>> debathena / xsession / jdreed 15:45 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> Point. OK, then, let's assume we go with the default
>> upstream behavior,
>> and we stick all the supported window managers in the login
>> session. How
>> can we most non-offensively rename "Xclient script" to
>> "Normal session" or
>> something and have it at the top of the list.
>> debathena / xsession / wdc 15:45 (rubber_ducky.sysdaemon)
>> amb: Although it is a surprise to discover that installing a
>> new
>> window manager adds to the list of session options, do you
>> see how
>> embracing that approach has value?
>> debathena / xsession / andersk 15:47 (Anders Kaseorg)
>> (to address your second question first) It is at the top of
>> the
>> list, right?
>> debathena / xsession / wdc 15:47 (rubber_ducky.sysdaemon)
>> Re: Xclient script:
>> Options are: divert it into the void until it gets a name
>> we like, and
>> use GNOME.
>> divert it with a name we like and offer GNOME too.
>>
>> Is there a chance that upstream will delete it when it's
>> pointed out
>> that it's the same as GNOME?
>> debathena / xsession / broder 15:48 (Evan Broder)
>> It's only the same as GNOME because we default to GNOME,
>> right? If
>> you were a KDE user, then it would be the same as KDE, would
>> it not?
>> debathena / xsession / andersk 15:48 (Anders Kaseorg)
>> We cannot divert it into the void. Then people with the
>> default
>> session in their .dmrc get broken.
>> debathena / xsession / jdreed 15:49 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> Can we divert it and simply change the display name. I know
>> that's not
>> ideal, but it's also harmless (since I think the name
>> in .dmrc is the
>> filename, not the display name)
>> debathena / xsession / andersk 15:50 (Anders Kaseorg)
>> That is possible. It’s made slightly more difficult because
>> the name
>> is translated into fifty languages.
>> debathena / xsession / jdreed 15:51 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> Wow, and the comment in default.desktop even points out that
>> the name
>> sucks
>> debathena / xsession / andersk 15:51 (Anders Kaseorg)
>> This should definitely be reported as an upstream bug.
>> debathena / xsession / wdc 15:51 (rubber_ducky.sysdaemon)
>> This has taken me far too long to make sense of. I feel
>> really stupid...
>>
>> So the Default session runs Xclient. We configured Xclient
>> to use GNOME
>> as a default. But if we changed Xclient, we'd be running a
>> default
>> but one that would be different from GNOME? Have I got it now?
>> debathena / xsession / andersk 15:52 (Anders Kaseorg)
>> We did not change Xclient in any way.
>> debathena / xsession / jdreed 15:52 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> I don't think you have to translate it. Even in non-Latin
>> languages,
>> the word "Xclient" is still there. Just call it "Athena" in
>> every language.
>> debathena / xsession / andersk 15:52 (Anders Kaseorg)
>> In both upstream Ubuntu, and in Debathena now, the Xclient
>> option
>> defaults to doing the same thing as GNOME.
>> debathena / xsession / andersk 15:53 (Anders Kaseorg)
>> It is possible to configure Xclient to point to a different
>> session
>> (such as KDE) on a system-wide basis. This is what Kubuntu
>> does, for
>> example.
>> debathena / xsession / wdc 15:53 (rubber_ducky.sysdaemon)
>> Could someone state the "bug" we would report, and the name
>> we would
>> suggest upstream?
>> debathena / xsession / andersk 15:54 (Anders Kaseorg)
>> I think “Run Xclient script” should be renamed to “System
>> default
>> session”.
>> debathena / xsession / wdc 15:54 (rubber_ducky.sysdaemon)
>> andersk: You've clarified my sense of what's going on.
>> Maybe I stated
>> myself badly, but I think I get it now.
>> debathena / xsession / andersk 15:54 (Anders Kaseorg)
>> It should definitely be renamed upstream. The question is
>> whether
>> it’s worth changing this ourselves for Athena.
>> debathena / xsession / andersk 15:54 (Anders Kaseorg)
>> If we do change it for Athena, “System default session” is
>> still the
>> most accurate name.
>> debathena / xsession / jdreed 15:55 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> I think it's worth changing it for Athena to "System default
>> session"
>> If we care enough about the translations, I bet someone in
>> 21F can
>> help.
>> debathena / xsession / andersk 15:55 (Anders Kaseorg)
>> A name that involves Athena would be inaccurate, because it
>> is not
>> necessary to pick that session to get the Athena functionality.
>> debathena / xsession / wdc 15:55 (rubber_ducky.sysdaemon)
>> What do people think of diverting default.desktop to have
>> the name
>>
>> "System default session" rather than "Athena"? It's work to
>> translate,
>> but it's one less thing to maintain going forward.
>> debathena / xsession / wdc 15:56 (rubber_ducky.sysdaemon)
>> I think I saw some kind of Fedora (sorry guys) thing that
>> enabled
>> getting translations from the community WAY fast...
>> debathena / xsession / jdreed 15:57 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> I suspect going over to 14N and knocking on doors is even
>> faster, but sure.
>> debathena / xsession / andersk 15:57 (Anders Kaseorg)
>> If we’re going to put effort into doing translations, we
>> should first
>> get consensus from upstream that this is the right name to
>> pick, so
>> that they don’t have to duplicate effort.
>> debathena / xsession / wdc 15:58 (rubber_ducky.sysdaemon)
>> andersk: Yes.
>> We can then collaborate and maybe drive the change forward
>> offering
>> some translations ourselves.
>> debathena / xsession / jdreed 15:58 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> Agreed, but I don't think Athena 10 should block on an
>> upstream consensus.
>> debathena / xsession / andersk 16:03 (Anders Kaseorg)
>> Okay. I still don’t think that it matters enough to make
>> that change
>> for Athena 10 before upstream does, but it sounds like the
>> rest of
>> you do.
>> debathena / xsession / ghudson 16:05 (Steel and circuits will
>> make me whole)
>> I side with Anders on that point but weakly so, and from a
>> process
>> perspective I think it's wise to defer to the support person
>> (jdreed).
>> debathena / xsession / andersk 16:05 (Anders Kaseorg)
>> I will go ahead and revert geofft’s r23269, because it
>> sounds like we
>> have at least reached consensus that we don’t want to change
>> the
>> session path, right?
>> debathena / xsession / jdreed 16:06 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> Correct, though did we reach consensus about the permission
>> checks
>> changes he made?
>> debathena / xsession / wdc 16:06 (rubber_ducky.sysdaemon)
>> I'm gonna play facilitator and re-state the plan going forward:
>> 1. divert /usr/share/gdm/BuiltInSessions/default.desktop to
>> contain
>> "System Default Session" as the name in english instead of
>> "Run Xclient Script."
>> 2. Open an upstream bug to get this change in, and to
>> collaborate
>> in moving it forward.
>> 3. Report that "Secure Remote Connection" is broken and
>> divert it
>> until it is fixed.
>> 4. Leave in place the existing "Last Session" and session
>> search path
>> behavior.
>> 5. Continue with the plan to de-support $WINDOW_MANAGER in
>> dot files
>> but instead of telling people to write their own .xsession,
>> we tell
>> them to select the window manager they like from the session
>> list, and
>> to agree to make it their default.
>> debathena / xsession / andersk 16:06 (Anders Kaseorg)
>> Unclear. I’d rather revert the entire commit rather than
>> part of it,
>> because the history will be less confusing that way. We should
>> continue to discuss the permission checks.
>> debathena / xsession / jdreed 16:07 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> Fine. But yes, we should come to consensus on the
>> permission checks.
>> debathena / xsession / jdreed 16:08 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> Bill:
>>
>> Step 5 is not quite right. It's "Choose one from the list,
>> or write your
>> own .xsession if your preferred WM is not listed."
>> debathena / xsession / ghudson 16:08 (Steel and circuits will
>> make me whole)
>> I personally thought the zenity dialog was a good solution
>> to the
>> permissions checks problem.
>> debathena / xsession / wdc 16:08 (rubber_ducky.sysdaemon)
>> andersk: implicit in my proposal is that yes, jdreed and I
>> and others
>> feel strongly that waiting for upstream on this isn't such a
>> good idea.
>> debathena / xsession / amb 16:10 (xyloid xanthops)
>> What's the expected lag from "request upstream" to "new
>> package in our
>> intrepid repo"?
>> debathena / xsession / jdreed 16:10 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> ghudson: The zenity dialog is fine.
>> debathena / xsession / andersk 16:10 (Anders Kaseorg)
>> amb: Probably high to infinite unless we get very lucky. More
>> likely, the fix will make its way into Jaunty.
>> debathena / xsession / wdc 16:10 (rubber_ducky.sysdaemon)
>> What would the zenity dialog say, specifically?
>> debathena / xsession / jdreed 16:11 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> wdc: We have a Zenity dialog in place right now.
>> debathena / xsession / jdreed 16:11 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> It informs the user that they are cruft and that they
>> received an error
>> about .dmrc, and that they can fix it by typing chomd 755 $HOME
>> debathena / xsession / ghudson 16:12 (Steel and circuits will
>> make me whole)
>> I mean, I don't think it's really gdm's job to enforce a
>> permissions
>> model on .dmrc. But I'm also not sure it's our job to globally
>> change the gdm behavior to address a few crufty people's user
>> experience.
>> debathena / xsession / wdc 16:12 (rubber_ducky.sysdaemon)
>> "They are cruft"????
>> debathena / xsession / ghudson 16:13 (Steel and circuits will
>> make me whole)
>> No, it doesn't say that in so many words.
>> debathena / xsession / broder 16:13 (Evan Broder)
>> Nice to see we're focusing on the important part of the message
>> debathena / xsession / jdreed 16:13 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> No, of course it doesn't say that, which is why I didn't use
>> quotation marks
>> debathena / xsession / ghudson 16:13 (Steel and circuits will
>> make me whole)
>> message "Your home directory is mode $hm, probably because
>> it was created" \
>> "a long time ago. You likely received a spurious error
>> dialog about" \
>> ".dmrc as a result of the mode bits on your home directory.
>> To fix this" \
>> "condition, you can run: chmod 755 \$HOME"
>> debathena / xsession / wdc 16:13 (rubber_ducky.sysdaemon)
>> ghudson: Thank you.
>> debathena / xsession / wdc 16:14 (rubber_ducky.sysdaemon)
>> Do we see any other compelling reason to accept geofft's
>> mode changes?
>> debathena / xsession / jdreed 16:15 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> The only advantage of geofft's changes is that without them,
>> users are likely
>> to see the first message, panic, and call OLC before they
>> get to the Zenity
>> dialog. But I'm not sure how much I care.
>> We could also just chmod people's homedirs, I suppose. Or
>> send them mail.
>> debathena / xsession / andersk 16:18 (Anders Kaseorg)
>> It is possible that software other than GDM also has overly
>> strict
>> permission checking, and therefore a warning is still useful
>> to those
>> users.
>> debathena / xsession / andersk 16:19 (Anders Kaseorg)
>> Certainly ssh has such checks under some circumstances.
>> debathena / xsession / jdreed 16:20 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> Then I will support reverting the changes and leaving it as
>> is (ie: with
>> the zenity dialog). I believe Greg counted the users with
>> 777 homedirs at
>> some point, and the number was fairly low.
>> debathena / xsession / andersk 16:21 (Anders Kaseorg)
>> Great. I’ll mail a zlog of this conversation to debathena@
>> in reply
>> to the thread so we don’t lose it, and we can proceed
>> accordingly.
>> debathena / xsession / jdreed 16:21 (This zephyr does not
>> necessarily reflect the views of IS&T, MIT, its)
>> "10% of accounts", so *shrug*.
>>
>> If we start seeing a flood of people calling about it, I'll
>> consider
>> proactively sending email
