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 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.
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 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.
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 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.
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 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
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 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.
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 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.
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
Muayyad AlSadi wrote:
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
FYI, for this purpose you can create an xorg.conf with only this setting (and otherwise blank).
Kevin Kofler
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 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
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 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
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.