Thomas, Thank you for letting me know what additional information I needed to provide. I will get it as soon as I have an opportunity. I really appreciate the help. As for the whole C-A-B issue... yes, honestly, dude, I wish that I never had to use C-A-B. But I do. I report bugs when I'm reasonably sure its not just me messing up, but I can't find everything. Nor do I have the time to file a report for everything I encounter (I wish I did). *** In order to fix bugs, we need people that are able and willing to track *** down the issues. No. Technically what you say is true. But realistically, it is not. It is not a valid assumption that any given user X will ever file a bug report. Yes, many users do, nearly all that I know personally... but to assume that a specific user will do so is a fallacy. And completely separate from that consideration: I ask again. What do the users who do file a bug report, and who do have a legitimate problem, and who do try to troubleshoot the issue as much as they can, but who experience the same problem that is most easily worked around by calling C-A-B do in the meantime, while they are waiting for their bug to be fixed or trying to fix it themselves? You say that any user who reasonably could do all of those above things will modify their configuration files. I say that that is an unreasonable assumption. People can file reports on behalf of other people, while the original person who experiences the problem is still effectively SOL. Whether it was intended to be a feature or not when it was first implemented, many users consider that hot-key sequence to be a feature, not a hack. The intended purpose for a operation in software is irreverent if a user continually uses something for an operation which it was not originally intended for. Either that new user defined purpose is appended to the original intended use, or it replaces that intended use. Arguing that C-A-B should be removed on the merits of it being accidentally activated is a perfectly legitimate argument. I agree that it HAS happened to me in the past. But I disagree that it should be completely removed. I disagree that I should be forced to edit a configuration file to restore the functionality (regardless of how trivially easy it is). Changing the activation sequence is one thing. Removing the functionality from on the fly access is entirely different. Could we not compromise? <div class="gmail_quote">On Fri, Feb 13, 2009 at 4:49 PM, Thomas Jaeger <<a href="mailto:thjaeger@gmail.com">thjaeger@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="Ih2E3d">Mike Jones wrote: > It is unreasonable to expect even users who have programing experience to > use the terminal for honestly much more than occasional scripts. I have > absolutely no desire to C-A-F#, find the program that is giving me fits, and > then kill it in the hopes it fixes my issue. </div>In order to fix bugs, we need people that are able and willing to track down the issues. <div class="Ih2E3d"> > > >> I'm one of those users who would prefer that the C-A-B command be left >> as it is, or be modified to allow the ability through some other > interface: >> such as twice successive. >> >> I have filed several bug reports about issues related to problems with >> X, <a href="https://bugs.launchpad.net/bugs/289898" target="_blank">https://bugs.launchpad.net/bugs/289898</a> for example. > This is a kernel bug. I would be very surprised if C-A-B worked here. > > > C-A-B does not work in that instance, you are correct. But since you seem to > know so much about it, could you please provide a fix for me? I have been > unable to figure out anything beyond what I reported already. </div>There's no useful information in that bug report. What you need is a dmesg from after the bug has happened if possible, or a backtrace if it's a kernel panic (flashing leds). See <a href="https://wiki.ubuntu.com/KernelTeamBugPolicies#Capturing%20OOPs" target="_blank">https://wiki.ubuntu.com/KernelTeamBugPolicies#Capturing%20OOPs</a> and <a href="https://help.ubuntu.com/community/DebuggingSystemCrash" target="_blank">https://help.ubuntu.com/community/DebuggingSystemCrash</a> . You'll probably need to forward the bug upstream once you've gathered the necessary information, it doesn't look like anybody's working on it. <div class="Ih2E3d"> >> But the problem is still going to be there for that person from when they >> originally filed the bug until the problem has been tracked down, until a >> fix has been written, until its been tested to not break anything, until > its >> been patched to the package, until the package as been released, and > finally >> the package has been downloaded (and in the case of things like the > kernal, >> and graphics support) until the computer (or X) has been restarted. > This is why we need to figure out if there's some sort of pattern behind > the problems people are seeing. > > I agree with John Moser. Allow the user to go back to work, and > automatically file a bug report using the apport interface. I assume thats > why apport exists, to catch crashes and report them when possible. > Otherwise... why does it pop up on my screen whenever a program crashes..? </div>Except that apparently most of the issues that people are solving with C-A-B have nothing to do with the X server. <div class="Ih2E3d"> > Thomas, do you mind if I ask why you seem so adamant that C-A-B stay > disabled? If we change it to A-S-K the accidental activation problem has a > (in my opinion much) lower risk, but the workaround still exists for when > people need it to. Would changing to A-S-K be acceptable to you? Or is there > another underlying issue? </div>A-S-K has always been there for people that need to do kernel debugging. Nobody else should ever have to deal with it and neither should we rely on C-A-B. It's just a bad way of dealing with problems. </blockquote></div>