On Tue, Feb 10, 2009 at 10:57 AM, Justin M. Wray <[email protected]> wrote: > Even if a new user is unfamiliar with the key combination, it only takes a > little education OR them doing it once. Lessons are learned hard. >
This is poorly conceived thinking, but switching it off is straight up naive. "This is a power user tool and can accidently happen, and is bad when accidents happen, so let's take it away." Knee-jerk reaction to dumb down the system. The correct solution is not dead-simple to implement, but it works: When you C-A-B, grab the whole screen and put up a confirmation dialog like gksudo does. You can't switch desktops off it (CAB happens sometimes while swapping around virtual desktops and landing in a text editor, trying to backspace over stuff), and it's right in your face. It says "In 10 seconds I will kill X and reload it. This will destroy all of your work. Click the big red CANCEL button below now or hit SPACE!" If the X server is frozen, the dialog can't be shown, can't be clicked, can't be touched. All you have to do is modify X to take an option "ZapProgram" "/usr/bin/uzapme" which gets the $DISPLAY environment passed to it. uzapme reads the user's configuration, executes a child "gzapme" or "kazzapme" and waits 10 seconds for the child to return. If the child doesn't exit favorably, i.e. complains it can't draw on X or just hangs (because of no user input, or because it tried to talk to X and got hung up), uzapme kills it and returns an unfavorable state to X. X then executes the ZAP code. This works because it relies on X's zap code to be executed. If CAB can cause X to exit, then it can instead cause X to run a child process and wait() for a result. If doing such would inherently hang and fail to terminate X under conditions of the child returning status "ESCREWTHISTERMINATEX" then obviously X is so borked right now that the zap code wouldn't have functioned anyway and you would have had to unplug it and plug it back in. > Should we remove all the abilities that may "damage" the system? > No, just throw up a single safety net. For many unsafe operations this is '-f', so on a real (not Fedora) system you 'rm -r /' and it goes "do you want to remove these files?" because you probably did something damaging; whereas you 'rm -rf /' and it goes "oh, you know what you doing, move zig." If the user's dumb enough to use '--force-all' or not click a button marked "Press this or your computer is effectively going to crash," it's now officially his fault. > Where does the line get drawn? > Usually in the sand, but sometimes on paper. In HTML the line gets drawn at an <hr> tag. > The C-A-B is an easy thing to learn and avoid, but a powerful resource when > needed. > Same argument for magic sysrq keys... not for non-power-users, some people just want the OS to get out of the way. The REAL solution is to run everything through an X proxy that can lose the X server head, like 'screen' for X. > Sent via BlackBerry by AT&T > > -----Original Message----- > From: Dylan McCall <[email protected]> > > Date: Tue, 10 Feb 2009 07:02:51 > To: Clive Wagenaar<[email protected]> > Cc: <[email protected]> > Subject: Re: Fwd: Is disabling ctrl-alt-backspace really such a good idea? > > >> I agree with this guy, have it on by default, noobs can use GUI to switch it >> off. >> >> Else, millions of users will be doing this on first boot up: >> >> alt f2 >> gksudo gedit /etc/X11/xorg.conf >> >> Section "ServerFlags" >> Option "DontZap" "no" >> EndSection > > The important thing is that those millions of users actually don't > mind tinkering with xorg.conf and probably do anyway. The users we are > trying to help, however, Don't Know The Key Combo Exists, or that > xorg.conf exists, or that they need to explicitly tell the system how > to be easier to them, until it is too late. They don't want to do any > extra configuration after installing the operating system. Those > millions of power-users do. > > It astounds me how people just forget about Ubuntu's goals and > aspiritions in light of this issue. It isn't doing much for user > friendliness when the community of contributors is using bad names on > those new users Ubuntu strives to be gentle to and then treating them > like outsiders. > > It isn't /likely/ for someone to hit C-A-B (although it's been done > once or twice by yours truly, particularly with graphics tools), but > the immediate issue is that we have a key combination which, without a > moment's question, eradicates one's session from existence. No session > saving, no notice, no sensitivity to whether the keyboard is grabbed > or another application is handling the event. It just happens no > matter what. Further, it relies on common keys. Sysrq K is alright > since nobody tends to use the Sys RQ key, but Ctrl and Alt are both > everyday modifier keys and Backspace is a natural key for deleting > stuff. We want our users to feel free exploring Ubuntu without the > risk of wiping out the system (within reason, of course). Hopefully > they can gain a trust of themselves and the system that way, start > paying more attention to the text on the screen and learning what it > all means. One thing I know is that a single catastrophic event like > "tinkering led to the loss of two hour's work when I pressed Ctrl Alt > Backspace" causes someone to doubt the value of that exploring. Then > there's another user reliant on others for resolving all issues > related to the computer. > > Something interesting I've learned in an Ubuntu Forums thread is that > a surprising number of people who want this key combo to stay don't > actually use it for its intended purpose (to reset X when it is > crashed). Instead, they use it as a shortcut for logging out. Doing > that is risky, messy and inadequate. > Perhaps if logging out (with session saving) was mapped to Ctrl Alt > Backspace we wouldn't have as many bothered users. > > > Bye, > -Dylan > > -- > Ubuntu-devel-discuss mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss > -- > Ubuntu-devel-discuss mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss > -- Ubuntu-devel-discuss mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
