Fwd: Is disabling ctrl-alt-backspace really such a good idea? - no.

Mike Jones eternalorb at gmail.com
Fri Feb 13 22:28:40 UTC 2009


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?



On Fri, Feb 13, 2009 at 4:49 PM, Thomas Jaeger <thjaeger at gmail.com> wrote:

> 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.
> In order to fix bugs, we need people that are able and willing to track
> down the issues.
>
> >
> >
> >>     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, https://bugs.launchpad.net/bugs/289898 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.
> 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 https://wiki.ubuntu.com/KernelTeamBugPolicies#Capturing%20OOPs and
> https://help.ubuntu.com/community/DebuggingSystemCrash .  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.
>
> >> 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..?
>
> Except that apparently most of the issues that people are solving with
> C-A-B have nothing to do with the X server.
>
> >     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?
>
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20090213/1fa1774f/attachment.html>


More information about the Ubuntu-devel-discuss mailing list