I was reading through the F11A Release Notes when I came across this:
"The key combination Ctrl-Alt-Backspace to kill the X server has been disabled by default as a decision of the upstream Xorg project."
Having to deal with many servers and workstations in a company it is crucial that Ctrl-Alt-Backspace be enabled by default. There are times when your KVM has lost mouse control or X is in a tight loop and something like Ctrl-Alt-Backspace can save the situation. This is much more common than the uncommon cases that are illustrated as to why this has been removed as default.
Ctrl-Alt-Backspace needs to be restored as the "default" and Emacs users or others that find themselves in conflict with Java expressions can just disable it for their very limited purpose.
Regards, Gerry
On Fri, 2009-03-27 at 16:31 -0400, Gerry Reno wrote:
I was reading through the F11A Release Notes when I came across this:
"The key combination Ctrl-Alt-Backspace to kill the X server hasbeen disabled by default as a decision of the upstream Xorg project."
Having to deal with many servers and workstations in a company it is crucial that Ctrl-Alt-Backspace be enabled by default. There are times when your KVM has lost mouse control or X is in a tight loop and something like Ctrl-Alt-Backspace can save the situation. This is much more common than the uncommon cases that are illustrated as to why this has been removed as default.
Ctrl-Alt-Backspace needs to be restored as the "default" and Emacs users or others that find themselves in conflict with Java expressions can just disable it for their very limited purpose.
aaaaaaagh, here comes the zombie thread again...run! run for your lives!
If it is configurable post-install or through a script in a kickstart file then I think it is a solid idea to comply with the direction that upstream is headed.
Just my opinion, -Adam
Adam Miller wrote:
If it is configurable post-install or through a script in a kickstart file then I think it is a solid idea to comply with the direction that upstream is headed.
Just my opinion, -Adam
That's totally ridiculous for sys admins to know have to prepare a kickstart file for all future Fedora installs. Upstream made a bad decision.
Regards, Gerry
On Fri, Mar 27, 2009 at 9:55 PM, Gerry Reno greno@verizon.net wrote:
Upstream made a bad decision.
Well, then maybe you should try to convince upstream to put back the old default?
note: I'll also miss the combo...
Gianluca Sforna wrote:
On Fri, Mar 27, 2009 at 9:55 PM, Gerry Reno greno@verizon.net wrote:
Upstream made a bad decision.
Well, then maybe you should try to convince upstream to put back the old default?
note: I'll also miss the combo...
For right now I'd like Fedora to ignore this really bad upstream decision and put back the X default behavior that has been there for decades. We can take it to upstream after this.
Regards, Gerry
-------- Original Message -------- Subject: Re: F11: xorg decision to disable Ctrl-Alt-Backspace From: Gianluca Sforna giallu@gmail.com To: Development discussions related to Fedora fedora-devel-list@redhat.com Date: 03/27/2009 03:58 PM
On Fri, Mar 27, 2009 at 9:55 PM, Gerry Reno greno@verizon.net wrote:
Upstream made a bad decision.
Well, then maybe you should try to convince upstream to put back the old default?
note: I'll also miss the combo...
The correct way of handling this would have been to keep the current default of enabled and Fedora should create an xorg.conf with this turned on. Anyone who is upgrading won't be affected, just new installs.
I'm positive when F11 is released we will see thread after thread after thread after thread of people whining about not being able to CTRL+ALT+BKSP.
No. No one reads release notes. You can make them as pretty as you like, but no one will read them.
I'd suggest filing a bug in Red Hat and X.org about it. If they get closed then whine on the mailing list some more. This decision really was not handled well.
P.S. I don't use emacs.
Adam Williamson wrote:
On Fri, 2009-03-27 at 16:31 -0400, Gerry Reno wrote:
I was reading through the F11A Release Notes when I came across this:
"The key combination Ctrl-Alt-Backspace to kill the X server hasbeen disabled by default as a decision of the upstream Xorg project."
Having to deal with many servers and workstations in a company it is crucial that Ctrl-Alt-Backspace be enabled by default. There are times when your KVM has lost mouse control or X is in a tight loop and something like Ctrl-Alt-Backspace can save the situation. This is much more common than the uncommon cases that are illustrated as to why this has been removed as default.
Ctrl-Alt-Backspace needs to be restored as the "default" and Emacs users or others that find themselves in conflict with Java expressions can just disable it for their very limited purpose.
aaaaaaagh, here comes the zombie thread again...run! run for your lives!
Well, sorry, didn't mean to hit some nerve. But, having Ctrl-Alt-Backspace is critical to system admins and most users. Only Emacs users have a problem with this and they are how much of the total distro population? (two fingers pinched). All the virtualization tools rely upon Ctrl-Alt-Backspace to restart X and you'll find it on all their menues.
Regards, Gerry
On 3/27/2009 4:45 PM, Adam Williamson wrote:
On Fri, 2009-03-27 at 16:31 -0400, Gerry Reno wrote:
I was reading through the F11A Release Notes when I came across this:
"The key combination Ctrl-Alt-Backspace to kill the X server hasbeen disabled by default as a decision of the upstream Xorg project."
Having to deal with many servers and workstations in a company it is crucial that Ctrl-Alt-Backspace be enabled by default. There are times when your KVM has lost mouse control or X is in a tight loop and something like Ctrl-Alt-Backspace can save the situation. This is much more common than the uncommon cases that are illustrated as to why this has been removed as default.
Ctrl-Alt-Backspace needs to be restored as the "default" and Emacs users or others that find themselves in conflict with Java expressions can just disable it for their very limited purpose.
aaaaaaagh, here comes the zombie thread again...run! run for your lives!
Hi Adam. Welcome to Fedora. I missed you since leaving some time ago.. well where you just left.
You will find that the 'same nuts' are here as there. They just have different names. 8-)
I'm sure many of us are used to hacking xorg.conf with:
Section "ServerFlags" Option "DontZap" "1" EndSection
A change to the default just means that people who care in the other direction need that same thing with s/1/0/ in their habits or kickstart %post.
Neither of these is very satisfactory to me.
Where this really belongs in with the user "keyboard shortcuts" preferences settings, so each desktop user gets it the way they want it. Then really nobody will care which way the default is, it's just a user preference.
(I understand why this is magically different from other keyboard config things, but I don't really care what the preferences magic does behind the curtain if it makes it work.)
All that said, in my experience when C-M-DEL works, C-M-Fn also works to switch VTs, with the same level of how-bad-the-session-is-borked affecting whether the X server magic hotkeys work. So, C-M-F3 and use the console login to go kill it pretty much always works for the scenarios you are worried about.
Thanks, Roland
Roland McGrath wrote:
I'm sure many of us are used to hacking xorg.conf with:
Section "ServerFlags" Option "DontZap" "1" EndSection
A change to the default just means that people who care in the other direction need that same thing with s/1/0/ in their habits or kickstart %post.
Neither of these is very satisfactory to me.
Where this really belongs in with the user "keyboard shortcuts" preferences settings, so each desktop user gets it the way they want it. Then really nobody will care which way the default is, it's just a user preference.
(I understand why this is magically different from other keyboard config things, but I don't really care what the preferences magic does behind the curtain if it makes it work.)
All that said, in my experience when C-M-DEL works, C-M-Fn also works to switch VTs, with the same level of how-bad-the-session-is-borked affecting whether the X server magic hotkeys work. So, C-M-F3 and use the console login to go kill it pretty much always works for the scenarios you are worried about.
Thanks, Roland
Just how do I sent that to a VM from a VMM? Ctrl-Alt-Backspace is the menu selection. And this behavior has been a part of X as I said, for decades.
Regards, Gerry
Gerry Reno wrote:
Roland McGrath wrote:
I'm sure many of us are used to hacking xorg.conf with:
Section "ServerFlags" Option "DontZap" "1" EndSection
A change to the default just means that people who care in the other direction need that same thing with s/1/0/ in their habits or kickstart %post.
Neither of these is very satisfactory to me.
Where this really belongs in with the user "keyboard shortcuts" preferences settings, so each desktop user gets it the way they want it. Then really nobody will care which way the default is, it's just a user preference.
(I understand why this is magically different from other keyboard config things, but I don't really care what the preferences magic does behind the curtain if it makes it work.)
All that said, in my experience when C-M-DEL works, C-M-Fn also works to switch VTs, with the same level of how-bad-the-session-is-borked affecting whether the X server magic hotkeys work. So, C-M-F3 and use the console login to go kill it pretty much always works for the scenarios you are worried about.
Thanks, Roland
Just how do I sent that to a VM from a VMM? Ctrl-Alt-Backspace is the menu selection. And this behavior has been a part of X as I said, for decades.
This change to default behavior of Ctrl-Alt-Backspace is an example of a tiny minority of Emacs users lobbying xorg for a change that will affect a huge number of community and commercial users including datacenters and their sys admins. This change needs to be reversed immediately. Ctrl-Alt-Backspace is embedded now into many tools including all the virtualization tools. It is part of the DNA of every sys admin. To change this behavior is just insanity.
Regards, Gerry
This change to default behavior of Ctrl-Alt-Backspace is an example of a tiny minority of Emacs users lobbying xorg for a change that will affect a huge number of community and commercial >users including datacenters and their sys admins. This change needs to be reversed immediately. Ctrl-Alt-Backspace is embedded now into many tools including all the virtualization tools. It is >part of the DNA of every sys admin. To change this behavior is just insanity.
Regards, Gerry
Please stop throwing around the "sys admins will freak out" card, I'm a sys admin and we do things correctly through provisioning using kickstarts. It will be maybe a 3 line edit to a script. It was an upstream choice, Fedora has historically remained compliant with upstream so I imagine if you would like a change to be made on this topic it would be most effective to discuss it with upstream.
-Adam
Adam Miller wrote:
This change to default behavior of Ctrl-Alt-Backspace is an example of a tiny minority of Emacs users lobbying xorg for a change that will affect a huge number of community and commercial >users including datacenters and their sys admins. This change needs to be reversed immediately. Ctrl-Alt-Backspace is embedded now into many tools including all the virtualization tools. It is >part of the DNA of every sys admin. To change this behavior is just insanity.
Regards, Gerry
Please stop throwing around the "sys admins will freak out" card, I'm a sys admin and we do things correctly through provisioning using kickstarts. It will be maybe a 3 line edit to a script. It was an upstream choice, Fedora has historically remained compliant with upstream so I imagine if you would like a change to be made on this topic it would be most effective to discuss it with upstream.
-Adam
I intend to discuss it with upstream. But this is a huge change to default behavior for X control that almost NO ONE knows about. The default methods of controlling the X server have been around for decades and many users and sys admins automatically know what the default behavior is that can be counted on in almost all situations and therefore this constitutes a big change. And big changes like this need to be advertised extensively instead of just quietly slipped in. I was hoping that Fedora might take the lead on stopping this bad change. And again, yes, I'll take this to upstream as well.
Regards, Gerry
2009/3/27 Gerry Reno greno@verizon.net:
Adam Miller wrote:
This change to default behavior of Ctrl-Alt-Backspace is an example of a tiny minority of Emacs users lobbying xorg for a change that will affect a huge number of community and commercial >users including datacenters and their sys admins. This change needs to be reversed immediately. Ctrl-Alt-Backspace is embedded now into many tools including all the virtualization tools. It is >part of the DNA of every sys admin. To change this behavior is just insanity.
Regards, Gerry
Please stop throwing around the "sys admins will freak out" card, I'm a sys admin and we do things correctly through provisioning using kickstarts. It will be maybe a 3 line edit to a script. It was an upstream choice, Fedora has historically remained compliant with upstream so I imagine if you would like a change to be made on this topic it would be most effective to discuss it with upstream.
-Adam
I intend to discuss it with upstream. But this is a huge change to default behavior for X control that almost NO ONE knows about. The default methods of controlling the X server have been around for decades and many users and sys admins automatically know what the default behavior is that can be counted on in almost all situations and therefore this constitutes a big change. And big changes like this need to be advertised extensively instead of just quietly slipped in. I was hoping that Fedora might take the lead on stopping this bad change. And again, yes, I'll take this to upstream as well.
Solution, ask people to include it in the Release Notes, where it belongs, and let sysadmins act appropriately. This is how things are done in Fedora.
-Yaakov
Yaakov Nemoy wrote:
2009/3/27 Gerry Reno greno@verizon.net:
Adam Miller wrote:
This change to default behavior of Ctrl-Alt-Backspace is an example of a tiny minority of Emacs users lobbying xorg for a change that will affect a huge number of community and commercial >users including datacenters and their sys admins. This change needs to be reversed immediately. Ctrl-Alt-Backspace is embedded now into many tools including all the virtualization tools. It is >part of the DNA of every sys admin. To change this behavior is just insanity.
Regards, Gerry
Please stop throwing around the "sys admins will freak out" card, I'm a sys admin and we do things correctly through provisioning using kickstarts. It will be maybe a 3 line edit to a script. It was an upstream choice, Fedora has historically remained compliant with upstream so I imagine if you would like a change to be made on this topic it would be most effective to discuss it with upstream.
-Adam
I intend to discuss it with upstream. But this is a huge change to default behavior for X control that almost NO ONE knows about. The default methods of controlling the X server have been around for decades and many users and sys admins automatically know what the default behavior is that can be counted on in almost all situations and therefore this constitutes a big change. And big changes like this need to be advertised extensively instead of just quietly slipped in. I was hoping that Fedora might take the lead on stopping this bad change. And again, yes, I'll take this to upstream as well.
Solution, ask people to include it in the Release Notes, where it belongs, and let sysadmins act appropriately. This is how things are done in Fedora.
-Yaakov
Please read the entire thread before responding to very early postings. The discussion has moved well beyond this point.
Regards, Gerry
Yaakov Nemoy wrote:
2009/3/27 Gerry Reno greno@verizon.net:
Adam Miller wrote:
This change to default behavior of Ctrl-Alt-Backspace is an example of a tiny minority of Emacs users lobbying xorg for a change that will affect a huge number of community and commercial >users including datacenters and their sys admins. This change needs to be reversed immediately. Ctrl-Alt-Backspace is embedded now into many tools including all the virtualization tools. It is >part of the DNA of every sys admin. To change this behavior is just insanity.
Regards, Gerry
Please stop throwing around the "sys admins will freak out" card, I'm a sys admin and we do things correctly through provisioning using kickstarts. It will be maybe a 3 line edit to a script. It was an upstream choice, Fedora has historically remained compliant with upstream so I imagine if you would like a change to be made on this topic it would be most effective to discuss it with upstream.
-Adam
I intend to discuss it with upstream.� But this is a huge change to default behavior for X control that almost NO ONE knows about.� The default methods of controlling the X server have been around for decades and many users and sys admins automatically know what the default behavior is that can be counted on in almost all situations and therefore this constitutes a big change.� And big changes like this need to be advertised extensively instead of just quietly slipped in.� I was hoping that Fedora might take the lead on stopping this bad change.� And again, yes, I'll take this to upstream as well.
Solution, ask people to include it in the Release Notes, where it belongs, and let sysadmins act appropriately. This is how things are done in Fedora.
-Yaakov
again i'll point out that fedora has always had packages that are different from upstream, why should this be any different?
phil
On 03/27/2009 02:28 PM, Adam Miller wrote:
This change to default behavior of Ctrl-Alt-Backspace is an example of a tiny minority of Emacs users lobbying xorg for a change that will affect a huge number of community and commercial>users including datacenters and their sys admins. This change needs to be reversed immediately. Ctrl-Alt-Backspace is embedded now into many tools including all the virtualization tools. It is>part of the DNA of every sys admin. To change this behavior is just insanity.
Regards, Gerry
Please stop throwing around the "sys admins will freak out" card, I'm a sys admin and we do things correctly through provisioning using kickstarts. It will be maybe a 3 line edit to a script. It was an upstream choice, Fedora has historically remained compliant with upstream so I imagine if you would like a change to be made on this topic it would be most effective to discuss it with upstream.
Also, won't Ctrl+Alt+<Fn> still work to get you to a vt where you can at your choice kill X manually, or try to debug the problem further?
Christopher Aillon wrote:
Also, won't Ctrl+Alt+<Fn> still work to get you to a vt where you can at your choice kill X manually, or try to debug the problem further?
From a previous post in thread: Just how do I sent that to a VM from a VMM? Ctrl-Alt-Backspace is the menu selection. And this behavior has been a part of X as I said, for decades.
Many tools have already embedded Ctrl-Alt-Backspace and they count on it's availability to function.
Regards, Gerry
On Fri, 2009-03-27 at 17:52 -0400, Gerry Reno wrote:
Christopher Aillon wrote:
Also, won't Ctrl+Alt+<Fn> still work to get you to a vt where you can at your choice kill X manually, or try to debug the problem further?
From a previous post in thread: Just how do I sent that to a VM from a VMM? Ctrl-Alt-Backspace is the menu selection. And this behavior has been a part of X as I said, for decades.
Many tools have already embedded Ctrl-Alt-Backspace and they count on it's availability to function.
So whoever wrote those tools confused a configurable keybinding with a supported api. It certainly highlights why it is a good idea to turn it off by default: it is a loaded weapon that random clients can use to kill your session.
No one has yet said what is supposed to happen when X on a desktop inevitably starts with the incorrect resolution. At the very least I could restart X easily. Now I need to log in then restart X? And what about regular users? Do I have to now instruct them to login as root and kill X?
Arthur Pemberton wrote:
No one has yet said what is supposed to happen when X on a desktop inevitably starts with the incorrect resolution. At the very least I could restart X easily. Now I need to log in then restart X? And what about regular users? Do I have to now instruct them to login as root and kill X?
I'm trying to understand how the problem of bad config relates to this xorg disabling Ctrl-Alt-Backspace discussion? I mean I could remotely login into the users terminal and fix their xorg.conf and then just tell them to hit Ctrl-Alt-Backspace and that should fix them up and if not I'll kill their X server. Or is there some other situation you're referring to?
Regards, Gerry
On Fri, Mar 27, 2009 at 5:46 PM, Gerry Reno greno@verizon.net wrote:
Arthur Pemberton wrote:
No one has yet said what is supposed to happen when X on a desktop inevitably starts with the incorrect resolution. At the very least I could restart X easily. Now I need to log in then restart X? And what about regular users? Do I have to now instruct them to login as root and kill X?
I'm trying to understand how the problem of bad config relates to this xorg disabling Ctrl-Alt-Backspace discussion? I mean I could remotely login into the users terminal and fix their xorg.conf and then just tell them to hit Ctrl-Alt-Backspace and that should fix them up and if not I'll kill their X server. Or is there some other situation you're referring to?
Regards, Gerry
I am referring to Bug #490082 which requires (apparently) every Fedora install which boots with the monitor off to restart X somehow. Removing Cltr+Alt+Backspace makes this bug even more annoying.
Once upon a time, Matthias Clasen mclasen@redhat.com said:
So whoever wrote those tools confused a configurable keybinding with a supported api.
I don't believe that the Zap function is a configurable keybinding. It can only be triggered by Ctrl+Alt+Backspace.
Also, for those recommending Ctrl+Alt+Fn to switch to a text console: that requires more cooperation from the X server (and functioning graphics). I've had X hose the graphics, be unable to restore a text console, but an X restart re-initialized the hardware back to a working state.
On Fri, Mar 27, 2009 at 06:14:15PM -0500, Chris Adams wrote:
Once upon a time, Matthias Clasen mclasen@redhat.com said:
So whoever wrote those tools confused a configurable keybinding with a supported api.
I don't believe that the Zap function is a configurable keybinding. It can only be triggered by Ctrl+Alt+Backspace.
You believe wrongly. It's the Terminate_Server symbol, and you can bind it to whatever you want with XKB.
Now, arguably, a better approach would have been to leave DontZap as the default but remove the Terminate_Server entry from the default XKB maps. That would let clients rebind it if they want to, which can be done without requiring administrative privileges.
Matthew Garrett wrote:
On Fri, Mar 27, 2009 at 06:14:15PM -0500, Chris Adams wrote:
Once upon a time, Matthias Clasen mclasen@redhat.com said:
So whoever wrote those tools confused a configurable keybinding with a supported api.
I don't believe that the Zap function is a configurable keybinding. It can only be triggered by Ctrl+Alt+Backspace.
You believe wrongly. It's the Terminate_Server symbol, and you can bind it to whatever you want with XKB.
Now, arguably, a better approach would have been to leave DontZap as the default but remove the Terminate_Server entry from the default XKB maps. That would let clients rebind it if they want to, which can be done without requiring administrative privileges.
I also made a suggestion upstream that to protect Emacs users, the default Ctrl-Alt-Backspace could be left enabled but that it would have to be pressed TWICE in order to kill the X server. This way tools that embed the Ctrl-Alt-Backspace keysequence such as virtualization tools would still work. The user would just have to select it twice from the menu. And this would be a lot more acceptable than just disabling the Ctrl-Alt-Backspace default.
Regards, Gerry
On Fri, Mar 27, 2009 at 7:14 PM, Chris Adams cmadams@hiwaay.net wrote:
Once upon a time, Matthias Clasen mclasen@redhat.com said:
So whoever wrote those tools confused a configurable keybinding with a supported api.
I don't believe that the Zap function is a configurable keybinding. It can only be triggered by Ctrl+Alt+Backspace.
Also, for those recommending Ctrl+Alt+Fn to switch to a text console: that requires more cooperation from the X server (and functioning graphics). I've had X hose the graphics, be unable to restore a text console, but an X restart re-initialized the hardware back to a working state.
I've always found it amusing that it takes a more convoluted key sequence to disconnect a hung ssh session (\n~.) then it does to kill X, and I've longed for a way to get something similar to the Hayes attention command delay (is that still patented? :) ) for X termination.
-Greg (Who has inadvertently killed X more than a few times in ways totally unrelated to emacs over the years; and whom has not had working zap for some time due to xmodmap swapping left-ctrl and capslock apparently breaking it)
I intend to discuss it with upstream. But this is a huge change to default behavior for X control that almost NO ONE knows about. The default methods of controlling the X server have been >around for decades and many users and sys admins automatically know what the default behavior is that can be counted on in almost all situations and therefore this constitutes a big change. >And big changes like this need to be advertised extensively instead of just quietly slipped in. I was hoping that Fedora might take the lead on stopping this bad change. And again, yes, I'll >take this to upstream as well.
Regards, Gerry
I will agree that it could be advertised more, but at the same time I think that if people don't read the release notes where information about the release is held, then it is no fault of the Fedora developers or document writers.
Also, won't Ctrl+Alt+<Fn> still work to get you to a vt where you can at your choice kill X manually, or try to debug the problem further?
Yes, yes it will. Solid observation :)
-Adam
Adam Miller wrote:
Also, won't Ctrl+Alt+<Fn> still work to get you to a vt where you can at your choice kill X manually, or try to debug the problem further?
Yes, yes it will. Solid observation :)
-Adam
NO! If the X server is in a tight loop sometimes you cannot even get a login prompt at a terminal. The ONLY thing that works is Ctrl-Alt-Backspace. And sometimes you have to issue it a few times and wait but generally it will kill the X server even when you cannot get logged in from a terminal.
Regards, Gerry
This thread has been rendered pointless, we're arguing a moot point. Fedora is apparently sticking with upstream on this so as you stated you will proceed to seek change through their avenues, please do so and once the change has been made upstream then it will be reflected in Fedora.
-Adam
Adam Miller wrote:
This thread has been rendered pointless, we're arguing a moot point. Fedora is apparently sticking with upstream on this so as you stated you will proceed to seek change through their avenues, please do so and once the change has been made upstream then it will be reflected in Fedora.
-Adam
and who are you to decide what fedora is choosing?, i can't even remember this being spoken about on the lists since the F11 announce on the test list, and there all that spoke on the matter were against it! fedora is a community! as for fedora always sticking with upstream i'm pretty positive you know this not to be true
On Fri, 2009-03-27 at 14:49 -0700, Christopher Aillon wrote:
On 03/27/2009 02:28 PM, Adam Miller wrote:
This change to default behavior of Ctrl-Alt-Backspace is an example of a tiny minority of Emacs users lobbying xorg for a change that will affect a huge number of community and commercial>users including datacenters and their sys admins. This change needs to be reversed immediately. Ctrl-Alt-Backspace is embedded now into many tools including all the virtualization tools. It is>part of the DNA of every sys admin. To change this behavior is just insanity.
Regards, Gerry
Please stop throwing around the "sys admins will freak out" card, I'm a sys admin and we do things correctly through provisioning using kickstarts. It will be maybe a 3 line edit to a script. It was an upstream choice, Fedora has historically remained compliant with upstream so I imagine if you would like a change to be made on this topic it would be most effective to discuss it with upstream.
Also, won't Ctrl+Alt+<Fn> still work to get you to a vt where you can at your choice kill X manually, or try to debug the problem further?
Not if your console is f*cked up and you just want the f*cking machine to reboot cleanly. Perhaps the bug here is that the X server deactivates ctl-alt-del. Or do the emacs weenies want that one too?
On Fri, 2009-03-27 at 14:49 -0700, Christopher Aillon wrote:
Also, won't Ctrl+Alt+<Fn> still work to get you to a vt where you can at your choice kill X manually, or try to debug the problem further?
Times when I really need to ctl-alt-bksp are generally times when the console state has been completely fucked up so that console switching doesn't work. And the reason I hit ctl-alt-bksp is usually so I can then hit ctl-alt-del to reboot the damned machine.
Seriously, how braindead is it to not having *some* reliable way to trigger a reboot without needing a working monitor or network connection? (Or working keymap...) If you're going to kill ctl-alt-bksp, you damn well better enable ctl-alt-del while X is running. (Why was THAT ever disabled in the first place?)
Callum Lerwick wrote:
On Fri, 2009-03-27 at 14:49 -0700, Christopher Aillon wrote:
Also, won't Ctrl+Alt+<Fn> still work to get you to a vt where you can at your choice kill X manually, or try to debug the problem further?
Times when I really need to ctl-alt-bksp are generally times when the console state has been completely fucked up so that console switching doesn't work. And the reason I hit ctl-alt-bksp is usually so I can then hit ctl-alt-del to reboot the damned machine.
Seriously, how braindead is it to not having *some* reliable way to trigger a reboot without needing a working monitor or network connection? (Or working keymap...) If you're going to kill ctl-alt-bksp, you damn well better enable ctl-alt-del while X is running. (Why was THAT ever disabled in the first place?)
lobbying by the same tiny minority.
Regards, Gerry
On Fri, 2009-03-27 at 19:09 -0400, Gerry Reno wrote:
Callum Lerwick wrote:
Seriously, how braindead is it to not having *some* reliable way to trigger a reboot without needing a working monitor or network connection? (Or working keymap...) If you're going to kill ctl-alt-bksp, you damn well better enable ctl-alt-del while X is running. (Why was THAT ever disabled in the first place?)
lobbying by the same tiny minority.
Somehow I doubt that. IIRC it's been like this since at least XFree86 3.3 in 1997 when I first started using Linux.
To anyone wanting to kill X when it hangs, why not login through a VC and "pkill X" .. Just like any process, why do we have to have magic keys!
On Fri, Mar 27, 2009 at 11:28 PM, Adam Miller maxamillion@gmail.com wrote:
This change to default behavior of Ctrl-Alt-Backspace is an example of a
tiny minority of Emacs users lobbying xorg for a change that will affect a huge number of community and commercial >users including datacenters and their sys admins. This change needs to be reversed immediately. Ctrl-Alt-Backspace is embedded now into many tools including all the virtualization tools. It is >part of the DNA of every sys admin. To change this behavior is just insanity.
Regards, Gerry
Please stop throwing around the "sys admins will freak out" card, I'm a sys admin and we do things correctly through provisioning using kickstarts. It will be maybe a 3 line edit to a script. It was an upstream choice, Fedora has historically remained compliant with upstream so I imagine if you would like a change to be made on this topic it would be most effective to discuss it with upstream.
-Adam
-- http://maxamillion.googlepages.com
() ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Ahmed Kamal wrote:
To anyone wanting to kill X when it hangs, why not login through a VC and "pkill X" .. Just like any process, why do we have to have magic keys!
Because not everyone logs in or is logged in that way. And when you're in a datacenter dealing with hundreds of machines you don't have time to be fiddling around with alternate mechanisms. You need to be able to count on the behaviors of controlling the X server that have been there for decades and as I said have become part of your DNA.
Regards, Gerry
On Friday 27 March 2009 21:50:01 Ahmed Kamal wrote:
To anyone wanting to kill X when it hangs, why not login through a VC and "pkill X" .. Just like any process, why do we have to have magic keys!
You need "magic keys" to get to the VC. And sometimes that just doesn't work.
I seem to remember the plan was to not have any VCs active when using the GUI login, anyway? At which point this becomes totally irrelevant ...
On Fri, 27 Mar 2009 17:19:05 -0400, Gerry Reno greno@verizon.net wrote:
This change to default behavior of Ctrl-Alt-Backspace is an example of a tiny minority of Emacs users lobbying xorg for a change that will affect a huge number of community and commercial users including datacenters and their sys admins. This change needs to be reversed immediately.
Oh please. When was the last time X wedged so the keyboard survived? Your imaginary sysadmins have to powercycle anyway.
-- Pete
On Fri, Mar 27, 2009 at 7:58 PM, Pete Zaitcev zaitcev@redhat.com wrote:
Oh please. When was the last time X wedged so the keyboard survived? Your imaginary sysadmins have to powercycle anyway.
Better yet, when is it not better to use SysRq keycombos and try to diagnose things? If you can get back keyboard control via SysRq, isn't it more beneficial to make use of SysRq instead of zapping?
-jef
On Fri, Mar 27, 2009 at 20:15:39 -0800, Jeff Spaleta jspaleta@gmail.com wrote:
On Fri, Mar 27, 2009 at 7:58 PM, Pete Zaitcev zaitcev@redhat.com wrote:
Oh please. When was the last time X wedged so the keyboard survived? Your imaginary sysadmins have to powercycle anyway.
Better yet, when is it not better to use SysRq keycombos and try to diagnose things? If you can get back keyboard control via SysRq, isn't it more beneficial to make use of SysRq instead of zapping?
Not if you are just trying to get your system to boot up. Currently I have to restart X a couple of times on average before I get a login screen. Eventually I shouldn't have to do that, but for now I have to live with it.
Of course I didn't find it too hard to customize my xorg.conf file to keep this feature working in the meantime.
On 03/27/2009 09:28 PM, Bruno Wolff III wrote:
On Fri, Mar 27, 2009 at 20:15:39 -0800, Jeff Spaletajspaleta@gmail.com wrote:
On Fri, Mar 27, 2009 at 7:58 PM, Pete Zaitcevzaitcev@redhat.com wrote:
Oh please. When was the last time X wedged so the keyboard survived? Your imaginary sysadmins have to powercycle anyway.
Better yet, when is it not better to use SysRq keycombos and try to diagnose things? If you can get back keyboard control via SysRq, isn't it more beneficial to make use of SysRq instead of zapping?
Not if you are just trying to get your system to boot up. Currently I have to restart X a couple of times on average before I get a login screen. Eventually I shouldn't have to do that, but for now I have to live with
I imagine that trying to diagnose the problem a little and filing a bug will lead to you having to live with that behavior for much less time than just leaving it to chance that eventually someone will randomly fix your precise issue.
2009/3/28 Rahul Sundaram sundaram@fedoraproject.org:
Muayyad AlSadi wrote:
and how can this be configured while do don't have a xorg.conf files ?
Just create one. Simple.
Rahul
Since I've been using Fedora we've gone from
having an xorg.conf which we more or less got to configure on firstboot, that was fine caused me no real problems
to
having no xorg.conf which I then have to figure out how to make myself, properly on every install and it still doesn't work as well as before
to
having X on Ctrl+Alt+F1 , one install I just realized I could no longer switch to a vt on F1, ok fine.
now
removing Ctrl+Alt+Backspace
At no point have I ever seen any real discussion on any of the lists about this it just happens. None of this changes have had any benefit to me on any of the several systems I've used X on.
In this case no one has pointed to an email archive of where this discussion took place. The attitude is that its been decided by the deciders -- so live with it. I do not understand where this kind of hostility towards some long time users is coming from.
On Sat, Mar 28, 2009 at 5:14 PM, Arthur Pemberton pemboa@gmail.com wrote:
2009/3/28 Rahul Sundaram sundaram@fedoraproject.org:
Muayyad AlSadi wrote:
and how can this be configured while do don't have a xorg.conf files ?
Just create one. Simple.
Rahul
Since I've been using Fedora we've gone from
having an xorg.conf which we more or less got to configure on firstboot, that was fine caused me no real problems
to
having no xorg.conf which I then have to figure out how to make myself, properly on every install and it still doesn't work as well as before
to
having X on Ctrl+Alt+F1 , one install I just realized I could no longer switch to a vt on F1, ok fine.
now
removing Ctrl+Alt+Backspace
At no point have I ever seen any real discussion on any of the lists about this it just happens. None of this changes have had any benefit to me on any of the several systems I've used X on.
In this case no one has pointed to an email archive of where this discussion took place. The attitude is that its been decided by the deciders -- so live with it. I do not understand where this kind of hostility towards some long time users is coming from.
I couldn't agree more, I use (well until they were stripped away) all of the above.
I'd like to also add logging in a root.
Arthur Pemberton wrote:
At no point have I ever seen any real discussion on any of the lists about this it just happens. None of this changes have had any benefit to me on any of the several systems I've used X on.
In this case no one has pointed to an email archive of where this discussion took place. The attitude is that its been decided by the deciders -- so live with it. I do not understand where this kind of hostility towards some long time users is coming from.
You will have to look beyond yourself and ask whether it has been a improvement in general (creating Xorg configuration by poking hardware directly, bypassing the kernel is way more fragile than auto-configuration in majority of systems for example) and then understand that much of the changes are just made in any free and open source software project by developers implementing those changes. In the case of major software like the Linux kernel and Xorg, these changes are in majority made by vendors to meet customer requirements (which I would count as meeting user needs even though this is no democracy) and these changes are made upstream for the most part. I don't see hostility in any of this.
Rahul
On Sat, Mar 28, 2009 at 7:45 PM, Rahul Sundaram sundaram@fedoraproject.org wrote:
Arthur Pemberton wrote:
At no point have I ever seen any real discussion on any of the lists about this it just happens. None of this changes have had any benefit to me on any of the several systems I've used X on.
In this case no one has pointed to an email archive of where this discussion took place. The attitude is that its been decided by the deciders -- so live with it. I do not understand where this kind of hostility towards some long time users is coming from.
You will have to look beyond yourself and ask whether it has been a improvement in general (creating Xorg configuration by poking hardware directly, bypassing the kernel is way more fragile than auto-configuration in majority of systems for example)
That's a simple question to ask myself. And the answer to that is no. I've never head of this fictional users that have a significant probability of having a different monitor connected to their computer on every boot. Nor have I seen any significant number of users accidentally depressing three keys at the same time. Why is it that auto configuration can't be used to auto configure on setup, not every time? Who benifits from not being restarting X with Ctrl+Alt+Backspace?
The autoconfig alone in my experience causes more problems than it solves -- having to explain to someone unfamiliar why is it their desktop looks weird because they started the machine with the monitor of.
and then understand that much of the changes are just made in any free and open source software project by developers implementing those changes. In the case of major software like the Linux kernel and Xorg, these changes are in majority made by vendors to meet customer requirements
I can understand all that. It fine if I don't count as a customer. I have previously asked for the rationale behind this latest change, or a link to where this was discussed so that I can understand it myself.
(which I would count as meeting user needs even though this is no democracy) and these changes are made upstream for the most part. I don't see hostility in any of this.
The hostility is in making significant changes to behaviors people have come to depend on and not letting them no about it till later on. Not hostile would have been an email to one of the many list altering us users of this upcoming change. Not hostile would be explaining the rationale instead of just saying that the change has been already, take it up with someone else. In no way are the release notes the best place to alert users of these kind of significant changes. This isn't a new feature, or some bug.
Casimiro de Almeida Barreto wrote:
One example: get an (not so) old ASUS box with SIS video and LG 710E monitor. X won't be OK until you get able to:
- Download system-config-display
- Figure out that monitor frequencies are not correct (even when you
choose it at system-config-display) and fix it by hand at the created xorg.conf ...
Did you file a bug report?
At this point many newbie users coming from other distributions (not to mention Windows people) will go back to lands they know better.
Other distributions are using the same Xorg. There is nothing magical that is going to fix these issues in other distributions. Fedora is ill suited for Windows users since they would expect patent encumbered and proprietary software we don't provide anyway but any regular users (regardless of whether they were Windows users before) would want things to work rather than manually configure it by hand. In cases where it doesn't work, just file a bug report.
Rahul
Arthur Pemberton wrote:
That's a simple question to ask myself. And the answer to that is no.
Like I indicated, look beyond yourself a bit. It is silly to suggest that autoconfiguration doesn't help the majority of users.
I've never head of this fictional users that have a significant probability of having a different monitor connected to their computer on every boot.
This is sort of corner case but even then, I have had to move struggle in the past to setup things when a new monitor was connected or when I had to plug my hard disk to someone else's system to copy content.
I am sure, you understand that autoconfiguration isn't designed just for this particular usage but for the general users who don't want to configure things manually on a new installation.
The hostility is in making significant changes to behaviors people have come to depend on and not letting them no about it till later on.
Changes are (primarily) being made upstream. Downstream users can document and communicate changes which we have.
Rahul
Le dimanche 29 mars 2009 à 21:49 +0530, Rahul Sundaram a écrit :
Changes are (primarily) being made upstream. Downstream users can document and communicate changes which we have.
Sorry, but that is utter bull*. The discussed change was requested by Ubuntu users. It lived for quite a long time in their distro. Then it was submitted upstream by Unbuntu people. For better or worse upstream merged it.
So you had one distribution that listened to its users and pushed a change they wanted.
At the same time, Fedora upstream devs didn't use their influence to block the change, didn't try to check what Fedora users wanted, and now we get the usual "upstream decided, live with it" speach.
And this is not an isolated case. It is consistent with historic Ubuntu and Fedora behaviour. This is sad. It is not the way to win new Fedora users.
Nicolas Mailhot wrote:
Le dimanche 29 mars 2009 à 21:49 +0530, Rahul Sundaram a écrit :
Changes are (primarily) being made upstream. Downstream users can document and communicate changes which we have.
Sorry, but that is utter bull*. The discussed change was requested by Ubuntu users. It lived for quite a long time in their distro. Then it was submitted upstream by Unbuntu people. For better or worse upstream merged it.
So you had one distribution that listened to its users and pushed a change they wanted.
At the same time, Fedora upstream devs didn't use their influence to block the change, didn't try to check what Fedora users wanted, and now we get the usual "upstream decided, live with it" speach.
And this is not an isolated case. It is consistent with historic Ubuntu and Fedora behaviour. This is sad. It is not the way to win new Fedora users.
it's sad that one distro's users decision affects every other distro, especially when that one distro is the one that's trying to be and operate exactly like windows!
phil
Nicolas Mailhot wrote:
Le dimanche 29 mars 2009 à 21:49 +0530, Rahul Sundaram a écrit :
Changes are (primarily) being made upstream. Downstream users can document and communicate changes which we have.
Sorry, but that is utter bull*. The discussed change was requested by Ubuntu users. It lived for quite a long time in their distro. Then it was submitted upstream by Unbuntu people. For better or worse upstream merged it.
So you had one distribution that listened to its users and pushed a change they wanted.
At the same time, Fedora upstream devs didn't use their influence to block the change, didn't try to check what Fedora users wanted, and now we get the usual "upstream decided, live with it" speach.
And this is not an isolated case. It is consistent with historic Ubuntu and Fedora behaviour. This is sad. It is not the way to win new Fedora users.
Kudos.
Ubuntu markets itself as a simpler experience. Easier for newbies. And that's the type of user base that they have. On the other hand, Fedora has catered more to the experienced user and through RedHat the commercial sector. And it is the commercial sector of Fedora and RedHat that are going to suffer from such a change and Fedora should have recognized this. For less experienced Ubuntu users this probably is not a problem, because they probably pull the cord everytime they have a problem anyway. But I have noticed of late, that there are now many complaining in the Ubuntu forums about this change as well. So Ubuntu didn't exactly listen to its user base either.
Regards, Gerry
On Sun, Mar 29, 2009 at 06:42:59PM +0200, Nicolas Mailhot wrote:
Le dimanche 29 mars 2009 à 21:49 +0530, Rahul Sundaram a écrit :
Changes are (primarily) being made upstream. Downstream users can document and communicate changes which we have.
Sorry, but that is utter bull*. The discussed change was requested by Ubuntu users. It lived for quite a long time in their distro. Then it was submitted upstream by Unbuntu people. For better or worse upstream merged it.
No. The patch was written and committed by Daniel Stone, who is not an Ubuntu developer. The issue was discussed with the Fedora X maintainers before it was merged. Everyone involved agreed that not having a keystroke that caused immediate data loss was a sensible idea.
At the same time, Fedora upstream devs didn't use their influence to block the change, didn't try to check what Fedora users wanted, and now we get the usual "upstream decided, live with it" speach.
A development mailing list is a poor way of judging user desire, as are non-representative polls.
On Sun, 29 Mar 2009, Matthew Garrett wrote:
No. The patch was written and committed by Daniel Stone, who is not an Ubuntu developer. The issue was discussed with the Fedora X maintainers before it was merged. Everyone involved agreed that not having a keystroke that caused immediate data loss was a sensible idea.
When my laptop would run out of memory, due to Firefox and pidgin and openoffice, I could always hit ctrl-alt-bckspace to NOT have data loss behind my session. Now you're telling me I need to power cycle my machine, causing a HIGHER change of data loss.
Let's be honest here, the change is not made to protect people against data loss. It's being made for emacs users at the expense of everyone else.
The best solution would be to find a new key combination that works for everyone. sysctl might be the best method here. If that is also not done, that the third best choice would be to have an easy way to edit this option in /etc/sysconfig. Requiring an xorg.conf just for this feature wil just cause those people more harm later on, when having an xorg.conf just for this will bite them with something unrelated.
Remember, opensource is about giving people a choice, not limiting people's choices.
Paul
On Sun, Mar 29, 2009 at 01:26:58PM -0400, Paul Wouters wrote:
Remember, opensource is about giving people a choice, not limiting people's choices.
You have many choices. The choices include:
*) Adding an xorg.conf fragment that re-enables zapping *) Filing a bug against the server and, through rational argument, convincing the upstream maintainers to revert this *) The above, but for the Fedora maintainers *) Using a locally patched package *) Forking the entirity of Fedora *) Describing the use cases that require hitting ctrl+alt+backspace and coming up with fixes that don't involve killing the entire user session *) Switching to Windows *) Switching to MacOS *) Becoming a hermit and not touching a computer ever again
And dozens more. Changing a boolean default does not limit choice. The only change is that you now have the choice of enabling zapping rather than the choice of disabling it.
On Sun, Mar 29, 2009 at 1:21 PM, Matthew Garrett mjg@redhat.com wrote:
On Sun, Mar 29, 2009 at 01:26:58PM -0400, Paul Wouters wrote:
Remember, opensource is about giving people a choice, not limiting
people's
choices.
You have many choices. The choices include:
*) Adding an xorg.conf fragment that re-enables zapping *) Filing a bug against the server and, through rational argument, convincing the upstream maintainers to revert this *) The above, but for the Fedora maintainers *) Using a locally patched package *) Forking the entirity of Fedora *) Describing the use cases that require hitting ctrl+alt+backspace and coming up with fixes that don't involve killing the entire user session *) Switching to Windows *) Switching to MacOS *) Becoming a hermit and not touching a computer ever again
And dozens more. Changing a boolean default does not limit choice. The only change is that you now have the choice of enabling zapping rather than the choice of disabling it.
-- Matthew Garrett | mjg59@srcf.ucam.org
This reply is ludicrous. Might as well ship F12 without Gnome, you can simply install it if you want......
The point is, a few protested and got the change submitted. Never mind the thousands that still want it.
Matthew Garrett wrote:
On Sun, Mar 29, 2009 at 06:42:59PM +0200, Nicolas Mailhot wrote:
Le dimanche 29 mars 2009 � 21:49 +0530, Rahul Sundaram a �crit :
Changes are (primarily) being made upstream. Downstream users can document and communicate changes which we have.
Sorry, but that is utter bull*. The discussed change was requested by Ubuntu users. It lived for quite a long time in their distro. Then it was submitted upstream by Unbuntu people. For better or worse upstream merged it.
No. The patch was written and committed by Daniel Stone, who is not an Ubuntu developer. The issue was discussed with the Fedora X maintainers before it was merged. Everyone involved agreed that not having a keystroke that caused immediate data loss was a sensible idea.
At the same time, Fedora upstream devs didn't use their influence to block the change, didn't try to check what Fedora users wanted, and now we get the usual "upstream decided, live with it" speach.
A development mailing list is a poor way of judging user desire, as are non-representative polls.
but who on earth can press those three keys by mistake? you'd have to be dumb, so the data loss point is moot, anyway if x locks up and zap is disabled your going to lose the data in a reboot anyway unless you have re-compiled the kernel and turned on the sysreq keys
phil
On Sun, Mar 29, 2009 at 06:33:29PM +0100, psmith wrote:
but who on earth can press those three keys by mistake? you'd have to be dumb, so the data loss point is moot, anyway if x locks up and zap is disabled your going to lose the data in a reboot anyway unless you have re-compiled the kernel and turned on the sysreq keys
Then I must be dumb. If that's the case, I recommend not running any software I contribute to.
On Sun, Mar 29, 2009 at 10:38 AM, Matthew Garrett mjg@redhat.com wrote:
On Sun, Mar 29, 2009 at 06:33:29PM +0100, psmith wrote:
but who on earth can press those three keys by mistake? you'd have to be dumb, so the data loss point is moot, anyway if x locks up and zap is disabled your going to lose the data in a reboot anyway unless you have re-compiled the kernel and turned on the sysreq keys
Then I must be dumb. If that's the case, I recommend not running any software I contribute to.
Yes, please give a list so I can be wary of that software.
Thank you.
On Sun, Mar 29, 2009 at 10:46:10AM -0700, Christopher Stone wrote:
On Sun, Mar 29, 2009 at 10:38 AM, Matthew Garrett mjg@redhat.com wrote:
On Sun, Mar 29, 2009 at 06:33:29PM +0100, psmith wrote:
but who on earth can press those three keys by mistake? you'd have to be dumb, so the data loss point is moot, anyway if x locks up and zap is disabled your going to lose the data in a reboot anyway unless you have re-compiled the kernel and turned on the sysreq keys
Then I must be dumb. If that's the case, I recommend not running any software I contribute to.
Yes, please give a list so I can be wary of that software.
The kernel, X, hal, gnome, vbetool, pm-utils, network-manager, a bunch of minor contributions to other things.
On Sun, Mar 29, 2009 at 10:51 AM, Matthew Garrett mjg@redhat.com wrote:
The kernel, X, hal, gnome, vbetool, pm-utils, network-manager, a bunch of minor contributions to other things.
Oh F*** we're doomed! :/
Matthew Garrett wrote:
On Sun, Mar 29, 2009 at 10:46:10AM -0700, Christopher Stone wrote:
On Sun, Mar 29, 2009 at 10:38 AM, Matthew Garrett mjg@redhat.com wrote:
On Sun, Mar 29, 2009 at 06:33:29PM +0100, psmith wrote:
but who on earth can press those three keys by mistake? you'd have to be dumb, so the data loss point is moot, anyway if x locks up and zap is disabled your going to lose the data in a reboot anyway unless you have re-compiled the kernel and turned on the sysreq keys
Then I must be dumb. If that's the case, I recommend not running any software I contribute to.
Yes, please give a list so I can be wary of that software.
The kernel, X, hal, gnome, vbetool, pm-utils, network-manager, a bunch of minor contributions to other things.
ooh ooh all bow down to the master coder, but he's not that leet as he can press three key combos by mistake lol
phil
Christopher Stone wrote:
On Sun, Mar 29, 2009 at 10:38 AM, Matthew Garrett mjg@redhat.com wrote:
On Sun, Mar 29, 2009 at 06:33:29PM +0100, psmith wrote:
but who on earth can press those three keys by mistake? you'd have to be dumb, so the data loss point is moot, anyway if x locks up and zap is disabled your going to lose the data in a reboot anyway unless you have re-compiled the kernel and turned on the sysreq keys
Then I must be dumb. If that's the case, I recommend not running any software I contribute to.
Yes, please give a list so I can be wary of that software.
Then, you might as well as stop running any Linux distribution. Matthew Garett code is in not optional in Linux.
Rahul
On Sun, Mar 29, 2009 at 10:58 AM, Rahul Sundaram sundaram@fedoraproject.org wrote:
Christopher Stone wrote:
On Sun, Mar 29, 2009 at 10:38 AM, Matthew Garrett mjg@redhat.com wrote:
On Sun, Mar 29, 2009 at 06:33:29PM +0100, psmith wrote:
but who on earth can press those three keys by mistake? you'd have to be dumb, so the data loss point is moot, anyway if x locks up and zap is disabled your going to lose the data in a reboot anyway unless you have re-compiled the kernel and turned on the sysreq keys
Then I must be dumb. If that's the case, I recommend not running any software I contribute to.
Yes, please give a list so I can be wary of that software.
Then, you might as well as stop running any Linux distribution. Matthew Garett code is in not optional in Linux.
Does not compute. How can someone who is allegedly intelligent not understand the difference between typing ctrl-alt-backspace and rm? Both could potentially cause data loss, so why remove one and not the other?
Maybe mister smarty can explain that to the list?
On Sun, Mar 29, 2009 at 11:02:33AM -0700, Christopher Stone wrote:
On Sun, Mar 29, 2009 at 10:58 AM, Rahul Sundaram sundaram@fedoraproject.org wrote:
Then, you might as well as stop running any Linux distribution. Matthew Garett code is in not optional in Linux.
Does not compute. How can someone who is allegedly intelligent not understand the difference between typing ctrl-alt-backspace and rm? Both could potentially cause data loss, so why remove one and not the other?
Maybe mister smarty can explain that to the list?
Ctrl+alt+backspace is a single key away from various other commonly used combinations - outside the emacs universe, a bunch of the gnome shortcuts are ctrl+alt+something, and ctrl+backspace is "delete previous word". When you have a key that's affected by modifiers, it doesn't seem unreasonable for people to try hitting other modifiers as well to see what they do. In my case, it was normally from flicking between workspaces and then going to hit backspace before I'd fully released the modifiers.
rm -fr / is rather a large number of keystrokes away from pretty much anything else you might want to do.
Once upon a time, Matthew Garrett mjg@redhat.com said:
When you have a key that's affected by modifiers, it doesn't seem unreasonable for people to try hitting other modifiers as well to see what they do.
If "hitting random keys to see what they do" is the standard, we might as well turn the computer off and give up now. This is a ludicrous argument.
On Sun, Mar 29, 2009 at 01:12:13PM -0500, Chris Adams wrote:
Once upon a time, Matthew Garrett mjg@redhat.com said:
When you have a key that's affected by modifiers, it doesn't seem unreasonable for people to try hitting other modifiers as well to see what they do.
If "hitting random keys to see what they do" is the standard, we might as well turn the computer off and give up now. This is a ludicrous argument.
How did you learn to use a computer? I did it mostly by trying random things to see what they did.
On Sun, Mar 29, 2009 at 11:23 AM, Matthew Garrett mjg@redhat.com wrote:
On Sun, Mar 29, 2009 at 01:12:13PM -0500, Chris Adams wrote:
Once upon a time, Matthew Garrett mjg@redhat.com said:
When you have a key that's affected by modifiers, it doesn't seem unreasonable for people to try hitting other modifiers as well to see what they do.
If "hitting random keys to see what they do" is the standard, we might as well turn the computer off and give up now. This is a ludicrous argument.
How did you learn to use a computer? I did it mostly by trying random things to see what they did.
How many times did you hit ctrl-alt-backspace before you realized you shouldn't be pressing that key combination at random?
Did you do a lot of really important work first and not save it before you started pressing random keys to test and see what they do?
On Sun, Mar 29, 2009 at 11:25:25AM -0700, Christopher Stone wrote:
On Sun, Mar 29, 2009 at 11:23 AM, Matthew Garrett mjg@redhat.com wrote:
How did you learn to use a computer? I did it mostly by trying random things to see what they did.
How many times did you hit ctrl-alt-backspace before you realized you shouldn't be pressing that key combination at random?
Twice - the second time to see if this bizarre behaviour was reproducible.
Did you do a lot of really important work first and not save it before you started pressing random keys to test and see what they do?
No, I lost no significant amount of useful work. But I also spent some time wondering why Linux needed a "Throw my work away without confirmation" hotkey. The times I've hit it by accident /since/ then have occasionally led to me losing something useful.
On Sun, Mar 29, 2009 at 11:30 AM, Matthew Garrett mjg@redhat.com wrote:
On Sun, Mar 29, 2009 at 11:25:25AM -0700, Christopher Stone wrote:
On Sun, Mar 29, 2009 at 11:23 AM, Matthew Garrett mjg@redhat.com wrote:
How did you learn to use a computer? I did it mostly by trying random things to see what they did.
How many times did you hit ctrl-alt-backspace before you realized you shouldn't be pressing that key combination at random?
Twice - the second time to see if this bizarre behaviour was reproducible.
Did you do a lot of really important work first and not save it before you started pressing random keys to test and see what they do?
No, I lost no significant amount of useful work. But I also spent some time wondering why Linux needed a "Throw my work away without confirmation" hotkey. The times I've hit it by accident /since/ then have occasionally led to me losing something useful.
Yes, there should be a confirmation key, like an additional key press after the ctrl-alt-bksp. I have used software that has ctrl/alt-ins/del combination (sdlmame from rpmfusion). I've never once hit ctrl-alt-backspace by mistake, but I could see it happening.
Matthew Garrett wrote:
On Sun, Mar 29, 2009 at 11:25:25AM -0700, Christopher Stone wrote:
On Sun, Mar 29, 2009 at 11:23 AM, Matthew Garrett mjg@redhat.com wrote:
How did you learn to use a computer? I did it mostly by trying random things to see what they did.
How many times did you hit ctrl-alt-backspace before you realized you shouldn't be pressing that key combination at random?
Twice - the second time to see if this bizarre behaviour was reproducible.
Did you do a lot of really important work first and not save it before you started pressing random keys to test and see what they do?
No, I lost no significant amount of useful work. But I also spent some time wondering why Linux needed a "Throw my work away without confirmation" hotkey. The times I've hit it by accident /since/ then have occasionally led to me losing something useful.
it's not a "throw away my work without confirmation key" (well it is for those stupid/blind/lazy enough to hit it by mistake but i digress) and i'd thank you to stop trying to portray it that way to get your change to stick (it's clearly obvious that you think this change is necesary), it's a save me from re-booting my pc when x totally screws up, and yes regardless of your coding prowess it still does screw up!
Once upon a time, Matthew Garrett mjg@redhat.com said:
How did you learn to use a computer? I did it mostly by trying random things to see what they did.
I read the book and (where available for things I'm interested in) the source (and sometimes by disassembling things when the source wasn't available).
In any case, if you are hitting random keys to see what they do, you shouldn't be suprised if they do things you don't like (and hopefully you'll learn what those keys do and remember them for times when you might need them).
On 2009/03/29 13:12 (GMT-0500) Chris Adams composed:
Once upon a time, Matthew Garrett mjg@redhat.com said:
When you have a key that's affected by modifiers, it doesn't seem unreasonable for people to try hitting other modifiers as well to see what they do.
....This is a ludicrous argument.
+10
On Sun, Mar 29, 2009 at 11:09 AM, Matthew Garrett mjg@redhat.com wrote:
On Sun, Mar 29, 2009 at 11:02:33AM -0700, Christopher Stone wrote:
On Sun, Mar 29, 2009 at 10:58 AM, Rahul Sundaram sundaram@fedoraproject.org wrote:
Then, you might as well as stop running any Linux distribution. Matthew Garett code is in not optional in Linux.
Does not compute. How can someone who is allegedly intelligent not understand the difference between typing ctrl-alt-backspace and rm? Both could potentially cause data loss, so why remove one and not the other?
Maybe mister smarty can explain that to the list?
Ctrl+alt+backspace is a single key away from various other commonly used combinations - outside the emacs universe, a bunch of the gnome shortcuts are ctrl+alt+something, and ctrl+backspace is "delete previous word". When you have a key that's affected by modifiers, it doesn't seem unreasonable for people to try hitting other modifiers as well to see what they do. In my case, it was normally from flicking between workspaces and then going to hit backspace before I'd fully released the modifiers.
rm -fr / is rather a large number of keystrokes away from pretty much anything else you might want to do.
so just change it to ctrl-alt-backspace-backspace. problem solved.
On 2009/03/29 19:09 (GMT+0100) Matthew Garrett composed:
When you have a key that's affected by modifiers, it doesn't seem unreasonable for people to try hitting other modifiers as well to see what they do. In my case, it was normally from flicking between workspaces and then going to hit backspace before I'd fully released the modifiers.
Not making the modified key the last struck and first released is an invitation for unexpected results, chaos as an expected result.
Matthew Garrett wrote:
On Sun, Mar 29, 2009 at 06:33:29PM +0100, psmith wrote:
but who on earth can press those three keys by mistake? you'd have to be dumb, so the data loss point is moot, anyway if x locks up and zap is disabled your going to lose the data in a reboot anyway unless you have re-compiled the kernel and turned on the sysreq keys
Then I must be dumb. If that's the case, I recommend not running any software I contribute to.
then either go to the doc and get your eyes tested, or improve your touch typing, or if there is noting wrong with your eyes try looking at what your doing!
admit YOUR failings and stop trying to force a fix for your problem on everyone else!
phil
psmith wrote:
then either go to the doc and get your eyes tested, or improve your touch typing, or if there is noting wrong with your eyes try looking at what your doing!
admit YOUR failings and stop trying to force a fix for your problem on everyone else!
Remember to be courteous.
http://fedoraproject.org/wiki/Communicate/MailingListGuidelines#Be_Courteous
Rahul
On Sun, Mar 29, 2009 at 10:01 AM, Matthew Garrett mjg@redhat.com wrote:
Everyone involved agreed that not having a keystroke that caused immediate data loss was a sensible idea.
Ha! Imagine if these same people were in charge of bash. We would have to remove the rm command because someone could accidentally type rm. Imagine if someone accidentally typed rm -fr / as root!!! That could be disastrous! !
Christopher Stone wrote:
On Sun, Mar 29, 2009 at 10:01 AM, Matthew Garrett mjg@redhat.com wrote:
Everyone involved agreed that not having a keystroke that caused immediate data loss was a sensible idea.
Ha! Imagine if these same people were in charge of bash. We would have to remove the rm command because someone could accidentally type rm. Imagine if someone accidentally typed rm -fr / as root!!! That could be disastrous! !
Kudos.
What many people don't realize is that now instead of when a user sees that their mouse and keyboard are locked up they can just hit the Gtrl-Alt-Backspace like they've done for years and kill their X server and be back at a login prompt, now they're going to call the help desk. And it going to go like this:
Help Desk> Good morning, Help Desk. How can I help you? User>My keyboard and mouse are behaving weird. I checked the cables and their plugged in ok. Help Desk> Sounds like your X server is messed up. Did you try killing your X server? User> Yes, I pressed Ctrl-Alt-Backspace but norhing happened. Help Desk> What OS is loaded on your workstation? User> I'm not sure. They loaded a new one last week. Help Desk> Ok, let me open a System Administration ticket for you. They'll call you back in about 10 minutes. User> Ok, thanks.
Ring User> Hello. SysAdmin> Hi, I see your having a problem with your workstation. User> Yes, my keyboard and mouse aren't responding now. They just kept getting slower and slower. SysAdmin> Ok, it sounds like something has happened to your X server or you have some runaway process. Let me check something. User> Ok. SysAdmin> Ok, I can see that your X server is pegged at 98.3 percent of cpu. So have you tried killing your X server yet? User> Yes, I tried Ctrl-Alt-Backspace but it didn't do anything. SysAdmin> Ok, I can kill your X server from here. Would you like me to do that? User> Yes, please. SysAdmin> Ok, I killed your X server. What do you see? User> It went back to the login prompt. SysAdmin> Good, you should be able to just log back in now. User> Yes, I'm in. Thanks a lot. SysAdmin> Your welcome. Is there anything else I can do for you? User> No, I'm fine now. SysAdmin> Ok, well have a good day. I'll close this ticket. User> Yes, go ahead. And thanks again. SysAdmin> No problem. If you have any more problems just call the Help Desk. Bye now. User> Ok, Bye.
And that's what we're going to start seeing instead of users being able to manage the situation themselves.
Regards, Gerry
2009/3/29 Gerry Reno greno@verizon.net:
And that's what we're going to start seeing instead of users being able to manage the situation themselves.
Indeed. I have spent *a lot* of time on IRC in #fedora helping people recover from situations like this. There is no way I'm going to be trying to explain to people on IRC how to switch virtual consoles, pull up a process list, kill an X server and restart X. I am just going to tell them they are screwed because some people want linux to be more like windows, and you will have to reboot the entire machine instead of just restarting X. Sorry.
On Sun, 2009-03-29 at 18:01 +0100, Matthew Garrett wrote:
No. The patch was written and committed by Daniel Stone, who is not an Ubuntu developer. The issue was discussed with the Fedora X maintainers before it was merged. Everyone involved agreed that not having a keystroke that caused immediate data loss was a sensible idea.
So we're disabling ctl-alt-del too?
If killing the X server is causing data loss, then there's a bug in your applications. In fact, that's an argument for ctl-alt-bs to be a regular part of applications testing.
... And still doesn't address the fact that the key combo could be changed to something more obscure rather than disabling it completely.
On Sun, Mar 29, 2009 at 01:16:10PM -0500, Callum Lerwick wrote:
On Sun, 2009-03-29 at 18:01 +0100, Matthew Garrett wrote:
No. The patch was written and committed by Daniel Stone, who is not an Ubuntu developer. The issue was discussed with the Fedora X maintainers before it was merged. Everyone involved agreed that not having a keystroke that caused immediate data loss was a sensible idea.
So we're disabling ctl-alt-del too?
No, since working at the console isn't an interesting desktop use case.
If killing the X server is causing data loss, then there's a bug in your applications. In fact, that's an argument for ctl-alt-bs to be a regular part of applications testing.
I don't know about you, but I prefer my text editors not to save to disk on every keystroke.
... And still doesn't address the fact that the key combo could be changed to something more obscure rather than disabling it completely.
What do you suggest? I'm serious here, if there's a genuinely implausible key combination then it's not going to be rejected out of hand - but I haven't been able to come up with one, and I haven't seen any good suggestions.
On Sun, Mar 29, 2009 at 07:26:44PM +0100, Matthew Garrett wrote:
... And still doesn't address the fact that the key combo could be changed to something more obscure rather than disabling it completely.
What do you suggest? I'm serious here, if there's a genuinely implausible key combination then it's not going to be rejected out of hand - but I haven't been able to come up with one, and I haven't seen any good suggestions.
We've already got Alt+SysRq+k, which Wikipedia's description says will "Kill all processes on the current virtual console (Can be used to kill X and svgalib programs, see below) This was originally designed to imitate a Secure Access Key".
Of course since sysrq-magic has been disabled by default for a while now, this will still require that an echo of "1" to /proc/sys/kernel/sysrq be done at boot.
-- John Kodis.
Once upon a time, Matthew Garrett mjg@redhat.com said:
On Sun, Mar 29, 2009 at 01:16:10PM -0500, Callum Lerwick wrote:
If killing the X server is causing data loss, then there's a bug in your applications. In fact, that's an argument for ctl-alt-bs to be a regular part of applications testing.
I don't know about you, but I prefer my text editors not to save to disk on every keystroke.
Stop exagerating; that's not required. Any decent X program _should_ handle saving data if it loses its connection to the X server. Killing the server does not terminate all the clients without notice. And guess what, many (most?) do. For example, if I kill X, the next time I start Firefox, it asks if I want to restore my previous session (which it dutifully saved away) or start a new one.
So far, your arguments are "I should be able to hit any random key at any time and not cause any problem" and "applications are so broken they can't handle an unusual condition and so need to save state at every change". Both of those are stupid.
On Sun, Mar 29, 2009 at 01:55:13PM -0500, Chris Adams wrote:
Once upon a time, Matthew Garrett mjg@redhat.com said:
I don't know about you, but I prefer my text editors not to save to disk on every keystroke.
Stop exagerating; that's not required. Any decent X program _should_ handle saving data if it loses its connection to the X server. Killing the server does not terminate all the clients without notice. And guess what, many (most?) do. For example, if I kill X, the next time I start Firefox, it asks if I want to restore my previous session (which it dutifully saved away) or start a new one.
Firefox does this by saving its session every time you hit a new page. It's actually remarkably difficult to handle the "My X server has gone away" case - traditional xlib behaviour is to just abort() your process. You can do some funky stuff involving signal handlers and longjmp, but by and large it's not practical to save app state when the server is killed. Especially if your application isn't an X one and just happens to run in a console.
So far, your arguments are "I should be able to hit any random key at any time and not cause any problem" and "applications are so broken they can't handle an unusual condition and so need to save state at every change". Both of those are stupid.
I should be able to hit a key without it having a surprising behaviour that closes all my applications without any sort of confirmation, yes. ctrl+alt+backspace was always a poor choice from this perspective.
Matthew Garrett wrote:
On Sun, Mar 29, 2009 at 01:55:13PM -0500, Chris Adams wrote:
Once upon a time, Matthew Garrett mjg@redhat.com said:
I don't know about you, but I prefer my text editors not to save to disk on every keystroke.
Stop exagerating; that's not required. Any decent X program _should_ handle saving data if it loses its connection to the X server. Killing the server does not terminate all the clients without notice. And guess what, many (most?) do. For example, if I kill X, the next time I start Firefox, it asks if I want to restore my previous session (which it dutifully saved away) or start a new one.
Firefox does this by saving its session every time you hit a new page. It's actually remarkably difficult to handle the "My X server has gone away" case - traditional xlib behaviour is to just abort() your process. You can do some funky stuff involving signal handlers and longjmp, but by and large it's not practical to save app state when the server is killed. Especially if your application isn't an X one and just happens to run in a console.
So far, your arguments are "I should be able to hit any random key at any time and not cause any problem" and "applications are so broken they can't handle an unusual condition and so need to save state at every change". Both of those are stupid.
I should be able to hit a key without it having a surprising behaviour that closes all my applications without any sort of confirmation, yes. ctrl+alt+backspace was always a poor choice from this perspective.
A key then yes, a three key combo then no you shouldn't, and it's hardly surprising behaviour to you since you seem to be doing it accidentally all the time, surely after the first or second time you realised that it's not a good idea to keep doing it. or if you don't have that good of a manual dexterity perhaps you should change you emacs keybindings, or even run an xorg.conf with the zap disabled.
again i say don't force a change on every other x user for your shortcommings!
Once upon a time, Matthew Garrett mjg@redhat.com said:
It's actually remarkably difficult to handle the "My X server has gone away" case - traditional xlib behaviour is to just abort() your process. You can do some funky stuff involving signal handlers and longjmp, but by and large it's not practical to save app state when the server is killed. Especially if your application isn't an X one and just happens to run in a console.
Huh, vim manages to handle this just fine. Maybe the emacs folks that don't like Ctrl+Alt+Backspace should give it a try...
On Sun, 2009-03-29 at 22:44 +0100, Matthew Garrett wrote:
Firefox does this by saving its session every time you hit a new page. It's actually remarkably difficult to handle the "My X server has gone away" case - traditional xlib behaviour is to just abort() your process. You can do some funky stuff involving signal handlers and longjmp, but by and large it's not practical to save app state when the server is killed.
And yet somehow many existing apps manage to do it...
A resilient app has to be able to handle having the plug pulled with no warning anyway.
Especially if your application isn't an X one and just happens to run in a console.
On the console we've had this thing called SIGHUP for the last few decades...
On Sun, 2009-03-29 at 19:26 +0100, Matthew Garrett wrote:
On Sun, Mar 29, 2009 at 01:16:10PM -0500, Callum Lerwick wrote:
On Sun, 2009-03-29 at 18:01 +0100, Matthew Garrett wrote:
No. The patch was written and committed by Daniel Stone, who is not an Ubuntu developer. The issue was discussed with the Fedora X maintainers before it was merged. Everyone involved agreed that not having a keystroke that caused immediate data loss was a sensible idea.
So we're disabling ctl-alt-del too?
No, since working at the console isn't an interesting desktop use case.
If killing the X server is causing data loss, then there's a bug in your applications. In fact, that's an argument for ctl-alt-bs to be a regular part of applications testing.
I don't know about you, but I prefer my text editors not to save to disk on every keystroke.
Well, I know for one Vim has crash recovery. And so does OpenOffice. And so does Evolution. This is not a new concept.
... And still doesn't address the fact that the key combo could be changed to something more obscure rather than disabling it completely.
What do you suggest? I'm serious here, if there's a genuinely implausible key combination then it's not going to be rejected out of hand - but I haven't been able to come up with one, and I haven't seen any good suggestions.
Now we're getting somewhere. First we might want to lay down some criteria:
1) Not every keyboard is a PC-101 (or 104). We run on non-PC platforms too. Example: My Rev C iMac keyboard has left ctl alt and command (maps as the "windows key") but only command on the right side. I've run in to PC laptops that don't have all modifiers on the right either. Laptops typically don't have real number pads.
2) It would be best to avoid "word" or even symbol keys, to avoid keymap problems. International users will probably appreciate this.
3) The average person has ten fingers, ten toes and a nose.
4) At some point you exceed the keyboard's rollover capability...
So, how about:
ctl-alt-shift-backspace ctl-alt-shift-backspace-tab ctl-alt-shift-enter-spacebar ctl-alt-shift-capslock-enter-backspace ctl-alt-lshift-rshift-backspace ctl-alt-lshift-rshift-backspace-tab ctl-alt-lshift-rshift-enter-spacebar ctl-alt-lshift-rshift-capslock-enter-backspace ctl-alt-lshift-rshift-capslock-backspace-enter-tab-spacebar
... Do I really need to go on? Pick something. :P
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Callum Lerwick wrote:
On Sun, 2009-03-29 at 19:26 +0100, Matthew Garrett wrote:
On Sun, Mar 29, 2009 at 01:16:10PM -0500, Callum Lerwick wrote:
On Sun, 2009-03-29 at 18:01 +0100, Matthew Garrett wrote:
No. The patch was written and committed by Daniel Stone,
who is not
an Ubuntu developer. The issue was discussed with the Fedora
X
maintainers before it was merged. Everyone involved agreed
that not
having a keystroke that caused immediate data loss was a
sensible
idea.
So we're disabling ctl-alt-del too?
No, since working at the console isn't an interesting desktop use
case.
If killing the X server is causing data loss, then there's a bug in your applications. In fact, that's an argument for ctl-alt-bs to be
a
regular part of applications testing.
I don't know about you, but I prefer my text editors not to save to
disk
on every keystroke.
Well, I know for one Vim has crash recovery. And so does OpenOffice.
And
so does Evolution. This is not a new concept.
... And still doesn't address the fact that the key combo could be changed to something more obscure rather than disabling it
completely.
What do you suggest? I'm serious here, if there's a genuinely implausible key combination then it's not going to be rejected out
of
hand - but I haven't been able to come up with one, and I haven't
seen
any good suggestions.
Now we're getting somewhere. First we might want to lay down
some
criteria:
- Not every keyboard is a PC-101 (or 104). We run on non-PC
platforms
too. Example: My Rev C iMac keyboard has left ctl alt and command
(maps
as the "windows key") but only command on the right side. I've run in
to
PC laptops that don't have all modifiers on the right either. Laptops typically don't have real number pads.
- It would be best to avoid "word" or even symbol keys, to avoid
keymap
problems. International users will probably appreciate this.
The average person has ten fingers, ten toes and a nose.
At some point you exceed the keyboard's rollover capability...
So, how about:
ctl-alt-shift-backspace ctl-alt-shift-backspace-tab ctl-alt-shift-enter-spacebar ctl-alt-shift-capslock-enter-backspace ctl-alt-lshift-rshift-backspace ctl-alt-lshift-rshift-backspace-tab ctl-alt-lshift-rshift-enter-spacebar ctl-alt-lshift-rshift-capslock-enter-backspace ctl-alt-lshift-rshift-capslock-backspace-enter-tab-spacebar
... Do I really need to go on? Pick something. :P
Ctrl-alt-shift-backspace could still be easy with the shallow keys used on laptops. Both shift keys at the same time is really...odd and most people only use one shift key (or at least heavily favor one). Double shift+anything should be rare enough that accidental killing is a sign of an extremely obscure typing style.
- --Ben
On Sun, Mar 29, 2009 at 01:59:31PM -0500, Callum Lerwick wrote:
ctl-alt-shift-backspace ctl-alt-shift-backspace-tab ctl-alt-shift-enter-spacebar ctl-alt-shift-capslock-enter-backspace ctl-alt-lshift-rshift-backspace ctl-alt-lshift-rshift-backspace-tab ctl-alt-lshift-rshift-enter-spacebar ctl-alt-lshift-rshift-capslock-enter-backspace ctl-alt-lshift-rshift-capslock-backspace-enter-tab-spacebar
I'm a little leary about things involving tab and space, given their use in other contexts - but, to be fair, requiring both shift keys would probably be adequate. My other thought is something involving the break key, since that's basically unused right now. The only real trouble there is the extent to which laptops will let you use modifiers with something generated using the Fn key.
On Sun, 2009-03-29 at 22:49 +0100, Matthew Garrett wrote:
I'm a little leary about things involving tab and space, given their use in other contexts - but, to be fair, requiring both shift keys would probably be adequate. My other thought is something involving the break key, since that's basically unused right now. The only real trouble there is the extent to which laptops will let you use modifiers with something generated using the Fn key.
My iMac keyboard lacks a pause/break key: (Picture isn't US layout but close enough...)
http://upload.wikimedia.org/wikipedia/commons/e/e4/Apple_USB_Keyboard_B.jpg
Also note Apple's recent keyboard designs have even less keys:
http://upload.wikimedia.org/wikipedia/commons/9/96/Apple-wireless-keyboard-a... http://upload.wikimedia.org/wikipedia/commons/8/81/Apple_Keyboard_A1242.jpg
Callum Lerwick wrote:
- The average person has ten fingers, ten toes and a nose.
I really don't want to have to use my toes or nose to press your key combo. ;-) Sure, a combo which is impossible to press with the hands only would protect effectively against accidental pressing, but it'd also make it a PITA to press the combo when actually needed.
Kevin Kofler
Kevin Kofler wrote:
Callum Lerwick wrote:
- The average person has ten fingers, ten toes and a nose.
I really don't want to have to use my toes or nose to press your key combo. ;-) Sure, a combo which is impossible to press with the hands only would protect effectively against accidental pressing, but it'd also make it a PITA to press the combo when actually needed.
Kevin Kofler
None of this protects cat owners either. Bubbles can still crash the X server simply by choosing an inappropriate place for her afternoon nap.
--CJD
On Monday 30 March 2009 22:36:55 Casey Dahlin wrote:
Kevin Kofler wrote:
Callum Lerwick wrote:
- The average person has ten fingers, ten toes and a nose.
I really don't want to have to use my toes or nose to press your key combo. ;-) Sure, a combo which is impossible to press with the hands only would protect effectively against accidental pressing, but it'd also make it a PITA to press the combo when actually needed.
Kevin KoflerNone of this protects cat owners either. Bubbles can still crash the X server simply by choosing an inappropriate place for her afternoon nap.
--CJD
Yes! And it also can pee on the keyboard (and, naturally, on the motherboard too, in case of a laptop). Do You think there is a way to stop cats from doing it? I don't. In fact I'm sure even SELinux won't help.
On Mon, 2009-03-30 at 13:36 -0400, Casey Dahlin wrote:
Kevin Kofler wrote:
Callum Lerwick wrote:
- The average person has ten fingers, ten toes and a nose.
I really don't want to have to use my toes or nose to press your key combo. ;-) Sure, a combo which is impossible to press with the hands only would protect effectively against accidental pressing, but it'd also make it a PITA to press the combo when actually needed.
Kevin KoflerNone of this protects cat owners either. Bubbles can still crash the X server simply by choosing an inappropriate place for her afternoon nap.
That would never happen with a dog. Clearly dogs are superior. Only emacs users have cats.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Casey Dahlin wrote:
Kevin Kofler wrote:
Callum Lerwick wrote:
- The average person has ten fingers, ten toes and a nose.
I really don't want to have to use my toes or nose to press your key combo. ;-) Sure, a combo which is impossible to press with the hands only would protect effectively against accidental pressing, but it'd also make it a PITA to press the combo when actually needed.
None of this protects cat owners either. Bubbles can still crash the X server simply by choosing an inappropriate place for her afternoon nap.
As a matter of fact, just last night, my own server-cum-desktop was brought to a screeching halt when the cat decided to walk across the UPS, and apparently hit the switch on that. There's not much of a software fix for that, is there?
And yes, I am a cat ownee and an emacs user (though one that definitely doesn't appreciate the loss of ctrl-alt-bsp).
- -- J. Randall Owens | http://www.ghiapet.net/ ProofReading Markup Language | http://prml.sourceforge.net/
On Sun, Mar 29, 2009 at 10:35 PM, Kevin Kofler wrote:
Callum Lerwick wrote:
- The average person has ten fingers, ten toes and a nose.
I really don't want to have to use my toes or nose to press your key combo. ;-) Sure, a combo which is impossible to press with the hands only would protect effectively against accidental pressing, but it'd also make it a PITA to press the combo when actually needed.
No, it's not pain, really. It may leave only some temporary marks depending on your momentum before impact.
I tried.
Kevin Kofler
Orcan
On 2009/03/29 19:26 (GMT+0100) Matthew Garrett composed:
I haven't seen any good suggestions.
Why is the openSUSE solution posted at least twice in this thread not a "good suggestion"?
On Sun, Mar 29, 2009 at 12:18 PM, Felix Miata mrmazda@ij.net wrote:
On 2009/03/29 19:26 (GMT+0100) Matthew Garrett composed:
I haven't seen any good suggestions.
Why is the openSUSE solution posted at least twice in this thread not a "good suggestion"?
Given a choice of the openSUSE method of ctrl-alt-backspace repeated twice vs. the Ubuntu method of just disabling it (haha) I choose the openSUSE method.
I think the Ubuntu decision to be more like Windows is an example we do not want to follow.
On Sun, Mar 29, 2009 at 03:18:29PM -0400, Felix Miata wrote:
On 2009/03/29 19:26 (GMT+0100) Matthew Garrett composed:
I haven't seen any good suggestions.
Why is the openSUSE solution posted at least twice in this thread not a "good suggestion"?
Because it provides no worthwhile feedback that what you've just pressed is bad, and so doesn't discourage you from trying it again. It reduces the probability of disaster but it's still not especially friendly.
On Sun, Mar 29, 2009 at 2:50 PM, Matthew Garrett mjg@redhat.com wrote:
On Sun, Mar 29, 2009 at 03:18:29PM -0400, Felix Miata wrote:
On 2009/03/29 19:26 (GMT+0100) Matthew Garrett composed:
I haven't seen any good suggestions.
Why is the openSUSE solution posted at least twice in this thread not a "good suggestion"?
Because it provides no worthwhile feedback that what you've just pressed is bad, and so doesn't discourage you from trying it again. It reduces the probability of disaster but it's still not especially friendly.
Actually the SUSE patch emits an audible tone the first time you press ctrl-alt-backspace. The tone will last for two seconds, and the user must press ctrl-alt-backspace again before the tone stops in order to kill X.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Christopher Stone wrote:
On Sun, Mar 29, 2009 at 2:50 PM, Matthew Garrett mjg@redhat.com wrote:
On Sun, Mar 29, 2009 at 03:18:29PM -0400, Felix Miata wrote:
On 2009/03/29 19:26 (GMT+0100) Matthew Garrett composed:
I haven't seen any good suggestions.
Why is the openSUSE solution posted at least twice in this thread not a "good suggestion"?
Because it provides no worthwhile feedback that what you've just pressed is bad, and so doesn't discourage you from trying it again. It reduces the probability of disaster but it's still not especially friendly.
Actually the SUSE patch emits an audible tone the first time you press ctrl-alt-backspace. The tone will last for two seconds, and the user must press ctrl-alt-backspace again before the tone stops in order to kill X.
I'd support this if people preferred. I know patches welcome is kind of a crappy response, but its probably a small amount of changes. Why don't you collect the necessary bits and get the package set up to build, then poke the maintainer about it?
- --CJD
On 2009/03/29 13:16 (GMT-0500) Callum Lerwick composed:
... And still doesn't address the fact that the key combo could be changed to something more obscure rather than disabling it completely.
Too obscure makes it useless. Enough people knew about it know to assist those who don't or manage on their own. It already had a reasonable level of obscurity before the change. It didn't need more. It should be put back just exactly like it was, except to add the openSUSE modification mentioned upthread.
On Sun, Mar 29, 2009 at 11:19 AM, Rahul Sundaram sundaram@fedoraproject.org wrote:
Arthur Pemberton wrote:
The hostility is in making significant changes to behaviors people have come to depend on and not letting them no about it till later on.
Changes are (primarily) being made upstream. Downstream users can document and communicate changes which we have.
Could you please point me to the discussion areas where this decision was made? Since I appernetly have to live with this decision, I would like to at least understand the logic behind it.
* Arthur Pemberton [29/03/2009 22:54] :
Could you please point me to the discussion areas where this decision was made? Since I appernetly have to live with this decision, I would like to at least understand the logic behind it.
http://lists.freedesktop.org/archives/xorg/2008-September/038786.html
Emmanuel
On Sun, Mar 29, 2009 at 4:00 PM, Emmanuel Seyman emmanuel.seyman@club-internet.fr wrote:
- Arthur Pemberton [29/03/2009 22:54] :
Could you please point me to the discussion areas where this decision was made? Since I appernetly have to live with this decision, I would like to at least understand the logic behind it.
http://lists.freedesktop.org/archives/xorg/2008-September/038786.html
That can't be it. It has been said that this decision was taken my developers and maintainers. This poll was not in favor of removing it, and the originator of the poll was campaigning for it through out the thread.
On Sun, Mar 29, 2009 at 04:16:26PM -0500, Arthur Pemberton wrote:
That can't be it. It has been said that this decision was taken my developers and maintainers. This poll was not in favor of removing it, and the originator of the poll was campaigning for it through out the thread.
Most of the discussion happened on IRC - I have no idea if it's logged or not.
On Sun, Mar 29, 2009 at 5:52 PM, Matthew Garrett mjg@redhat.com wrote:
On Sun, Mar 29, 2009 at 04:16:26PM -0500, Arthur Pemberton wrote:
That can't be it. It has been said that this decision was taken my developers and maintainers. This poll was not in favor of removing it, and the originator of the poll was campaigning for it through out the thread.
Most of the discussion happened on IRC - I have no idea if it's logged or not.
Which probably means a group of 4-5 people spent 9 seconds on the debate without any real user input...
On Sun, Mar 29, 2009 at 05:59:16PM -0400, Dr. Diesel wrote:
On Sun, Mar 29, 2009 at 5:52 PM, Matthew Garrett mjg@redhat.com wrote:
On Sun, Mar 29, 2009 at 04:16:26PM -0500, Arthur Pemberton wrote: > That can't be it. It has been said that this decision was taken my > developers and maintainers. This poll was not in favor of removing it, > and the originator of the poll was campaigning for it through out the > thread. Most of the discussion happened on IRC - I have no idea if it's logged or not.Which probably means a group of 4-5 people spent 9 seconds on the debate without any real user input...
Oddly enough, it turns out that developers tend to use their code as well.
On Sun, Mar 29, 2009 at 6:10 PM, Matthew Garrett mjg@redhat.com wrote:
On Sun, Mar 29, 2009 at 05:59:16PM -0400, Dr. Diesel wrote:
On Sun, Mar 29, 2009 at 5:52 PM, Matthew Garrett mjg@redhat.com
wrote:
On Sun, Mar 29, 2009 at 04:16:26PM -0500, Arthur Pemberton wrote: > That can't be it. It has been said that this decision was taken my > developers and maintainers. This poll was not in favor of removingit,
> and the originator of the poll was campaigning for it through outthe
> thread. Most of the discussion happened on IRC - I have no idea if it'slogged
or not.Which probably means a group of 4-5 people spent 9 seconds on the
debate
without any real user input...
Oddly enough, it turns out that developers tend to use their code as well.
So far nobody has been able to produce any support for this change. Of the zillions of Linux based forums I read daily I've never once every heard of this complaint.
Arthur Pemberton wrote:
That's a simple question to ask myself. And the answer to that is no.
Like I indicated, look beyond yourself a bit. It is silly to suggest that autoconfiguration doesn't help the majority of users.
I've never head of this fictional users that have a significant probability of having a different monitor connected to their computer on every boot.
This is sort of corner case but even then, I have had to move struggle in the past to setup things when a new monitor was connected or when I had to plug my hard disk to someone else's system to copy content.
I am sure, you understand that autoconfiguration isn't designed just for this particular usage but for the general users who don't want to configure things manually on a new installation.
The hostility is in making significant changes to behaviors people have come to depend on and not letting them no about it till later on.
Changes are (primarily) being made upstream. Downstream users can document and communicate changes which we have.
Rahul
On Sun, 2009-03-29 at 02:58 -0500, Arthur Pemberton wrote:
That's a simple question to ask myself. And the answer to that is no. I've never head of this fictional users that have a significant probability of having a different monitor connected to their computer on every
It's not about every boot, it's about a lot of times in the same boot. I suspend my laptop more often than shut it down, and I constantly move from a local vga monitor, to an hdmi monitor, to numerous projectors for presentations, to nothing connected at all on a regular basis. I love the fact that Linux can finally do on the fly configurations like this without having to mess with config files and restart X sessions. Other operating systems have been able to do this trivially for years.
On Sun, Mar 29, 2009 at 01:33:36AM +0530, Rahul Sundaram wrote:
Muayyad AlSadi wrote:
and how can this be configured while do don't have a xorg.conf files ?
Just create one. Simple.
Simple? Could we have an example of a *complete* xorg file which does not break the autodetection capabilities of xorg but activate C-A-BS? Something I could put in a local rpm file and install with the rest of the distribution. I know I'm not able to do one, and I've tried for other flags, but I may have missed something.
OG.
On Sun, Mar 29, 2009 at 12:44 AM, Olivier Galibert galibert@pobox.com wrote:
On Sun, Mar 29, 2009 at 01:33:36AM +0530, Rahul Sundaram wrote:
Muayyad AlSadi wrote:
and how can this be configured while do don't have a xorg.conf files ?
Just create one. Simple.
Simple? Could we have an example of a *complete* xorg file which does not break the autodetection capabilities of xorg but activate C-A-BS? Something I could put in a local rpm file and install with the rest of the distribution. I know I'm not able to do one, and I've tried for other flags, but I may have missed something.
Section "ServerFlags" Option "DontZap" "false" EndSection
Is all you need, it won't break anything but re enables C-A-BS
drago01 wrote:
On Sun, Mar 29, 2009 at 12:44 AM, Olivier Galibert galibert@pobox.com wrote:
On Sun, Mar 29, 2009 at 01:33:36AM +0530, Rahul Sundaram wrote:
Muayyad AlSadi wrote:
and how can this be configured while do don't have a xorg.conf files ?
Just create one. Simple.
Simple? �Could we have an example of a *complete* xorg file which does not break the autodetection capabilities of xorg but activate C-A-BS? Something I could put in a local rpm file and install with the rest of the distribution. �I know I'm not able to do one, and I've tried for other flags, but I may have missed something.
Section "ServerFlags" Option "DontZap" "false" EndSection
Is all you need, it won't break anything but re enables C-A-BS
so to counter the extremely small emacs community can get used to using an xorg.conf with
Section "ServerFlags" Option "DontZap" "true" EndSection
and the rest of us can stick with the years old normal behaviour
phil
Olivier Galibert wrote:
On Sun, Mar 29, 2009 at 01:33:36AM +0530, Rahul Sundaram wrote:
Muayyad AlSadi wrote:
and how can this be configured while do don't have a xorg.conf files ?
Just create one. Simple.
Simple? Could we have an example of a *complete* xorg file which does not break the autodetection capabilities of xorg but activate C-A-BS? Something I could put in a local rpm file and install with the rest of the distribution. I know I'm not able to do one, and I've tried for other flags, but I may have missed something.
I have expanded the notes at
https://fedoraproject.org/wiki/Fedora_11_Beta_release_notes#X_server
If that does not work properly, do file a bug report. Hope that helps.
Rahul
Rahul Sundaram wrote:
Olivier Galibert wrote:
On Sun, Mar 29, 2009 at 01:33:36AM +0530, Rahul Sundaram wrote:
Muayyad AlSadi wrote:
and how can this be configured while do don't have a xorg.conf files ?
Just create one. Simple.
Simple? Could we have an example of a *complete* xorg file which does not break the autodetection capabilities of xorg but activate C-A-BS? Something I could put in a local rpm file and install with the rest of the distribution. I know I'm not able to do one, and I've tried for other flags, but I may have missed something.
I have expanded the notes at
https://fedoraproject.org/wiki/Fedora_11_Beta_release_notes#X_server
If that does not work properly, do file a bug report. Hope that helps.
Rahul
And this in no way properly addresses the issue as put forth in this thread.
Xorg says it is making this change in response to complaints from desktop users. I want to see those complaints. How many were there? Out of ten million installations I would think maybe there would be at least 1,000 complaints to even bring the issue into statistical significance. That would still only be 1/100th of 1 percent of all installations. Surely they can meet that meager standard. Show me the complaints.
Regards, Gerry
Gerry Reno wrote:
Rahul Sundaram wrote:
Olivier Galibert wrote:
Simple? Could we have an example of a *complete* xorg file which does not break the autodetection capabilities of xorg but activate C-A-BS? Something I could put in a local rpm file and install with the rest of the distribution. I know I'm not able to do one, and I've tried for other flags, but I may have missed something.
I have expanded the notes at
https://fedoraproject.org/wiki/Fedora_11_Beta_release_notes#X_server
If that does not work properly, do file a bug report. Hope that helps.
And this in no way properly addresses the issue as put forth in this thread.
I was not trying to address anything that you said but simply documenting how to revert the change as a user asked in this thread. You have made your disagreement clear and don't really have to keep replying to every mail.
Rahul
Ctrl+Alt+Backspace is also a keyboard shortcut for deleting certain expressions in C and Java modes in Emacs
and since when EMACSians are considered desktop users!!
Muayyad AlSadi wrote:
and how can this be configured while do don't have a xorg.conf files ?
Just create one. Simple.
do you really think I can't!!
I'm just shedding some lights on that dark corner
we have people have decided that we don't xorg.conf but it comes that some nvidia cards needs it because on of X drivers in the auto detection steps graps it and never release it
another case were some cards need passing some flags for the cursor to be shown
a trivial solution for the first case was to use s-c-d and set it to vesa and for the second to create a skeleton xorg.conf where I can add some driver specific options --- on another topic we have some people decided that we no longer need s-c-d assuming that we don't need xorg.conf files
and on this topic another one is assuming that we don't need CTRL+ALT+BKSP and tells those who want it to edit xorg.conf files which does not exists and the tool to create such files are to be dropped
and BTW what does "your sysadmin" mean ?! we are talking about desktop use cases, sysadmin is synonym to yourself in such context
how can we know how many fedorians have EMACS installed
Muayyad AlSadi wrote:
we have people have decided that we don't xorg.conf but it comes that some nvidia cards needs it because on of X drivers in the auto detection steps graps it and never release it
another case were some cards need passing some flags for the cursor to be shown
All these are bugs that needs to be fixed. Report them.
Rahul
On Sat, Mar 28, 2009 at 11:51:25 -0700, Christopher Aillon caillon@redhat.com wrote:
I imagine that trying to diagnose the problem a little and filing a bug will lead to you having to live with that behavior for much less time than just leaving it to chance that eventually someone will randomly fix your precise issue.
No it won't. Airlie isn't interested in looking at problems with my hardware right now. Maybe when he is done getting stuff in shape for the newer cards I might get him to look at it.
Once upon a time, Jeff Spaleta jspaleta@gmail.com said:
Better yet, when is it not better to use SysRq keycombos and try to diagnose things? If you can get back keyboard control via SysRq, isn't it more beneficial to make use of SysRq instead of zapping?
Well, that's disabled by default also.
Could someone please explain what's going on. The only documentation in Fedora i see about this decision is in the F11 alpha release notes. Maybe everyone reads them but me, however it would be nice if these kind of significant changes were announced.
Its been said that this decision was taken upstream. My initial Googling shows this first being brought up as an idea in Ubuntu [1] where it is shown as implemented. It is later shown as a secret poll on the freedesktop list [2]. Is there any reason the Xorg maintainer in Fedora didn't make us aware of that all this was going on?
Aren't the release notes expected to be read upon release, when it is way to late to give input? I don't agree that adding a paragraph or two in the release notes are good enough for changes that effect everyone. Xorg seems especially guilty of making significant changes which are later just discovered by users.
[1] https://blueprints.launchpad.net/ubuntu/+spec/xorg-ctrl-alt-backspace [2] http://lists.freedesktop.org/archives/xorg/2008-September/038786.html
On 3/27/09, Chris Adams cmadams@hiwaay.net wrote:
Once upon a time, Jeff Spaleta jspaleta@gmail.com said:
Better yet, when is it not better to use SysRq keycombos and try to diagnose things? If you can get back keyboard control via SysRq, isn't it more beneficial to make use of SysRq instead of zapping?
Well, that's disabled by default also.
Chris Adams cmadams@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Fri, Mar 27, 2009 at 10:31 PM, Arthur Pemberton pemboa@gmail.com wrote:
[1] https://blueprints.launchpad.net/ubuntu/+spec/xorg-ctrl-alt-backspace
- There is no need for such a feature for an end user desktop system (you cannot kill the X server in MacOSX...)
HAHAAH I was just thinking to myself before I read this, "I bet the reasoning for this is something like, Windows doesnt have ctrl-alt-bksp therefore ubuntu shouldnt either"
WHAT A JOKE!!!!
We are disabling ctrl-alt-backspace because Ubuntu is doing it because Windows doesn't have that feautre.
Okay.
- The typical end user does not know about this feature (it is undocumented and hidden) and it is relatively easy to trigger it by mistake. It can have disastrous consequences.
relatively easy? relative to what? ctrl-alt-shift-sysrq-q? LOL
- If one really needs to kill the X server, he can go to a tty term and do it by hand.
Indeed. But it is also *a lot* easier for a newb to hit ctrl-alt-backsapce.
I am truely amazed this is in Ubuntu, I would think they would want the exact opposite, and actually make it easier for newbies to recover from an X crash.
Can we please now make decisions on technical merit and not because of what some other OS does. PLEASE.
On Saturday 28 March 2009 09:31:29 Arthur Pemberton wrote:
Could someone please explain what's going on. The only documentation in Fedora i see about this decision is in the F11 alpha release notes. Maybe everyone reads them but me, however it would be nice if these kind of significant changes were announced.
Its been said that this decision was taken upstream. My initial Googling shows this first being brought up as an idea in Ubuntu [1] where it is shown as implemented. It is later shown as a secret poll on the freedesktop list [2]. Is there any reason the Xorg maintainer in Fedora didn't make us aware of that all this was going on?
Aren't the release notes expected to be read upon release, when it is way to late to give input? I don't agree that adding a paragraph or two in the release notes are good enough for changes that effect everyone. Xorg seems especially guilty of making significant changes which are later just discovered by users.
[1] https://blueprints.launchpad.net/ubuntu/+spec/xorg-ctrl-alt-backspace [2] http://lists.freedesktop.org/archives/xorg/2008-September/038786.html
On 3/27/09, Chris Adams cmadams@hiwaay.net wrote:
Once upon a time, Jeff Spaleta jspaleta@gmail.com said:
Better yet, when is it not better to use SysRq keycombos and try to diagnose things? If you can get back keyboard control via SysRq, isn't it more beneficial to make use of SysRq instead of zapping?
Well, that's disabled by default also.
Chris Adams cmadams@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
-- Fedora 9 : sulphur is good for the skin ( www.pembo13.com )
And the most funny thing is, the secret polls result was *no* The poll was started on "Mon Sep 22 19:41:16 PDT 2008" And on " 2008-10-07 23:30:05 (GMT)" Daniel Stone committed the "Make DontZap the default" patch.
P.S. yes, I'm one of the guys for whom sometimes Ctrl-Alt-Fn doesn't work, but Ctrl-Alt-Backspace does.
P.P.S. google for <"Daniel Stone" fedora>
On Fri, Mar 27, 2009 at 10:31 PM, Arthur Pemberton pemboa@gmail.com wrote:
[2] http://lists.freedesktop.org/archives/xorg/2008-September/038786.html
The poll was meaningless; that thread just captures people's sentiments. When the patch was committed, it was because the X developers had been talking about it for a long time as being the right thing to do.
-- Dan
Dan Nicholson wrote:
On Fri, Mar 27, 2009 at 10:31 PM, Arthur Pemberton pemboa@gmail.com wrote:
[2] http://lists.freedesktop.org/archives/xorg/2008-September/038786.html
The poll was meaningless; that thread just captures people's sentiments. When the patch was committed, it was because the X developers had been talking about it for a long time as being the right thing to do.
The X developers had been talking about without ANY community input. That makes for very bad decisions. They didn't even realize that people expect the Ctrl-Alt-Backspace to be available to them as it has for decades. What is left unsaid is that there a lot of emacs users in Xorg. Despite the fact that they sign as "a vim user", they're all vim users but mostly emacs users, and that's not the same as signing "not an emacs user".
I've opened a thread on xorg-devel and have been getting nothing but ridiculous arguments in response. Mostly like, "well *I* accidentally killed my X server while I was typing". Total nonsense. This is all about a tiny minority of Emacs users, mostly inside Xorg itself introducing a change that has a large to impact to the overall Xorg community and all for the benefit of just the tiny Emacs community. That completely wrong and is bad stewardship. Fedora needs to see this change for what it really is and reject it. We need to continue the historical default behavior for Ctrl-Alt-Backspace that users and sysadmins have counted on for decades without organizations and users needing to install special setups in xorg.conf which is a completely unnecessary bother and a waste of time and resources.
Regards, Gerry
On 3/28/2009 10:55 AM, Gerry Reno wrote:
Dan Nicholson wrote:
On Fri, Mar 27, 2009 at 10:31 PM, Arthur Pemberton pemboa@gmail.com wrote:
[2] http://lists.freedesktop.org/archives/xorg/2008-September/038786.html
The poll was meaningless; that thread just captures people's sentiments. When the patch was committed, it was because the X developers had been talking about it for a long time as being the right thing to do.
The X developers had been talking about without ANY community input. That makes for very bad decisions. They didn't even realize that people expect the Ctrl-Alt-Backspace to be available to them as it has for decades. What is left unsaid is that there a lot of emacs users in Xorg. Despite the fact that they sign as "a vim user", they're all vim users but mostly emacs users, and that's not the same as signing "not an emacs user".
I've opened a thread on xorg-devel and have been getting nothing but ridiculous arguments in response. Mostly like, "well *I* accidentally killed my X server while I was typing". Total nonsense. This is all about a tiny minority of Emacs users, mostly inside Xorg itself introducing a change that has a large to impact to the overall Xorg community and all for the benefit of just the tiny Emacs community. That completely wrong and is bad stewardship. Fedora needs to see this change for what it really is and reject it. We need to continue the historical default behavior for Ctrl-Alt-Backspace that users and sysadmins have counted on for decades without organizations and users needing to install special setups in xorg.conf which is a completely unnecessary bother and a waste of time and resources.
Just keep repeating to yourself, "Linux is an OS... Linux is not a cause... Linux is an OS... Linux is not a cause..."
;-)
2009/3/28 Gerry Reno greno@verizon.net:
Dan Nicholson wrote:
On Fri, Mar 27, 2009 at 10:31 PM, Arthur Pemberton pemboa@gmail.com wrote:
[2] http://lists.freedesktop.org/archives/xorg/2008-September/038786.html
The poll was meaningless; that thread just captures people's sentiments. When the patch was committed, it was because the X developers had been talking about it for a long time as being the right thing to do.
The X developers had been talking about without ANY community input. That makes for very bad decisions. They didn't even realize that people expect the Ctrl-Alt-Backspace to be available to them as it has for decades. What is left unsaid is that there a lot of emacs users in Xorg. Despite the fact that they sign as "a vim user", they're all vim users but mostly emacs users, and that's not the same as signing "not an emacs user".
Please stop with the conspiracy theory. This has nothing to do with emacs. It has everything to do with people accidentally killing their X session. I have no idea where you've gotten the idea that this was done for emacs users. Read Daniel's reply to you again.
-- Dan
Dan Nicholson wrote:
2009/3/28 Gerry Reno greno@verizon.net:
Dan Nicholson wrote:
On Fri, Mar 27, 2009 at 10:31 PM, Arthur Pemberton pemboa@gmail.com wrote:
[2] http://lists.freedesktop.org/archives/xorg/2008-September/038786.html
The poll was meaningless; that thread just captures people's sentiments. When the patch was committed, it was because the X developers had been talking about it for a long time as being the right thing to do.
The X developers had been talking about without ANY community input. That makes for very bad decisions. They didn't even realize that people expect the Ctrl-Alt-Backspace to be available to them as it has for decades. What is left unsaid is that there a lot of emacs users in Xorg. Despite the fact that they sign as "a vim user", they're all vim users but mostly emacs users, and that's not the same as signing "not an emacs user".
Please stop with the conspiracy theory. This has nothing to do with emacs. It has everything to do with people accidentally killing their X session. I have no idea where you've gotten the idea that this was done for emacs users. Read Daniel's reply to you again.
-- Dan
This is not a conspiracy theory. If you've ever used emacs you know that they have a number of Ctrl-Alt-XXXXX sequences that are very close to Ctrl-Alt-Backspace. And emacs users have whined about everything Ctrl-Alt such as Ctrl-Alt-Del, Ctrl-Alt-Backspace, etc.
In thirty years of administering and managing *nix systems inside companies that have tens of thousands of employees, I have never had a user come to me and complain that they were having trouble because they kept killing their X server with Ctrl-Alt-Backspace. Daniel rammed this change into Xorg without ANY community input. And further there is no statisically significant number of cases where people are killing their X server accidentally. The only user community that has ever had this problem is the Emacs community because of their similar keystroke combinations to Ctrl-Alt-Backspace.
Regards, Gerry
On Saturday 28 March 2009 19:15:28 Dan Nicholson wrote:
2009/3/28 Gerry Reno greno@verizon.net:
Dan Nicholson wrote:
On Fri, Mar 27, 2009 at 10:31 PM, Arthur Pemberton pemboa@gmail.com wrote:
[2] http://lists.freedesktop.org/archives/xorg/2008-September/038786.html
The poll was meaningless; that thread just captures people's sentiments. When the patch was committed, it was because the X developers had been talking about it for a long time as being the right thing to do.
The X developers had been talking about without ANY community input. That makes for very bad decisions. They didn't even realize that people expect the Ctrl-Alt-Backspace to be available to them as it has for decades. What is left unsaid is that there a lot of emacs users in Xorg. Despite the fact that they sign as "a vim user", they're all vim users but mostly emacs users, and that's not the same as signing "not an emacs user".
Please stop with the conspiracy theory. This has nothing to do with emacs. It has everything to do with people accidentally killing their X session. I have no idea where you've gotten the idea that this was done for emacs users. Read Daniel's reply to you again.
-- Dan
Can someone, please, explain me what is a user trying to do when he accidentally kills X?
And if the answer is: "Pressing all the buttons he sees", what stops the same user from pressing reset/poweroff or even Ctrl-Alt-F4 + Ctrl-Alt-Del?
Oh and one more... I also wonder why we don't disable Ctrl-Alt-Fn, cause a user may accidentally switch to another vt and don't know how to come back.
On Sat, 2009-03-28 at 19:26 +0400, Suren Karapetyan wrote:
Can someone, please, explain me what is a user trying to do when he accidentally kills X?
And if the answer is: "Pressing all the buttons he sees", what stops the same user from pressing reset/poweroff or even Ctrl-Alt-F4 + Ctrl-Alt-Del?
In emacs, Ctrl-Alt-\ means indent the selected region according to style rules for the type of file being edited (very useful), and Ctrl-Alt-End does something related to emacs-Lisp programming (less useful, IMO). Both \ and End are right next to Bksp on my laptop keyboard, but only the \ is at risk on my desktop keyboard. Other nearby keys (=, ], and PgDn) don't have default emacs bindings with Ctrl-Alt, but I suppose a sophisticated emacs user could bind them to something useful.
Some GNOME keyboard shortcuts use Ctrl-Alt as well.
I'm a GNOME and emacs user, but I'm not taking sides here, just responding to the request for information.
Oh and one more... I also wonder why we don't disable Ctrl-Alt-Fn, cause a user may accidentally switch to another vt and don't know how to come back.
On Sun, 2009-03-29 at 00:44 +0100, Kevin Kofler wrote:
Matthew Saltzman wrote:
In emacs
Now is there a use case you can think of which does NOT involve Emacs?
I mentioned some GNOME keyboard shortcuts that involve Ctrl-Alt-<something>. I suppose it's possible to add more, and more dangerous ones, than I spotted in System -> Preferences -> Personal -> Keyboard Shortcuts.
Kevin Kofler
Matthew Saltzman wrote:
On Sat, 2009-03-28 at 19:26 +0400, Suren Karapetyan wrote:
Can someone, please, explain me what is a user trying to do when he accidentally kills X?
And if the answer is: "Pressing all the buttons he sees", what stops the same user from pressing reset/poweroff or even Ctrl-Alt-F4 + Ctrl-Alt-Del?
In emacs, Ctrl-Alt-\ means indent the selected region according to style rules for the type of file being edited (very useful), and Ctrl-Alt-End does something related to emacs-Lisp programming (less useful, IMO). Both \ and End are right next to Bksp on my laptop keyboard, but only the \ is at risk on my desktop keyboard.
I guess; I never even knew Ctrl-Alt-\ (indent-region) was there, instead using C-Alt-q (bound to c-indent-exp for C, (indent-pp-sexp for lisp, etc) for everything I need when programming. They seem to do the same thing.
Andrew.
On Sat, 2009-03-28 at 08:15 -0700, Dan Nicholson wrote:
Please stop with the conspiracy theory. This has nothing to do with emacs. It has everything to do with people accidentally killing their X session. I have no idea where you've gotten the idea that this was done for emacs users. Read Daniel's reply to you again.
Is "accidentally hitting it" really the only reason? If so, the simplest thing to do would be to CHANGE THE KEYBINDING not remove functionality. Change it to oh, I don't know, ctl-alt-del? quadruple-bucky-cokebottle? You've got ~101 keys to work with, I'm sure we can find something acceptable.
... Or is there another reason?
On Sat, Mar 28, 2009 at 11:29:17AM -0500, Callum Lerwick wrote:
... Or is there another reason?
Yes. Xorg developers are paid by Microsoft.
Seriously. ctrl+alt+backspace is about the least likely key combination to be accidently hit, but it's still entirely possible. Changing it to another set of keys doesn't actually fix things.
On Sat, 2009-03-28 at 16:39 +0000, Matthew Garrett wrote:
On Sat, Mar 28, 2009 at 11:29:17AM -0500, Callum Lerwick wrote:
... Or is there another reason?
Yes. Xorg developers are paid by Microsoft.
I was thinking more along the lines of "omg security!" or "Our software is PERFECT you have no need to kill it!".
Seriously. ctrl+alt+backspace is about the least likely key combination to be accidently hit, but it's still entirely possible. Changing it to another set of keys doesn't actually fix things.
What, emacs users are going to accidentally hit lctl-rctl-lshift-rshift-lalt-ralt-backspace too?
2009/3/28 Callum Lerwick seg@haxxed.com:
On Sat, 2009-03-28 at 08:15 -0700, Dan Nicholson wrote:
Please stop with the conspiracy theory. This has nothing to do with emacs. It has everything to do with people accidentally killing their X session. I have no idea where you've gotten the idea that this was done for emacs users. Read Daniel's reply to you again.
Is "accidentally hitting it" really the only reason? If so, the simplest thing to do would be to CHANGE THE KEYBINDING not remove functionality. Change it to oh, I don't know, ctl-alt-del? quadruple-bucky-cokebottle? You've got ~101 keys to work with, I'm sure we can find something acceptable.
... Or is there another reason?
I'd prefer a system where X.org wouldn't have any keyboard shortcuts at all. Things would just work and I wouldn't ever need to Zap X or go to a vt to fix things.
Of course, the world isn't perfect, and there probably is need for a global shortcut to kill or restart X, among other things. However, it would be nice if X eventually got rid of everything ctrl-alt-something (Zap, vt switches, resolution changes, etc.) , so that the combinations could be used for more useful purposes, and replaced them with less intrusive ones, if any, as default.
2009/3/28 Joonas Sarajärvi muepsj@gmail.com:
Of course, the world isn't perfect, and there probably is need for a global shortcut to kill or restart X, among other things. However, it would be nice if X eventually got rid of everything ctrl-alt-something (Zap, vt switches, resolution changes, etc.) , so that the combinations could be used for more useful purposes, and replaced them with less intrusive ones, if any, as default.
That system is called XKB. You can remap keys to your heart's desire.
-- Dan
2009/3/28 Dan Nicholson dbn.lists@gmail.com:
2009/3/28 Joonas Sarajärvi muepsj@gmail.com:
Of course, the world isn't perfect, and there probably is need for a global shortcut to kill or restart X, among other things. However, it would be nice if X eventually got rid of everything ctrl-alt-something (Zap, vt switches, resolution changes, etc.) , so that the combinations could be used for more useful purposes, and replaced them with less intrusive ones, if any, as default.
That system is called XKB. You can remap keys to your heart's desire.
I know that I can configure and tweak my system to my heart's content, but I rather get used to the default settings where it makes sense. It eases life with multiple computers, as well as helping others to use the same software.
I just think that the traditional X shortcuts are not a very good solution to a problem, and a better one could be developed. I don't know any perfect solutions, but in my opinion, it is good that some of the most obtrusive shortcuts are already (possibly) getting a non-default status.
While I haven't lost any important work due to X.org zapping, I fail to see why a modern graphics system should have many keyboard shortcuts itself in such prominent places.
I am also an Emacs user, though I haven't yet figured what control in Emacs is close to ctrl-alt-backspace. Maybe it's the Finnish layout that has something positioned more favourably...
Joonas Sarajärvi wrote:
2009/3/28 Dan Nicholson dbn.lists@gmail.com:
2009/3/28 Joonas Sarajärvi muepsj@gmail.com:
Of course, the world isn't perfect, and there probably is need for a global shortcut to kill or restart X, among other things. However, it would be nice if X eventually got rid of everything ctrl-alt-something (Zap, vt switches, resolution changes, etc.) , so that the combinations could be used for more useful purposes, and replaced them with less intrusive ones, if any, as default.
That system is called XKB. You can remap keys to your heart's desire.
I know that I can configure and tweak my system to my heart's content, but I rather get used to the default settings where it makes sense. It eases life with multiple computers, as well as helping others to use the same software.
I just think that the traditional X shortcuts are not a very good solution to a problem, and a better one could be developed.
The traditional three-keystroke combination of Ctrl-Alt-Backspace has been working successfully for decades. There is absolutely nothing wrong with this keysequence. It is one of the most unlikely keysequences that a general X user is ever going to hit accidentally. It is only the tiny Emacs community with their very similar keystroke combinations that has ever had any problems with accidentally tripping this keystroke combination. And it's not fair to the general Xorg community that a historical well-understood and expected default should be disabled all in the interest of one tiny subcommunity.
I don't know any perfect solutions, but in my opinion, it is good that some of the most obtrusive shortcuts are already (possibly) getting a non-default status.
While I haven't lost any important work due to X.org zapping, I fail to see why a modern graphics system should have many keyboard shortcuts itself in such prominent places.
I am also an Emacs user, though I haven't yet figured what control in Emacs is close to ctrl-alt-backspace. Maybe it's the Finnish layout that has something positioned more favourably...
Try Ctrl-Alt-End or Ctrl-Alt-. Emacs users can easily mistakenly type Ctrl-Alt-Backspace when attempting these keystrokes especially on laptops. But again, that doesn't mean we need to change default behaviors. What it means is that the Emacs community needs to prepare special xorg.conf entries for their purpose of disabling Ctrl-Alt-Backspace for them and not pushing a huge change on the massive overall Xorg community.
Regards, Gerry
2009/3/28 Gerry Reno greno@verizon.net:
Joonas Sarajärvi wrote:
2009/3/28 Dan Nicholson dbn.lists@gmail.com:
2009/3/28 Joonas Sarajärvi muepsj@gmail.com:
Of course, the world isn't perfect, and there probably is need for a global shortcut to kill or restart X, among other things. However, it would be nice if X eventually got rid of everything ctrl-alt-something (Zap, vt switches, resolution changes, etc.) , so that the combinations could be used for more useful purposes, and replaced them with less intrusive ones, if any, as default.
That system is called XKB. You can remap keys to your heart's desire.
I know that I can configure and tweak my system to my heart's content, but I rather get used to the default settings where it makes sense. It eases life with multiple computers, as well as helping others to use the same software.
I just think that the traditional X shortcuts are not a very good solution to a problem, and a better one could be developed.
The traditional three-keystroke combination of Ctrl-Alt-Backspace has been working successfully for decades. There is absolutely nothing wrong with this keysequence. It is one of the most unlikely keysequences that a general X user is ever going to hit accidentally. It is only the tiny Emacs community with their very similar keystroke combinations that has ever had any problems with accidentally tripping this keystroke combination. And it's not fair to the general Xorg community that a historical well-understood and expected default should be disabled all in the interest of one tiny subcommunity.
My support for support the X.org developers' decision isn't due to my Emacs usage. I just think it's a better design to not have the Zap function enabled as default.
I think leaving the zap function disabled is very much in line with the general character of Fedora. In past, we have many times replaced old, de-facto ways of doing things with new, innovative solutions and decision. In Fedora 10, the default vt for X was changed from vt 1 to vt 7, despite many arguments similar to yours, and despite that it could potentially confuse some experienced users. Especially now that this isn't even a Fedora decision but an upstream one, it would in my opinion seem a bit odd if Fedora did override that decision. The X developers seem to think that the system should work so well that there would be no need for a magic key combo for killing the server. I think that's quite optimistic and forward-looking, which is mindset that Fedora also happens to follow quite often.
I don't know any perfect solutions, but in my opinion, it is good that some of the most obtrusive shortcuts are already (possibly) getting a non-default status.
While I haven't lost any important work due to X.org zapping, I fail to see why a modern graphics system should have many keyboard shortcuts itself in such prominent places.
I am also an Emacs user, though I haven't yet figured what control in Emacs is close to ctrl-alt-backspace. Maybe it's the Finnish layout that has something positioned more favourably...
Try Ctrl-Alt-End or Ctrl-Alt-. Emacs users can easily mistakenly type Ctrl-Alt-Backspace when attempting these keystrokes especially on laptops. But again, that doesn't mean we need to change default behaviors. What it means is that the Emacs community needs to prepare special xorg.conf entries for their purpose of disabling Ctrl-Alt-Backspace for them and not pushing a huge change on the massive overall Xorg community.
I haven't probably ever used those commands in Emacs.
Joonas Sarajärvi wrote:
2009/3/28 Gerry Reno greno@verizon.net:
The traditional three-keystroke combination of Ctrl-Alt-Backspace has been working successfully for decades. There is absolutely nothing wrong with this keysequence. It is one of the most unlikely keysequences that a general X user is ever going to hit accidentally. It is only the tiny Emacs community with their very similar keystroke combinations that has ever had any problems with accidentally tripping this keystroke combination. And it's not fair to the general Xorg community that a historical well-understood and expected default should be disabled all in the interest of one tiny subcommunity.
My support for support the X.org developers' decision isn't due to my Emacs usage. I just think it's a better design to not have the Zap function enabled as default.
I think leaving the zap function disabled is very much in line with the general character of Fedora. In past, we have many times replaced old, de-facto ways of doing things with new, innovative solutions and decision. In Fedora 10, the default vt for X was changed from vt 1 to vt 7, despite many arguments similar to yours, and despite that it could potentially confuse some experienced users. Especially now that this isn't even a Fedora decision but an upstream one, it would in my opinion seem a bit odd if Fedora did override that decision. The X developers seem to think that the system should work so well that there would be no need for a magic key combo for killing the server. I think that's quite optimistic and forward-looking, which is mindset that Fedora also happens to follow quite often.
The change regarding the default vt made sense since it made the whole vt keystroke sequence more sensible. The change with regard to default setting for Ctrl-Alt-Backspace does not make sense. The default setting has not been causing anyone any problems outside of the tiny Emacs community. And the Emacs community as I said can create their own special xorg.conf file to deal with their special keystroke combination conflict. And please, Xorg changing the default is not some forward-looking thing in any way. It is nothing more than a special interest implementation for a tiny subcommunity that ends up impacting sysadmins and creating additional work for them and increases demands on time and resources.
I don't know any perfect solutions, but in my opinion, it is good that some of the most obtrusive shortcuts are already (possibly) getting a non-default status.
While I haven't lost any important work due to X.org zapping, I fail to see why a modern graphics system should have many keyboard shortcuts itself in such prominent places.
I am also an Emacs user, though I haven't yet figured what control in Emacs is close to ctrl-alt-backspace. Maybe it's the Finnish layout that has something positioned more favourably...
Try Ctrl-Alt-End or Ctrl-Alt-. Emacs users can easily mistakenly type Ctrl-Alt-Backspace when attempting these keystrokes especially on laptops. But again, that doesn't mean we need to change default behaviors. What it means is that the Emacs community needs to prepare special xorg.conf entries for their purpose of disabling Ctrl-Alt-Backspace for them and not pushing a huge change on the massive overall Xorg community.
I haven't probably ever used those commands in Emacs.
Well there are plenty of Emacs users who do use those commands and who are having the conflict problem with Ctrl-Alt-Backspace.
Regards, Gerry
It is nothing more than a special interest implementation for a tiny subcommunity that ends up impacting sysadmins and creating additional work for them and increases demands on time and resources.
You have said this many times in this thread already. I still think there are reasons to disable zapping as default, beyond just pleasing Emacs users.
On Sat, 2009-03-28 at 14:16 -0400, Gerry Reno wrote:
And the Emacs community as I said can create their own special xorg.conf file to deal with their special keystroke combination conflict. And please, Xorg changing the default is not some forward-looking thing in any way. It is nothing more than a special interest implementation for a tiny subcommunity that ends up impacting sysadmins and creating additional work for them and increases demands on time and resources.
Could you stop with the Emacs conspiracy theory? You are making the rest of us look bad.
Once upon a time, Joonas Sarajärvi muepsj@gmail.com said:
I think leaving the zap function disabled is very much in line with the general character of Fedora. In past, we have many times replaced old, de-facto ways of doing things with new, innovative solutions and decision.
Yes, but this is a case of replacing an old, de-facto way of doing things with nothing. Now, if your X server is hosed, you hit the reset switch.
Especially now that this isn't even a Fedora decision but an upstream one, it would in my opinion seem a bit odd if Fedora did override that decision.
This is a configuration item, and plenty of configuration items are changed from upstream defaults.
On Sat, 2009-03-28 at 19:55 +0200, Joonas Sarajärvi wrote:
I think leaving the zap function disabled is very much in line with the general character of Fedora. In past, we have many times replaced old, de-facto ways of doing things with new, innovative solutions and decision.
"You are not allowed to kill your X server" is new and innovative? What, are we Apple now?
In Fedora 10, the default vt for X was changed from vt 1 to vt 7, despite many arguments similar to yours, and despite that it could potentially confuse some experienced users.
... Yes, a minor rearrangement of vcons. That's not the same thing as removing functionality entirely.
Especially now that this isn't even a Fedora decision but an upstream one, it would in my opinion seem a bit odd if Fedora did override that decision. The X developers seem to think that the system should work so well that there would be no need for a magic key combo for killing the server.
This is what is known as "delusional" and is not how you create reliable software. You get reliable software by EXPECTING failure and put mechanisms in place to mitigate it.
On 2009/03/28 08:15 (GMT-0700) Dan Nicholson composed:
It has everything to do with people accidentally killing their X session.
IMO there's no such thing as "accidentally" striking any key sequence that requires three depressed keys at once. OTOH, openSUSE's solution to require Ctrl-Alt-BS to be struck twice before it takes effect seems fine.
On Sat, Mar 28, 2009 at 10:55:37AM -0400, Gerry Reno wrote:
I've opened a thread on xorg-devel and have been getting nothing but ridiculous arguments in response. Mostly like, "well *I* accidentally killed my X server while I was typing". Total nonsense. This is all about a tiny minority of Emacs users, mostly inside Xorg itself introducing a change that has a large to impact to the overall Xorg community and all for the benefit of just the tiny Emacs community. That completely wrong and is bad stewardship.
Ctrl-Alt-Backspace was changed because of... a conspiracy of secret emacs users?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Gerry Reno wrote:
*snip*
Fedora needs to see this change for what it really is and reject it. We need to continue the historical default behavior for Ctrl-Alt-Backspace that users and sysadmins have counted on for decades without organizations and users needing to install special setups in xorg.conf which is a completely unnecessary bother and a waste of time and resources.
I don't terribly care about this change, but I'm thoroughly sick of this list's argumentum-ad-I'm-1000-years-old-and-will-never-change.
Any sysadmin who can't handle something like this needs to be fired, preferably by the reanimated corpse of Charles Darwin. Adapt and survive.
- --CJD
Casey Dahlin escreveu:
Gerry Reno wrote:
*snip*
Fedora needs to see this change for what it really is and reject it. We need to continue the historical default behavior for Ctrl-Alt-Backspace that users and sysadmins have counted on for decades without organizations and users needing to install special setups in xorg.conf which is a completely unnecessary bother and a waste of time and
resources.
I don't terribly care about this change, but I'm thoroughly sick of this list's argumentum-ad-I'm-1000-years-old-and-will-never-change.
Any sysadmin who can't handle something like this needs to be fired, preferably by the reanimated corpse of Charles Darwin. Adapt and survive.
--CJD
Fedora is not for sysadmins. It id got common users that just purchased a new notebook or a new box and also for people who's migrating from Windows Vista or something like that. It's for people who don't know that <ctrl>+alt+F2 will lead to a console loging and from that they can do something like killall -KILL Xorg...
Point is: linux is 1000 years old and distros should keep compatibility with older behaviours.
But even when you consider sysadmins, their performance is evaluated based on the time they expend doing their tasks and such time is affected every time behaviour is changed. Ok, after a while they'll catch up their pace, but the initial loss of performance is anoying. Fedora people will tell that they should be using RHEL or CENTOS...
IMHO it's irritating when you install Fedora in a box and display is not OK (from install) and you must seek discussion lists to figure out how to fix things. It's irritating when you are not able to log as root and the answer is: well, press Ctrl-Alt-F2 and use a console session. This is not something acceptable for starters (most of people migrating from other OSes). It's irritating when gdm configuration is changed and you get the answer "why you want to enable X to accept foreign connections?" when people know the (obviouss) answer (that probably you want to have remote connections).
The consequence of this kind of posture around Linux is that even though Windows Vista sucked so much, migration to linux was not that sensible (but I know many companies that migrated to Apple and OS X despite how expensive Apple hardware is).
Now we are in the middle of an unprecedent crisis. If we don't cat people's hearts and minds we won't have money to keep financing distros development. That's a real and immediate problem to be asserted by developers.
On Fri, Mar 27, 2009 at 9:45 PM, Chris Adams cmadams@hiwaay.net wrote:
Once upon a time, Jeff Spaleta jspaleta@gmail.com said:
Better yet, when is it not better to use SysRq keycombos and try to diagnose things? If you can get back keyboard control via SysRq, isn't it more beneficial to make use of SysRq instead of zapping?
Well, that's disabled by default also.
What emacs commands do the sysreqs override? :P
Jeff Spaleta skrev:
If you can get back keyboard control via SysRq, isn't it more beneficial to make use of SysRq instead of zapping?
Yes, if Alt-SysRq-K does everything Ctrl-Alt-Backspace does, and more, then perhaps that should be enabled by default instead?
Any security implications of enabling SysRq by default?
Alt-SysRq is actually "make a screenshot of the active window" in GNOME, but perhaps that's not such a big deal in the case when X is hosed.
/abo
On Sat, 2009-03-28 at 10:57 +0100, Alexander Boström wrote:
Jeff Spaleta skrev:
If you can get back keyboard control via SysRq, isn't it more beneficial to make use of SysRq instead of zapping?
Yes, if Alt-SysRq-K does everything Ctrl-Alt-Backspace does, and more, then perhaps that should be enabled by default instead?
Hm... if disabled, zillions of gnome-screenshooter windows starts to appear (I haven't actually counted them and the amount is probably proportional to the time I hold Alt [Gr]-SysRq before hitting K), if enabled, caps-lock indicator starts to blink and the computer freezes (whole computer, not only X)... Not sure how this can be helpful at all...
Any security implications of enabling SysRq by default?
Alt-SysRq is actually "make a screenshot of the active window" in GNOME, but perhaps that's not such a big deal in the case when X is hosed.
/abo
Martin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Martin Sourada wrote:
On Sat, 2009-03-28 at 10:57 +0100, Alexander Boström wrote:
Jeff Spaleta skrev:
If you can get back keyboard control via SysRq, isn't it more beneficial to make use of SysRq instead of zapping?
Yes, if Alt-SysRq-K does everything Ctrl-Alt-Backspace does, and more, then perhaps that should be enabled by default instead?
Hm... if disabled, zillions of gnome-screenshooter windows starts to appear (I haven't actually counted them and the amount is probably proportional to the time I hold Alt [Gr]-SysRq before hitting K), if enabled, caps-lock indicator starts to blink and the computer freezes (whole computer, not only X)... Not sure how this can be helpful at all...
The hangup is a kernel panic, probably a bug.
- --CJD
On Saturday 28 March 2009 11:25:42 Martin Sourada wrote:
Hm... if disabled, zillions of gnome-screenshooter windows starts to appear (I haven't actually counted them and the amount is probably proportional to the time I hold Alt [Gr]-SysRq before hitting K), if enabled, caps-lock indicator starts to blink and the computer freezes (whole computer, not only X)... Not sure how this can be helpful at all...
Not everyone uses GNOME ;o)
On Sat, 2009-03-28 at 10:57 +0100, Alexander Boström wrote:
Jeff Spaleta skrev:
If you can get back keyboard control via SysRq, isn't it more beneficial to make use of SysRq instead of zapping?
Yes, if Alt-SysRq-K does everything Ctrl-Alt-Backspace does, and more, then perhaps that should be enabled by default instead?
Hm... if disabled, zillions of gnome-screenshooter windows starts to appear (I haven't actually counted them and the amount is probably proportional to the time I hold Alt [Gr]-SysRq before hitting K), if enabled, caps-lock indicator starts to blink and the computer freezes (whole computer, not only X)... Not sure how this can be helpful at all...
Any security implications of enabling SysRq by default?
Alt-SysRq is actually "make a screenshot of the active window" in GNOME, but perhaps that's not such a big deal in the case when X is hosed.
/abo
Martin
Alexander Boström (abo@stacken.kth.se) said:
Yes, if Alt-SysRq-K does everything Ctrl-Alt-Backspace does, and more, then perhaps that should be enabled by default instead?
Any security implications of enabling SysRq by default?
Anyone at the keyboard can immediately reboot the box without any syncing, clean shutdown, or authorization at all.
Aside from that, it's perfectly secure. :)
Bill
On Tuesday 31 March 2009 00:32:28 Bill Nottingham wrote:
Alexander Boström (abo@stacken.kth.se) said:
Yes, if Alt-SysRq-K does everything Ctrl-Alt-Backspace does, and more, then perhaps that should be enabled by default instead?
Any security implications of enabling SysRq by default?
Anyone at the keyboard can immediately reboot the box without any syncing, clean shutdown, or authorization at all.
Aside from that, it's perfectly secure. :)
Bill
Anyone at the keyboard can also pull the wire (usually). For the cases where this isn't the desired behavior (e.g. kiosk), it can be switched off. :)
I would be muck more concerned if there are some problems like unlocking a locked session or similar. But if it kills all the processes on the same vt there should be no problems like this, should they?
Once upon a time, Bill Nottingham notting@redhat.com said:
Anyone at the keyboard can immediately reboot the box without any syncing, clean shutdown, or authorization at all.
Well, as seen with the GNOME clock applet permissions, we're now told that "console access" == "full access", so why not?
Don't have it both ways, where everybody has to do some configuration to get a desirable configuration. It should all be done out of the box for one end (end user rules all) or the other (system admin rules all). It should all be documented (so either end of the spectrum knows where they stand and what they might want to change).
Chris Adams (cmadams@hiwaay.net) said:
Once upon a time, Bill Nottingham notting@redhat.com said:
Anyone at the keyboard can immediately reboot the box without any syncing, clean shutdown, or authorization at all.
Well, as seen with the GNOME clock applet permissions, we're now told that "console access" == "full access", so why not?
If you're honestly arguing that the ability to set the clock equates to the ability to kill all processes except init, or the ability to immediately reboot the box, then I can see why this thread devolves into 200-message madness so quickly.
Bill
Once upon a time, Bill Nottingham notting@redhat.com said:
If you're honestly arguing that the ability to set the clock equates to the ability to kill all processes except init, or the ability to immediately reboot the box, then I can see why this thread devolves into 200-message madness so quickly.
I'm not saying they are the same. However, in the Bugzilla ticket for the clock-applet, the argument was:
Sorry but all these "security" concerns are completely bullshit since this scenario only applies to users logged in at the _local_ console. By design, the OS trusts users at the local console. The user might as well just use an axe to destroy the machine or boot into single user mode and do whatever the hell he wants.
Also, the clock applet isn't the only thing with this security mindset. The GNOME process app allows users to raise process priority (which is usually reserved for root).
I'm just saying if "the OS trusts users at the local console" is the Fedora design, then apply it equally. The defaults should reflect that design across the board, and they should be documented somewhere so people that don't want to trust the console user can adjust them.
On Saturday 28 March 2009 04:15:39 Jeff Spaleta wrote:
On Fri, Mar 27, 2009 at 7:58 PM, Pete Zaitcev zaitcev@redhat.com wrote:
Oh please. When was the last time X wedged so the keyboard survived? Your imaginary sysadmins have to powercycle anyway.
Better yet, when is it not better to use SysRq keycombos and try to diagnose things? If you can get back keyboard control via SysRq, isn't it more beneficial to make use of SysRq instead of zapping?
Fedora has been disabling the "magic SysRq" by default for several years?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Pete Zaitcev wrote:
On Fri, 27 Mar 2009 17:19:05 -0400, Gerry Reno
greno@verizon.net wrote:
This change to default behavior of Ctrl-Alt-Backspace is an
example of a
tiny minority of Emacs users lobbying xorg for a change that will
affect
a huge number of community and commercial users including
datacenters
and their sys admins. This change needs to be reversed
immediately.
Oh please. When was the last time X wedged so the keyboard
survived?
Your imaginary sysadmins have to powercycle anyway.
-- Pete
There's a bug with the Intel driver when DE for KWin is enabled such that the system eventually uses all of its available file handles and everything locks up with the notification of "too many open files". Nothing can be run since that is requires a file to be opened. Ctrl+Alt+Bksp is the only way I've found that "fixes" the problem without a reboot (other than not using DE, which is...annoying). Yes there is a bug open against it: https://bugzilla.redhat.com/show_bug.cgi?id=486695. Anything else that causes similar things to happen either need a reboot without Ctrl+Alt+Bksp.
- --Ben
On Saturday 28 March 2009 03:58:20 Pete Zaitcev wrote:
On Fri, 27 Mar 2009 17:19:05 -0400, Gerry Reno greno@verizon.net wrote:
This change to default behavior of Ctrl-Alt-Backspace is an example of a tiny minority of Emacs users lobbying xorg for a change that will affect a huge number of community and commercial users including datacenters and their sys admins. This change needs to be reversed immediately.
Oh please. When was the last time X wedged so the keyboard survived? Your imaginary sysadmins have to powercycle anyway.
About three days ago, actually ...
On Fri, Mar 27, 2009 at 3:31 PM, Gerry Reno greno@verizon.net wrote:
I was reading through the F11A Release Notes when I came across this:
"The key combination Ctrl-Alt-Backspace to kill the X server has been disabled by default as a decision of the upstream Xorg project."
Having to deal with many servers and workstations in a company it is crucial that Ctrl-Alt-Backspace be enabled by default. There are times when your KVM has lost mouse control or X is in a tight loop and something like Ctrl-Alt-Backspace can save the situation. This is much more common than the uncommon cases that are illustrated as to why this has been removed as default.
Ctrl-Alt-Backspace needs to be restored as the "default" and Emacs users or others that find themselves in conflict with Java expressions can just disable it for their very limited purpose.
Regards, Gerry
So what am I supposed to do when X starts with the monitor off [1] ? Restart the commuter?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=490082
On Fri, 2009-03-27 at 16:31 -0400, Gerry Reno wrote:
I was reading through the F11A Release Notes when I came across this:
"The key combination Ctrl-Alt-Backspace to kill the X server hasbeen disabled by default as a decision of the upstream Xorg project."
Having to deal with many servers and workstations in a company it is crucial that Ctrl-Alt-Backspace be enabled by default. There are times when your KVM has lost mouse control or X is in a tight loop and something like Ctrl-Alt-Backspace can save the situation. This is much more common than the uncommon cases that are illustrated as to why this has been removed as default.
Ctrl-Alt-Backspace needs to be restored as the "default" and Emacs users or others that find themselves in conflict with Java expressions can just disable it for their very limited purpose.
Regards, Gerry
Hm... I'm personally not very much concerned about it... If X is just misbehaving you can switch to terminal and kill it. If it freezes, it blocks the keyboard and ctrl+alt+backspace is unusable as well, at least for me... The only good solution *I* see is to redesign it so that X never blocks the keyboard, even if frozen. I don't always have a second computer to use to ssh to my laptop to kill the frozen X...
Also, as pointed out by other people, it's *default* setting. If you disagree with it, just change it to your preference. No one stops you doing that. And if you still disagree with it being default, go complain upstream, Fedora just follows what the upstream project has chosen to do.
Martin
On Fri, 2009-03-27 at 23:11 +0100, Martin Sourada wrote:
Hm... I'm personally not very much concerned about it...
I'm not concerned about it either. I don't run X directly on my servers, so the whole VM thing is a little bit of hogwash to me. ssh exported X works just fine for when I need something graphical, otherwise it's CLI.
What exactly is your use case that you need a local functioning X on all these systems in your data center and virtual hosts?
Jesse Keating wrote:
I'm not concerned about it either. I don't run X directly on my servers, so the whole VM thing is a little bit of hogwash to me. ssh exported X works just fine for when I need something graphical, otherwise it's CLI.
What exactly is your use case that you need a local functioning X on all these systems in your data center and virtual hosts?
X servers are everywhere these days. Even on some of our servers and VM's. We have servers hosting test VM's for users and we have X running so that we can bring up the graphical virtualization tools so we can run the VM's console and see what is happening with a particular users VM X server.
Regards, Gerry
On Friday 27 March 2009 18:04:11 Gerry Reno wrote:
Jesse Keating wrote:
I'm not concerned about it either. I don't run X directly on my servers, so the whole VM thing is a little bit of hogwash to me. ssh exported X works just fine for when I need something graphical, otherwise it's CLI.
What exactly is your use case that you need a local functioning X on all these systems in your data center and virtual hosts?
X servers are everywhere these days. Even on some of our servers and VM's. We have servers hosting test VM's for users and we have X running so that we can bring up the graphical virtualization tools so we can run the VM's console and see what is happening with a particular users VM X server.
I have to agree with Jesse on this. It sounds like you are getting a lot more exercise than a SysAdmin should. ;-)
I am surprised that you have so many systems on which this is apparently a problem and yet you do not do provisioning where a simple config change would resolve it. Even without provisioning for installs, any config provisioning would easily handle this.
I am also a SysAdmin, and I do (very rarely) use this key combination, but certainly not often enough to see this as a big deal. There are soooo many ways around this change and around the need for the key combination in the first place.
I wish you luck in your upstream fight.
Patrick W. Barnes wrote:
I have to agree with Jesse on this. It sounds like you are getting a lot more exercise than a SysAdmin should. ;-)
I am surprised that you have so many systems on which this is apparently a problem and yet you do not do provisioning where a simple config change would resolve it. Even without provisioning for installs, any config provisioning would easily handle this.
I am also a SysAdmin, and I do (very rarely) use this key combination, but certainly not often enough to see this as a big deal. There are soooo many ways around this change and around the need for the key combination in the first place.
This is a big deal because now some tiny minority has lobbied for changes to X that end up affecting a large community. And the bogus arguments about user getting confused about keys is just that totally bogus. I've never had a user complain about X control key combinations. Emacs users complain because Emacs wants to have the same key control sequences as Xorg. That's just wrong. And as a sys admin if you're not willing to stand up and say that's wrong, then watch for more ridiculous changes coming your way in the future.
I wish you luck in your upstream fight
There shouldn't even need to be a fight. It's a totally ridiculous change based on bogus arguments to begin with.
Regards, Gerry
On Friday 27 March 2009 18:22:14 Gerry Reno wrote:
This is a big deal because now some tiny minority has lobbied for changes to X that end up affecting a large community. And the bogus arguments about user getting confused about keys is just that totally bogus. I've never had a user complain about X control key combinations. Emacs users complain because Emacs wants to have the same key control sequences as Xorg. That's just wrong. And as a sys admin if you're not willing to stand up and say that's wrong, then watch for more ridiculous changes coming your way in the future.
...
There shouldn't even need to be a fight. It's a totally ridiculous change based on bogus arguments to begin with.
I agree with most of your arguments. If the change were to completely remove support for my desired behavior, I would also complain. Since it is just a change to the default behavior, and I can easily recover my preferred behavior, I will accept the change and wish those who care more strongly the best of luck.
"I support and oppose many things, but not strongly enough to pick up a pen." - Bender, Futurama
Gerry Reno wrote:
Patrick W. Barnes wrote:
I have to agree with Jesse on this. It sounds like you are getting a lot more exercise than a SysAdmin should. ;-)
I am surprised that you have so many systems on which this is apparently a problem and yet you do not do provisioning where a simple config change would resolve it. Even without provisioning for installs, any config provisioning would easily handle this.
I am also a SysAdmin, and I do (very rarely) use this key combination, but certainly not often enough to see this as a big deal. There are soooo many ways around this change and around the need for the key combination in the first place.
This is a big deal because now some tiny minority has lobbied for changes to X that end up affecting a large community. And the bogus arguments about user getting confused about keys is just that totally bogus. I've never had a user complain about X control key combinations. Emacs users complain because Emacs wants to have the same key control sequences as Xorg. That's just wrong. And as a sys admin if you're not willing to stand up and say that's wrong, then watch for more ridiculous changes coming your way in the future.
I wish you luck in your upstream fight
There shouldn't even need to be a fight. It's a totally ridiculous change based on bogus arguments to begin with.
And a few more angry threads are starting to pop up here and there as word of this is getting out:
http://www.linux-archive.org/kubuntu-user/265174-restarting-x-server.html
Regards, Gerry
On Fri, 2009-03-27 at 19:38 -0400, Gerry Reno wrote:
There shouldn't even need to be a fight. It's a totally ridiculous change based on bogus arguments to begin with.
And a few more angry threads are starting to pop up here and there as word of this is getting out:
http://www.linux-archive.org/kubuntu-user/265174-restarting-x-server.html
If there shouldn't be a fight and if the change was as really stupid as you say it is, you shouldn't have much difficulty getting it reverted upstream.
Gerry Reno wrote:
This is a big deal because now some tiny minority has lobbied for changes to X that end up affecting a large community. And the bogus arguments about user getting confused about keys is just that totally bogus. I've never had a user complain about X control key combinations. Emacs users complain because Emacs wants to have the same key control sequences as Xorg. That's just wrong. And as a sys admin if you're not willing to stand up and say that's wrong, then watch for more ridiculous changes coming your way in the future.
I agree here, I think disabling Ctrl+Alt+BkSp by default makes no sense whatsoever.
Sure, it's just a default setting, but that doesn't mean the default shouldn't be sane.
And setting defaults is one of the things a distribution is for. I disagree about the assertion that we should blindly follow upstream defaults. Several packages have Fedora-specific default configurations. KDE even has a kde-settings package for that purpose (and no, there's no way we're going to remove that package). Many other packages ship with config files which differ from upstream's defaults.
Kevin Kofler
On Fri, Mar 27, 2009 at 1:31 PM, Gerry Reno greno@verizon.net wrote:
I was reading through the F11A Release Notes when I came across this:
"The key combination Ctrl-Alt-Backspace to kill the X server has been disabled by default as a decision of the upstream Xorg project."
Amazing! How did this get through without anyone knowing?
I'm sure if X.org (or Fedora) actually asked the community, this change would have never made it upstream.
Extremely poor judgement by upstream IMO.
I am in 100% total agreement with Gerry, and I hope the FESCo or whatever body is in charge of making a decision for Fedora will make the correct decision on this. Obviously (for those of us with brains) the X.org people did not make the correct decision.
/me *shakes head in bewilderment*
Christopher Stone wrote:
On Fri, Mar 27, 2009 at 1:31 PM, Gerry Reno greno@verizon.net wrote:
I was reading through the F11A Release Notes when I came across this:
"The key combination Ctrl-Alt-Backspace to kill the X server has been disabled by default as a decision of the upstream Xorg project."
Amazing! How did this get through without anyone knowing?
A lot of people already knew and it has been well documented in the release notes. There was a long discussion already in fedora-test list.
I am in 100% total agreement with Gerry, and I hope the FESCo or whatever body is in charge of making a decision for Fedora will make the correct decision on this.
I hope, we continue to leave such decisions to the maintainers of the software rather than micro manage them with a committee. FESCo should not be (usually) be overriding maintainer decisions.
Rahul
On 03/27/2009 10:08 PM, Rahul Sundaram wrote:
Christopher Stone wrote:
<snip<
I hope, we continue to leave such decisions to the maintainers of the software rather than micro manage them with a committee. FESCo should not be (usually) be overriding maintainer decisions.
Rahul
Maintainers should also (usually) be listening to the community.
Clyde E. Kunkel wrote:
On 03/27/2009 10:08 PM, Rahul Sundaram wrote:
Christopher Stone wrote:
<snip<
I hope, we continue to leave such decisions to the maintainers of the software rather than micro manage them with a committee. FESCo should not be (usually) be overriding maintainer decisions.
Rahul
Maintainers should also (usually) be listening to the community.
Community is not a single entity. It is a very diverse set of independent people with sometimes very strong opinions on both sides.
Rahul
On 03/28/2009 01:24 PM, Rahul Sundaram wrote:
Clyde E. Kunkel wrote:
On 03/27/2009 10:08 PM, Rahul Sundaram wrote:
Christopher Stone wrote:
<snip<
I hope, we continue to leave such decisions to the maintainers of the software rather than micro manage them with a committee. FESCo should not be (usually) be overriding maintainer decisions.
Rahul
Maintainers should also (usually) be listening to the community.
Community is not a single entity. It is a very diverse set of independent people with sometimes very strong opinions on both sides.
Rahul
And the many strong opinions need to be heard by the maintainers. If there is a strong opinion, as this diverse thread has shown, then that is a strong indication that a decision should be revisited and if no change is made, then say why with the facts and data to support it. I haven't seen a real strong indication in this thread why the default behavior should be as it is, only why it shouldn't be, tho it does seem to be a simple matter to turn on c-a-bs. The question revolves around defaults and which it should be.
lyde E. Kunkel wrote:
And the many strong opinions need to be heard by the maintainers
They did hear it (read fedora-test list discussions on the same topic) but the point remains that the community doesn't have one single opinion on this topic. Trying to pitch it as a debate between some monolithic community on one side and the maintainers on the other side is just plain wrong. Maintainers are part of the same community as everybody else.
Rahul
Rahul Sundaram wrote:
They did hear it (read fedora-test list discussions on the same topic) but the point remains that the community doesn't have one single opinion on this topic. Trying to pitch it as a debate between some monolithic community on one side and the maintainers on the other side is just plain wrong. Maintainers are part of the same community as everybody else.
FWIW, maintainers also don't have a single uniform opinion. I'm a maintainer, though not of X.Org, and I think it's a mistake to disable Ctrl+Alt+BkSp by default.
Kevin Kofler
Kevin Kofler wrote:
Rahul Sundaram wrote:
They did hear it (read fedora-test list discussions on the same topic) but the point remains that the community doesn't have one single opinion on this topic. Trying to pitch it as a debate between some monolithic community on one side and the maintainers on the other side is just plain wrong. Maintainers are part of the same community as everybody else.
FWIW, maintainers also don't have a single uniform opinion. I'm a maintainer, though not of X.Org, and I think it's a mistake to disable Ctrl+Alt+BkSp by default.
You are just proving my point that pitching it as community vs maintainers makes absolutely no sense because it is every individual's opinion which is different.
Rahul
On 03/28/2009 08:35 PM, Rahul Sundaram wrote:
Kevin Kofler wrote:
Rahul Sundaram wrote:
They did hear it (read fedora-test list discussions on the same topic) but the point remains that the community doesn't have one single opinion on this topic. Trying to pitch it as a debate between some monolithic community on one side and the maintainers on the other side is just plain wrong. Maintainers are part of the same community as everybody else.
FWIW, maintainers also don't have a single uniform opinion. I'm a maintainer, though not of X.Org, and I think it's a mistake to disable Ctrl+Alt+BkSp by default.
You are just proving my point that pitching it as community vs maintainers makes absolutely no sense because it is every individual's opinion which is different.
Rahul
In reading thru this thread I don't see an us vs them. All I see is a community that has strong opinions. Maintainers should listen to the community. Forget about strong individual opinions--this thread shows that there is enough concern that the maintainers should respect that concern and at least address it thru the forums or with code.
Once upon a time, Clyde E. Kunkel clydekunkel7734@cox.net said:
On 03/28/2009 08:35 PM, Rahul Sundaram wrote:
You are just proving my point that pitching it as community vs maintainers makes absolutely no sense because it is every individual's opinion which is different.
In reading thru this thread I don't see an us vs them. All I see is a community that has strong opinions. Maintainers should listen to the community. Forget about strong individual opinions--this thread shows that there is enough concern that the maintainers should respect that concern and at least address it thru the forums or with code.
Yeah, I haven't seen many people that really wanted this change.
If the Fedora maintainer doesn't want to override this (mostly poorly received) upstream decision, please at least follow the suggestion made here to make two changes:
- re-enable DontZap by default - unbind the Terminate_Server keysym from Ctrl+Alt+Backspace
This makes it easier for end-users to re-enable the old behavior (on a per-user basis instead of per-system basis even).
This brings up another thought though: is there a more up-to-date keyboard mapping editor than xkeycaps (e.g. something integrated into GNOME and KDE)? I guess this specific binding could be added to the GNOME keyboard layout options or keyboard shortcuts screens (I assume there's something similar in KDE).
On Sun, 2009-03-29 at 11:20 -0500, Chris Adams wrote:
- re-enable DontZap by default
- unbind the Terminate_Server keysym from Ctrl+Alt+Backspace
This makes it easier for end-users to re-enable the old behavior (on a per-user basis instead of per-system basis even).
... Thing is, the time I usually need ctl-alt-bs is when the X server screws up immediately on startup. Likely hanging before any clients even have a chance to run.
Christopher Stone chris.stone@gmail.com writes:
I am in 100% total agreement with Gerry, and I hope the FESCo or whatever body is in charge of making a decision for Fedora will make the correct decision on this. Obviously (for those of us with brains) the X.org people did not make the correct decision.
Obviously I must be without brains, because I support the change.
/Benny
On Sat, Mar 28, 2009 at 7:30 AM, Benny Amorsen benny+usenet@amorsen.dk wrote:
Christopher Stone chris.stone@gmail.com writes:
I am in 100% total agreement with Gerry, and I hope the FESCo or whatever body is in charge of making a decision for Fedora will make the correct decision on this. Obviously (for those of us with brains) the X.org people did not make the correct decision.
Obviously I must be without brains, because I support the change.
Right, I suppose the X.org people realize that X is so incredibly stable, that no software, no matter how poorly written could ever cause X to lock up. Especially games. You know, those things that newbies run. And you know newbies, they are extremely proficient at switching virtual consoles and killing X sessions...
Can I please just give a big fat DUH to all the X.org people out there? Thanks for being so stupid.
-Chris
I actually agree that Ctrl-Alt-Backspace should stay around but also respect that it is ultimately up to upstream to decide but here is a wacky solution that might just work. How about having a small package that automatically enables Ctrl-Alt-Backspace when installed (call it "ctrl-alt-backspace" for arguments sake). Sysadmins or people who just want it enabled can easily install it and even make it part of kickstart file for larger installations. Emacs users or anybody else who might accidentally hit that combo by accident can simply leave it uninstalled. Then we can all be happy and get on with more interesting arguments such as how quickly would i go blind if i just keep staring at the bottom of my mouse?
John5342 wrote:
I actually agree that Ctrl-Alt-Backspace should stay around but also respect that it is ultimately up to upstream to decide but here is a wacky solution that might just work. How about having a small package that automatically enables Ctrl-Alt-Backspace when installed (call it "ctrl-alt-backspace" for arguments sake). Sysadmins or people who just want it enabled can easily install it and even make it part of kickstart file for larger installations. Emacs users or anybody else who might accidentally hit that combo by accident can simply leave it uninstalled. Then we can all be happy and get on with more interesting arguments such as how quickly would i go blind if i just keep staring at the bottom of my mouse?
NO! This means a lot of work for sysadmins around the world that is totally unnecessary. There is nothing wrong with the current Ctrl-Alt-Backspace default of enabled. Nothing. If there are any special packages/files to be created they need to be created only by the tiny Emacs community users. There is absolutely no sane reason to cause a massive impact to sysadmins worldwide by changing a global default that has been working successfully for decades and all for the benefit of a tiny few in the Emacs community. Emacs control sequences of Ctrl-Alt-End and Ctrl-Alt-\ cause problems for Emacs users because they can accidentally hit Ctrl-Alt-Backspace as these keystroke combinations are very close. But that doesn't give anybody the right to thrust a massive change on the whole Xorg community of tens of millions of installations just so a handful of Emacs users can be protected. What needs to happen is that the default needs to remain as it has always been, and the Emacs community needs to create xorg.conf entries for their users, since they are the only ones having any type of problem with Ctrl-Alt-Backspace. That limits the impact to a tiny number of Emacs uses instead of the whole Xorg installations worldwide.
Regards, Gerry
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Gerry Reno wrote:
John5342 wrote:
How about having a small package that automatically enables Ctrl-Alt-Backspace when installed (call it "ctrl-alt-backspace" for arguments sake).
NO! This means a lot of work for sysadmins around the world that is totally unnecessary.
Wow. First you don't seem to use any provisioning, now you don't seem to use kickstart files either. I don't know what it is you're doing to these computers, but it isn't looking much like "administration."
Or maybe its because none of those things have been around for "decades," and if Fedora were sane you'd still administrate it the way you did Unix boxes in 1986.
- --CJD
On Fri, 2009-03-27 at 16:31 -0400, Gerry Reno wrote:
I was reading through the F11A Release Notes when I came across this:
"The key combination Ctrl-Alt-Backspace to kill the X server hasbeen disabled by default as a decision of the upstream Xorg project."
Having to deal with many servers and workstations in a company it is crucial that Ctrl-Alt-Backspace be enabled by default. There are times when your KVM has lost mouse control or X is in a tight loop and something like Ctrl-Alt-Backspace can save the situation. This is much more common than the uncommon cases that are illustrated as to why this has been removed as default.
Ctrl-Alt-Backspace needs to be restored as the "default" and Emacs users or others that find themselves in conflict with Java expressions can just disable it for their very limited purpose.
Regards, Gerry
Rahul,
What's the policy on having the URL for both this thread and the other incredibly long thread regarding that that appeared shortly after f11-alpha including in the release notes, so that people can go and read these threads, realize that (in almost every case) there point of view regarding this has already been presented and that this is how it will be?
I'm figuring that something should be attempted so that we don't have to go through this conversation a third time when f11 is released. ;-]
Rodd
Rodd Clarkson wrote:
Rahul,
What's the policy on having the URL for both this thread and the other incredibly long thread regarding that that appeared shortly after f11-alpha including in the release notes, so that people can go and read these threads, realize that (in almost every case) there point of view regarding this has already been presented and that this is how it will be?
I'm figuring that something should be attempted so that we don't have to go through this conversation a third time when f11 is released. ;-]
I don't think it is appropriate content for release notes since it isn't useful to lead users to read a few threads with hundreds of mails in that context. Fedora release notes is not Fedora Weekly News.
Rahul
On Mon, 2009-03-30 at 10:55 +0530, Rahul Sundaram wrote:
Rodd Clarkson wrote:
Rahul,
What's the policy on having the URL for both this thread and the other incredibly long thread regarding that that appeared shortly after f11-alpha including in the release notes, so that people can go and read these threads, realize that (in almost every case) there point of view regarding this has already been presented and that this is how it will be?
I'm figuring that something should be attempted so that we don't have to go through this conversation a third time when f11 is released. ;-]
I don't think it is appropriate content for release notes since it isn't useful to lead users to read a few threads with hundreds of mails in that context. Fedora release notes is not Fedora Weekly News.
I'm not suggesting that you put all these threads into the release notes, just a url so that hopefully people will read the discussion already had (and then hopefully avoid having the same fruitless convesation again).
R.
* Rodd Clarkson rodd@clarkson.id.au [20090331 03:56]:
On Mon, 2009-03-30 at 10:55 +0530, Rahul Sundaram wrote:
[snip]
I don't think it is appropriate content for release notes since it isn't useful to lead users to read a few threads with hundreds of mails in that context. Fedora release notes is not Fedora Weekly News.
I'm not suggesting that you put all these threads into the release notes, just a url so that hopefully people will read the discussion already had (and then hopefully avoid having the same fruitless convesation again).
You have an excessive amount of faith in people. This discussion will be had again (and again), probably by mostly the same people, once it's rolled out in a release. Same arguments, same flames, possibly a different list.
I have read this thread with much merriment, seeing hilarious accusations of conspiracy by closet Emacs users (as if Vim users would be any better *grin*, tinfoil? first door on the left), shouting from the roof-tops by a real minority (albeit vocal such) etc etc ad nauseum as well as more and more far-fetched and ludicrous analogies being put forth. (I did laugh at the shatterproof glass one..)
I don't think this is necessarily a good poster-child discussion to stick in the release-notes without a healthy dose of soap+water to clean it up first. "We resist change" somehow don't seem to quite match the Fedora that I've come to know.
C-A-Bs is a known key combination, it may occasionaly help in a sticky situation (not getting covered in syrup in the first place would help too) but it may also cause people to lose a session and unsaved work. SysRq's are disabled by default for good reason, and so should C-A-Bs be, where savvy admins that need the functionality ought to be capable of enabling it *should the need arise*. (They do *test* things before they roll them out company wide, right?)
Personally, I've seen some interesting technical bits in this thread, that you now - thanks to the autoconfiguration of X - can drop in snippets of xorg.conf (can sysadmins spell "puppet" please?) to enable/disable very selected bits. It's also a long long time since I personally had to use C-A-Bs out of anything but lazyness. A wedged X usually means either a flip to a vc (Thunar in F10 updates-testing seems to do this recently, and no, I've not filed a BZ - yet) to nuke the offending process or a hard reboot since keyboard interrupt left the building.
Right.. I'm late for work and I'll get off my soapbox now.
Anders Rayner-Karlsson wrote:
- Rodd Clarkson rodd@clarkson.id.au [20090331 03:56]:
On Mon, 2009-03-30 at 10:55 +0530, Rahul Sundaram wrote:
[snip]
I don't think it is appropriate content for release notes since it isn't useful to lead users to read a few threads with hundreds of mails in that context. Fedora release notes is not Fedora Weekly News.
I'm not suggesting that you put all these threads into the release notes, just a url so that hopefully people will read the discussion already had (and then hopefully avoid having the same fruitless convesation again).
You have an excessive amount of faith in people. This discussion will be had again (and again), probably by mostly the same people, once it's rolled out in a release. Same arguments, same flames, possibly a different list.
I rarely step in threads, so forgive me for this once.
Good computing => "least surprise effect". People coming from windows => ctrl+alt+<fumble>bs "OH CRAP --- I am so XXXX I forgot to save my work files in 15 Word (ops, Openoffice) windows in the past 3 days!!!!" People knowing their systems and just upgrading => x blocked => ctrl+alt+bs ... ctrl+alt+bs... "what the..." ... CTRL+ALT+BS. "OH SHIT -- I got to hard reboot loosing all the work on console sessions and possibly fucking up that crap of XXXX filesystem the installer forced me to use!!!!"
If you think that some of the old users not sticking with this mailing list will ever get to know you're taken a so relevant decision (i.e. by carefully reading a changelog) you're very probably wrong. They expect not to be surprised.
SO, if you want to make a so relevant decision, the only viable ways not to get existing users "surprised" (and one (more) step towards other distros) are: 1) leave it as it always been; the programmers of the old say "if it's not broken, don't fix it" (this is truly the way of the Tao); or 2) have a BIG BOX warning about the change and how to put it as it was before; but preferabily 3) have a BIG BOX with a BIG BUTTON during installation asking "do you REALLY want to disable the life-saver ctrl+alt+bs sequence that saved your system from total hang so many times in the past?"
My two cents.
Giancarlo Niccolai.
* Giancarlo Niccolai gc@falconpl.org [20090331 09:54]:
Anders Rayner-Karlsson wrote:
- Rodd Clarkson rodd@clarkson.id.au [20090331 03:56]:
On Mon, 2009-03-30 at 10:55 +0530, Rahul Sundaram wrote:
[snip]
I don't think it is appropriate content for release notes since it isn't useful to lead users to read a few threads with hundreds of mails in that context. Fedora release notes is not Fedora Weekly News.
I'm not suggesting that you put all these threads into the release notes, just a url so that hopefully people will read the discussion already had (and then hopefully avoid having the same fruitless convesation again).
You have an excessive amount of faith in people. This discussion will be had again (and again), probably by mostly the same people, once it's rolled out in a release. Same arguments, same flames, possibly a different list.
I rarely step in threads, so forgive me for this once.
Good computing => "least surprise effect". People coming from windows => ctrl+alt+<fumble>bs "OH CRAP --- I am so XXXX I forgot to save my work files in 15 Word (ops, Openoffice) windows in the past 3 days!!!!" People knowing their systems and just upgrading => x blocked => ctrl+alt+bs ... ctrl+alt+bs... "what the..." ... CTRL+ALT+BS. "OH SHIT -- I got to hard reboot loosing all the work on console sessions and possibly fucking up that crap of XXXX filesystem the installer forced me to use!!!!"
If people truly know their systems, as you suggest they do, your second scenario will not happen. Switching to a vc is hardly rocket surgery if you are at all familiar with the system. Trying C-A-Bs and finding it ineffective, it's not a big step to trying C-A-F[1-6] to see if you can get a vc. Anyone incapable of something so truly simple would probably not resort to C-A-Bs in the first instance, but go for the powerswitch immediately.
If you think that some of the old users not sticking with this mailing list will ever get to know you're taken a so relevant decision (i.e. by carefully reading a changelog) you're very probably wrong. They expect not to be surprised.
Part of my job is to set expectations with customers having much the same attitude as you are exhibiting. Read the releasenotes, read the changelogs.
This is hardly such a critical change as some are making it out to be and re-enabling it for those few that really want the functionality back is trivial, as exhibited in the thread already.
SO, if you want to make a so relevant decision, the only viable ways not to get existing users "surprised" (and one (more) step towards other distros) are:
- leave it as it always been; the programmers of the old say "if it's
not broken, don't fix it" (this is truly the way of the Tao); or
There is a case for arguing that leaving C-A-Bs enabled is broken. It was argued upstream - successfully. If you disagree with that decision, you can always lobby upstream to revert the change. This point has also already been made in this thread.
- have a BIG BOX warning about the change and how to put it as it was
before; but preferabily
Considering the amount of changes that will have happened between F10 and F11, do you honestly belive that this even is feasible? Anyone upgrading or installing F11 would have hundreds, if not thousands, of "BIG BOX" warnings to click through before they even got near the system to use it. This is what the Release Notes is for.
Remember - as passionate as you feel about *this* change, others feel about other changes that happens. In the grand scheme of things, this is rather an insignificant change as the functionality is not removed, it simply will not be enabled by default.
- have a BIG BOX with a BIG BUTTON during installation asking "do you
REALLY want to disable the life-saver ctrl+alt+bs sequence that saved your system from total hang so many times in the past?"
This is not a convincing business justification, and a customer filing a feature request with that type of argument would see it shot down in flames very rapidly. "I want this feature because I want it" ends up forgotten at the bottom of the pile.
Take a step back, and come up with a rational, direct and convincing argument for why this functionality absolutely have to be enabled by default. No emotion, just clear, cold hard facts and argument. Present it here so that it can be challenged (that'll strengthen the argument when you later take it upstream) and debated.
Cheers,
Anders Rayner-Karlsson wrote:
This is hardly such a critical change as some are making it out to be and re-enabling it for those few that really want the functionality back is trivial, as exhibited in the thread already.
I don't really think it can trivially be re-enabled. A common use case is when first installing and you can't see the X display because there's something wrong with the driver or with the resolution. You can't find out how to re-enable ctrl-alt-bs either, because you don't have a working computer to do the web search.
Andrew.
Anders Rayner-Karlsson wrote:
- Giancarlo Niccolai gc@falconpl.org [20090331 09:54]:
Anders Rayner-Karlsson wrote:
- Rodd Clarkson rodd@clarkson.id.au [20090331 03:56]:
On Mon, 2009-03-30 at 10:55 +0530, Rahul Sundaram wrote:
[snip]
I don't think it is appropriate content for release notes since it isn't useful to lead users to read a few threads with hundreds of mails in that context. Fedora release notes is not Fedora Weekly News.
I'm not suggesting that you put all these threads into the release notes, just a url so that hopefully people will read the discussion already had (and then hopefully avoid having the same fruitless convesation again).
You have an excessive amount of faith in people. This discussion will be had again (and again), probably by mostly the same people, once it's rolled out in a release. Same arguments, same flames, possibly a different list.
I rarely step in threads, so forgive me for this once.
Good computing => "least surprise effect". People coming from windows => ctrl+alt+<fumble>bs "OH CRAP --- I am so XXXX I forgot to save my work files in 15 Word (ops, Openoffice) windows in the past 3 days!!!!" People knowing their systems and just upgrading => x blocked => ctrl+alt+bs ... ctrl+alt+bs... "what the..." ... CTRL+ALT+BS. "OH SHIT -- I got to hard reboot loosing all the work on console sessions and possibly fucking up that crap of XXXX filesystem the installer forced me to use!!!!"
If people truly know their systems, as you suggest they do, your second scenario will not happen. Switching to a vc is hardly rocket surgery if you are at all familiar with the system. Trying C-A-Bs and finding it ineffective, it's not a big step to trying C-A-F[1-6] to see if you can get a vc. Anyone incapable of something so truly simple would probably not resort to C-A-Bs in the first instance, but go for the powerswitch immediately.
it may be educated enough to try it. But it is not like that an X session hang so bad that you have to ctrl-alt-bs it will allow you to CAF1-6 at all, or will let you to do anything meaningful with it (i.e. bash may not be able to get the resources to start). When you HAVE to CABs, it's because you CAN'T CAF1-6.
(There was my two cents, so don't expect me to join in this convo; I just wanted to correct your assumption that you may CAF1-6 away a situation in which you have to CABs, which is wrong, as another poster pointed out).
GN.
* Giancarlo Niccolai gc@falconpl.org [20090331 12:20]:
it may be educated enough to try it. But it is not like that an X session hang so bad that you have to ctrl-alt-bs it will allow you to CAF1-6 at all, or will let you to do anything meaningful with it (i.e. bash may not be able to get the resources to start). When you HAVE to CABs, it's because you CAN'T CAF1-6.
(There was my two cents, so don't expect me to join in this convo; I just wanted to correct your assumption that you may CAF1-6 away a situation in which you have to CABs, which is wrong, as another poster pointed out).
IIRC, and I believe that was pointed out in this thread as well, is that these keypresses are handled in the same way by the same part of the X server. If C-A-Bs works, so will C-A-F2 to drop you at a vc.
Through past experience, I have never found an instance (since moving from XFree86 to Xorg) where the Xserver was wedged in a way that switching to a vc did not work, but C-A-Bs did. I have seen plenty of X lockups (Xorg intel driver issues in F10) in the last few months and not a single one of those were resolvable by C-A-Bs.
Cheers,
On Tuesday 31 March 2009 12:56:38 Anders Rayner-Karlsson wrote:
- Giancarlo Niccolai gc@falconpl.org [20090331 12:20]:
it may be educated enough to try it. But it is not like that an X session hang so bad that you have to ctrl-alt-bs it will allow you to CAF1-6 at all, or will let you to do anything meaningful with it (i.e. bash may not be able to get the resources to start). When you HAVE to CABs, it's because you CAN'T CAF1-6.
(There was my two cents, so don't expect me to join in this convo; I just wanted to correct your assumption that you may CAF1-6 away a situation in which you have to CABs, which is wrong, as another poster pointed out).
IIRC, and I believe that was pointed out in this thread as well, is that these keypresses are handled in the same way by the same part of the X server. If C-A-Bs works, so will C-A-F2 to drop you at a vc.
and in this thread was also pointed:
"When something starts to eat all resources, you can kill it (with whole X server if it's not the X server eating all). You definitely have no time to switch to vt, log in and kill it..."
Through past experience, I have never found an instance (since moving from XFree86 to Xorg) where the Xserver was wedged in a way that switching to a vc did not work, but C-A-Bs did. I have seen plenty of X lockups (Xorg intel driver issues in F10) in the last few months and not a single one of those were resolvable by C-A-Bs.
you have just different user experience
* Michal Hlavinka mhlavink@redhat.com [20090331 13:06]:
On Tuesday 31 March 2009 12:56:38 Anders Rayner-Karlsson wrote:
IIRC, and I believe that was pointed out in this thread as well, is that these keypresses are handled in the same way by the same part of the X server. If C-A-Bs works, so will C-A-F2 to drop you at a vc.
and in this thread was also pointed:
"When something starts to eat all resources, you can kill it (with whole X server if it's not the X server eating all). You definitely have no time to switch to vt, log in and kill it..."
And the BZ's for this observed behaviour are...?
Through past experience, I have never found an instance (since moving from XFree86 to Xorg) where the Xserver was wedged in a way that switching to a vc did not work, but C-A-Bs did. I have seen plenty of X lockups (Xorg intel driver issues in F10) in the last few months and not a single one of those were resolvable by C-A-Bs.
you have just different user experience
That is entirely possible. I did a straw poll among my technical colleagues (and included a Senior Director for good measure) and the only one that uses C-A-Bs (due to flaws in suspend/resume) is the Senior Director. No-one else could find a reason to retain C-A-Bs as enabled by default.
Maybe - and here's the rub - disabling the ability to kill X willy-nilly would encourage people to file bugs against the applications that really misbehave, allowing for an overall improvement of stability, usability and end user experience?
Or perhaps some people are perfectly content having to shoot their X server on a regular basis because they can't be asked to file a bug... That's real community spirit at play, right there.
On Tuesday 31 March 2009 13:23:05 Anders Rayner-Karlsson wrote:
And the BZ's for this observed behaviour are...?
Why don't you go search yourself?
Through past experience, I have never found an instance (since moving from XFree86 to Xorg) where the Xserver was wedged in a way that switching to a vc did not work, but C-A-Bs did. I have seen plenty of X lockups (Xorg intel driver issues in F10) in the last few months and not a single one of those were resolvable by C-A-Bs.
you have just different user experience
That is entirely possible. I did a straw poll among my technical colleagues (and included a Senior Director for good measure) and the only one that uses C-A-Bs (due to flaws in suspend/resume) is the Senior Director. No-one else could find a reason to retain C-A-Bs as enabled by default.
That flaw might not be easily fixed; and in the meantime, until it's fixed, what should he do?
Maybe - and here's the rub - disabling the ability to kill X willy-nilly would encourage people to file bugs against the applications that really misbehave, allowing for an overall improvement of stability, usability and end user experience?
Or perhaps some people are perfectly content having to shoot their X server on a regular basis because they can't be asked to file a bug... That's real community spirit at play, right there.
Developers hate bugs that go "suddenly my X server seemed to not be responding". It might be an X server fault, it might be an application issue, and in this day and age the odds of most people being able to narrow it down enough to make a readable bug report are pretty small. The main pain point here is that at the point the problem occurs, it's often very, very difficult to obtain any useful information.
Now, if you are volunteering to help ... ?
* Bill Crawford billcrawford1970@gmail.com [20090331 14:34]:
On Tuesday 31 March 2009 13:23:05 Anders Rayner-Karlsson wrote:
And the BZ's for this observed behaviour are...?
Why don't you go search yourself?
Because I am not the one experiencing or complaining about this behaviour. If you are seeing undesirable and broken behaviour by an application or by the X server itself, requiring you to resort to this type of behaviour as provided by C-A-Bs - filing bugs against the parts broken springs to mind as being on the agenda.
As such - you'd know what bugs you have filed, and you'd be able to provide the BZ id's.
I on the other hand, have not seen the behaviour, don't know which application you are running that causes the behaviour and therefore are not in a particularly good position to locate the BZ's.
I thought this was a fairly straight forward path of thought, but it seems I was incorrect.
That is entirely possible. I did a straw poll among my technical colleagues (and included a Senior Director for good measure) and the only one that uses C-A-Bs (due to flaws in suspend/resume) is the Senior Director. No-one else could find a reason to retain C-A-Bs as enabled by default.
That flaw might not be easily fixed; and in the meantime, until it's fixed, what should he do?
Re-enable it, or was that really non-trivial to think of? *confused*
Maybe - and here's the rub - disabling the ability to kill X willy-nilly would encourage people to file bugs against the applications that really misbehave, allowing for an overall improvement of stability, usability and end user experience?
Or perhaps some people are perfectly content having to shoot their X server on a regular basis because they can't be asked to file a bug... That's real community spirit at play, right there.
Developers hate bugs that go "suddenly my X server seemed to not be responding". It might be an X server fault, it might be an application issue, and in this day and age the odds of most people being able to narrow it down enough to make a readable bug report are pretty small. The main pain point here is that at the point the problem occurs, it's often very, very difficult to obtain any useful information.
Now, if you are volunteering to help ... ?
The term "reproducer" springs to mind. If you don't know exactly what it is that breaks, you can still describe how to get there. A bug report with a reproducer is better than no bug filed at all, and being able to run sosreport and putting together a bulleted list with, for example: * start application A * start application B * move Application A's window so it completely obscures application B's window -> X hangs solid
There's a very good chance that someone will be able to a) reproduce the issue, b) fix it.
If you're writing code, and it's your code that trips the issue, you can probably write a small-ish program that trigger the problem and attach to the BZ.
On Tuesday 31 March 2009 14:07:15 Anders Rayner-Karlsson wrote:
- Bill Crawford billcrawford1970@gmail.com [20090331 14:34]:
On Tuesday 31 March 2009 13:23:05 Anders Rayner-Karlsson wrote:
And the BZ's for this observed behaviour are...?
Why don't you go search yourself?
Because I am not the one experiencing or complaining about this behaviour. If you are seeing undesirable and broken behaviour by an application or by the X server itself, requiring you to resort to this type of behaviour as provided by C-A-Bs - filing bugs against the parts broken springs to mind as being on the agenda.
As such - you'd know what bugs you have filed, and you'd be able to provide the BZ id's.
I on the other hand, have not seen the behaviour, don't know which application you are running that causes the behaviour and therefore are not in a particularly good position to locate the BZ's.
I thought this was a fairly straight forward path of thought, but it seems I was incorrect.
Now, you are being deliberately rude.
That is entirely possible. I did a straw poll among my technical colleagues (and included a Senior Director for good measure) and the only one that uses C-A-Bs (due to flaws in suspend/resume) is the Senior Director. No-one else could find a reason to retain C-A-Bs as enabled by default.
That flaw might not be easily fixed; and in the meantime, until it's fixed, what should he do?
Re-enable it, or was that really non-trivial to think of? *confused*
**** off with the "really non-trivial to think of" crap please.
It's not easy to re-enable something *when you discover you need it* if it's been disabled, is it?
The term "reproducer" springs to mind. If you don't know exactly what it is that breaks, you can still describe how to get there. A bug report with a reproducer is better than no bug filed at all, and being able to run sosreport and putting together a bulleted list with, for example:
- start application A
- start application B
- move Application A's window so it completely obscures application B's window
-> X hangs solid
Yes, and it if't not trivially reproducable, they shouldn't be able to find any way out of it?
It's not always trivial to reproduce things.
Please don't assume that your 99% of people without problems automatically means it's the fault of the remaining 1% if it breaks.
There's a very good chance that someone will be able to a) reproduce the issue, b) fix it.
No, there is rarely a "good chance" unless it's an easy-to-trip case.
Someone was nice enough to point me to this thread and I wanted to pass along the favor to all those who may benefit from reading it as I think its message is applicable. . https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00861.html
-Adam
On Tuesday 31 March 2009 14:38:17 Adam Miller wrote:
Someone was nice enough to point me to this thread and I wanted to pass along the favor to all those who may benefit from reading it as I think its message is applicable. . https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00861.htm l
Perhaps a good response to the whole thread, but not really answering me ;O
Still that illustrates part of the "problem" that I and many others feel here. Yes, we may have OCD. We may be whining loudly. I just don't see why it's seen as "ok" to just railroad through it all, claim you're doing better, and insist that everyone accept that.
Adam Miller wrote:
Someone was nice enough to point me to this thread and I wanted to pass along the favor to all those who may benefit from reading it as I think its message is applicable. . https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00861.html
-Adam
IMHO it doesn't apply, in the sense that saying that changing is good doesn't mean necessarily that *this* change is good.
And now I stop trolling: didn't want to drag on this thread. It's rather obvious that this change will be done no matter what (i.e. no matter any relevant technical argumentation).
GN.
Anders Rayner-Karlsson wrote:
- Giancarlo Niccolai gc@falconpl.org [20090331 12:20]:
it may be educated enough to try it. But it is not like that an X session hang so bad that you have to ctrl-alt-bs it will allow you to CAF1-6 at all, or will let you to do anything meaningful with it (i.e. bash may not be able to get the resources to start). When you HAVE to CABs, it's because you CAN'T CAF1-6.
(There was my two cents, so don't expect me to join in this convo; I just wanted to correct your assumption that you may CAF1-6 away a situation in which you have to CABs, which is wrong, as another poster pointed out).
IIRC, and I believe that was pointed out in this thread as well, is that these keypresses are handled in the same way by the same part of the X server. If C-A-Bs works, so will C-A-F2 to drop you at a vc.
Dropping you to a VC and having a system stable enough to be able to do anything useful in that VC (including launching a shell) are two different matters.
Through past experience, I have never found an instance (since moving from XFree86 to Xorg) where the Xserver was wedged in a way that switching to a vc did not work, but C-A-Bs did. I have seen plenty of X lockups (Xorg intel driver issues in F10) in the last few months and not a single one of those were resolvable by C-A-Bs.
I had. As a programmer, I often try bleeding-edge software, and often contribute in making it more stable.
As I said, I am not against turning off a feature by default, even if vital for someone (i.e. for me that, as a programmer,... etc). I am against turning off a vital feature that the people that need it (and need it bad) will discover being turned off exactly when they need it the most. If not for anything else, if not for the "millions" (really) boxes one should spread around during install to explain policy changes, THIS is one for sure.
GN.
* Giancarlo Niccolai gc@falconpl.org [20090331 13:40]:
Dropping you to a VC and having a system stable enough to be able to do anything useful in that VC (including launching a shell) are two different matters.
I'd be seriously interested to find out what you do with your system as that does not match my Fedora experience at all. And I spend 10-12 hours in it *a day* and have done so for the last two and a half years, starting with FC6.
I had. As a programmer, I often try bleeding-edge software, and often contribute in making it more stable.
I don't run Rawhide, so perhaps there the difference lie. I do have updates-testing enabled and have not had reason to provide feedback for many weeks now (last feedback was on the libvirtd/selinux issue).
A proposal would be to have a small separate package in Rawhide (that never enters a real release) that add the C-A-Bs back in. If you're cutting edge or developer, ability to zap X could be useful. (And you know how to enable the feature as well, in a full release.)
As I said, I am not against turning off a feature by default, even if vital for someone (i.e. for me that, as a programmer,... etc). I am against turning off a vital feature that the people that need it (and need it bad) will discover being turned off exactly when they need it the most. If not for anything else, if not for the "millions" (really) boxes one should spread around during install to explain policy changes, THIS is one for sure.
Reading the Release Notes to discover changes like this is not unreasonable to expect of technical people. A short link to the Fedora Wiki with the type of information that has been provided in this thread explaining how to re-enable "I want to kill X on demand, no questions asked" should be more than adequate.
I see distinct parallels between A-SysRq-<whatever> and C-A-Bs from a system perspective. Both are essentially debug functionality and should be enabled by those that need it, rather than forcing people to disable it that does not need it.
Anders Rayner-Karlsson wrote:
- Giancarlo Niccolai gc@falconpl.org [20090331 12:20]:
it may be educated enough to try it. But it is not like that an X session hang so bad that you have to ctrl-alt-bs it will allow you to CAF1-6 at all, or will let you to do anything meaningful with it (i.e. bash may not be able to get the resources to start). When you HAVE to CABs, it's because you CAN'T CAF1-6.
(There was my two cents, so don't expect me to join in this convo; I just wanted to correct your assumption that you may CAF1-6 away a situation in which you have to CABs, which is wrong, as another poster pointed out).
IIRC, and I believe that was pointed out in this thread as well, is that these keypresses are handled in the same way by the same part of the X server. If C-A-Bs works, so will C-A-F2 to drop you at a vc.
Not quite. It does so often, but not always, because when C-A-Fn is pressed, some memory ( ... file descriptors, inodes etc.) needs to be allocated and be swapped around to launch a console.
In case of heavy "memory-hog races", this can easily fail or it may take a long time.
Through past experience, I have never found an instance (since moving from XFree86 to Xorg) where the Xserver was wedged in a way that switching to a vc did not work, but C-A-Bs did.
I've been in such situations many times ;)
I have seen plenty of X lockups (Xorg intel driver issues in F10) in the last few months and not a single one of those were resolvable by C-A-Bs.
Try a classical multi-user workstation-pools setup with "C-A-F<N>" disabled - Then, there is no C-A-Fn to press, while a C-A-BS would simply kill the user's logging and bring him back to his login.
Another case where this does't work is when switching from "x-terminal" to console leaves the console in some unusable state (e.g. when pressing C-A-Fn come up with a "black screen" or with a "fly-dirt screen" because of some bugs some where).
Ralf
On 2009/03/31 12:56 (GMT+0200) Anders Rayner-Karlsson composed:
Through past experience, I have never found an instance (since moving from XFree86 to Xorg) where the Xserver was wedged in a way that switching to a vc did not work, but C-A-Bs did.
Lucky you. Others have done Ctrl-Alt-F[1-6] only to find a blank screen, unresponsive keyboard, or horked charset making the VCs useless for recovering X.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Anders Rayner-Karlsson wrote:
- Giancarlo Niccolai gc@falconpl.org [20090331 12:20]:
it may be educated enough to try it. But it is not like that an X session hang so bad that you have to ctrl-alt-bs it will allow you to CAF1-6 at all, or will let you to do anything meaningful with it (i.e. bash may not be able to get the resources to start). When you
HAVE to
CABs, it's because you CAN'T CAF1-6.
(There was my two cents, so don't expect me to join in this convo; I just wanted to correct your assumption that you may CAF1-6 away
a
situation in which you have to CABs, which is wrong, as another
poster
pointed out).
IIRC, and I believe that was pointed out in this thread as well, is that these keypresses are handled in the same way by the same
part of
the X server. If C-A-Bs works, so will C-A-F2 to drop you at a vc.
Through past experience, I have never found an instance (since
moving
from XFree86 to Xorg) where the Xserver was wedged in a way that switching to a vc did not work, but C-A-Bs did. I have seen plenty of X lockups (Xorg intel driver issues in F10) in the last few months and not a single one of those were resolvable by C-A-Bs.
As I posted elsewhere in the thread, there is a bug where all available fds are taken. If the vt doesn't already have bash open, no dice. If it's not already running something you can kill with, no dice. (I can type into the terminals I have open all i want, nothing actually gets done because nothing can be open()ed. C-A-Bs is the only way I know of to fix it. There is a bug open for it (486695).
- --Ben
Cheers,
Giancarlo Niccolai wrote:
Good computing => "least surprise effect". People coming from windows => ctrl+alt+<fumble>bs "OH CRAP --- I am so XXXX I forgot to save my work files in 15 Word (ops, Openoffice) windows in the past 3 days!!!!"
And where is the problem? These people have just been through an elementary lesson on difference of OSes in a violent way.
Or to put it conversely: Who do these windoze newbies think they are to throw away a well-known and valuable feature has been around for 15 years or more?
Ralf
Ralf Corsepius wrote:
Giancarlo Niccolai wrote:
Good computing => "least surprise effect". People coming from windows => ctrl+alt+<fumble>bs "OH CRAP --- I am so XXXX I forgot to save my work files in 15 Word (ops, Openoffice) windows in the past 3 days!!!!"
And where is the problem? These people have just been through an elementary lesson on difference of OSes in a violent way.
Or to put it conversely: Who do these windoze newbies think they are to throw away a well-known and valuable feature has been around for 15 years or more?
Ralf
I don't know if you noticed it, but that was exactly my point. We can't prevent anyone from doing dumb things; there will always be a smarter way to do dumb things just the same. It seemed to me that the above "people coming from windows" surprise situation is a bit ridiculous, and I hoped someone else felt the same way (as you do). By extension, preventing that surprise by denying a nearly vital feature, unless you find out the hard way that it has been removed is and are probably not in the position to re-enable it,... is just at the same level of the surprise it wanted to spare.
Just, I thought we were all linuxsters enough to get the puny of that right away.
GN.
On Tue, 2009-03-31 at 09:53 +0200, Giancarlo Niccolai wrote:
Good computing => "least surprise effect". People coming from windows => ctrl+alt+<fumble>bs "OH CRAP --- I am so XXXX I forgot to save my work files in 15 Word (ops, Openoffice) windows in the past 3 days!!!!"
Openoffice has autosave/crash recovery, so this would not happen.
People knowing their systems and just upgrading => x blocked => ctrl+alt+bs ... ctrl+alt+bs... "what the..." ... CTRL+ALT+BS. "OH SHIT -- I got to hard reboot loosing all the work on console sessions and possibly fucking up that crap of XXXX filesystem the installer forced me to use!!!!"
Ctrl-alt-bs doesn't reboot the kernel so your filesystem loss scenario is at odds with reality.
Callum Lerwick wrote:
On Tue, 2009-03-31 at 09:53 +0200, Giancarlo Niccolai wrote:
Good computing => "least surprise effect". People coming from windows => ctrl+alt+<fumble>bs "OH CRAP --- I am so XXXX I forgot to save my work files in 15 Word (ops, Openoffice) windows in the past 3 days!!!!"
Openoffice has autosave/crash recovery, so this would not happen.
...which mitigates the alleged "harm" of c-a-bs, weakening the argument against it.
People knowing their systems and just upgrading => x blocked => ctrl+alt+bs ... ctrl+alt+bs... "what the..." ... CTRL+ALT+BS. "OH SHIT -- I got to hard reboot loosing all the work on console sessions and possibly fucking up that crap of XXXX filesystem the installer forced me to use!!!!"
Ctrl-alt-bs doesn't reboot the kernel so your filesystem loss scenario is at odds with reality.
...which means that the alternative (which *is* to hard-kill the entire system) is far more destructive than c-a-bs; thus, a reason for it to stay.
I'm confused; both of you seem to feel that c-a-bs is better than no c-a-bs?
Rodd Clarkson wrote:
I'm figuring that something should be attempted so that we don't have to go through this conversation a third time when f11 is released. ;-]
I think that's just futile. The only way NOT to have those threads spring up like mushrooms is to reenable that feature by default.
Kevin Kofler
On Mon, Mar 30, 2009 at 3:24 PM, Kevin Kofler kevin.kofler@chello.at wrote:
Rodd Clarkson wrote:
I'm figuring that something should be attempted so that we don't have to go through this conversation a third time when f11 is released. ;-]
I think that's just futile. The only way NOT to have those threads spring up like mushrooms is to reenable that feature by default.
And that will be only worse when RHEL/Centos adopt this later on.
On Mon, Mar 30, 2009 at 4:24 PM, Kevin Kofler kevin.kofler@chello.at wrote:
Rodd Clarkson wrote:
I'm figuring that something should be attempted so that we don't have to go through this conversation a third time when f11 is released. ;-]
I think that's just futile. The only way NOT to have those threads spring up like mushrooms is to reenable that feature by default.
No, the right solution is to examine the cases for why people were using the key before, and come up with a design which addresses them. This may involve writing *new code*, as opposed to e.g. just turning on whatever code happens to exist now elsewhere (referring to the kernel sysrq key).
While I think it's crazy to have a magic key combination which instantly logs you out without any confirmation, it'd be very useful to have some kind of "oh crap" key to recover from things like a wedged fullscreen application, stuck X server grab, etc.
Colin Walters wrote:
No, the right solution is to examine the cases for why people were using the key before, and come up with a design which addresses them.
This will not help at all, because people expect to be able to use the current key combo, not something new they never heard of.
Kevin Kofler
Sticking with old decrepit ways of doing things that aren't of good design purely because it is tradition or "everyone knows about it" is no reason to stick with it. Otherwise we are no better than Microsoft. If this is something that needed to be changed and the X.org upstream developers decided that they had a solid reason to do so, then I support them. Anyone who has posted a case about it being and issue to systems administrators or emacs users have yet to provide the list with a situation that doesn't have an alternative or a solution.
-Adam
On Mon, Mar 30, 2009 at 3:42 PM, Kevin Kofler kevin.kofler@chello.at wrote:
Colin Walters wrote:
No, the right solution is to examine the cases for why people were using the key before, and come up with a design which addresses them.
This will not help at all, because people expect to be able to use the current key combo, not something new they never heard of.
On Mon, Mar 30, 2009 at 3:47 PM, Adam Miller maxamillion@gmail.com wrote:
Sticking with old decrepit ways of doing things that aren't of good design
No one has describe how having this is bad design. I asked, all I have heard is because someone may accidentally press three keys concurrently.
purely because it is tradition or "everyone knows about it" is no reason to stick with it.
it happens to be pretty useful.
Otherwise we are no better than Microsoft. If this is something that needed to be changed and the X.org upstream developers decided that they had a solid reason to do so
There is no (yet available) evidence of this.
, then I support them. Anyone who has posted a case about it being and issue to systems administrators or emacs users have yet to provide the list with a situation that doesn't have an alternative or a solution.
Change the emacs shortcut.
On Mon, Mar 30, 2009 at 5:01 PM, Emmanuel Seyman emmanuel.seyman@club-internet.fr wrote:
- Arthur Pemberton [30/03/2009 23:51] :
No one has describe how having this is bad design. I asked, all I have heard is because someone may accidentally press three keys concurrently.
That's pretty much the definition of bad design.
Emmanuel
I've accidentally erased the contents of a document then hit Ctrl+S. Is that a bad design? And that's ignoring how unlikely a mistake Ctrl+Alt+backspace is.
* Arthur Pemberton [31/03/2009 00:22] :
I've accidentally erased the contents of a document then hit Ctrl+S. Is that a bad design?
Given that you can undo the erasing then press Ctrl-S again, I'ld say no.
And that's ignoring how unlikely a mistake Ctrl+Alt+backspace is.
I can see someone wanting to hit Ctrl-Alt-$Key then Backspace and hitting Ctrl-Alt-$Key followed by Ctrl-Alt-Backspace instead.
Emmanuel
On Mon, Mar 30, 2009 at 5:28 PM, Emmanuel Seyman emmanuel.seyman@club-internet.fr wrote:
- Arthur Pemberton [31/03/2009 00:22] :
I can see someone wanting to hit Ctrl-Alt-$Key then Backspace and hitting Ctrl-Alt-$Key followed by Ctrl-Alt-Backspace instead.
This is almost entirely in the real of fiction now. I give up. Do whatever whoever decides need to be done with or without any actual open discussion with the stake holders.
On Mon, 2009-03-30 at 17:31 -0500, Arthur Pemberton wrote:
On Mon, Mar 30, 2009 at 5:28 PM, Emmanuel Seyman emmanuel.seyman@club-internet.fr wrote:
- Arthur Pemberton [31/03/2009 00:22] :
I can see someone wanting to hit Ctrl-Alt-$Key then Backspace and hitting Ctrl-Alt-$Key followed by Ctrl-Alt-Backspace instead.
This is almost entirely in the real of fiction now. I give up. Do whatever whoever decides need to be done with or without any actual open discussion with the stake holders.
At least two people have admitting to doing exactly this.
You don't understand the word fiction do you?
Dave.
-- Fedora 9 : sulphur is good for the skin ( www.pembo13.com )
On Tue, Mar 31, 2009 at 10:25:47AM +1000, Dave Airlie wrote:
On Mon, 2009-03-30 at 17:31 -0500, Arthur Pemberton wrote:
On Mon, Mar 30, 2009 at 5:28 PM, Emmanuel Seyman emmanuel.seyman@club-internet.fr wrote:
- Arthur Pemberton [31/03/2009 00:22] :
I can see someone wanting to hit Ctrl-Alt-$Key then Backspace and hitting Ctrl-Alt-$Key followed by Ctrl-Alt-Backspace instead.
This is almost entirely in the real of fiction now. I give up. Do whatever whoever decides need to be done with or without any actual open discussion with the stake holders.
At least two people have admitting to doing exactly this.
You don't understand the word fiction do you?
Way more than two people admit to using C-A-BS. Couldn't the two somewhat fumble-fingered people just enable dontzap for themselves?
OG.
On Tue, Mar 31, 2009 at 5:31 PM, Emmanuel Seyman emmanuel.seyman@club-internet.fr wrote:
- Arthur Pemberton [30/03/2009 23:51] :
No one has describe how having this is bad design. I asked, all I have heard is because someone may accidentally press three keys concurrently.
That's pretty much the definition of bad design.
yes, It is bad design, If you have a very common key combination that a lot of people knows, (I am talking about Ctrl+Alt+Del to open the login prompt on Windows), and another one Ctrl+Alt+Backspace where Backspace and Del are very near each other on many keyboards. This case is extreme on my laptop (thinkpad) Del is just over Backspace, and I have seen a few people, try the Ctrl+Alt+Del sequence on screensaver locked sessions
On Monday 30 March 2009 23:35:14 Robert Marcano wrote:
On Tue, Mar 31, 2009 at 5:31 PM, Emmanuel Seyman
emmanuel.seyman@club-internet.fr wrote:
- Arthur Pemberton [30/03/2009 23:51] :
No one has describe how having this is bad design. I asked, all I have heard is because someone may accidentally press three keys concurrently.
That's pretty much the definition of bad design.
yes, It is bad design, If you have a very common key combination that a lot of people knows, (I am talking about Ctrl+Alt+Del to open the login prompt on Windows), and another one Ctrl+Alt+Backspace where Backspace and Del are very near each other on many keyboards. This case is extreme on my laptop (thinkpad) Del is just over Backspace, and I have seen a few people, try the Ctrl+Alt+Del sequence on screensaver locked sessions
So, to come back to an argument oft-repeated in this context ... how hard would it be for users who need this change to just put something in xorg.conf or remap the "zap" key combination?
Robert Marcano wrote:
yes, It is bad design, If you have a very common key combination that a lot of people knows, (I am talking about Ctrl+Alt+Del to open the login prompt on Windows)
This is not Window$.
Ctrl+Alt+Del shouldn't be expected to do anything other than reboot on GNU/Linux. (And FWIW, I think the Ctrl+Alt+Del reboot should also be enabled in X11.)
Kevin Kofler
On Tuesday 31 March 2009 16:28:28 Kevin Kofler wrote: ...
Ctrl+Alt+Del shouldn't be expected to do anything other than reboot on GNU/Linux. (And FWIW, I think the Ctrl+Alt+Del reboot should also be enabled in X11.)
I dunno, I quite like using that as the logout shortcut (without prompting).
On Tue, 2009-03-31 at 17:28 +0200, Kevin Kofler wrote:
Robert Marcano wrote:
yes, It is bad design, If you have a very common key combination that a lot of people knows, (I am talking about Ctrl+Alt+Del to open the login prompt on Windows)
This is not Window$.
Ctrl+Alt+Del shouldn't be expected to do anything other than reboot on GNU/Linux. (And FWIW, I think the Ctrl+Alt+Del reboot should also be enabled in X11.)
What about on a sparc system, or an ARM board or legacy 68k machine? What about systems that don't even have those keys?
I'm not really sure I understand why a key combination that happens to be meaningful to the firmware of the IBM PC should get special status as "just reboot" in projects that are designed to run on a much wider range of systems.
Regards, Bryn.
On Wed, Apr 1, 2009 at 10:58 AM, Kevin Kofler kevin.kofler@chello.at wrote:
Robert Marcano wrote:
yes, It is bad design, If you have a very common key combination that a lot of people knows, (I am talking about Ctrl+Alt+Del to open the login prompt on Windows)
This is not Window$.
Ctrl+Alt+Del shouldn't be expected to do anything other than reboot on GNU/Linux. (And FWIW, I think the Ctrl+Alt+Del reboot should also be enabled in X11.)
Kevin Kofler
I was not saying to make Ctrl+Alt+Del works like Windows, I am saying Del is very near to Backspace, and when someone see a screensaver locked up X session, one of the first thing they try is control + alt + del to login, and a simple finger mistake and your session goes down.
Robert Marcano wrote:
I was not saying to make Ctrl+Alt+Del works like Windows, I am saying Del is very near to Backspace, and when someone see a screensaver locked up X session, one of the first thing they try is control + alt
- del to login, and a simple finger mistake and your session goes
down.
Then they're already screwing up because this is not Window$, so they shouldn't press Ctrl+Alt+Del in the first place.
This is actually an argument for mapping Ctrl+Alt+Del to reboot even in X11, it'd make them lose that habit pretty quickly. :-p
Kevin Kofler
On Tuesday 31 March 2009 17:39:01 Robert Marcano wrote:
I was not saying to make Ctrl+Alt+Del works like Windows, I am saying Del is very near to Backspace, and when someone see a screensaver locked up X session, one of the first thing they try is control + alt
- del to login, and a simple finger mistake and your session goes
down.
This is one of the few sane arguments in the whole debate. If there is a genuine problem with this (and someone commented a day or two ago about problems due to a laptop keyboard with the backspace very near something else) then we actually have a good reason to opt for a different - or more obviously configurable - way to kill the session; logging out is generally already configurarable by the desktop environment.
On Wed, Apr 01, 2009 at 12:09:01PM +1930, Robert Marcano wrote:
I was not saying to make Ctrl+Alt+Del works like Windows, I am saying Del is very near to Backspace, and when someone see a screensaver locked up X session, one of the first thing they try is control + alt
- del to login, and a simple finger mistake and your session goes
down.
BS is close to del only on laptop keyboards. Your scenario definitively doesn't work as well on laptops.
OG.
On Wed, Apr 1, 2009 at 4:54 PM, Olivier Galibert galibert@pobox.com wrote:
On Wed, Apr 01, 2009 at 12:09:01PM +1930, Robert Marcano wrote:
I was not saying to make Ctrl+Alt+Del works like Windows, I am saying Del is very near to Backspace, and when someone see a screensaver locked up X session, one of the first thing they try is control + alt
- del to login, and a simple finger mistake and your session goes
down.
BS is close to del only on laptop keyboards. Your scenario definitively doesn't work as well on laptops.
So my IBM Latinamerican keyboard is a laptop keyboard, I did not knew that.
1cm is enough to make a mistake
OG.
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Thu, Apr 2, 2009 at 5:34 AM, Bill Crawford billcrawford1970@gmail.com wrote:
On Tuesday 31 March 2009 22:52:35 Robert Marcano wrote:
1cm is enough to make a mistake
Yup. Just last year I accidentally type "crontab -r" instead of "-e" ...
Perhaps all destructive commands should be removed ;o)
It is amazing how people is able to say anything to win an argument (I count myself too :-P), when you typed the letter "r" did it executed immediately without giving you time to read and press enter?, I am pretty sure the answer is no. Control+alt+bs does not gives anyone time to fix the mistake, maybe if the X servers were able to check if you pressed that key combination for 4 seconds (like the power buttons case already mentioned) I could be against the zap option deactivation, but that is not the case
On Wednesday 01 April 2009 14:10:55 Robert Marcano wrote:
On Thu, Apr 2, 2009 at 5:34 AM, Bill Crawford
billcrawford1970@gmail.com wrote:
On Tuesday 31 March 2009 22:52:35 Robert Marcano wrote:
1cm is enough to make a mistake
Yup. Just last year I accidentally type "crontab -r" instead of "-e" ...
Perhaps all destructive commands should be removed ;o)
It is amazing how people is able to say anything to win an argument (I count myself too :-P)
I did have my tongue firmly in my cheek there :)
, when you typed the letter "r" did it executed immediately without giving you time to read and press enter?, I am pretty sure the answer is no. Control+alt+bs does not gives anyone time to fix the mistake, maybe if the X servers were able to check if you pressed that key combination for 4 seconds (like the power buttons case already mentioned) I could be against the zap option deactivation, but that is not the case
I'd be happy with a (small!) delay. I just can't understand the mentality that there shouldn't be an off switch in case someone presses it ;o)
Don't think that a typo is the same as a key combination... but I see where you're coming from. I still stand behind upstream's decision because its really their decision to make.
-Adam
On Wed, Apr 1, 2009 at 5:04 AM, Bill Crawford billcrawford1970@gmail.com wrote:
On Tuesday 31 March 2009 22:52:35 Robert Marcano wrote:
1cm is enough to make a mistake
Yup. Just last year I accidentally type "crontab -r" instead of "-e" ...
Perhaps all destructive commands should be removed ;o)
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Once upon a time, Emmanuel Seyman emmanuel.seyman@club-internet.fr said:
- Arthur Pemberton [30/03/2009 23:51] :
No one has describe how having this is bad design. I asked, all I have heard is because someone may accidentally press three keys concurrently.
That's pretty much the definition of bad design.
I've typed in a text box in Firefox and hit Ctrl+W ("erase word" for years on Unix systems, including older Firefox, but now "close window") and lost information. It is a lot easier to hit Ctrl+W than Ctrl+Alt+Backspace. Firefox only prompts on Ctrl+W if you have multiple tabs.
On Mon, Mar 30, 2009 at 05:40:59PM -0500, Chris Adams wrote:
Once upon a time, Emmanuel Seyman emmanuel.seyman@club-internet.fr said:
- Arthur Pemberton [30/03/2009 23:51] :
No one has describe how having this is bad design. I asked, all I have heard is because someone may accidentally press three keys concurrently.
That's pretty much the definition of bad design.
I've typed in a text box in Firefox and hit Ctrl+W ("erase word" for years on Unix systems, including older Firefox, but now "close window") and lost information.
With a recent Firefox, you haven't lost information. The tab is there in the "recently closed tabs" history menu with the text you've entered kept.
OG who lost a bunch of wiki input before that recently closed tabs option
Emmanuel Seyman wrote:
- Arthur Pemberton [30/03/2009 23:51] :
No one has describe how having this is bad design. I asked, all I have heard is because someone may accidentally press three keys concurrently.
That's pretty much the definition of bad design.
Emmanuel
no that's pretty much the definition of a dumb user, or someone who's touch typing isn't up to par, or even worse someone who's not watching what he's doing!
Adam Miller wrote:
Sticking with old decrepit ways of doing things that aren't of good design purely because it is tradition or "everyone knows about it" is no reason to stick with it.
I disagree there. Users grow habits. Breaking them is bad usability for your existing users. This is also why usability studies using only new users are flawed, they're looking for the perfect design given no preconceptions, but intentionally ignoring the habit factor.
Kevin Kofler (who uses the classic menu rather than Kickoff in KDE 4, whose widget style is still Bluecurve and who'll undoubtedly also disable DontZap, i.e. enable zapping, in F11)
On Monday 30 March 2009 21:47:23 Adam Miller wrote:
Sticking with old decrepit ways of doing things that aren't of good design purely because it is tradition or "everyone knows about it" is no reason to stick with it. Otherwise we are no better than Microsoft.
... and deliberately changing to something that's "better for the Windows users" is better?
Sorry, but suddenly disabling functionality we're used to having in the name of "it's simpler, people can't hurt themselves" is also just like Microsoft.
Your point was?
If this is something that needed to be changed and the X.org upstream developers decided that they had a solid reason to do so, then I support them. Anyone who has posted a case about it being and issue to systems administrators or emacs users have yet to provide the list with a situation that doesn't have an alternative or a solution.
... because they must be right?
On Mon, Mar 30, 2009 at 4:42 PM, Kevin Kofler kevin.kofler@chello.at wrote:
Colin Walters wrote:
No, the right solution is to examine the cases for why people were using the key before, and come up with a design which addresses them.
This will not help at all, because people expect to be able to use the current key combo, not something new they never heard of.
Nothing says that a new "oh crap" key system couldn't be Ctrl-Alt-Backspace as well; what key it is exactly I see as distinct from what the key provides. Though as for which specific key, unifying it with Ctrl-Alt-Delete would make sense to me, but I appreciate the backwards compatibilty/habit argument.
On Monday 30 March 2009 21:57:10 Colin Walters wrote:
On Mon, Mar 30, 2009 at 4:42 PM, Kevin Kofler kevin.kofler@chello.at wrote:
Colin Walters wrote:
No, the right solution is to examine the cases for why people were using the key before, and come up with a design which addresses them.
This will not help at all, because people expect to be able to use the current key combo, not something new they never heard of.
Nothing says that a new "oh crap" key system couldn't be Ctrl-Alt-Backspace as well; what key it is exactly I see as distinct from what the key provides. Though as for which specific key, unifying it with Ctrl-Alt-Delete would make sense to me, but I appreciate the backwards compatibilty/habit argument.
Yes, this is the point :o) it might have been better to announce "we're changing the default key combination" and include instructions on how to change it back if needed.
I don't like the argument that users need protecting from this. If you push the power switch on anything in your kitchen it's generally going to go on or off immediately; the reason we do it different on a PC *is* mainly to do with data loss but also to allow its dual use as a "suspend or hibernate" key. It's the same with a "kill my X server" button: sure, maybe insist it be pressed more than once, or change where the button is, ... but saying we can't have one because it's sharp is ... well, maybe the X.org developers shouldn't be allowed sharp objects. Jus' sayin' ;o)
On Mon, 2009-03-30 at 22:42 +0200, Kevin Kofler wrote:
Colin Walters wrote:
No, the right solution is to examine the cases for why people were using the key before, and come up with a design which addresses them.
This will not help at all, because people expect to be able to use the current key combo, not something new they never heard of.
So let's list the cases that zap would actually recover from:
1: stuck grabs 2: focus reverts to None and your window manager is dead 3: X driver that's decided to stop rendering (or stop rendering correctly)
In case 3, you need to blow away the session and there's no getting around it. So VT switch and killall gnome-session will do just fine. For case 2, I seem to recall this being an unpleasant requirement of the X protocol somewhere along the line; but I'm looking into it.
For case 1, you might be able to recover if you could just figure out which client was being obstreperous. So clearly the right thing is to dump active grab state to the X log on VT switch. If there's anything there, then you know who to blame and you can pkill just that and recover. If there's not, then the session is doomed.
Something like this perhaps:
http://ajax.fedorapeople.org/patches/xserver-grab-debugging.patch
I mean, I know it's bad form to post code to a development list, but I hope I can be forgiven this time.
- ajax
2009/3/31 Adam Jackson ajax@redhat.com:
On Mon, 2009-03-30 at 22:42 +0200, Kevin Kofler wrote:
Colin Walters wrote:
No, the right solution is to examine the cases for why people were using the key before, and come up with a design which addresses them.
This will not help at all, because people expect to be able to use the current key combo, not something new they never heard of.
So let's list the cases that zap would actually recover from:
1: stuck grabs 2: focus reverts to None and your window manager is dead 3: X driver that's decided to stop rendering (or stop rendering correctly)
Let me add:
4: Randr configuration is either broken or out of date, and the system didn't detect it correctly
More than a few times now I've forgotten I had set up an external monitor, suspended, and unsuspended later and faced with a black screen thought my machine had locked. Of course this is a system bug, but then all of these things are.
For case 1, you might be able to recover if you could just figure out which client was being obstreperous. So clearly the right thing is to dump active grab state to the X log on VT switch. If there's anything there, then you know who to blame and you can pkill just that and recover. If there's not, then the session is doomed.
That's useful. A lot of the time I have a good idea of what app has a stuck grab, but this is a bit easier. Ideally there would be a way to forcibly ungrab but I suppose that may confuse application toolkits.
Anyways one could obviously spend almost arbitrary amounts of time writing recovery code, but I just wanted the discussion to at least consider writing *some* new code and looking at the cases, rather than having "enable or don't enable DontZap" be the only options.
On Tue, 2009-03-31 at 10:51 -0400, Colin Walters wrote:
2009/3/31 Adam Jackson ajax@redhat.com:
So let's list the cases that zap would actually recover from:
1: stuck grabs 2: focus reverts to None and your window manager is dead 3: X driver that's decided to stop rendering (or stop rendering correctly)
Let me add:
4: Randr configuration is either broken or out of date, and the system didn't detect it correctly
More than a few times now I've forgotten I had set up an external monitor, suspended, and unsuspended later and faced with a black screen thought my machine had locked. Of course this is a system bug, but then all of these things are.
Yeah, this is hard.
Part of the problem here is that the X server doesn't really have a good way of knowing when a suspend happens. For UMS drivers, we vt-switch and hope that works, but that means you can't distinguish normal vt switch from suspend. Maybe you always want to do an output rescan at vt enter? Maybe not. Maybe just rescan and send config change events to the desktop, but not actively change the topology.
For KMS drivers, we suspend in place now, which is pretty awesome since it eliminates flicker on the way down and on the way back up. So the kernel driver ought to be smart enough to send configuration changes back through a uevent. I don't think we're doing anything with those events yet though.
For case 1, you might be able to recover if you could just figure out which client was being obstreperous. So clearly the right thing is to dump active grab state to the X log on VT switch. If there's anything there, then you know who to blame and you can pkill just that and recover. If there's not, then the session is doomed.
That's useful. A lot of the time I have a good idea of what app has a stuck grab, but this is a bit easier. Ideally there would be a way to forcibly ungrab but I suppose that may confuse application toolkits.
We had an optional bit of config file magic at one point that would let you turn on a magic key combo to break the current grab. Plus a matching request in the XFree86-Misc extension to turn it back off, since otherwise you can defeat screen locking. Gone in 1.6 though, that extension was pretty much a mistake. [1]
The problem with the notion of breaking grabs is that it's an arms race. X is just broken here. The only way to fix it is to break out to a wayland mini-app that does the moral equivalent of MacOS's Force Quit. (And in some sense, by the time you're running a whole new display system to fix your old one, it's time to just move on.)
Since we can't _actually_ fix grabs, the right thing to do is punish apps that abuse them. Server zap doesn't do this. It punishes the whole session. Even just breaking the grab doesn't get things fixed, because the bug stays there in the app forever. You want the recovery path to be such that you can inspect the state of the broken app at the moment it's misbehaving. Grab state dump on VT switch accomplishes this better than either zap or grab-break.
[1] - Not so much that the things it embodied were bad ideas - though they all were to some extent - but that the implementation showed a willful disregard for the rest of the server. GrabBreak could easily have been a new, possibly even privileged, XKB action, but instead it was a magic trapdoor. Why do anything in the existing design when you can add another layer of crap on top.
- ajax
On Tuesday 31 March 2009 16:48:13 Adam Jackson wrote:
On Tue, 2009-03-31 at 10:51 -0400, Colin Walters wrote:
...
That's useful. A lot of the time I have a good idea of what app has a stuck grab, but this is a bit easier. Ideally there would be a way to forcibly ungrab but I suppose that may confuse application toolkits.
We had an optional bit of config file magic at one point that would let you turn on a magic key combo to break the current grab. Plus a matching request in the XFree86-Misc extension to turn it back off, since otherwise you can defeat screen locking. Gone in 1.6 though, that extension was pretty much a mistake. [1]
This was actually very, very useful (I get to use it on a fair number of occasions, and when the alternatives are (1) wait ten minutes for the app to catch up or (2) kill it and lose whatever was in it, I go with (3) break the grab and do something else for a bit.
The problem with the notion of breaking grabs is that it's an arms race. X is just broken here. The only way to fix it is to break out to a wayland mini-app that does the moral equivalent of MacOS's Force Quit. (And in some sense, by the time you're running a whole new display system to fix your old one, it's time to just move on.)
You lose the option to wait for the app to catch up, without it preventing you from doing anything else, which is the current behaviour if you *don't* break the grab.
We don't always want to quit the app, in other words.
Since we can't _actually_ fix grabs, the right thing to do is punish apps that abuse them. Server zap doesn't do this. It punishes the whole session. Even just breaking the grab doesn't get things fixed, because the bug stays there in the app forever. You want the recovery path to be such that you can inspect the state of the broken app at the moment it's misbehaving. Grab state dump on VT switch accomplishes this better than either zap or grab-break.
But you're actually punishing the *user* here. That is what upsets me, I can't speak for anyone else.
I may know very well what the problem is, and that it's fixed by a newer version of or replacement for my browser. I may be unable to upgrade to a version of the OS that comes with that new version because I have multiple GPUs ... ;o)
[1] - Not so much that the things it embodied were bad ideas - though they all were to some extent - but that the implementation showed a willful disregard for the rest of the server. GrabBreak could easily have been a new, possibly even privileged, XKB action, but instead it was a magic trapdoor. Why do anything in the existing design when you can add another layer of crap on top.
- ajax
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Adam Jackson wrote:
On Tue, 2009-03-31 at 10:51 -0400, Colin Walters wrote:
2009/3/31 Adam Jackson ajax@redhat.com:
So let's list the cases that zap would actually recover from:
1: stuck grabs 2: focus reverts to None and your window manager is dead 3: X driver that's decided to stop rendering (or stop rendering correctly)
Let me add:
4: Randr configuration is either broken or out of date, and the system didn't detect it correctly
More than a few times now I've forgotten I had set up an external monitor, suspended, and unsuspended later and faced with a black screen thought my machine had locked. Of course this is a system bug, but then all of these things are.
Yeah, this is hard.
Part of the problem here is that the X server doesn't really have a good way of knowing when a suspend happens. For UMS drivers, we vt-switch and hope that works, but that means you can't distinguish normal vt switch from suspend. Maybe you always want to do an output rescan at vt enter? Maybe not. Maybe just rescan and send config change events to the desktop, but not actively change the topology.
For KMS drivers, we suspend in place now, which is pretty awesome since it eliminates flicker on the way down and on the way back up. So the kernel driver ought to be smart enough to send configuration changes back through a uevent. I don't think we're doing anything with those events yet though.
If X simply knew it was in an inconsistent state, could it initiate recovery from there? It'd be nice if we could have a simple /usr/bin/xreconfig so we could add this to the "easy fix from vt" cases.
- --CJD
On Thu, 2009-04-02 at 01:16 -0400, Casey Dahlin wrote:
If X simply knew it was in an inconsistent state, could it initiate recovery from there? It'd be nice if we could have a simple /usr/bin/xreconfig so we could add this to the "easy fix from vt" cases.
Ngggh.
xrandr --auto would get you most of the way there, except, if you're vt-switched away from X, then it can't actually do the hardware probe again, because it doesn't own the hardware. You could do something like (chvt 7; sleep 5; xrandr --auto) &, along with all the requisite DISPLAY= and XAUTHORITY= and maybe that would help?
- ajax
Adam Jackson wrote:
On Thu, 2009-04-02 at 01:16 -0400, Casey Dahlin wrote:
If X simply knew it was in an inconsistent state, could it initiate recovery from there? It'd be nice if we could have a simple /usr/bin/xreconfig so we could add this to the "easy fix from vt" cases.
Ngggh.
xrandr --auto would get you most of the way there, except, if you're vt-switched away from X, then it can't actually do the hardware probe again, because it doesn't own the hardware. You could do something like (chvt 7; sleep 5; xrandr --auto) &, along with all the requisite DISPLAY= and XAUTHORITY= and maybe that would help?
- ajax
You could probably replace the chvt 7; sleep 5 with something that would simply wait for X's vt to become active again (new code). Then there'd be the matter of getting the environment.
My first thought was to simply have a command that would set a flag inside of X, and then have x respond as if the user had done xrandr --auto the next time the vt became active.
Its definitely not /pretty/ to do any way I can think of, and I'm not sure the benefit outweighs the ugly when I step back and look at it.
--CJD
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Adam Jackson wrote:
On Mon, 2009-03-30 at 22:42 +0200, Kevin Kofler wrote:
Colin Walters wrote:
No, the right solution is to examine the cases for why people
were
using the key before, and come up with a design which
addresses them.
This will not help at all, because people expect to be able to use
the
current key combo, not something new they never heard of.
So let's list the cases that zap would actually recover from:
1: stuck grabs 2: focus reverts to None and your window manager is dead 3: X driver that's decided to stop rendering (or stop rendering correctly)
In case 3, you need to blow away the session and there's no getting around it. So VT switch and killall gnome-session will do just fine. For case 2, I seem to recall this being an unpleasant requirement of
the
X protocol somewhere along the line; but I'm looking into it.
For case 1, you might be able to recover if you could just figure out which client was being obstreperous. So clearly the right thing is to dump active grab state to the X log on VT switch. If there's anything there, then you know who to blame and you can pkill just that and recover. If there's not, then the session is doomed.
Something like this perhaps:
http://ajax.fedorapeople.org/patches/xserver-grab-debugging.patch
I mean, I know it's bad form to post code to a development list, but I hope I can be forgiven this time.
- ajax
I'll add
5. Maximum number of open files hit (I experience when using KWin compositing on intel driver).
I know of no non-C-A-Bs way to get out of it without rebooting. https://bugzilla.redhat.com/show_bug.cgi?id=486695
- --Ben
Adam Jackson wrote:
So let's list the cases that zap would actually recover from:
1: stuck grabs 2: focus reverts to None and your window manager is dead 3: X driver that's decided to stop rendering (or stop rendering correctly)
4: "log out"... didn't. :-)
There's no data loss since I'm trying to make X shut down anyway. (And, guess what? VT switching *doesn't work* with NVIDIA's so-called "drivers". It'll be wonderful to have nouveau learn how to support triple-head across two boards.)
While I do have access to other machines from which I could ssh in, there's a huge convenience difference between giving the three-finger salute and getting immediately back to work, and powering up another box, logging in, finding X, killing it, going back down the hall to my machine, finding out it didn't work, trying again...
(I've not filed bugs any of the many occasions this has happened because I'm using trunk KDE; I tend not to bother filing bugs against stuff that has a high probability of having been fixed before I even noticed it, and might well be due to a bad build on my end.)
In the grand scheme of things, I log out so infrequently it's not a huge deal, but I still think disabling c-a-bs is the wrong decision.
On Tue, 2009-03-31 at 10:16 -0400, Adam Jackson wrote:
So let's list the cases that zap would actually recover from:
1: stuck grabs 2: focus reverts to None and your window manager is dead 3: X driver that's decided to stop rendering (or stop rendering correctly)
In case 3, you need to blow away the session and there's no getting around it. So VT switch and killall gnome-session will do just fine. For case 2, I seem to recall this being an unpleasant requirement of the X protocol somewhere along the line; but I'm looking into it.
For case 1, you might be able to recover if you could just figure out which client was being obstreperous. So clearly the right thing is to dump active grab state to the X log on VT switch. If there's anything there, then you know who to blame and you can pkill just that and recover. If there's not, then the session is doomed.
Something like this perhaps:
http://ajax.fedorapeople.org/patches/xserver-grab-debugging.patch
I mean, I know it's bad form to post code to a development list, but I hope I can be forgiven this time.
You are honestly expecting Aunt Tillie to log in to a console and grovel through log files?
Here, how about a real life test case:
#include <stdlib.h> #include <SDL/SDL.h>
int main(int argc, char *argv[]){ if ( SDL_Init(SDL_INIT_VIDEO|SDL_INIT_TIMER) < 0 ) { fprintf(stderr, "Unable to init SDL: %s\n", SDL_GetError()); exit(1); } SDL_Surface *screen; screen = SDL_SetVideoMode(640, 480, 32, SDL_SWSURFACE|SDL_FULLSCREEN); if ( screen == NULL ) { fprintf(stderr, "Unable to set 640x480 video: %s\n", SDL_GetError()); exit(1); } SDL_WM_GrabInput(SDL_GRAB_ON); SDL_ShowCursor(SDL_DISABLE); SDL_Delay(1000); abort(); return 0; }
Compile with 'gcc -O2 -Wall -lSDL sdlcrash.c -o sdlcrash'.
Little Billy's game of Quake 3 crashes. How does he recover? What does Aunt Tille tell him if he asks for help? (This seems to have gotten better at some point, apparently the GNOME menu learned to stay in the visible part of the goddamn screen...)
Now how about Seg, the guy who debugs Little Billy's game. Take out the 'SDL_FULLSCREEN' flag from sdlcrash, recompile and run it under gdb. Wait for the crash... kablooey! I run in to this situation all the goddamn time trying to debug Second Life. It grabs the mouse when you click to move the camera, which is what you're doing most of the time. If it crashes then you're screwed.
Is there some way to recover other than killing off the process, which screws any chance of debugging it because it's no longer running? Remote debugging isn't always particularly convenient.
On Sat, 2009-04-04 at 12:41 -0500, Callum Lerwick wrote:
You are honestly expecting Aunt Tillie to log in to a console and grovel through log files?
No, Aunt Tillie is going to hit c-a-d or the power button like she does in windows. She doesn't know the difference between that and c-a-backspace anyway, and the only visible difference for her is that full reboot takes slightly longer.
Here, how about a real life test case:
<snip>
Running this in rawhide doesn't do anything particularly special. The app crashes, certainly, but input continues to work afterward. Haven't tried with F10 yet, maybe it's worse there.
Now how about Seg, the guy who debugs Little Billy's game. Take out the 'SDL_FULLSCREEN' flag from sdlcrash, recompile and run it under gdb. Wait for the crash... kablooey! I run in to this situation all the goddamn time trying to debug Second Life. It grabs the mouse when you click to move the camera, which is what you're doing most of the time. If it crashes then you're screwed.
I assume that you mean "gdb it from within X" here, in which case yes, this is difficult. Option one is to set a breakpoint on the signal handler and do:
(gdb) commands 1 Type commands for when breakpoint 1 is hit, one per line. End with a line saying just "end".
call XUngrabPointer(SDL_Display, 0) call XUngrabKeyboard(SDL_Display, 0) end
Except of course that SDL_Display isn't really a variable, so, figure that bit out. Or just do it from the signal handler in SDL or the app itself, except then you have to set the breakpoint after those calls have run. You're playing with fire a bit here since if you faulted in the middle of an xlib call, the ungrab requests are probably going to be sent as garbage.
Other option is to somehow get an XKillClient() to happen, which would break the server's connection to the now-halted client, and thus reset grab state. Again, if you do this from within the crashing client you run the risk of corrupting xlib's state, so it's only better than the ungrab hack if you can get it to fire from some other client.
Third option from within the crashing app itself is close(ConnectionNumber(dpy)), I suppose. That'll trigger disconnect handling in the server without generating more protocol.
Is there some way to recover other than killing off the process, which screws any chance of debugging it because it's no longer running? Remote debugging isn't always particularly convenient.
Yep, life is hard.
You may be able to use the GL support in Xephyr instead? That would limit the scope of the grab to the nested Xephyr server.
- ajax
On Mon, 2009-04-06 at 10:14 -0400, Adam Jackson wrote:
No, Aunt Tillie is going to hit c-a-d
... Which is disabled inside X.
or the power button
Sure hope ACPI is working...
like she does in windows. She doesn't know the difference between that and c-a-backspace anyway, and the only visible difference for her is that full reboot takes slightly longer.
Here, how about a real life test case:
<snip>
Running this in rawhide doesn't do anything particularly special. The app crashes, certainly, but input continues to work afterward. Haven't tried with F10 yet, maybe it's worse there.
The mouse cursor disappears and becomes completely nonfunctional. Also, you're stuck looking at the upper left 640x480 corner of the screen. For best effect your desktop should be at ~1280x960 or more before running the test. Note the gnome-display-properties applet doesn't even fit on the screen.
Sure hope Aunt Tillie knows how to log out using only the keyboard. Oh wait:
https://bugzilla.redhat.com/show_bug.cgi?id=430404
Though I guess you can just wait for the timeout... (Yeah yeah, supposedly fixed in F11 :)
On Wed, 2009-04-08 at 13:37 -0500, Callum Lerwick wrote:
On Mon, 2009-04-06 at 10:14 -0400, Adam Jackson wrote:
No, Aunt Tillie is going to hit c-a-d
... Which is disabled inside X.
Strange, it sure seems to pop up a powerdown dialog for me. Although the original point was about stuck grabs, so, fair enough.
or the power button
Sure hope ACPI is working...
If the EC doesn't respond, the keyboard controller sure as hell isn't going to.
Running this in rawhide doesn't do anything particularly special. The app crashes, certainly, but input continues to work afterward. Haven't tried with F10 yet, maybe it's worse there.
The mouse cursor disappears and becomes completely nonfunctional. Also, you're stuck looking at the upper left 640x480 corner of the screen. For best effect your desktop should be at ~1280x960 or more before running the test. Note the gnome-display-properties applet doesn't even fit on the screen.
I bet that's fixed with this build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1286108
- ajax
On Mon, Mar 30, 2009 at 3:37 PM, Colin Walters walters@verbum.org wrote:
On Mon, Mar 30, 2009 at 4:24 PM, Kevin Kofler kevin.kofler@chello.at wrote:
Rodd Clarkson wrote:
I'm figuring that something should be attempted so that we don't have to go through this conversation a third time when f11 is released. ;-]
I think that's just futile. The only way NOT to have those threads spring up like mushrooms is to reenable that feature by default.
No, the right solution is to examine the cases for why people were using the key before, and come up with a design which addresses them. This may involve writing *new code*, as opposed to e.g. just turning on whatever code happens to exist now elsewhere (referring to the kernel sysrq key).
While I think it's crazy to have a magic key combination which instantly logs you out without any confirmation, it'd be very useful to have some kind of "oh crap" key to recover from things like a wedged fullscreen application, stuck X server grab, etc.
You know the reset button on the machine resets the entire machine, right?
On 2009/03/30 15:45 (GMT-0500) Arthur Pemberton composed:
You know the reset button on the machine resets the entire machine, right?
What planet are you from? Most modern systems have no such button, and the power switch won't necessary suffice in its stead.
On Monday, 30 March 2009 at 23:06, Felix Miata wrote:
On 2009/03/30 15:45 (GMT-0500) Arthur Pemberton composed:
You know the reset button on the machine resets the entire machine, right?
What planet are you from? Most modern systems have no such button, and the power switch won't necessary suffice in its stead.
Not where I live. Here all modern systems have the reset switch.
Regards, R.
On 2009/03/30 23:12 (GMT+0200) Dominik 'Rathann' Mierzejewski composed:
On Monday, 30 March 2009 at 23:06, Felix Miata wrote:
On 2009/03/30 15:45 (GMT-0500) Arthur Pemberton composed:
You know the reset button on the machine resets the entire machine, right?
What planet are you from? Most modern systems have no such button, and the power switch won't necessary suffice in its stead.
Not where I live. Here all modern systems have the reset switch.
Maybe you've not seen a Dell made in the last 8 years. I've not seen one Dell made in that period that has one. Even if there are many still made with reset buttons, a huge number, including those from other major players like Lenovo, Gateway and HP, have none.
Dominik 'Rathann' Mierzejewski wrote:
On Monday, 30 March 2009 at 23:06, Felix Miata wrote:
On 2009/03/30 15:45 (GMT-0500) Arthur Pemberton composed:
You know the reset button on the machine resets the entire machine, right?
What planet are you from? Most modern systems have no such button, and the power switch won't necessary suffice in its stead.
Not where I live. Here all modern systems have the reset switch.
Regards, R.
yeah here too, even the high end gaming cases sill have reset switches
On Mon, 2009-03-30 at 15:45 -0500, Arthur Pemberton wrote:
You know the reset button on the machine resets the entire machine, right?
No matter how fast or sloppy my typing, nor what editor I use, I'm very unlikely to accidentally reach under the desk and hit the (recessed) reset button while sitting at the keyboard, working.
On many machines now, the power switch invokes a shutdown dialog, instead of simply powering the machine off with no warning--see the GNOME power-management applet's dialog. On my wife's Dell Dimension, I haven't even been able to locate a reset button--the only thing on the front panel available to press is the power button. No reset button on any of my laptops, either.
On Mon, 2009-03-30 at 18:26 -0400, Matthew Saltzman wrote:
On Mon, 2009-03-30 at 15:45 -0500, Arthur Pemberton wrote:
You know the reset button on the machine resets the entire machine, right?
No matter how fast or sloppy my typing, nor what editor I use, I'm very unlikely to accidentally reach under the desk and hit the (recessed) reset button while sitting at the keyboard, working.
On many machines now, the power switch invokes a shutdown dialog, instead of simply powering the machine off with no warning--see the GNOME power-management applet's dialog. On my wife's Dell Dimension, I haven't even been able to locate a reset button--the only thing on the front panel available to press is the power button. No reset button on any of my laptops, either.
On all machines I know of, pressing the power button for 4 seconds performs a hard reset.
Simo.
On Mon, Mar 30, 2009 at 09:22:37PM -0400, Simo Sorce wrote:
You know the reset button on the machine resets the entire machine, right?
front panel available to press is the power button. No reset button on any of my laptops, either.
On all machines I know of, pressing the power button for 4 seconds performs a hard reset.
On all machines I know of, putting your size 13 boot through the case performs a hard power off...
That doesn't make it relevant.
regards, Kyle
On Mon, 2009-03-30 at 21:38 -0400, Kyle McMartin wrote:
On Mon, Mar 30, 2009 at 09:22:37PM -0400, Simo Sorce wrote:
You know the reset button on the machine resets the entire machine, right?
front panel available to press is the power button. No reset button on any of my laptops, either.
On all machines I know of, pressing the power button for 4 seconds performs a hard reset.
On all machines I know of, putting your size 13 boot through the case performs a hard power off...
That doesn't make it relevant.
Given it happened to me a couple of times to unwillingly press my foot (or my knee depending on the machine) for more than 4 seconds on the power button of the machine I have laid down on one side under my desk, thus causing an instant power-off, I think it is pretty much relevant.
However thanks for the useful and polite reply, it's always pleasant to get a cheering message from the STFU-I gang ...
Simo.
On Mon, Mar 30, 2009 at 09:58:39PM -0400, Simo Sorce wrote:
Given it happened to me a couple of times to unwillingly press my foot (or my knee depending on the machine) for more than 4 seconds on the power button of the machine I have laid down on one side under my desk, thus causing an instant power-off, I think it is pretty much relevant.
My point was *THIS IS NOT A SOFTWARE PROBLEM.*
On Mon, 2009-03-30 at 21:22 -0400, Simo Sorce wrote:
On Mon, 2009-03-30 at 18:26 -0400, Matthew Saltzman wrote:
On Mon, 2009-03-30 at 15:45 -0500, Arthur Pemberton wrote:
You know the reset button on the machine resets the entire machine, right?
No matter how fast or sloppy my typing, nor what editor I use, I'm very unlikely to accidentally reach under the desk and hit the (recessed) reset button while sitting at the keyboard, working.
On many machines now, the power switch invokes a shutdown dialog, instead of simply powering the machine off with no warning--see the GNOME power-management applet's dialog. On my wife's Dell Dimension, I haven't even been able to locate a reset button--the only thing on the front panel available to press is the power button. No reset button on any of my laptops, either.
On all machines I know of, pressing the power button for 4 seconds performs a hard reset.
Yes, also not likely to be done by accident.
Simo.
Matthew Saltzman wrote:
On Mon, 2009-03-30 at 21:22 -0400, Simo Sorce wrote:
On Mon, 2009-03-30 at 18:26 -0400, Matthew Saltzman wrote:
On Mon, 2009-03-30 at 15:45 -0500, Arthur Pemberton wrote:
You know the reset button on the machine resets the entire machine, right?
No matter how fast or sloppy my typing, nor what editor I use, I'm very unlikely to accidentally reach under the desk and hit the (recessed) reset button while sitting at the keyboard, working.
On many machines now, the power switch invokes a shutdown dialog, instead of simply powering the machine off with no warning--see the GNOME power-management applet's dialog. On my wife's Dell Dimension, I haven't even been able to locate a reset button--the only thing on the front panel available to press is the power button. No reset button on any of my laptops, either.
On all machines I know of, pressing the power button for 4 seconds performs a hard reset.
Yes, also not likely to be done by accident.
except by those emacs users who have admitted randomly pressing buttons to see what they do, you know that's how to learns computers nowadays ;-)
Matthew Saltzman wrote:
No matter how fast or sloppy my typing, nor what editor I use, I'm very unlikely to accidentally reach under the desk and hit the (recessed) reset button while sitting at the keyboard, working.
I actually accidentally triggered the reset button on the case at least once.
Kevin Kofler
On Tue, 2009-03-31 at 17:34 +0200, Kevin Kofler wrote:
Matthew Saltzman wrote:
No matter how fast or sloppy my typing, nor what editor I use, I'm very unlikely to accidentally reach under the desk and hit the (recessed) reset button while sitting at the keyboard, working.
I actually accidentally triggered the reset button on the case at least once.
OK (I'm trying to picture it, and I keep seeing Rose Mary Woods demonstrating how she "accidentally" created the infamous 18-minute gap in the Watergate tapes), but it's still "unlikely" if you are typing, much more so than any Ctrl-Alt-<whatever> key combo.
Kevin Kofler
Matthew Saltzman wrote:
OK (I'm trying to picture it, and I keep seeing Rose Mary Woods demonstrating how she "accidentally" created the infamous 18-minute gap in the Watergate tapes), but it's still "unlikely" if you are typing, much more so than any Ctrl-Alt-<whatever> key combo.
I accidentally hit it with my foot.
Kevin Kofler
On Tue, 2009-03-31 at 19:43 +0200, Kevin Kofler wrote:
Matthew Saltzman wrote:
OK (I'm trying to picture it, and I keep seeing Rose Mary Woods demonstrating how she "accidentally" created the infamous 18-minute gap in the Watergate tapes), but it's still "unlikely" if you are typing, much more so than any Ctrl-Alt-<whatever> key combo.
I accidentally hit it with my foot.
Did you move the machine after that, or do you now tie your feet to the chair posts?
Kevin Kofler
On Tue, Mar 31, 2009 at 16:00:17 -0400, Matthew Saltzman mjs@clemson.edu wrote:
On Tue, 2009-03-31 at 19:43 +0200, Kevin Kofler wrote:
Matthew Saltzman wrote:
OK (I'm trying to picture it, and I keep seeing Rose Mary Woods demonstrating how she "accidentally" created the infamous 18-minute gap in the Watergate tapes), but it's still "unlikely" if you are typing, much more so than any Ctrl-Alt-<whatever> key combo.
I accidentally hit it with my foot.
Did you move the machine after that, or do you now tie your feet to the chair posts?
After accidentally hitting the switch on a powerstrip, I taped an angle bracket over it so I couldn't do that again.
On Mon, Mar 30, 2009 at 6:26 PM, Matthew Saltzman mjs@clemson.edu wrote:
On many machines now, the power switch invokes a shutdown dialog, instead of simply powering the machine off with no warning--see the GNOME power-management applet's dialog. On my wife's Dell Dimension, I haven't even been able to locate a reset button--the only thing on the front panel available to press is the power button. No reset button on any of my laptops, either.
But you can normally do a hard power-off by keeping the power button pressed for 4 seconds; this cuts off power rather than generating an ACPI event.
On Tue, 2009-03-31 at 11:56 -0400, Michel Salim wrote:
On Mon, Mar 30, 2009 at 6:26 PM, Matthew Saltzman mjs@clemson.edu wrote:
On many machines now, the power switch invokes a shutdown dialog, instead of simply powering the machine off with no warning--see the GNOME power-management applet's dialog. On my wife's Dell Dimension, I haven't even been able to locate a reset button--the only thing on the front panel available to press is the power button. No reset button on any of my laptops, either.
But you can normally do a hard power-off by keeping the power button pressed for 4 seconds; this cuts off power rather than generating an ACPI event.
Yes, but by accident? Four seconds is a long time to have to consider lifting your finger off the button before something happens that can't be stopped/reversed.
Colin Walters wrote:
On Mon, Mar 30, 2009 at 4:24 PM, Kevin Kofler kevin.kofler@chello.at wrote:
Rodd Clarkson wrote:
I'm figuring that something should be attempted so that we don't have to go through this conversation a third time when f11 is released. ;-]
I think that's just futile. The only way NOT to have those threads spring up like mushrooms is to reenable that feature by default.
No, the right solution is to examine the cases for why people were using the key before,
c-a-bs to me is an "ejection seat button" => disabling it is not helpful
and come up with a design which addresses them.
The cases I press it typically are "cases of emergencies"
This may involve writing *new code*, as opposed to e.g. just turning on whatever code happens to exist now elsewhere (referring to the kernel sysrq key).
While I think it's crazy to have a magic key combination which instantly logs you out without any confirmation, it'd be very useful to have some kind of "oh crap" key to recover from things like a wedged fullscreen application, stuck X server grab, etc.
Windows think: "Pilot, Do you really want to eject the seat, ... Confirm ejecting the seat"
Ralf Corsepius rc040203@freenet.de writes:
c-a-bs to me is an "ejection seat button" => disabling it is not helpful
I like that analogy. Or maybe a better one is to those fire extinguishers you see behind little glass doors in every public building --- you know, "In case of emergency, break glass".
X.org has decided that it would be a safety feature to install shatterproof glass in those boxes.
regards, tom lane
On Mon, Mar 30, 2009 at 9:49 PM, Tom Lane tgl@redhat.com wrote:
Ralf Corsepius rc040203@freenet.de writes:
c-a-bs to me is an "ejection seat button" => disabling it is not helpful
It's like an ejection seat button without a label. ;-)
I was just thinking it would be cool if c-a-bs would send you to a virtual console and open up a text confirmation dialog box. Dunno if something like that is possible though.
Christopher Stone wrote:
On Mon, Mar 30, 2009 at 9:49 PM, Tom Lane tgl@redhat.com wrote:
Ralf Corsepius rc040203@freenet.de writes:
c-a-bs to me is an "ejection seat button" => disabling it is not helpful
It's like an ejection seat button without a label. ;-)
Well, IMO, it's obscured enough, such that educated users find it when they feel they need it and new-comers not hit it accidentally.
And if they hit it accidentially, it will surprise them only once or twice, hardly causing any damage and push them through a learning curve, helping them to understand that X11 is not Windows.
I was just thinking it would be cool if c-a-bs would send you to a virtual console and open up a text confirmation dialog box. Dunno if something like that is possible though.
As I previously wrote, to me such proposals are in the same class as: "Do you really want to eject? Enter root password to eject, confirm ejection ... ejection will be started in 60 secs ..."
It voids "c-a-bs" as a means of "emergency button". They are meant to prevent _further_ damage in situations of emergencies and aren't necessarily guaranteed to "not cause damage".
I mean, when pressing "c-a-bs", I am expecting the Xserver to terminate immediately and do not expect those "open applications to save their state".
That said, "c-a-bs" to me is one of the last options to choose from when trying to rescue a system before having to resort to more brutal means: "c-alt-del", "soft power off", "hard power off" [1].
Ralf
[1] Classical situation: Something in X or below it (Xdriver/kernel) is hogging CPU/memory to an extend a system doesn't respond to interactive input anymore. And yes, these kind of situations do still happen.
On Tuesday 31 March 2009 11:27:15 Ralf Corsepius wrote:
Christopher Stone wrote:
On Mon, Mar 30, 2009 at 9:49 PM, Tom Lane tgl@redhat.com wrote:
Ralf Corsepius rc040203@freenet.de writes:
c-a-bs to me is an "ejection seat button" => disabling it is not helpful
...
I was just thinking it would be cool if c-a-bs would send you to a virtual console and open up a text confirmation dialog box. Dunno if something like that is possible though.
As I previously wrote, to me such proposals are in the same class as: "Do you really want to eject? Enter root password to eject, confirm ejection ... ejection will be started in 60 secs ..."
It voids "c-a-bs" as a means of "emergency button". They are meant to prevent _further_ damage in situations of emergencies and aren't necessarily guaranteed to "not cause damage".
Yes, I agree, completely. When something starts to eat all resources, you can kill it (with whole X server if it's not the X server eating all). You definitely have no time to switch to vt, log in and kill it...
I think disabling c+a+bs is really wrong decision :(
...
On Tuesday 31 March 2009 11:50:00 Michal Hlavinka wrote:
On Tuesday 31 March 2009 11:27:15 Ralf Corsepius wrote:
Christopher Stone wrote:
On Mon, Mar 30, 2009 at 9:49 PM, Tom Lane tgl@redhat.com wrote:
Ralf Corsepius rc040203@freenet.de writes:
c-a-bs to me is an "ejection seat button" => disabling it is not helpful
...
I was just thinking it would be cool if c-a-bs would send you to a virtual console and open up a text confirmation dialog box. Dunno if something like that is possible though.
As I previously wrote, to me such proposals are in the same class as: "Do you really want to eject? Enter root password to eject, confirm ejection ... ejection will be started in 60 secs ..."
It voids "c-a-bs" as a means of "emergency button". They are meant to prevent _further_ damage in situations of emergencies and aren't necessarily guaranteed to "not cause damage".
Yes, I agree, completely. When something starts to eat all resources, you can kill it (with whole X server if it's not the X server eating all). You definitely have no time to switch to vt, log in and kill it...
Exactly!
I think disabling c+a+bs is really wrong decision :(
I don't care if we have control+alt+backspace or control+shift+alt+f5+backspace+* but I want to have it enabled by default.
Jaroslav
...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Michal Hlavinka wrote:
On Tuesday 31 March 2009 11:27:15 Ralf Corsepius wrote:
Christopher Stone wrote:
On Mon, Mar 30, 2009 at 9:49 PM, Tom Lane tgl@redhat.com
wrote:
Ralf Corsepius rc040203@freenet.de writes:
c-a-bs to me is an "ejection seat button" => disabling it is not helpful
...
I was just thinking it would be cool if c-a-bs would send you to a virtual console and open up a text confirmation dialog box.
Dunno if
something like that is possible though.
As I previously wrote, to me such proposals are in the same class
as:
"Do you really want to eject? Enter root password to eject, confirm ejection ... ejection will be started in 60 secs ..."
It voids "c-a-bs" as a means of "emergency button". They are
meant to
prevent _further_ damage in situations of emergencies and aren't necessarily guaranteed to "not cause damage".
Yes, I agree, completely. When something starts to eat all resources,
you
can kill it (with whole X server if it's not the X server eating all). You definitely have no time to switch to vt, log in and kill it...
I think disabling c+a+bs is really wrong decision :(
...
And if those resources are open files? You don't know until it's already happened afaik. I think zapping should be enabled, but a more obscure key combination may be necessary to prevent accidental triggers.
- --Ben
On Tuesday 31 March 2009 05:49:07 Tom Lane wrote:
Ralf Corsepius rc040203@freenet.de writes:
c-a-bs to me is an "ejection seat button" => disabling it is not helpful
I like that analogy. Or maybe a better one is to those fire extinguishers you see behind little glass doors in every public building --- you know, "In case of emergency, break glass".
X.org has decided that it would be a safety feature to install shatterproof glass in those boxes.
No, they've taken the box away. That's the point.
Shatterproof glass is the "you have to press it twice" or "you have to hold it down for four seconds".
On Fri, 2009-03-27 at 16:31 -0400, Gerry Reno wrote:
Having to deal with many servers and workstations in a company it is crucial that Ctrl-Alt-Backspace be enabled by default. There are times when your KVM has lost mouse control or X is in a tight loop and something like Ctrl-Alt-Backspace can save the situation. This is much more common than the uncommon cases that are illustrated as to why this has been removed as default.
No, it can't.
C-A-BS is handled in the event loop [1]. If you're stuck in the driver, away from the event loop, you're never going to get back to it to handle the zap event. And if you were processing events, you could equally well vt-switch and clean up from there.
We're planning to make that keycombo trigger the logout dialog. If your DE has a sensible task manager applet, that would probably also belong here so you can zap rude processes.
[1] - To be annoyingly pedantic, the keystroke is added to the input queue in a signal handler, but the queue is processed in the main loop, and any actions that result from the keystroke happen then and not in the signal handler (like sending X events to clients, or releasing the display for VT switch, or shutting down).
- ajax
Adam Jackson wrote:
On Fri, 2009-03-27 at 16:31 -0400, Gerry Reno wrote:
Having to deal with many servers and workstations in a company it is crucial that Ctrl-Alt-Backspace be enabled by default. There are times when your KVM has lost mouse control or X is in a tight loop and something like Ctrl-Alt-Backspace can save the situation. This is much more common than the uncommon cases that are illustrated as to why this has been removed as default.
No, it can't.
C-A-BS is handled in the event loop [1]. If you're stuck in the driver, away from the event loop, you're never going to get back to it to handle the zap event. And if you were processing events, you could equally well vt-switch and clean up from there.
We're planning to make that keycombo trigger the logout dialog. If your DE has a sensible task manager applet, that would probably also belong here so you can zap rude processes.
[1] - To be annoyingly pedantic, the keystroke is added to the input queue in a signal handler, but the queue is processed in the main loop, and any actions that result from the keystroke happen then and not in the signal handler (like sending X events to clients, or releasing the display for VT switch, or shutting down).
- ajax
So sysrq-k would actually be an improvement, I assume.
I'd like to see more thoughts on enabling those. There's quite a few of them that I wouldn't mind having around.
--CJD
devel@lists.stg.fedoraproject.org
-
Adam Jackson -
Adam Miller -
Adam Williamson -
Ahmed Kamal -
Alexander Boström -
Anders Rayner-Karlsson -
Andrew Haley -
Andy Lawrence -
Arthur Pemberton -
Ben Boeckel -
Benny Amorsen -
Bill Crawford -
Bill Nottingham -
Bruno Wolff III -
Bryn M. Reeves -
Callum Lerwick -
Casey Dahlin -
casimiro barreto -
Chris Adams -
Christopher Aillon -
Christopher Stone -
Clyde E. Kunkel -
Colin Walters -
Dan Nicholson -
David Airlie -
David Boles -
Dominik 'Rathann' Mierzejewski -
drago01 -
Emmanuel Seyman -
Felix Miata -
Gerry Reno -
Giancarlo Niccolai -
Gianluca Sforna -
Gregory Maxwell -
J. Randall Owens -
Jaroslav Reznik -
Jef Spaleta -
Jesse Keating -
John5342 -
jon doe -
Joonas Sarajärvi -
Kevin Kofler -
kodis＠comcast.net -
Kyle McMartin -
Martin Sourada -
Matthew Garrett -
Matthew Saltzman -
Matthew Woehlke -
Matthias Clasen -
Michael Cronenworth -
Michal Hlavinka -
Michel Salim -
Muayyad AlSadi -
Nicolas Mailhot -
Olivier Galibert -
Orcan Ogetbil -
Patrick W. Barnes -
Paul Wouters -
Pete Zaitcev -
Rahul Sundaram -
Ralf Corsepius -
Robert Marcano -
Rodd Clarkson -
Roland McGrath -
Simo Sorce -
Suren Karapetyan -
Tom Lane -
Yaakov Nemoy