4:07 p.m.
Hi folks,
If you're running F10Beta/Rawhide, you may have noticed already, but I
wanted to make sure everyone knows this is intentional:
X HAS MOVED FROM VT7 TO VT1.
GDM specifically starts X on tty1, and upstart does not start a getty on
tty1 in runlevel 5.
Other display managers might need to be changed to match (or they might
Just Work since tty1 will be the first unused tty).
If you maintain one of the other display managers, it would be good to
make sure that your packages do the right thing.
Thanks!
-w
4:19 p.m.
If you're running F10Beta/Rawhide, you may have noticed already,
but I
wanted to make sure everyone knows this is intentional:
X HAS MOVED FROM VT7 TO VT1.
GDM specifically starts X on tty1, and upstart does not start a getty on
tty1 in runlevel 5.
I'm running today's rawhide, but I still see X11 on vty7 (Ctrl-Alt-F7),
init log on vty1, and text login on vty2 through vty6.
"rpm -qa" says:
gdm-2.4.0-11.fc10.i386
xorg-x11-server-Xorg-1.5.2-9.fc10.i386
xorg-x11-xinit-1.0.9-4.fc10.i386
/etc/inittab says:
id:5:initdefault:
The anaconda-11.4.1.51 installer also runs X11 on vty7, with anaconda "console"
on vty1, shell on vty2, various logs on vty3 through vty5, and "No signal" on
vty6.
--
4:54 p.m.
On Mon, 2008-10-27 at 14:19 -0700, John Reiser wrote:
> If you're running F10Beta/Rawhide, you may have noticed
already, but I
> wanted to make sure everyone knows this is intentional:
>
> X HAS MOVED FROM VT7 TO VT1.
>
> GDM specifically starts X on tty1, and upstart does not start a getty on
> tty1 in runlevel 5.
I'm running today's rawhide, but I still see X11 on vty7 (Ctrl-Alt-F7),
init log on vty1, and text login on vty2 through vty6.
Are you running GDM as your display manager? It's on tty1 on my system -
same gdm / xinit versions as you. When was the last time you rebooted?
The anaconda-11.4.1.51 installer also runs X11 on vty7, with anaconda
"console"
on vty1, shell on vty2, various logs on vty3 through vty5, and "No signal" on
vty6.
You're correct; this information does not apply to anaconda. (At least
not yet.)
One thing though: Anaconda typically runs X on tty6.
tty1: console
tty2: shell
tty3: anaconda.log
tty4: syslog
tty5: redirected output from commands run by anaconda
tty6: X
Not sure why it would show up as tty7 on your system.
-w
9:55 p.m.
> I'm running today's rawhide, but I still see X11 on vty7
(Ctrl-Alt-F7),
> init log on vty1, and text login on vty2 through vty6.
Are you running GDM as your display manager? It's on tty1 on my system -
same gdm / xinit versions as you. When was the last time you rebooted?
A reboot brought up gdm on vty1.
> The anaconda-11.4.1.51 installer also runs X11 on vty7, with
anaconda "console"
> on vty1, shell on vty2, various logs on vty3 through vty5, and "No signal"
on vty6.
You're correct; this information does not apply to anaconda. (At least
not yet.)
One thing though: Anaconda typically runs X on tty6.
tty1: console
tty2: shell
tty3: anaconda.log
tty4: syslog
tty5: redirected output from commands run by anaconda
tty6: X
Not sure why it would show up as tty7 on your system.
Perhaps because of "blank graphical welcome screen for DVD install"
which is https://bugzilla.redhat.com/show_bug.cgi?id=466370
I see vty1-5 as above, "No signal" on vty6. vty7 has a blank screen
except for a blinking underline text cursor in the upper left corner.
--
5:18 p.m.
On Mon, Oct 27, 2008 at 3:06 PM, Chuck Anderson <cra(a)wpi.edu> wrote:
On Mon, Oct 27, 2008 at 05:07:59PM -0400, Will Woods wrote:
> If you're running F10Beta/Rawhide, you may have noticed already, but I
> wanted to make sure everyone knows this is intentional:
>
> X HAS MOVED FROM VT7 TO VT1.
So what goodness does this provide for us?
http://fedoramagazine.wordpress.com/2008/10/21/interview-fedora-10s-bette...
--
Dan
5:48 p.m.
On Mon, 2008-10-27 at 17:07 -0400, Will Woods wrote:
Hi folks,
If you're running F10Beta/Rawhide, you may have noticed already, but I
wanted to make sure everyone knows this is intentional:
X HAS MOVED FROM VT7 TO VT1.
GDM specifically starts X on tty1, and upstart does not start a getty on
tty1 in runlevel 5.
One consequence that is worth pointing out is that there is nothing on
vt7 now. Some people seemed to expect a getty there, but that is not the
case.
4:54 a.m.
Will Woods píše v Po 27. 10. 2008 v 17:07 -0400:
Hi folks,
If you're running F10Beta/Rawhide, you may have noticed already, but I
wanted to make sure everyone knows this is intentional:
X HAS MOVED FROM VT7 TO VT1.
GDM specifically starts X on tty1, and upstart does not start a getty on
tty1 in runlevel 5.
How can I disable this "feature"? I really do not want change my habits
after 10+ years with X on vt7.
Other display managers might need to be changed to match (or they
might
Just Work since tty1 will be the first unused tty).
If you maintain one of the other display managers, it would be good to
make sure that your packages do the right thing.
Dan
6:40 a.m.
Dan Horák wrote:
Will Woods píše v Po 27. 10. 2008 v 17:07 -0400:
> Hi folks,
>
> If you're running F10Beta/Rawhide, you may have noticed already, but I
> wanted to make sure everyone knows this is intentional:
>
> X HAS MOVED FROM VT7 TO VT1.
>
> GDM specifically starts X on tty1, and upstart does not start a getty on
> tty1 in runlevel 5.
>
>
How can I disable this "feature"? I really do not want change my habits
after 10+ years with X on vt7.
+1
I hope it might be possible, by changing the order in upstart -- ie.
first run mingetty, then gdm (as for years before). Perhaps also restore
mingetty on tty1 ...
By the way, I cannot understand why gdm, when running before mingetty
(for better startup speed), must be run on tty1 only. It seems that it
should be possible to run it before, but cause it to use tty7.
It is insignificant for end users on what tty X run. But for other
users, it is better to preserve compatibility with 10+ years.
I can help to make changes for invoking X on tty7 instead of tty1 .
Regards,
Dmitry Butskoy
http://www.fedoraproject.org/wiki/DmitryButskoy
8:17 a.m.
On Tue, Oct 28, 2008 at 02:40:51PM +0300, Dmitry Butskoy wrote:
I hope it might be possible, by changing the order in upstart -- ie.
first run mingetty, then gdm (as for years before). Perhaps also restore
mingetty on tty1 ...
By the way, I cannot understand why gdm, when running before mingetty
(for better startup speed), must be run on tty1 only. It seems that it
should be possible to run it before, but cause it to use tty7.
It is insignificant for end users on what tty X run. But for other
users, it is better to preserve compatibility with 10+ years.
I can help to make changes for invoking X on tty7 instead of tty1 .
It seems an insignificant use case to keep compatibility with X on
tty7 compared to the benefits of progress--in this case one less VT
change on bootup means less flicker and faster bootup. I've been
using Fedora/Red Hat for 10+ years and once the reason was pointed out
to me, I completely agree that this is a good move. I'll adjust.
8:28 a.m.
Chuck Anderson wrote:
On Tue, Oct 28, 2008 at 02:40:51PM +0300, Dmitry Butskoy wrote:
> I hope it might be possible, by changing the order in upstart -- ie.
> first run mingetty, then gdm (as for years before). Perhaps also restore
> mingetty on tty1 ...
>
> By the way, I cannot understand why gdm, when running before mingetty
> (for better startup speed), must be run on tty1 only. It seems that it
> should be possible to run it before, but cause it to use tty7.
>
> It is insignificant for end users on what tty X run. But for other
> users, it is better to preserve compatibility with 10+ years.
>
> I can help to make changes for invoking X on tty7 instead of tty1 .
>
It seems an insignificant use case to keep compatibility with X on
tty7 compared to the benefits of progress--in this case one less VT
change on bootup means less flicker and faster bootup.
I mean "X before console's tty" as well, but instead of "first X on
tty1, then consoles on tty2-6", I propose "first X on tty7, then
consoles on tty1-6". In other words, preserve both the compatibility and
the faster bootup.
~buc
8:31 a.m.
Chuck Anderson wrote:
> On Tue, Oct 28, 2008 at 02:40:51PM +0300, Dmitry Butskoy wrote:
>
>> I hope it might be possible, by changing the order in upstart -- ie.
>> first run mingetty, then gdm (as for years before). Perhaps also
>> restore
>> mingetty on tty1 ...
>>
>> By the way, I cannot understand why gdm, when running before mingetty
>> (for better startup speed), must be run on tty1 only. It seems that it
>> should be possible to run it before, but cause it to use tty7.
>>
>> It is insignificant for end users on what tty X run. But for other
>> users, it is better to preserve compatibility with 10+ years.
>>
>> I can help to make changes for invoking X on tty7 instead of tty1 .
>>
>
> It seems an insignificant use case to keep compatibility with X on
> tty7 compared to the benefits of progress--in this case one less VT
> change on bootup means less flicker and faster bootup.
I mean "X before console's tty" as well, but instead of "first X on
tty1, then consoles on tty2-6", I propose "first X on tty7, then
consoles on tty1-6". In other words, preserve both the compatibility and
the faster bootup.
Heck, even just one tty can help with fixing X issues.
~buc
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
novus ordo absurdum
8:43 a.m.
On Tue, Oct 28, 2008 at 04:28:36PM +0300, Dmitry Butskoy wrote:
> It seems an insignificant use case to keep compatibility with X
on
> tty7 compared to the benefits of progress--in this case one less VT
> change on bootup means less flicker and faster bootup.
I mean "X before console's tty" as well, but instead of "first X on
tty1, then consoles on tty2-6", I propose "first X on tty7, then
consoles on tty1-6". In other words, preserve both the compatibility and
the faster bootup.
The system boots up in tty1 first. Having X change to tty7 is a VT
change, hence flicker and delay.
8:55 a.m.
Chuck Anderson wrote:
The system boots up in tty1 first. Having X change to tty7 is a VT
change, hence flicker and delay.
Well,
Is it possible for users who do not use "graphical boot" (there are such
users...), use "traditional" tty7 instead?
IOW, if X is already running, leave it on tty1, else invoke it on tty7.
If tty1 is already busy (by X), do not invoke mingetty on it.
~buc
9:24 a.m.
On Tue, Oct 28, 2008 at 6:55 AM, Dmitry Butskoy <buc(a)odusz.so-cdu.ru> wrote:
Chuck Anderson wrote:
>
> The system boots up in tty1 first. Having X change to tty7 is a VT
> change, hence flicker and delay.
>
Well,
Is it possible for users who do not use "graphical boot" (there are such
users...), use "traditional" tty7 instead?
IOW, if X is already running, leave it on tty1, else invoke it on tty7. If
tty1 is already busy (by X), do not invoke mingetty on it.
Users who do not want a graphical boot set rc 3 as their default
runlevel, and everything is the same as it always was with getty on
tty1-6. If you then run startx, it will start on tty7. In rc 5, X is
started on tty1 and getty is not. That's all there is to it.
--
Dan
9:49 a.m.
Dan Nicholson wrote:
On Tue, Oct 28, 2008 at 6:55 AM, Dmitry Butskoy
<buc(a)odusz.so-cdu.ru> wrote:
> Chuck Anderson wrote:
>
>> The system boots up in tty1 first. Having X change to tty7 is a VT
>> change, hence flicker and delay.
>>
>>
> Well,
>
> Is it possible for users who do not use "graphical boot" (there are such
> users...), use "traditional" tty7 instead?
>
> IOW, if X is already running, leave it on tty1, else invoke it on tty7. If
> tty1 is already busy (by X), do not invoke mingetty on it.
>
Users who do not want a graphical boot set rc 3 as their default
runlevel,
Not all, I do not use graphical boot and set rc 5 ;)
Though I boot my desktop (==workstation) approximately once in month...
(It explains why I do not need neither graphical, nor fastest boot...)
and everything is the same as it always was with getty on
tty1-6. If you then run startx, it will start on tty7.
Well, if I change the "consoles/X" order in upstart, then gdm will
appear at tty7 as before?
~buc
9:57 a.m.
Dmitry Butskoy píše v Út 28. 10. 2008 v 17:49 +0300:
Dan Nicholson wrote:
> On Tue, Oct 28, 2008 at 6:55 AM, Dmitry Butskoy <buc(a)odusz.so-cdu.ru> wrote:
>
>> Chuck Anderson wrote:
>>
>>> The system boots up in tty1 first. Having X change to tty7 is a VT
>>> change, hence flicker and delay.
>>>
>>>
>> Well,
>>
>> Is it possible for users who do not use "graphical boot" (there are
such
>> users...), use "traditional" tty7 instead?
>>
>> IOW, if X is already running, leave it on tty1, else invoke it on tty7. If
>> tty1 is already busy (by X), do not invoke mingetty on it.
>>
>
> Users who do not want a graphical boot set rc 3 as their default
> runlevel,
Not all, I do not use graphical boot and set rc 5 ;)
Though I boot my desktop (==workstation) approximately once in month...
(It explains why I do not need neither graphical, nor fastest boot...)
> and everything is the same as it always was with getty on
> tty1-6. If you then run startx, it will start on tty7.
Well, if I change the "consoles/X" order in upstart, then gdm will
appear at tty7 as before?
AFAIK there was/is a some code in GDM that explicitly passed the "vt 7"
option to the X server. It was not done in upstart on the "init" level.
Dan
12:54 p.m.
Dmitry Butskoy wrote:
Dan Nicholson wrote:
> On Tue, Oct 28, 2008 at 6:55 AM, Dmitry Butskoy <buc(a)odusz.so-cdu.ru>
> wrote:
>
>> Chuck Anderson wrote:
>>
>>> The system boots up in tty1 first. Having X change to tty7 is a VT
>>> change, hence flicker and delay.
>>>
>>>
>> Well,
>>
>> Is it possible for users who do not use "graphical boot" (there are
>> such
>> users...), use "traditional" tty7 instead?
>>
>> IOW, if X is already running, leave it on tty1, else invoke it on
>> tty7. If
>> tty1 is already busy (by X), do not invoke mingetty on it.
>>
>
> Users who do not want a graphical boot set rc 3 as their default
> runlevel,
Not all, I do not use graphical boot and set rc 5 ;)
Though I boot my desktop (==workstation) approximately once in
month... (It explains why I do not need neither graphical, nor fastest
boot...)
> and everything is the same as it always was with getty on
> tty1-6. If you then run startx, it will start on tty7.
Well, if I change the "consoles/X" order in upstart, then gdm will
appear at tty7 as before?
~buc
Should be.
--CJD
9:51 a.m.
On Tue October 28 2008, Dan Nicholson wrote:
Users who do not want a graphical boot set rc 3 as their default
runlevel, and everything is the same as it always was with getty on
tty1-6. If you then run startx, it will start on tty7. In rc 5, X is
started on tty1 and getty is not. That's all there is to it.
What happens if one boots into runlevel 3 and then changes into runlevel 5?
Will the login on tty1 then be killed and replaced by X?
Regards,
Till
10:22 a.m.
On 2008/10/28 15:51 (GMT+0100) Till Maas composed:
On Tue October 28 2008, Dan Nicholson wrote:
> Users who do not want a graphical boot set rc 3 as their default
> runlevel, and everything is the same as it always was with getty on
> tty1-6. If you then run startx, it will start on tty7. In rc 5, X is
> started on tty1 and getty is not. That's all there is to it.
What happens if one boots into runlevel 3 and then changes into
runlevel 5?
Will the login on tty1 then be killed and replaced by X?
I just did yum update, rebooted into runlevel 3, logged in on tty1, did
telinit 5, got kdm on vt7, switched to tty1, and found a normal shell prompt
following typical X startup messages, and kdm still on vt7. :-p
--
"Everyone should be quick to listen, slow to speak, and
slow to become angry." James 1:19 NIV
Team OS/2 ** Reg. Linux User #211409
Felix Miata *** http://fm.no-ip.com/
9:52 a.m.
Dan Nicholson píše v Út 28. 10. 2008 v 07:24 -0700:
On Tue, Oct 28, 2008 at 6:55 AM, Dmitry Butskoy
<buc(a)odusz.so-cdu.ru> wrote:
> Chuck Anderson wrote:
>>
>> The system boots up in tty1 first. Having X change to tty7 is a VT
>> change, hence flicker and delay.
>>
>
> Well,
>
> Is it possible for users who do not use "graphical boot" (there are such
> users...), use "traditional" tty7 instead?
>
> IOW, if X is already running, leave it on tty1, else invoke it on tty7. If
> tty1 is already busy (by X), do not invoke mingetty on it.
Users who do not want a graphical boot set rc 3 as their default
runlevel, and everything is the same as it always was with getty on
tty1-6. If you then run startx, it will start on tty7. In rc 5, X is
started on tty1 and getty is not. That's all there is to it.
Hm, but I am using runlevel 5 as default and do not use graphical boot
and I want to keep the old behaviour. I can survive a short delay and
some flickering during the vt switching. How can I set that?
Dan
8:27 a.m.
On Tue, Oct 28, 2008 at 4:40 AM, Dmitry Butskoy <buc(a)odusz.so-cdu.ru> wrote:
By the way, I cannot understand why gdm, when running before mingetty (for
better startup speed), must be run on tty1 only. It seems that it should be
possible to run it before, but cause it to use tty7.
It's not for speed, it's so there will be no VT switching when booting.
It is insignificant for end users on what tty X run. But for other
users, it
is better to preserve compatibility with 10+ years.
Why is it significant what tty any program runs on? Isn't the
assumption that getty will be on tty1 just as faulty as the assumption
X will be on tty7?
--
Dan
8:43 a.m.
Dan Nicholson wrote:
On Tue, Oct 28, 2008 at 4:40 AM, Dmitry Butskoy
<buc(a)odusz.so-cdu.ru> wrote:
> By the way, I cannot understand why gdm, when running before mingetty (for
> better startup speed), must be run on tty1 only. It seems that it should be
> possible to run it before, but cause it to use tty7.
>
It's not for speed, it's so there will be no VT switching when booting.
Does such a one switching cost so much?
Why is it significant what tty any program runs on? Isn't the
assumption that getty will be on tty1 just as faulty as the assumption
X will be on tty7?
Nope.
First, it is long precedent.
Second, there are non-GUI installations (including those where X invoked
by "startx" from runlevel 3). Hence it looks strange to count tty
consoles starting from 2 (instead of 1). Some people will be shocked,
whereas such a shocking seems not necessary for the faster bootup feature.
~buc
8:44 a.m.
Dan Nicholson wrote:
Why is it significant what tty any program runs on? Isn't the
assumption that getty will be on tty1 just as faulty as the assumption
X will be on tty7?
--
Dan
Because you are changing a user interface. What is going to happen when
the user switches to tty1 and nothing happens? The basic logic of
putting X on tty7 is to get it out of the way. Humans will use the
lowest numbered ttys first. Besides breaking existing documentation,
including advice on various forums, is not a good idea.
8:49 a.m.
On Tue, Oct 28, 2008 at 6:44 AM, shmuel siegel
<fedora(a)shmuelhome.mine.nu> wrote:
Dan Nicholson wrote:
>
> Why is it significant what tty any program runs on? Isn't the
> assumption that getty will be on tty1 just as faulty as the assumption
> X will be on tty7?
>
> --
> Dan
>
Because you are changing a user interface. What is going to happen when the
user switches to tty1 and nothing happens? The basic logic of putting X on
tty7 is to get it out of the way. Humans will use the lowest numbered ttys
first. Besides breaking existing documentation, including advice on various
forums, is not a good idea.
The basic logic of X starting on tty7 is because it was the first open
VT because getty is already running on tty1-6. I can show you the code
in the X server where it picks the first available VT. This is just
changing it so that X will start on tty1. What interface is that
breaking? A broken assumption that tty1 == !X?
--
Dan
9:49 a.m.
Dan Nicholson wrote:
On Tue, Oct 28, 2008 at 6:44 AM, shmuel siegel
<fedora(a)shmuelhome.mine.nu> wrote:
> Dan Nicholson wrote:
>
>> Why is it significant what tty any program runs on? Isn't the
>> assumption that getty will be on tty1 just as faulty as the assumption
>> X will be on tty7?
>>
>> --
>> Dan
>>
>>
> Because you are changing a user interface. What is going to happen when the
> user switches to tty1 and nothing happens? The basic logic of putting X on
> tty7 is to get it out of the way. Humans will use the lowest numbered ttys
> first. Besides breaking existing documentation, including advice on various
> forums, is not a good idea.
>
The basic logic of X starting on tty7 is because it was the first open
VT because getty is already running on tty1-6. I can show you the code
in the X server where it picks the first available VT. This is just
changing it so that X will start on tty1. What interface is that
breaking? A broken assumption that tty1 == !X?
--
Dan
Did you ever think that maybe, just maybe, the code did that
deliberately? Maybe someone thought that it would be a good idea for
usable consoles numbers to start at 1? Or someone thought that once
people started down a certain path with conventions, it shouldn't be
changed unless the people saw a real benefit. I don't think that it is a
broken assumption that I should know where my usable consoles are.
Forcing the user to guess where the console is is a broken interface.
Maybe this cartoon will make the point
http://www.lesher.ws/queryinterface.html.
10:08 a.m.
shmuel siegel wrote:
Dan Nicholson wrote:
> On Tue, Oct 28, 2008 at 6:44 AM, shmuel siegel
> <fedora(a)shmuelhome.mine.nu> wrote:
>
>> Dan Nicholson wrote:
>>
>>> Why is it significant what tty any program runs on? Isn't the
>>> assumption that getty will be on tty1 just as faulty as the assumption
>>> X will be on tty7?
>>>
>>> --
>>> Dan
>>>
>>>
>> Because you are changing a user interface. What is going to happen
>> when the
>> user switches to tty1 and nothing happens? The basic logic of
>> putting X on
>> tty7 is to get it out of the way. Humans will use the lowest
>> numbered ttys
>> first. Besides breaking existing documentation, including advice on
>> various
>> forums, is not a good idea.
>>
>
> The basic logic of X starting on tty7 is because it was the first open
> VT because getty is already running on tty1-6. I can show you the code
> in the X server where it picks the first available VT. This is just
> changing it so that X will start on tty1. What interface is that
> breaking? A broken assumption that tty1 == !X?
>
> --
> Dan
>
>
Did you ever think that maybe, just maybe, the code did that
deliberately? Maybe someone thought that it would be a good idea for
usable consoles numbers to start at 1? Or someone thought that once
people started down a certain path with conventions, it shouldn't be
changed unless the people saw a real benefit. I don't think that it is
a broken assumption that I should know where my usable consoles are.
Forcing the user to guess where the console is is a broken interface.
Maybe this cartoon will make the point
http://www.lesher.ws/queryinterface.html.
Just stop for a second.
Roll back from the keyboard a bit. Take a deep breath. Clear your mind
of what you were doing. Relax. Listen to the gentle whirr of your
computer, and close your eyes.
Feeling relaxed? Ok, now open your eyes, and ask yourself the following
question:
"Do I /really/ care?"
Look at the F keys on your keyboard. The whole of your gripe lies within
the space of 6 inches. Lets not have a flame war today. Lets just move
our habits 6 inches to the left and let life be good.
--CJD
10:32 a.m.
On 2008/10/28 11:08 (GMT-0400) Casey Dahlin composed:
Look at the F keys on your keyboard. The whole of your gripe lies
within
the space of 6 inches. Lets not have a flame war today. Lets just move
our habits 6 inches to the left and let life be good.
Can't do it. My Function keys are where they belong over on the left in a
column of pairs. F1 is the upper left most key on the keyboard, most easy to
find via touch.
F1 F2
F3 F4 Esc ...
F5 F6 TAB ...
F7 F8 Ctrl ...
F9 F10 Shift ...
F11 F12 Alt ...
--
"Everyone should be quick to listen, slow to speak, and
slow to become angry." James 1:19 NIV
Team OS/2 ** Reg. Linux User #211409
Felix Miata *** http://fm.no-ip.com/
10:33 a.m.
Casey Dahlin wrote:
Just stop for a second.
Roll back from the keyboard a bit. Take a deep breath. Clear your mind
of what you were doing. Relax. Listen to the gentle whirr of your
computer, and close your eyes.
Feeling relaxed? Ok, now open your eyes, and ask yourself the
following question:
"Do I /really/ care?"
Yes!
Look at the F keys on your keyboard. The whole of your gripe lies
within the space of 6 inches. Lets not have a flame war today.
Actually, you try to start just now...
Lets just move our habits 6 inches
Nope. Lets preserve our habits. This habits costs nothing for Joe Users
(who use X only).
to the left and let life be good.
Why your life should be good, but my life not? </rhetoric>
I agree, that sometimes changes are incompatible. But in this case
exactly, we can preserve compatibility with some amount of old users.
~buc
12:38 p.m.
On Tue, 2008-10-28 at 18:33 +0300, Dmitry Butskoy wrote:
Casey Dahlin wrote:
> Just stop for a second.
>
> Roll back from the keyboard a bit. Take a deep breath. Clear your mind
> of what you were doing. Relax. Listen to the gentle whirr of your
> computer, and close your eyes.
>
> Feeling relaxed? Ok, now open your eyes, and ask yourself the
> following question:
>
> "Do I /really/ care?"
Yes!
YHBT, HAND.
10:44 a.m.
On Tue, Oct 28, 2008 at 11:08:03AM -0400, Casey Dahlin wrote:
"Do I /really/ care?"
Look at the F keys on your keyboard. The whole of your gripe lies within
the space of 6 inches. Lets not have a flame war today. Lets just move
our habits 6 inches to the left and let life be good.
6 inches to the left is the phone.
Yes, I care. The self-declared "desktop" guys, which for most of them
don't seem to have met a user in their life, have decided a while ago
that whoever doesn't fit their imaginary use case is irrelevant and
can be ignored. 10+ years old conventions and habits are unimportant
and can be ignored if it gives them less work to do what they want to
have. This is just one more in a series.
Meanwhile, Ubuntu runs rings around Fedora when it comes to popularity
for the desktop, and the server experience grows increasingly worse.
And joy is to be had for all.
OG.
11 a.m.
On Tue, 2008-10-28 at 16:44 +0100, Olivier Galibert wrote:
On Tue, Oct 28, 2008 at 11:08:03AM -0400, Casey Dahlin wrote:
> "Do I /really/ care?"
>
> Look at the F keys on your keyboard. The whole of your gripe lies within
> the space of 6 inches. Lets not have a flame war today. Lets just move
> our habits 6 inches to the left and let life be good.
6 inches to the left is the phone.
Yes, I care. The self-declared "desktop" guys, which for most of them
don't seem to have met a user in their life, have decided a while ago
that whoever doesn't fit their imaginary use case is irrelevant and
can be ignored. 10+ years old conventions and habits are unimportant
and can be ignored if it gives them less work to do what they want to
have. This is just one more in a series.
Meanwhile, Ubuntu runs rings around Fedora when it comes to popularity
for the desktop, and the server experience grows increasingly worse.
Partly because they make hard decisions and ignore certain segments of
the Linux user-base to produce well-polished, easy-to-use distribution.
Ubuntu enabled NetworkManager way before we did so in Fedora. I
personally wouldn't have done that as early as they did (and I didn't
push for it in Fedora for that reason), and doing so didn't work for
some of Ubuntu's users. But they kept it on anyway because for most of
their target audience, it improved their lives. Otherwise they would
have turned it off years ago.
Were there Ubuntu users who were pissed off that arcane kernel boot
messages were covered up by a pretty bootsplash? Did they get angry and
go away?
Ubuntu is Ubuntu precisely because of the controversial choices that the
people driving the distribution made. Is their popularity the result of
the "correctness" of any of these hard choices? Maybe.
Dan
11:15 a.m.
On Tue, 2008-10-28 at 12:00 -0400, Dan Williams wrote:
On Tue, 2008-10-28 at 16:44 +0100, Olivier Galibert wrote:
> On Tue, Oct 28, 2008 at 11:08:03AM -0400, Casey Dahlin wrote:
> > "Do I /really/ care?"
> >
> > Look at the F keys on your keyboard. The whole of your gripe lies within
> > the space of 6 inches. Lets not have a flame war today. Lets just move
> > our habits 6 inches to the left and let life be good.
>
> 6 inches to the left is the phone.
>
> Yes, I care. The self-declared "desktop" guys, which for most of them
> don't seem to have met a user in their life, have decided a while ago
> that whoever doesn't fit their imaginary use case is irrelevant and
> can be ignored. 10+ years old conventions and habits are unimportant
> and can be ignored if it gives them less work to do what they want to
> have. This is just one more in a series.
>
> Meanwhile, Ubuntu runs rings around Fedora when it comes to popularity
> for the desktop, and the server experience grows increasingly worse.
Partly because they make hard decisions and ignore certain segments of
the Linux user-base to produce well-polished, easy-to-use distribution.
I strongestly disagree - These people are unable to comprehend how they
are running down Fedora and prefer pushing around users.
Ubuntu enabled NetworkManager way before we did so in Fedora.
Well chosen example: Ubuntu had been so stupid to adopt an immature
tool aiming at single-user/single-seat laptop users, first.
One reason for why I am not using Ubuntu.
I
personally wouldn't have done that as early as they did (and I didn't
push for it in Fedora for that reason), and doing so didn't work for
some of Ubuntu's users. But they kept it on anyway because for most of
their target audience, it improved their lives. Otherwise they would
have turned it off years ago.
Were there Ubuntu users who were pissed off that arcane kernel boot
messages were covered up by a pretty bootsplash? Did they get angry and
go away?
Ubuntu is Ubuntu precisely because of the controversial choices that the
people driving the distribution made. Is their popularity the result of
the "correctness" of any of these hard choices? Maybe.
Ask yourselves
why we are not NOT using Ubuntu - If people wanted Fedora
to be Ubuntu, we weren't using Fedora.
Ralf
11:38 a.m.
On Tue, 2008-10-28 at 17:15 +0100, Ralf Corsepius wrote:
On Tue, 2008-10-28 at 12:00 -0400, Dan Williams wrote:
> On Tue, 2008-10-28 at 16:44 +0100, Olivier Galibert wrote:
> > On Tue, Oct 28, 2008 at 11:08:03AM -0400, Casey Dahlin wrote:
> > > "Do I /really/ care?"
> > >
> > > Look at the F keys on your keyboard. The whole of your gripe lies within
> > > the space of 6 inches. Lets not have a flame war today. Lets just move
> > > our habits 6 inches to the left and let life be good.
> >
> > 6 inches to the left is the phone.
> >
> > Yes, I care. The self-declared "desktop" guys, which for most of
them
> > don't seem to have met a user in their life, have decided a while ago
> > that whoever doesn't fit their imaginary use case is irrelevant and
> > can be ignored. 10+ years old conventions and habits are unimportant
> > and can be ignored if it gives them less work to do what they want to
> > have. This is just one more in a series.
> >
> > Meanwhile, Ubuntu runs rings around Fedora when it comes to popularity
> > for the desktop, and the server experience grows increasingly worse.
>
> Partly because they make hard decisions and ignore certain segments of
> the Linux user-base to produce well-polished, easy-to-use distribution.
I strongestly disagree - These people are unable to comprehend how they
are running down Fedora and prefer pushing around users.
> Ubuntu enabled NetworkManager way before we did so in Fedora.
Well chosen example: Ubuntu had been so stupid to adopt an immature
tool aiming at single-user/single-seat laptop users, first.
One reason for why I am not using Ubuntu.
> I
> personally wouldn't have done that as early as they did (and I didn't
> push for it in Fedora for that reason), and doing so didn't work for
> some of Ubuntu's users. But they kept it on anyway because for most of
> their target audience, it improved their lives. Otherwise they would
> have turned it off years ago.
>
> Were there Ubuntu users who were pissed off that arcane kernel boot
> messages were covered up by a pretty bootsplash? Did they get angry and
> go away?
>
> Ubuntu is Ubuntu precisely because of the controversial choices that the
> people driving the distribution made. Is their popularity the result of
> the "correctness" of any of these hard choices? Maybe.
Ask yourselves why we are not NOT using Ubuntu - If people wanted Fedora
Because they compromise free software in a short-sighted manner by
recommending and including proprietary illegally-distributed codecs and
bundled binary drivers (or ndiswrapper) and because they don't
contribute much back to the community?
I don't particularly care where my VTs are at. I learn and adapt,
otherwise I'd still be using WordStar or PFWrite or some other crappy
DOS application for writing documents, and WinSOCK for my SLIP dialup at
9600bps.
Dan
3:22 p.m.
Olivier Galibert (galibert(a)pobox.com) said:
> Look at the F keys on your keyboard. The whole of your gripe
lies within
> the space of 6 inches. Lets not have a flame war today. Lets just move
> our habits 6 inches to the left and let life be good.
6 inches to the left is the phone.
Yes, I care. The self-declared "desktop" guys, which for most of them
don't seem to have met a user in their life, have decided a while ago
that whoever doesn't fit their imaginary use case is irrelevant and
can be ignored.
Don't worry, they're coming for your spouses and children next! Seriously,
I'm not sure how this sort of statement provides useful context to the
discussion.
1) Reducing the amount of flicker and useless mode switching on startup
is definitely a good thing
2) From a logical standpoint, the first tty should be for the most important
user interaction. If you're booting in text mode, that's a getty. If
you're booting with a GUI login... that's the GUI.
Bill
3:35 p.m.
Bill Nottingham wrote:
1) Reducing the amount of flicker and useless mode switching on
startup
is definitely a good thing
2) From a logical standpoint, the first tty should be for the most important
user interaction. If you're booting in text mode, that's a getty. If
you're booting with a GUI login... that's the GUI.
Bill
We disagree on the second point. I don't see where the GUI login cares
which tty is being used. But humans switching to console mode do want to
know which parameter to use.
4:07 p.m.
On Tue October 28 2008, Bill Nottingham wrote:
2) From a logical standpoint, the first tty should be for the most
important user interaction. If you're booting in text mode, that's a getty.
If you're booting with a GUI login... that's the GUI.
But this does not work if someone firsts boots into text mode and then starts
the GUI, either via startx or switching the runlevel. I doubt that someone
starts the GUI from the TUI without the intent to use the GUI afterwards. The
logic does also not work if someone wants to use any other tty than the
current one, because the one the user switches to will always become the one
used for the most important user interaction. ;-)
Regards,
Till
11:01 a.m.
Op dinsdag 28-10-2008 om 11:08 uur [tijdzone -0400], schreef Casey
Dahlin:
"Do I /really/ care?"
In some other open-source projects I'm involved in we are used to answer
this question with: 'So you guarantee that you will answer all users
with the question where their text-console went to? We can assign all
bug-reports that 'Linux crashed' to you, because X is not responsive
anymore and people can not switch to their beloved console at tty1? And
you will tell all reviewers which will complain this that it saves you
some flicker during boot?'
In that case I don't care. But in the case that this will be used
against Fedora, I do care. But then again, I said it, it's your problem
now.
Maybe it's something to note in the release notes, though. Or add it to
some FAQ.
Joost
12:01 p.m.
Joost van der Sluis wrote:
Op dinsdag 28-10-2008 om 11:08 uur [tijdzone -0400], schreef Casey
Dahlin:
> "Do I /really/ care?"
>
In some other open-source projects I'm involved in we are used to answer
this question with: 'So you guarantee that you will answer all users
with the question where their text-console went to? We can assign all
bug-reports that 'Linux crashed' to you, because X is not responsive
anymore and people can not switch to their beloved console at tty1? And
you will tell all reviewers which will complain this that it saves you
some flicker during boot?'
Gladly. Send 'em my way.
--CJD
10:24 a.m.
On Tue, Oct 28, 2008 at 04:49:33PM +0200, shmuel siegel wrote:
Did you ever think that maybe, just maybe, the code did that
deliberately? Maybe someone thought that it would be a good idea for
usable consoles numbers to start at 1? Or someone thought that once
people started down a certain path with conventions, it shouldn't be
changed unless the people saw a real benefit.
Haven't you heard? If you're not a graphical-only desktop-type single
user working on a laptop, you're not relevant.
OG.
10:39 a.m.
On Tue, 2008-10-28 at 16:24 +0100, Olivier Galibert wrote:
On Tue, Oct 28, 2008 at 04:49:33PM +0200, shmuel siegel wrote:
> Did you ever think that maybe, just maybe, the code did that
> deliberately? Maybe someone thought that it would be a good idea for
> usable consoles numbers to start at 1? Or someone thought that once
> people started down a certain path with conventions, it shouldn't be
> changed unless the people saw a real benefit.
Haven't you heard? If you're not a graphical-only desktop-type single
user working on a laptop, you're not relevant.
Exactly - nothing much to add.
Time to evaluate other distros.
11:06 a.m.
On Tue, Oct 28, 2008 at 8:39 AM, Ralf Corsepius <rc040203(a)freenet.de> wrote:
On Tue, 2008-10-28 at 16:24 +0100, Olivier Galibert wrote:
> On Tue, Oct 28, 2008 at 04:49:33PM +0200, shmuel siegel wrote:
> > Did you ever think that maybe, just maybe, the code did that
> > deliberately? Maybe someone thought that it would be a good idea for
> > usable consoles numbers to start at 1? Or someone thought that once
> > people started down a certain path with conventions, it shouldn't be
> > changed unless the people saw a real benefit.
>
> Haven't you heard? If you're not a graphical-only desktop-type single
> user working on a laptop, you're not relevant.
Exactly - nothing much to add.
Time to evaluate other distros.
I can think of better reasons to switch distros other than what tty X is run
on.
Let's keep this thread going, lots of great entertainment value!
11:19 a.m.
On Tue, 2008-10-28 at 09:06 -0700, Christopher Stone wrote:
On Tue, Oct 28, 2008 at 8:39 AM, Ralf Corsepius
<rc040203(a)freenet.de>
wrote:
On Tue, 2008-10-28 at 16:24 +0100, Olivier Galibert wrote:
> On Tue, Oct 28, 2008 at 04:49:33PM +0200, shmuel siegel
wrote:
> > Did you ever think that maybe, just maybe, the code did
that
> > deliberately? Maybe someone thought that it would be a
good idea for
> > usable consoles numbers to start at 1? Or someone thought
that once
> > people started down a certain path with conventions, it
shouldn't be
> > changed unless the people saw a real benefit.
>
> Haven't you heard? If you're not a graphical-only
desktop-type single
> user working on a laptop, you're not relevant.
Exactly - nothing much to add.
Time to evaluate other distros.
I can think of better reasons to switch distros other than what tty X
is run on.
True, but it's one brick in a lengthy series of stupid and silly
decisions, which have been gradually running down Fedora into this
single-user windows clone it has evolved into.
Let's keep this thread going, lots of great entertainment value!
Right, the "great RH tyrants who are finally showing up!" :)
11:30 a.m.
On Tue, Oct 28, 2008 at 9:19 AM, Ralf Corsepius <rc040203(a)freenet.de> wrote:
On Tue, 2008-10-28 at 09:06 -0700, Christopher Stone wrote:
> On Tue, Oct 28, 2008 at 8:39 AM, Ralf Corsepius <rc040203(a)freenet.de>
> wrote:
> On Tue, 2008-10-28 at 16:24 +0100, Olivier Galibert wrote:
> > On Tue, Oct 28, 2008 at 04:49:33PM +0200, shmuel siegel
> wrote:
> > > Did you ever think that maybe, just maybe, the code did
> that
> > > deliberately? Maybe someone thought that it would be a
> good idea for
> > > usable consoles numbers to start at 1? Or someone thought
> that once
> > > people started down a certain path with conventions, it
> shouldn't be
> > > changed unless the people saw a real benefit.
> >
> > Haven't you heard? If you're not a graphical-only
> desktop-type single
> > user working on a laptop, you're not relevant.
>
> Exactly - nothing much to add.
>
> Time to evaluate other distros.
>
>
>
> I can think of better reasons to switch distros other than what tty X
> is run on.
True, but it's one brick in a lengthy series of stupid and silly
decisions, which have been gradually running down Fedora into this
single-user windows clone it has evolved into.
I'm not sure why you think it is stupid and silly. Perhaps I have not read
this tread closely enough. I personally think it is totally irrelevant and
I could care less if X is run on tty1, tty7 or tty4 for that matter.
Is there some technical reason to keep X on tty7 other than "that's the way
it has always been"?
I don't see how tty7 or tty1 makes any difference to a desktop user, or a
server user, or a newbie or an expert.
Linux has evolved away from many anachronistic traditions of Unix, I don't
see how this is any different.
11:48 a.m.
Christopher Stone píše v Út 28. 10. 2008 v 09:30 -0700:
On Tue, Oct 28, 2008 at 9:19 AM, Ralf Corsepius
<rc040203(a)freenet.de>
wrote:
On Tue, 2008-10-28 at 09:06 -0700, Christopher Stone wrote:
> On Tue, Oct 28, 2008 at 8:39 AM, Ralf Corsepius
<rc040203(a)freenet.de>
> wrote:
> On Tue, 2008-10-28 at 16:24 +0100, Olivier Galibert
wrote:
> > On Tue, Oct 28, 2008 at 04:49:33PM +0200, shmuel
siegel
> wrote:
> > > Did you ever think that maybe, just maybe, the
code did
> that
> > > deliberately? Maybe someone thought that it
would be a
> good idea for
> > > usable consoles numbers to start at 1? Or
someone thought
> that once
> > > people started down a certain path with
conventions, it
> shouldn't be
> > > changed unless the people saw a real benefit.
> >
> > Haven't you heard? If you're not a graphical-only
> desktop-type single
> > user working on a laptop, you're not relevant.
>
> Exactly - nothing much to add.
>
> Time to evaluate other distros.
>
>
>
> I can think of better reasons to switch distros other than
what tty X
> is run on.
True, but it's one brick in a lengthy series of stupid and
silly
decisions, which have been gradually running down Fedora into
this
single-user windows clone it has evolved into.
I'm not sure why you think it is stupid and silly. Perhaps I have not
read this tread closely enough. I personally think it is totally
irrelevant and I could care less if X is run on tty1, tty7 or tty4 for
that matter.
Is there some technical reason to keep X on tty7 other than "that's
the way it has always been"?
Maybe because you want to switch to the first vt with Ctrl-Alt-F1 and
not Ctrl-Alt-F2?
I don't see how tty7 or tty1 makes any difference to a desktop user,
or a server user, or a newbie or an expert.
Linux has evolved away from many anachronistic traditions of Unix,
I
don't see how this is any different.
Dan
12:09 p.m.
Christopher Stone wrote:
I don't see how tty7 or tty1 makes any difference to a desktop user,
or a server user, or a newbie or an expert.
It makes a difference for "old" user.
Some old age users (35+) began when the desktop was poor and monitors
were bad. Very often they started on a serial "dumb" tty (like vt100),
and use Vi to type their programs and cmdline for everything else.
For the same reason, why you cannot cause your grandmother to love
modern club music (she still prefer classic or rock-n-roll), the old
Linux users still prefer (yes, it is so!) to use Linux consoles. Someone
use it rarely, someone every day.
Certainly it is impossible to not use GUI now, and surely they use GUI.
But because of it habits, they switch to consoles often enough. In other
words, they do Ctrl-Alt-Fn to go to a console, and Alt-F7 to go to X.
And they press this keys every day every hour.
When you go to change tty7 to tty1, you cause them to change their
habits from Ctrl-ALt-F1/Alt-F7 to Ctlr-Alt-F2/Alt-F1. It is not good.
Why? Try to cause your grandmother to listen modern music, she will
answer you...
Please note, that Linux (and Fedora) is not for "young people" only. It
is for "all the people". Not for "young enthusiasts", there are a lot
of
"already not young" enthusiasts. The community consisting only from
young men, is impractical in the real serious world...
~buc
12:20 p.m.
I've been quietly lurking for ages now, but this is really too much.
So the argument is "you can't teach and old dog new tricks"?
I am an "old" user by this definition (though I prefer emacs to vi) and
I don't see any problems with this at all. It looks substantially nicer
than it did before (Kudos to everyone involved with this) and would
appear to the newer-to-linux set.
It also brings a vast improvement for me: when the x server restarts my
monitor takes a bit to resync ... causing a delay of 1+ seconds on each
restart before the picture is usable.
Hitting alt-f2 isn't any harder than hitting alt-f1, and if you've got X
as you're primary display (via runlevel 5) then I'd argue that X _is_
the first virtual console.
My only complaint is that I'd like to be able to set a console to 80x25
but I haven't figured out how to do that yet.
Brian
On Tue, 2008-10-28 at 20:09 +0300, Dmitry Butskoy wrote:
Christopher Stone wrote:
>
> I don't see how tty7 or tty1 makes any difference to a desktop user,
> or a server user, or a newbie or an expert.
It makes a difference for "old" user.
Some old age users (35+) began when the desktop was poor and monitors
were bad. Very often they started on a serial "dumb" tty (like vt100),
and use Vi to type their programs and cmdline for everything else.
For the same reason, why you cannot cause your grandmother to love
modern club music (she still prefer classic or rock-n-roll), the old
Linux users still prefer (yes, it is so!) to use Linux consoles. Someone
use it rarely, someone every day.
Certainly it is impossible to not use GUI now, and surely they use GUI.
But because of it habits, they switch to consoles often enough. In other
words, they do Ctrl-Alt-Fn to go to a console, and Alt-F7 to go to X.
And they press this keys every day every hour.
When you go to change tty7 to tty1, you cause them to change their
habits from Ctrl-ALt-F1/Alt-F7 to Ctlr-Alt-F2/Alt-F1. It is not good.
Why? Try to cause your grandmother to listen modern music, she will
answer you...
Please note, that Linux (and Fedora) is not for "young people" only. It
is for "all the people". Not for "young enthusiasts", there are a lot
of
"already not young" enthusiasts. The community consisting only from
young men, is impractical in the real serious world...
~buc
12:34 p.m.
On Tue, Oct 28, 2008 at 10:20 AM, Brian Wheeler <bdwheele(a)indiana.edu>wrote:
My only complaint is that I'd like to be able to set a console to
80x25
but I haven't figured out how to do that yet.
See /usr/share/doc/kernel-doc-2.6.26/Documentation/svga.txt in the
kernel-doc package.
12:36 p.m.
On Tue, 2008-10-28 at 10:34 -0700, Christopher Stone wrote:
On Tue, Oct 28, 2008 at 10:20 AM, Brian Wheeler
<bdwheele(a)indiana.edu>
wrote:
My only complaint is that I'd like to be able to set a console
to 80x25
but I haven't figured out how to do that yet.
See /usr/share/doc/kernel-doc-2.6.26/Documentation/svga.txt in the
kernel-doc package.
Thanks, I'll check it out!
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
12:36 p.m.
On Tue, 2008-10-28 at 13:20 -0400, Brian Wheeler wrote:
It also brings a vast improvement for me: when the x server restarts
my
monitor takes a bit to resync ... causing a delay of 1+ seconds on each
restart before the picture is usable.
My monitor takes 3 seconds to resync. So with the old 3 switches, that's
a full 12 seconds of black screen...
12:15 p.m.
Ralf Corsepius wrote:
On Tue, 2008-10-28 at 09:06 -0700, Christopher Stone wrote:
> On Tue, Oct 28, 2008 at 8:39 AM, Ralf Corsepius <rc040203(a)freenet.de>
> wrote:
> On Tue, 2008-10-28 at 16:24 +0100, Olivier Galibert wrote:
> > On Tue, Oct 28, 2008 at 04:49:33PM +0200, shmuel siegel
> wrote:
> > > Did you ever think that maybe, just maybe, the code did
> that
> > > deliberately? Maybe someone thought that it would be a
> good idea for
> > > usable consoles numbers to start at 1? Or someone thought
> that once
> > > people started down a certain path with conventions, it
> shouldn't be
> > > changed unless the people saw a real benefit.
> >
> > Haven't you heard? If you're not a graphical-only
> desktop-type single
> > user working on a laptop, you're not relevant.
>
> Exactly - nothing much to add.
>
> Time to evaluate other distros.
>
>
>
> I can think of better reasons to switch distros other than what tty X
> is run on.
>
True, but it's one brick in a lengthy series of stupid and silly
decisions, which have been gradually running down Fedora into this
single-user windows clone it has evolved into.
Are you serious? Really? You must have a very tenuous grasp of OS internals.
Who does this affect?
1) People using the console a lot who also run X (remember, runlevel 3
hasn't changed). Desktop users don't use consoles, server users don't
use X (I hope). Only a few species of geek remain.
2) People recovering from X crashes. Bugs. Errors. Things we could be
fixing and making not happen rather than accommodating this bizzare F1
fetish.
--CJD
12:30 p.m.
On Tue, 2008-10-28 at 13:15 -0400, Casey Dahlin wrote:
2) People recovering from X crashes. Bugs. Errors. Things we could be
fixing and making not happen rather than accommodating this bizzare F1
fetish.
Are we not running at least one getty on VT2 when X is running? Making
it harder to log in to the box when X crashes (hope you have another
machine to SSH in with...) just makes it harder to fix X bugs. If not,
this scenario seems moot to me.
12:37 p.m.
2008/10/28 Callum Lerwick <seg(a)haxxed.com>:
On Tue, 2008-10-28 at 13:15 -0400, Casey Dahlin wrote:
> 2) People recovering from X crashes. Bugs. Errors. Things we could be
> fixing and making not happen rather than accommodating this bizzare F1
> fetish.
Are we not running at least one getty on VT2 when X is running? Making
it harder to log in to the box when X crashes (hope you have another
machine to SSH in with...) just makes it harder to fix X bugs. If not,
this scenario seems moot to me.
Yes tty2-6 still have getty on them just like they always have.
--
Dan
12:38 p.m.
On Tue, 2008-10-28 at 13:15 -0400, Casey Dahlin wrote:
Ralf Corsepius wrote:
> On Tue, 2008-10-28 at 09:06 -0700, Christopher Stone wrote:
>
>> On Tue, Oct 28, 2008 at 8:39 AM, Ralf Corsepius <rc040203(a)freenet.de>
>> wrote:
>> On Tue, 2008-10-28 at 16:24 +0100, Olivier Galibert wrote:
>> > On Tue, Oct 28, 2008 at 04:49:33PM +0200, shmuel siegel
>> wrote:
>> > > Did you ever think that maybe, just maybe, the code did
>> that
>> > > deliberately? Maybe someone thought that it would be a
>> good idea for
>> > > usable consoles numbers to start at 1? Or someone thought
>> that once
>> > > people started down a certain path with conventions, it
>> shouldn't be
>> > > changed unless the people saw a real benefit.
>> >
>> > Haven't you heard? If you're not a graphical-only
>> desktop-type single
>> > user working on a laptop, you're not relevant.
>>
>> Exactly - nothing much to add.
>>
>> Time to evaluate other distros.
>>
>>
>>
>> I can think of better reasons to switch distros other than what tty X
>> is run on.
>>
> True, but it's one brick in a lengthy series of stupid and silly
> decisions, which have been gradually running down Fedora into this
> single-user windows clone it has evolved into.
>
>
Are you serious? Really?
Yes, I am.
You must have a very tenuous grasp of OS internals.
Who does this affect?
E.g. application devs, documentation writers, experienced
users.
The only party to which this change doesn't make a difference is total
newcomers.
1) People using the console a lot who also run X (remember, runlevel
3
hasn't changed).
That's my standard use case, because I do need X11 running
most of the
time on my machines. I log into them on consoles and launch a desktop
via startx, when I need it.
Desktop users don't use consoles, server users don't
use X (I hope). Only a few species of geek remain.
Not true. Most "Win
converts" (I prefer them call them Win-kiddies) are
working on "personal machines" and are running X11-Desktops.
For other users (feel free to call them them "geeks", X11/gdm etc. are
just avoidable ballast.
2) People recovering from X crashes. Bugs. Errors. Things we could be
fixing and making not happen rather than accommodating this bizzare F1
fetish.
Once more, your "F1 fetish" to me is a silly, avoidable change, whose
only feature it is to break documentations, habits and to add further
hassle. A completely superfluous change.
12:54 p.m.
On Tue, 2008-10-28 at 18:38 +0100, Ralf Corsepius wrote:
Once more, your "F1 fetish" to me is a silly, avoidable change, whose
only feature it is to break documentations, habits and to add further
hassle. A completely superfluous change.
As noted multiple times on this thread, the change prevents the
multi-second monitor refresh issues when mode is changed by vt switches.
We can save people 3+ seconds in their boot up to usability time which
is no small feat.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
1:04 p.m.
Jesse Keating wrote:
On Tue, 2008-10-28 at 18:38 +0100, Ralf Corsepius wrote:
> Once more, your "F1 fetish" to me is a silly, avoidable change, whose
> only feature it is to break documentations, habits and to add further
> hassle. A completely superfluous change.
>
As noted multiple times on this thread, the change prevents the
multi-second monitor refresh issues when mode is changed by vt switches.
We can save people 3+ seconds in their boot up to usability time which
is no small feat.
There were also many alternatives mentioned in this thread. And reasons
were given as to why this change is a bad idea. I haven't seen any
response to the alternatives. The typical response to the objections
were either "don't start a flame war" or "who cares about your use
case". Is feedback wanted?
1:29 p.m.
On Tue, 2008-10-28 at 20:04 +0200, shmuel siegel wrote:
There were also many alternatives mentioned in this thread. And
reasons
were given as to why this change is a bad idea. I haven't seen any
response to the alternatives. The typical response to the objections
were either "don't start a flame war" or "who cares about your use
case". Is feedback wanted?
well this thread has gone pretty out of control, so any chance of
getting the people who were actually doing the work to look in on it is
probably not going to happen.
A more technical discussion, posed to the people who were making the
changes could perhaps result in a discussion about why the alternatives
either won't work, or weren't considered.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
1:38 p.m.
Jesse Keating wrote:
well this thread has gone pretty out of control,
We agree on
this.
so any chance of
getting the people who were actually doing the work to look in on it is
probably not going to happen.
A more technical discussion, posed to the people who were making the
changes could perhaps result in a discussion about why the alternatives
either won't work, or weren't considered.
So who should we talk to?
1:44 p.m.
On Tue, 2008-10-28 at 20:38 +0200, shmuel siegel wrote:
So who should we talk to?
This was a change driven by the Fedora Desktop team, who can be find on
the mailing list
https://www.redhat.com/mailman/listinfo/fedora-desktop-list or in
gimpnet IRC
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
5:38 p.m.
On Tue, 2008-10-28 at 11:29 -0700, Jesse Keating wrote:
On Tue, 2008-10-28 at 20:04 +0200, shmuel siegel wrote:
> There were also many alternatives mentioned in this thread. And reasons
> were given as to why this change is a bad idea. I haven't seen any
> response to the alternatives. The typical response to the objections
> were either "don't start a flame war" or "who cares about your
use
> case". Is feedback wanted?
well this thread has gone pretty out of control, so any chance of
getting the people who were actually doing the work to look in on it is
probably not going to happen.
Understood, the almighty RHs knows better, the
community is dumb :(
A more technical discussion, posed to the people who were making the
changes could perhaps result in a discussion about why the alternatives
either won't work, or weren't considered.
The point is: To you, your claimed 3 seconds bootup speed up is a great
achievement. To me, this "achievement" is negligible.
To me, the fact of X11 going to F1 is a usability regression.
5:43 p.m.
On Tuesday 28 October 2008 03:38:09 pm Ralf Corsepius wrote:
On Tue, 2008-10-28 at 11:29 -0700, Jesse Keating wrote:
> On Tue, 2008-10-28 at 20:04 +0200, shmuel siegel wrote:
> > There were also many alternatives mentioned in this thread. And reasons
> > were given as to why this change is a bad idea. I haven't seen any
> > response to the alternatives. The typical response to the objections
> > were either "don't start a flame war" or "who cares about
your use
> > case". Is feedback wanted?
>
> well this thread has gone pretty out of control, so any chance of
> getting the people who were actually doing the work to look in on it is
> probably not going to happen.
Understood, the almighty RHs knows better, the community is dumb :(
No, you're just complaining needlessly in this instance (and others). And I'm
not a RHer.
> A more technical discussion, posed to the people who were making
the
> changes could perhaps result in a discussion about why the alternatives
> either won't work, or weren't considered.
The point is: To you, your claimed 3 seconds bootup speed up is a great
achievement. To me, this "achievement" is negligible.
To me, the fact of X11 going to F1 is a usability regression.
And no one else cares. The worst thing about Fedora isn't all these tiny
changes, it's the huge threads of one or two people complaining about it that
happen after the change.
Regards,
--
Conrad Meyer <konrad(a)tylerc.org>
1:47 p.m.
Ralf Corsepius wrote:
On Tue, 2008-10-28 at 11:29 -0700, Jesse Keating wrote:
> On Tue, 2008-10-28 at 20:04 +0200, shmuel siegel wrote:
>
>> There were also many alternatives mentioned in this thread. And reasons
>> were given as to why this change is a bad idea. I haven't seen any
>> response to the alternatives. The typical response to the objections
>> were either "don't start a flame war" or "who cares about your
use
>> case". Is feedback wanted?
>>
> well this thread has gone pretty out of control, so any chance of
> getting the people who were actually doing the work to look in on it is
> probably not going to happen.
>
Understood, the almighty RHs knows better, the community is dumb :(
You know these kinds of conspiracy delusions are associated with some
forms of schizophrenia.
--CJD
1:08 p.m.
On Tue, 28 Oct 2008 20:04:25 +0200, shmuel siegel <fedora(a)shmuelhome.mine.nu>
wrote:
There were also many alternatives mentioned in this thread. And
reasons
were given as to why this change is a bad idea. [...]
I haven't seen a single one so far. Granted, I only skimmed the
flamewar, looking at messages to which people with clue replied.
-- Pete
1:05 p.m.
Jesse Keating wrote:
As noted multiple times on this thread, the change prevents the
multi-second monitor refresh issues when mode is changed by vt switches.
We can save people 3+ seconds in their boot up to usability time which
is no small feat.
As noted at least once, why not ask the kernel to just consider vt7 as
current *to start with*?
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
ESNR: signal to noise ratio too low (try a mailer without disclaimers)
4:57 a.m.
Jesse Keating wrote:
On Tue, 2008-10-28 at 18:38 +0100, Ralf Corsepius wrote:
> Once more, your "F1 fetish" to me is a silly, avoidable change, whose
> only feature it is to break documentations, habits and to add further
> hassle. A completely superfluous change.
As noted multiple times on this thread, the change prevents the
multi-second monitor refresh issues when mode is changed by vt switches.
The flicker / resync delay comes from the *mode switch*, not the *vt
switch*. And, no, a vt switch does *not* imply a mode switch.
The reason you'll have flicker today when switching from/to X11 is that
X11 does a mode switch when you switch from/to the terminal X11 is
running on.
I havn't played with kernel mode setting yet, but I'd expect kernel mode
setting killing that mode switch because ...
(a) you'll drive all your text consoles and the X11 screen in the
very same video mode and
(b) X11 doesn't play with video modes any more because that is the
kernels job now and
(c) the kernel knows it doesn't need to switch the video mode.
If that isn't the case you are doing something very wrong.
Make an experiment, using "poor mans kernel mode setting" aka linux
framebuffer:
(1) Grab any box next to you. F8, F9, RHEL-5, whatever,
doesn't matter, should work with any.
(2) Setup the machine to boot using vesafb: add
vga=0x314 (800x600) or vga=0x317 (1024x768) to the kernel
command line.
(3) Setup X11 to use the fbdev driver.
Reboot the machine. When it is done, switch between X11 and text
consoles. Notice the mode switch and thus the flicker is gone.
Probably you have to make plymouth draw its nice graphics on tty7
instead of tty1 to maintain the fancy cross fading effect when starting
X11 in tty7. Shouldn't be a big deal though, if plymouth does that vt
switch right after KMS entered graphics mode and before printing
anything on the screen it should went unnoticed.
cheers,
Gerd
10:55 a.m.
On Wed, 2008-10-29 at 10:57 +0100, Gerd Hoffmann wrote:
Shouldn't be a big deal though, if plymouth does that vt
switch right after KMS entered graphics mode and before printing
anything on the screen it should went unnoticed.
Good explanation, except that KMS only works for a very limited set of
ATI graphics cards, and nowhere else.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
11:20 a.m.
Jesse Keating wrote:
On Wed, 2008-10-29 at 10:57 +0100, Gerd Hoffmann wrote:
> Shouldn't be a big deal though, if plymouth does that vt
> switch right after KMS entered graphics mode and before printing
> anything on the screen it should went unnoticed.
Good explanation, except that KMS only works for a very limited set of
ATI graphics cards, and nowhere else.
But without KMS the X11 start will mode-switch and thus flicker anyway,
no matter whenever tty1 or tty7 is used, right?
cheers,
Gerd
2:01 p.m.
On Wed, 2008-10-29 at 08:55 -0700, Jesse Keating wrote:
On Wed, 2008-10-29 at 10:57 +0100, Gerd Hoffmann wrote:
> Shouldn't be a big deal though, if plymouth does that vt
> switch right after KMS entered graphics mode and before printing
> anything on the screen it should went unnoticed.
Good explanation, except that KMS only works for a very limited set of
ATI graphics cards, and nowhere else.
Jesse,
While that is the current state, it isn't the final state. The goal is
have KMS eventually work on all/nearly all cards. Don't dismiss Gerd's
suggestion based on the current state.
Dax Kelson
Guru Labs
11:09 a.m.
On Wed, 2008-10-29 at 10:57 +0100, Gerd Hoffmann wrote:
Jesse Keating wrote:
> On Tue, 2008-10-28 at 18:38 +0100, Ralf Corsepius wrote:
>> Once more, your "F1 fetish" to me is a silly, avoidable change, whose
>> only feature it is to break documentations, habits and to add further
>> hassle. A completely superfluous change.
>
> As noted multiple times on this thread, the change prevents the
> multi-second monitor refresh issues when mode is changed by vt switches.
The flicker / resync delay comes from the *mode switch*, not the *vt
switch*. And, no, a vt switch does *not* imply a mode switch.
The resync delay, yes. If there is a mode switch, then that'll take
time.
However, just plain vt switch _does_ paint the whole screen. If you're
trying to crossfade from plymouth to gdm, then you want to not clear to
black before starting X, which means you can't change vt.
- ajax
11:25 a.m.
Adam Jackson wrote:
On Wed, 2008-10-29 at 10:57 +0100, Gerd Hoffmann wrote:
> Jesse Keating wrote:
>> On Tue, 2008-10-28 at 18:38 +0100, Ralf Corsepius wrote:
>>> Once more, your "F1 fetish" to me is a silly, avoidable change,
whose
>>> only feature it is to break documentations, habits and to add further
>>> hassle. A completely superfluous change.
>> As noted multiple times on this thread, the change prevents the
>> multi-second monitor refresh issues when mode is changed by vt switches.
> The flicker / resync delay comes from the *mode switch*, not the *vt
> switch*. And, no, a vt switch does *not* imply a mode switch.
The resync delay, yes. If there is a mode switch, then that'll take
time.
However, just plain vt switch _does_ paint the whole screen. If you're
trying to crossfade from plymouth to gdm, then you want to not clear to
black before starting X, which means you can't change vt.
Read the mail again. All of it. Last paragraph suggests to run
plymouth on tty7 to keep the cross-fading effect.
thanks,
Gerd
3:52 p.m.
Gerd Hoffmann (kraxel(a)redhat.com) said:
Read the mail again. All of it. Last paragraph suggests to run
plymouth on tty7 to keep the cross-fading effect.
Which either requires disgusting kernel convolutions (as stated
before), or doing it in plymouth userspace... which still gets you
a vt switch, as ttys have been initiated at that point.
Bill
3:59 p.m.
Bill Nottingham wrote:
Gerd Hoffmann (kraxel(a)redhat.com) said:
> Read the mail again. All of it. Last paragraph suggests to run
> plymouth on tty7 to keep the cross-fading effect.
Which either requires disgusting kernel convolutions (as stated
before), or doing it in plymouth userspace... which still gets you
a vt switch, as ttys have been initiated at that point.
Do it in plymouth userspace of course (requiring a patched kernel would
be insane). Before anything is displayed on the screen, so you switch
from black tty1 to black tty7. No visible flicker, see?
cheers,
Gerd
11:11 a.m.
On Wed, Oct 29, 2008 at 10:57:14AM +0100, Gerd Hoffmann wrote:
Jesse Keating wrote:
> On Tue, 2008-10-28 at 18:38 +0100, Ralf Corsepius wrote:
>> Once more, your "F1 fetish" to me is a silly, avoidable change, whose
>> only feature it is to break documentations, habits and to add further
>> hassle. A completely superfluous change.
>
> As noted multiple times on this thread, the change prevents the
> multi-second monitor refresh issues when mode is changed by vt switches.
The flicker / resync delay comes from the *mode switch*, not the *vt
switch*. And, no, a vt switch does *not* imply a mode switch.
vt switching implies a screen repaint, which will cause a visible visual
artifact. You're correct that in the kms world that doesn't imply a mode
switch, but that's not really the point.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
4:35 p.m.
On Tue, 28 Oct 2008, Bill Nottingham wrote:
Ralf Corsepius (rc040203(a)freenet.de) said:
> > Who does this affect?
> E.g. application devs, documentation writers, experienced users.
Much like passwd auth to PAM. Heck, passwd -> shadow. twm -> fvwm
-> AnotherLevel -> GNOME.
The only thing constant is change.
One day, my homedir will not have dot files that prevent me to login X
upon upgrading :)
Paul
4:45 p.m.
On Tue, Oct 28, 2008 at 04:31:53PM -0400, Bill Nottingham wrote:
Ralf Corsepius (rc040203(a)freenet.de) said:
> > Who does this affect?
> E.g. application devs, documentation writers, experienced users.
Much like passwd auth to PAM. Heck, passwd -> shadow. twm -> fvwm
-> AnotherLevel -> GNOME.
The only thing constant is change.
Every day it's the same old thing! Variety! I wan't something
/different/! Bring me the hasenfeffer!
4:56 p.m.
Chuck Anderson wrote:
On Tue, Oct 28, 2008 at 04:31:53PM -0400, Bill Nottingham wrote:
> Ralf Corsepius (rc040203(a)freenet.de) said:
>
>>> Who does this affect?
>>>
>> E.g. application devs, documentation writers, experienced users.
>>
> Much like passwd auth to PAM. Heck, passwd -> shadow. twm -> fvwm
> -> AnotherLevel -> GNOME.
>
> The only thing constant is change.
>
Every day it's the same old thing! Variety! I wan't something
/different/! Bring me the hasenfeffer!
I have no idea what you just said.
--CJD
5:02 p.m.
On Tue, Oct 28, 2008 at 05:56:46PM -0400, Casey Dahlin wrote:
Chuck Anderson wrote:
> On Tue, Oct 28, 2008 at 04:31:53PM -0400, Bill Nottingham wrote:
>
>> Ralf Corsepius (rc040203(a)freenet.de) said:
>>>> Who does this affect?
>>>>
>>> E.g. application devs, documentation writers, experienced users.
>>>
>> Much like passwd auth to PAM. Heck, passwd -> shadow. twm -> fvwm
>> -> AnotherLevel -> GNOME.
>>
>> The only thing constant is change.
>>
>
> Every day it's the same old thing! Variety! I wan't something
> /different/! Bring me the hasenfeffer!
>
>
I have no idea what you just said.
Sorry, a little Bugs Bunny joke.
5:57 p.m.
On Tue, Oct 28, 2008 at 06:02:40PM -0400, Chuck Anderson wrote:
On Tue, Oct 28, 2008 at 05:56:46PM -0400, Casey Dahlin wrote:
> Chuck Anderson wrote:
>> On Tue, Oct 28, 2008 at 04:31:53PM -0400, Bill Nottingham wrote:
>>
>>> Ralf Corsepius (rc040203(a)freenet.de) said:
>>>>> Who does this affect?
>>>>>
>>>> E.g. application devs, documentation writers, experienced users.
>>>>
>>> Much like passwd auth to PAM. Heck, passwd -> shadow. twm -> fvwm
>>> -> AnotherLevel -> GNOME.
>>>
>>> The only thing constant is change.
>>>
>>
>> Every day it's the same old thing! Variety! I wan't something
>> /different/! Bring me the hasenfeffer!
>>
>>
> I have no idea what you just said.
Sorry, a little Bugs Bunny joke.
Search youtube for "Shiskabugs" :-)
1:37 p.m.
Casey Dahlin wrote:
>>>
> True, but it's one brick in a lengthy series of stupid and silly
> decisions, which have been gradually running down Fedora into this
> single-user windows clone it has evolved into.
>
>
Are you serious? Really? You must have a very tenuous grasp of OS
internals.
No, every change requires extensive documentation and retraining or you
will have confused and disgruntled users.
Who does this affect?
1) People using the console a lot who also run X (remember, runlevel 3
hasn't changed). Desktop users don't use consoles, server users don't
use X (I hope). Only a few species of geek remain.
This dichotomy exists only in your imagination. Desktop users sometimes
interact with servers, server users nearly always interact with desktops.
2) People recovering from X crashes. Bugs. Errors. Things we could be
fixing and making not happen rather than accommodating this bizzare F1
fetish.
People reading documentation. Please change the behavior _after_
updating all existing documentation.
--
Les Mikesell
lesmikesell(a)gmail.com
3:06 p.m.
Les Mikesell wrote:
Casey Dahlin wrote:
> >>>
>> True, but it's one brick in a lengthy series of stupid and silly
>> decisions, which have been gradually running down Fedora into this
>> single-user windows clone it has evolved into.
>>
>>
> Are you serious? Really? You must have a very tenuous grasp of OS
> internals.
No, every change requires extensive documentation and retraining or
you will have confused and disgruntled users.
> Who does this affect?
> 1) People using the console a lot who also run X (remember, runlevel
> 3 hasn't changed). Desktop users don't use consoles, server users
> don't use X (I hope). Only a few species of geek remain.
This dichotomy exists only in your imagination. Desktop users
sometimes interact with servers, server users nearly always interact
with desktops.
The users are the same. The computers, however, are different.
> 2) People recovering from X crashes. Bugs. Errors. Things we
could be
> fixing and making not happen rather than accommodating this bizzare
> F1 fetish.
People reading documentation. Please change the behavior _after_
updating all existing documentation.
Documentation changes need to go out /at/ the time of change. Not
before, not after (though they do need to be prepared ahead of time). I
know for the documentation we control the effort will be made to keep
that up to date. There's been a recent influx of new contributors
recently that care about this area a lot and are doing their best.
For documentation we don't control, well, there will always be issues.
I should also point out that for people that know about VTs, the mental
fallback pattern probably handles this well. *Ctrl+Alt+F1* "Huh?"
*Ctrl+Alt+F1* "What the..." *Ctrl+Alt+F2* "Hmm, that's weird"
*Ctrl+Alt+F1* "Oh, ok."
--CJD
3:40 p.m.
Casey Dahlin wrote:
>> Who does this affect?
>> 1) People using the console a lot who also run X (remember, runlevel
>> 3 hasn't changed). Desktop users don't use consoles, server users
>> don't use X (I hope). Only a few species of geek remain.
>
> This dichotomy exists only in your imagination. Desktop users
> sometimes interact with servers, server users nearly always interact
> with desktops.
>
The users are the same. The computers, however, are different.
The user is the one that needs consistency.
>> 2) People recovering from X crashes. Bugs. Errors. Things we
could be
>> fixing and making not happen rather than accommodating this bizzare
>> F1 fetish.
>
> People reading documentation. Please change the behavior _after_
> updating all existing documentation.
>
Documentation changes need to go out /at/ the time of change. Not
before, not after (though they do need to be prepared ahead of time). I
know for the documentation we control the effort will be made to keep
that up to date. There's been a recent influx of new contributors
recently that care about this area a lot and are doing their best.
But you find documentation by doing a google search. How do you plan to
replace all of that, along with the memory of people who read it earlier?
For documentation we don't control, well, there will always be
issues.
I should also point out that for people that know about VTs, the mental
fallback pattern probably handles this well. *Ctrl+Alt+F1* "Huh?"
*Ctrl+Alt+F1* "What the..." *Ctrl+Alt+F2* "Hmm, that's weird"
*Ctrl+Alt+F1* "Oh, ok."
Yes, that might be a reasonable description of someone's encounter with
fedora. At least someone who is already used to the inability to stick
to a user interface. But is that the way you want people to respond to
an operating system - punch keys at random until something appears to work?
--
Les Mikesell
lesmikesell(a)gmail.com
3:48 p.m.
Les Mikesell wrote:
Casey Dahlin wrote:
>
>>> Who does this affect?
>>> 1) People using the console a lot who also run X (remember,
>>> runlevel 3 hasn't changed). Desktop users don't use consoles,
>>> server users don't use X (I hope). Only a few species of geek remain.
>>
>> This dichotomy exists only in your imagination. Desktop users
>> sometimes interact with servers, server users nearly always interact
>> with desktops.
>>
>
> The users are the same. The computers, however, are different.
The user is the one that needs consistency.
Ctrl+Alt+F1 brings up the primary user interface. Sounds consistent to me.
>>> 2) People recovering from X crashes. Bugs. Errors. Things
we could
>>> be fixing and making not happen rather than accommodating this
>>> bizzare F1 fetish.
>>
>> People reading documentation. Please change the behavior _after_
>> updating all existing documentation.
>>
> Documentation changes need to go out /at/ the time of change. Not
> before, not after (though they do need to be prepared ahead of time).
> I know for the documentation we control the effort will be made to
> keep that up to date. There's been a recent influx of new
> contributors recently that care about this area a lot and are doing
> their best.
But you find documentation by doing a google search. How do you plan
to replace all of that, along with the memory of people who read it
earlier?
You're right. Stop the release, we need to ship Red Hat 7.3 instead.
> For documentation we don't control, well, there will always
be issues.
>
> I should also point out that for people that know about VTs, the
> mental fallback pattern probably handles this well. *Ctrl+Alt+F1*
> "Huh?" *Ctrl+Alt+F1* "What the..." *Ctrl+Alt+F2* "Hmm,
that's weird"
> *Ctrl+Alt+F1* "Oh, ok."
Yes, that might be a reasonable description of someone's encounter
with fedora. At least someone who is already used to the inability to
stick to a user interface. But is that the way you want people to
respond to an operating system - punch keys at random until something
appears to work?
People have more in common with chimpanzees than you realize.
--CJD
5:37 p.m.
Casey Dahlin wrote:
>
> The user is the one that needs consistency.
>
Ctrl+Alt+F1 brings up the primary user interface. Sounds consistent to me.
It could have been, when you didn't have an existing user base.
> But you find documentation by doing a google search. How do you
plan
> to replace all of that, along with the memory of people who read it
> earlier?
>
You're right. Stop the release, we need to ship Red Hat 7.3 instead.
I'd actually like that very much, if you dropped in the security fixes
and some decent fonts. I have a couple of machines that have never
crashed since that release and one that was up for over 4 years non-stop
until I had to move it. When you can improve on that, you would have a
reason for change.
--
Les Mikesell
lesmikesell(a)gmail.com
6:10 p.m.
On Tue, 2008-10-28 at 16:06 -0400, Casey Dahlin wrote:
Les Mikesell wrote:
> Casey Dahlin wrote:
>> >>>
>>> True, but it's one brick in a lengthy series of stupid and silly
>>> decisions, which have been gradually running down Fedora into this
>>> single-user windows clone it has evolved into.
>>>
>>>
>> Are you serious? Really? You must have a very tenuous grasp of OS
>> internals.
>
> No, every change requires extensive documentation and retraining or
> you will have confused and disgruntled users.
>
>> Who does this affect?
>> 1) People using the console a lot who also run X (remember, runlevel
>> 3 hasn't changed). Desktop users don't use consoles, server users
>> don't use X (I hope). Only a few species of geek remain.
>
> This dichotomy exists only in your imagination. Desktop users
> sometimes interact with servers, server users nearly always interact
> with desktops.
I'd go one step further ...
The users are the same. The computers, however, are different.
In many cases, the user is the same, the computer is the same, but the
situations and roles of both machine and user vary.
Never attached your "netbook/laptop" to your "home desktop with the big
screen and used your "netbook/laptop" as file server?
Ralf
11:17 a.m.
Ralf Corsepius wrote:
On Tue, 2008-10-28 at 16:24 +0100, Olivier Galibert wrote:
> On Tue, Oct 28, 2008 at 04:49:33PM +0200, shmuel siegel wrote:
>
>> Did you ever think that maybe, just maybe, the code did that
>> deliberately? Maybe someone thought that it would be a good idea for
>> usable consoles numbers to start at 1? Or someone thought that once
>> people started down a certain path with conventions, it shouldn't be
>> changed unless the people saw a real benefit.
>>
> Haven't you heard? If you're not a graphical-only desktop-type single
> user working on a laptop, you're not relevant.
>
Exactly - nothing much to add.
Time to evaluate other distros.
Time to unite "good old community" people...
Unfortunately, most 10+ experienced users already have made a career,
hence they have a work, and they are busy. Too busy to start even a SIG
group. Some essential organizational efforts are necessary for obtaining
their participation...
~buc
11:45 a.m.
Dmitry Butskoy píše v Út 28. 10. 2008 v 19:17 +0300:
Ralf Corsepius wrote:
> On Tue, 2008-10-28 at 16:24 +0100, Olivier Galibert wrote:
>
>> On Tue, Oct 28, 2008 at 04:49:33PM +0200, shmuel siegel wrote:
>>
>>> Did you ever think that maybe, just maybe, the code did that
>>> deliberately? Maybe someone thought that it would be a good idea for
>>> usable consoles numbers to start at 1? Or someone thought that once
>>> people started down a certain path with conventions, it shouldn't be
>>> changed unless the people saw a real benefit.
>>>
>> Haven't you heard? If you're not a graphical-only desktop-type single
>> user working on a laptop, you're not relevant.
>>
> Exactly - nothing much to add.
>
> Time to evaluate other distros.
>
>
Time to unite "good old community" people...
Count me in :-)
Unfortunately, most 10+ experienced users already have made a career,
hence they have a work, and they are busy. Too busy to start even a SIG
group. Some essential organizational efforts are necessary for obtaining
their participation...
I cannot understand why it is so big trouble to let the old (or better
classic) behaviour be still an option, when somebody decides that his
way is the right way.
Dan
11:56 a.m.
On Tue, 2008-10-28 at 17:45 +0100, Dan Horák wrote:
Dmitry Butskoy píše v Út 28. 10. 2008 v 19:17 +0300:
> Ralf Corsepius wrote:
> > On Tue, 2008-10-28 at 16:24 +0100, Olivier Galibert wrote:
> >
> >> On Tue, Oct 28, 2008 at 04:49:33PM +0200, shmuel siegel wrote:
> >>
> >>> Did you ever think that maybe, just maybe, the code did that
> >>> deliberately? Maybe someone thought that it would be a good idea for
> >>> usable consoles numbers to start at 1? Or someone thought that once
> >>> people started down a certain path with conventions, it shouldn't
be
> >>> changed unless the people saw a real benefit.
> >>>
> >> Haven't you heard? If you're not a graphical-only desktop-type
single
> >> user working on a laptop, you're not relevant.
> >>
> > Exactly - nothing much to add.
> >
> > Time to evaluate other distros.
> >
> >
>
> Time to unite "good old community" people...
Count me in :-)
me too :-)
> Unfortunately, most 10+ experienced users already have made a
career,
> hence they have a work, and they are busy. Too busy to start even a SIG
> group. Some essential organizational efforts are necessary for obtaining
> their participation...
I cannot understand why it is so big trouble to let the old (or better
classic) behaviour be still an option, when somebody decides that his
way is the right way.
Good idea. Have a "single-user/single-seat" vs.
""multiuser" toggle in
the install ;)
Ralf
12:03 p.m.
On Tue, Oct 28, 2008 at 12:56 PM, Ralf Corsepius <rc040203(a)freenet.de> wrote:
Good idea. Have a "single-user/single-seat" vs. ""multiuser"
toggle in
the install ;)
Ralf, the desktop team has done quite a bit of work relating to
multiple user scenarios such as fast user switching, GNOME user share,
ConsoleKit building a better foundation for multiseat, etc. About the
only thing that isn't yet fully fleshed out for multiuser is
NetworkManager, but the old system of "run system-config-network"
wasn't really any better. The system settings work going on in NM
should improve things further.
3:17 p.m.
On Tuesday, 28 October 2008 at 18:03, Colin Walters wrote:
On Tue, Oct 28, 2008 at 12:56 PM, Ralf Corsepius
<rc040203(a)freenet.de> wrote:
>
> Good idea. Have a "single-user/single-seat" vs.
""multiuser" toggle in
> the install ;)
Ralf, the desktop team has done quite a bit of work relating to
multiple user scenarios such as fast user switching, GNOME user share,
ConsoleKit building a better foundation for multiseat, etc. About the
only thing that isn't yet fully fleshed out for multiuser is
NetworkManager, but the old system of "run system-config-network"
wasn't really any better. The system settings work going on in NM
should improve things further.
As long as I keep loosing my network connection upon log-out,
NetworkManager is not an option and has no place on my machines.
Regards,
R.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
3:34 p.m.
Dominik 'Rathann' Mierzejewski (dominik(a)greysector.net) said:
As long as I keep loosing my network connection upon log-out,
NetworkManager is not an option and has no place on my machines.
Right-click -> "Edit connections", pick your preferred setting,
click on 'System setting'.
(Note: Not valid for WPA, etc. That doesn't work outside of NM anyway...)
Bill
3:38 p.m.
On Tuesday, 28 October 2008 at 21:34, Bill Nottingham wrote:
Dominik 'Rathann' Mierzejewski (dominik(a)greysector.net) said:
> As long as I keep loosing my network connection upon log-out,
> NetworkManager is not an option and has no place on my machines.
Right-click -> "Edit connections", pick your preferred setting,
click on 'System setting'.
(Note: Not valid for WPA, etc. That doesn't work outside of NM anyway...)
Wrong. wpa_supplicant works just fine without NM. In fact, because of this
deficiency (and the fact that NM fails to associate with my WPA network
at work 9 out of 10 times), I'm using wpa_supplicant directly, without
NM. At least it works.
Regards,
R.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
5:04 p.m.
On Tue, 2008-10-28 at 13:03 -0400, Colin Walters wrote:
On Tue, Oct 28, 2008 at 12:56 PM, Ralf Corsepius
<rc040203(a)freenet.de> wrote:
>
> Good idea. Have a "single-user/single-seat" vs.
""multiuser" toggle in
> the install ;)
Ralf, the desktop team has done quite a bit of work relating to
multiple user scenarios such as fast user switching, GNOME user share,
ConsoleKit building a better foundation for multiseat, etc.
We will see how things
have evolved with FC10. My experiences with FC9's
desktop so far have not been "overwhelming" and my experiments with
rawhide over the last couple of weeks, haven't been much better.
About the only thing that isn't yet fully fleshed out for
multiuser is
NetworkManager,
Correct, no network profiles, no support for autofs mounted homes,
no
separation of "system-wide/user" choices, permanent issues with
gnome-keyring, SELinux, broken or unreadable dialogs, no documentation,
etc.
but the old system of "run system-config-network"
wasn't really any better.
Yes, one buggered system is being replaced with a bad
one.
The major advantage of the old "system-config-network": It at least
behaved deterministic. Using NM is like "herding a sack of fleas" as we
say in German.
The system settings work going on in NM
should improve things further.
12:04 p.m.
Ralf Corsepius wrote:
On Tue, 2008-10-28 at 17:45 +0100, Dan Horák wrote:
> Dmitry Butskoy píše v Út 28. 10. 2008 v 19:17 +0300:
>
>> Ralf Corsepius wrote:
>>
>>> On Tue, 2008-10-28 at 16:24 +0100, Olivier Galibert wrote:
>>>
>>>
>>>> On Tue, Oct 28, 2008 at 04:49:33PM +0200, shmuel siegel wrote:
>>>>
>>>>
>>>>> Did you ever think that maybe, just maybe, the code did that
>>>>> deliberately? Maybe someone thought that it would be a good idea for
>>>>> usable consoles numbers to start at 1? Or someone thought that once
>>>>> people started down a certain path with conventions, it shouldn't
be
>>>>> changed unless the people saw a real benefit.
>>>>>
>>>>>
>>>> Haven't you heard? If you're not a graphical-only desktop-type
single
>>>> user working on a laptop, you're not relevant.
>>>>
>>>>
>>> Exactly - nothing much to add.
>>>
>>> Time to evaluate other distros.
>>>
>>>
>>>
>> Time to unite "good old community" people...
>>
> Count me in :-)
>
me too :-)
>> Unfortunately, most 10+ experienced users already have made a career,
>> hence they have a work, and they are busy. Too busy to start even a SIG
>> group. Some essential organizational efforts are necessary for obtaining
>> their participation...
>>
> I cannot understand why it is so big trouble to let the old (or better
> classic) behaviour be still an option, when somebody decides that his
> way is the right way.
>
Good idea. Have a "single-user/single-seat" vs. ""multiuser"
toggle in
the install ;)
Ralf
I think that's much. Theres a 1-liner conf file change to fix it.
--CJD
11:57 a.m.
On Tue, 2008-10-28 at 17:45 +0100, Dan Horák wrote:
Dmitry Butskoy píše v Út 28. 10. 2008 v 19:17 +0300:
> Ralf Corsepius wrote:
> > On Tue, 2008-10-28 at 16:24 +0100, Olivier Galibert wrote:
> >
> >> On Tue, Oct 28, 2008 at 04:49:33PM +0200, shmuel siegel wrote:
> >>
> >>> Did you ever think that maybe, just maybe, the code did that
> >>> deliberately? Maybe someone thought that it would be a good idea for
> >>> usable consoles numbers to start at 1? Or someone thought that once
> >>> people started down a certain path with conventions, it shouldn't
be
> >>> changed unless the people saw a real benefit.
> >>>
> >> Haven't you heard? If you're not a graphical-only desktop-type
single
> >> user working on a laptop, you're not relevant.
> >>
> > Exactly - nothing much to add.
> >
> > Time to evaluate other distros.
> >
> >
>
> Time to unite "good old community" people...
Count me in :-)
>
> Unfortunately, most 10+ experienced users already have made a career,
> hence they have a work, and they are busy. Too busy to start even a SIG
> group. Some essential organizational efforts are necessary for obtaining
> their participation...
I cannot understand why it is so big trouble to let the old (or better
classic) behaviour be still an option, when somebody decides that his
way is the right way.
Each additional option adds another codepath that must be tested and
maintained, another set of options that must be tested both
independently and together, and potentially another UI widget that just
clutters up dialogs. Or a config file option which must be maintained
indefinitely otherwise people will complain when it's removed. At some
point, carrying older options along becomes unsustainable versus the
resources required to add capabilities or even just fix existing bugs.
I don't know anyone that has a Zip disk any more; how much effort should
be put into developing, testing, and ensuring that Zip disks or ORB
drives work perfectly, or should people just convert over to CD/RW
instead?
Dan
9:09 a.m.
On Tue October 28 2008, Dan Nicholson wrote:
On Tue, Oct 28, 2008 at 4:40 AM, Dmitry Butskoy
<buc(a)odusz.so-cdu.ru> wrote:
> By the way, I cannot understand why gdm, when running before mingetty
> (for better startup speed), must be run on tty1 only. It seems that it
> should be possible to run it before, but cause it to use tty7.
It's not for speed, it's so there will be no VT switching when booting.
Imho then the kernel should be patched to start booting graphically using tty7
and not tty1. Then you have no switching and do not disturb text-only
machines.
Regards,
Till
3:26 p.m.
Till Maas (opensource(a)till.name) said:
Imho then the kernel should be patched to start booting graphically
using tty7
and not tty1. Then you have no switching and do not disturb text-only
machines.
Having the kernel parse its own commandline for a runlevel (a concept that has
nothing to do with the kernel, and doesn't even exist under some init systems)
and then choosing to rearrange the tty init sequence based on that?
I'll pass.
Bill
3:39 p.m.
Bill Nottingham wrote:
Till Maas (opensource(a)till.name) said:
> Imho then the kernel should be patched to start booting graphically using tty7
> and not tty1. Then you have no switching and do not disturb text-only
> machines.
>
Having the kernel parse its own commandline for a runlevel (a concept that has
nothing to do with the kernel, and doesn't even exist under some init systems)
and then choosing to rearrange the tty init sequence based on that?
I'll pass.
Bill
I don't think that's what he meant. I think he meant simply for tty7 to
always be the active tty on boot. That's a bit easier to stomach.
--CJD
3:43 p.m.
Casey Dahlin (cdahlin(a)redhat.com) said:
>> Imho then the kernel should be patched to start booting
graphically
>> using tty7 and not tty1. Then you have no switching and do not
>> disturb text-only machines.
>
> Having the kernel parse its own commandline for a runlevel (a concept that has
> nothing to do with the kernel, and doesn't even exist under some init systems)
> and then choosing to rearrange the tty init sequence based on that?
I don't think that's what he meant. I think he meant simply for tty7 to
always be the active tty on boot. That's a bit easier to stomach.
If you don't add the bits I mentioned, then you'll get a blank tty7
when you boot in text mode. Which is presumably not what you want.
Bill
3:54 p.m.
Bill Nottingham wrote:
Casey Dahlin (cdahlin(a)redhat.com) said:
>>> Imho then the kernel should be patched to start booting graphically
>>> using tty7 and not tty1. Then you have no switching and do not
>>> disturb text-only machines.
>>>
>> Having the kernel parse its own commandline for a runlevel (a concept that has
>> nothing to do with the kernel, and doesn't even exist under some init
systems)
>> and then choosing to rearrange the tty init sequence based on that?
>>
> I don't think that's what he meant. I think he meant simply for tty7 to
> always be the active tty on boot. That's a bit easier to stomach.
>
If you don't add the bits I mentioned, then you'll get a blank tty7
when you boot in text mode. Which is presumably not what you want.
Bill
We could either offer a getty on tty7 (not too hard) or we could instead
add a small API to the kernel that would allow remapping which F key
went to which tty, so you could have ctrl+alt+f1 bring up tty7. That way
we could remap things so the user got the correct behavior.
We wouldn't have to actually /do/ this, but if the API were there, we
can tell the people who care to go figure it out.
--CJD
5:14 p.m.
Bill Nottingham wrote:
Casey Dahlin said:
> I don't think that's what he meant. I think he meant simply for tty7 to
> always be the active tty on boot. That's a bit easier to stomach.
If you don't add the bits I mentioned, then you'll get a blank tty7
when you boot in text mode. Which is presumably not what you want.
So add an explicit switch to tty1 in runlevel 3. It shouldn't flicker
because it's not changing display modes (at least, I don't remember
flicker switching between mingetty VT's; can't check right now because
X->VGA switching doesn't work on this machine). Where's the problem?
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
ESNR: signal to noise ratio too low (try a mailer without disclaimers)
7:55 p.m.
Matthew Woehlke (mw_triad(a)users.sourceforge.net) said:
> If you don't add the bits I mentioned, then you'll get a
blank tty7
> when you boot in text mode. Which is presumably not what you want.
So add an explicit switch to tty1 in runlevel 3. It shouldn't flicker
because it's not changing display modes (at least, I don't remember
flicker switching between mingetty VT's; can't check right now because
X->VGA switching doesn't work on this machine). Where's the problem?
You're having the kernel operate on Fedora specific commandline options
to start on a completely different tty, one that could be configured
by anyone locally to do something else entirely. (Unless you do it in
userspace, which means you jump away and then jump back for text mode,
which...)
Bill
10:20 a.m.
(Please do not quote my e-mail address unobfuscated in message bodies.)
Bill Nottingham wrote:
Matthew Woehlke (ahem(a)stop.that) said:
>> If you don't add the bits I mentioned, then you'll get a blank tty7
>> when you boot in text mode. Which is presumably not what you want.
> So add an explicit switch to tty1 in runlevel 3. It shouldn't flicker
> because it's not changing display modes (at least, I don't remember
> flicker switching between mingetty VT's; can't check right now because
> X->VGA switching doesn't work on this machine). Where's the problem?
You're having the kernel operate on Fedora specific commandline options
to start on a completely different tty, one that could be configured
by anyone locally to do something else entirely. (Unless you do it in
userspace, which means you jump away and then jump back for text mode,
which...)
Aside from the obvious question if this wouldn't start out as a
Fedora-specific kernel patch, why do you assume Fedora will be the only
distro with this problem? Or is plymouth (and similar technologies)
expected to remain Fedora-only forever?
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
EPUN: program terminated due to egregious wordplay
3:48 p.m.
Matthew Woehlke (the-spambots-will-find-you(a)no.matter.what) said:
Aside from the obvious question if this wouldn't start out as a
Fedora-specific kernel patch, why do you assume Fedora will be the only
distro with this problem? Or is plymouth (and similar technologies)
expected to remain Fedora-only forever?
I'd like to think it can be used other places, yes. But flopping ttys
based on command line arguments is just *WRONG*, for the reasons stated
already.
For example, right now, the user can customize their init system so that
tty7 is a continually updating 'top'. Or Star Wars piped through libcaca.
So, to do this reliably, you'd have to somehow get 'the specifics of how
the init system is configured' into the kernel, which is getting into
ridiculous levels of convolution.
Bill
4 p.m.
On Tue October 28 2008, Casey Dahlin wrote:
Bill Nottingham wrote:
> Till Maas (opensource(a)till.name) said:
>> Imho then the kernel should be patched to start booting graphically
>> using tty7 and not tty1. Then you have no switching and do not disturb
>> text-only machines.
>
> Having the kernel parse its own commandline for a runlevel (a concept
> that has nothing to do with the kernel, and doesn't even exist under some
> init systems) and then choosing to rearrange the tty init sequence based
> on that?
>
> I'll pass.
I don't think that's what he meant. I think he meant simply
for tty7 to
always be the active tty on boot. That's a bit easier to stomach.
I meant that if rhgb is passed to the kernel, then tty7 should be the active
tty on boot and be used for the graphical display and then after booting
finished, X can be started on tty7 without a flicker. If X is not going to be
started, I guess it does not hurt to either switch to tty1 or add another
getty to tty7.
Regards,
Till
9:37 a.m.
Dan Nicholson wrote:
Why is it significant what tty any program runs on? Isn't the
assumption that getty will be on tty1 just as faulty as the assumption
X will be on tty7?
It has been that way for a *long* time. When something goes wrong I
can't fix in X11 usually hit "Ctrl-Alt-F1" to get the login prompt, like
*lots* of other people I assume. That suddenly stops working. Be
prepared for lots of people wondering where the text console is gone to.
cheers,
Gerd
12:07 p.m.
On Mon, 2008-10-27 at 17:07 -0400, Will Woods wrote:
Hi folks,
If you're running F10Beta/Rawhide, you may have noticed already, but I
wanted to make sure everyone knows this is intentional:
X HAS MOVED FROM VT7 TO VT1.
OK look. If you absolutely cannot deal with this DRASTIC change in
behavior:
1) add "start on started prefdm" to /etc/event.d/tty1
2) (GNOME) edit /etc/gdm/custom.conf and add
FirstVT=7
to the top of the file. Or:
(KDE) edit /etc/kde/kdm/kdmrc and set
ServerVTs=-7
ConsoleTTYs=tty1,tty2,tty3,tty4,tty5,tty6
3) Sigh contentedly at the restoration of your precious tradition.
If you use runlevel 3 + startx, nothing has changed.
Y'know, it took me all of 10 minutes to figure this out on my own. How
long has this thread gone on? I guess y'all have a lot of free time on
your hands? Because, hey, we've got this release coming out soon - maybe
you could help test it or something?
Just a thought.
-w
p.s.:
https://bugzilla.redhat.com/showdependencytree.cgi?id=F10Preview
https://bugzilla.redhat.com/showdependencytree.cgi?id=F10Blocker
https://bugzilla.redhat.com/showdependencytree.cgi?id=F10Target
12:14 p.m.
Will Woods wrote:
1) add "start on started prefdm" to /etc/event.d/tty1
2) (GNOME) edit /etc/gdm/custom.conf and add
FirstVT=7
to the top of the file. Or:
(KDE) edit /etc/kde/kdm/kdmrc and set
ServerVTs=-7
ConsoleTTYs=tty1,tty2,tty3,tty4,tty5,tty6
Could it be mentioned in ReleaseNotes?
~buc
6:23 a.m.
Dmitry Butskoy wrote:
Will Woods wrote:
>
> 1) add "start on started prefdm" to /etc/event.d/tty1
> 2) (GNOME) edit /etc/gdm/custom.conf and add
> FirstVT=7
> to the top of the file. Or:
> (KDE) edit /etc/kde/kdm/kdmrc and set
> ServerVTs=-7
> ConsoleTTYs=tty1,tty2,tty3,tty4,tty5,tty6
>
Could it be mentioned in ReleaseNotes?
Yes, Join the docs project. It only takes a couple of minutes to sign up
and edit the wiki.
http://fedoraproject.org/wiki/DocsProject/ReleaseNotes/Process
Rahul
12:17 p.m.
Will Woods píše v Út 28. 10. 2008 v 13:07 -0400:
On Mon, 2008-10-27 at 17:07 -0400, Will Woods wrote:
> Hi folks,
>
> If you're running F10Beta/Rawhide, you may have noticed already, but I
> wanted to make sure everyone knows this is intentional:
>
> X HAS MOVED FROM VT7 TO VT1.
OK look. If you absolutely cannot deal with this DRASTIC change in
behavior:
1) add "start on started prefdm" to /etc/event.d/tty1
2) (GNOME) edit /etc/gdm/custom.conf and add
FirstVT=7
to the top of the file. Or:
(KDE) edit /etc/kde/kdm/kdmrc and set
ServerVTs=-7
ConsoleTTYs=tty1,tty2,tty3,tty4,tty5,tty6
3) Sigh contentedly at the restoration of your precious tradition.
Thanks a lot, Will.
Dan
12:36 p.m.
2008/10/28 Will Woods <wwoods(a)redhat.com>:
On Mon, 2008-10-27 at 17:07 -0400, Will Woods wrote:
> Hi folks,
>
> If you're running F10Beta/Rawhide, you may have noticed already, but I
> wanted to make sure everyone knows this is intentional:
>
> X HAS MOVED FROM VT7 TO VT1.
OK look. If you absolutely cannot deal with this DRASTIC change in
behavior:
1) add "start on started prefdm" to /etc/event.d/tty1
2) (GNOME) edit /etc/gdm/custom.conf and add
FirstVT=7
to the top of the file. Or:
(KDE) edit /etc/kde/kdm/kdmrc and set
ServerVTs=-7
ConsoleTTYs=tty1,tty2,tty3,tty4,tty5,tty6
3) Sigh contentedly at the restoration of your precious tradition.
If you use runlevel 3 + startx, nothing has changed.
I don't think this is quite how it works in the plymouth/gdm new world
order. Especially since newer gdm doesn't support FirstVT anymore.
plymouth drops a file /var/spool/gdm/force-display-on-active-vt, which
gdm checks for when starting its slave. Instead, I think this can all
be handled from upstart with a preference FORCEACTIVEVT in
/etc/sysconfig/desktop (names/files open for suggestion).
Attached is an untested patch which:
1. Writes /var/spool/gdm/force-display-on-active-vt from prefdm if
$FORCEACTIVEVT = yes
2. Starts getty on tty1 in rc5 if $FORCEACTIVEVT=no
So, you can get the old behavior back with
echo 'FORCEACTIVEVT=no' >> /etc/sysconfig/desktop
This requires that writing /var/spool/gdm/force-display-on-active-vt
is removed from plymouth.
--
Dan
12:54 p.m.
On Tue, 2008-10-28 at 10:36 -0700, Dan Nicholson wrote:
2008/10/28 Will Woods <wwoods(a)redhat.com>:
> On Mon, 2008-10-27 at 17:07 -0400, Will Woods wrote:
>> Hi folks,
>>
>> If you're running F10Beta/Rawhide, you may have noticed already, but I
>> wanted to make sure everyone knows this is intentional:
>>
>> X HAS MOVED FROM VT7 TO VT1.
>
> OK look. If you absolutely cannot deal with this DRASTIC change in
> behavior:
>
> 1) add "start on started prefdm" to /etc/event.d/tty1
> 2) (GNOME) edit /etc/gdm/custom.conf and add
> FirstVT=7
> to the top of the file. Or:
> (KDE) edit /etc/kde/kdm/kdmrc and set
> ServerVTs=-7
> ConsoleTTYs=tty1,tty2,tty3,tty4,tty5,tty6
> 3) Sigh contentedly at the restoration of your precious tradition.
>
> If you use runlevel 3 + startx, nothing has changed.
I don't think this is quite how it works in the plymouth/gdm new world
order. Especially since newer gdm doesn't support FirstVT anymore.
Really? Because I *did* test it before sending mail, and it worked as
expected; X was on VT7 again. But maybe things are different when we
start right after plymouth..
..anyway, it's worth documenting how to change it back.
This is probably a good time to mention that the Docs Project would
surely love help in documenting these sorts of changes for the release
notes:
http://fedoraproject.org/wiki/DocsProject/ReleaseNotes/Process
-w
1:42 p.m.
2008/10/28 Will Woods <wwoods(a)redhat.com>:
On Tue, 2008-10-28 at 10:36 -0700, Dan Nicholson wrote:
> 2008/10/28 Will Woods <wwoods(a)redhat.com>:
> > On Mon, 2008-10-27 at 17:07 -0400, Will Woods wrote:
> >> Hi folks,
> >>
> >> If you're running F10Beta/Rawhide, you may have noticed already, but I
> >> wanted to make sure everyone knows this is intentional:
> >>
> >> X HAS MOVED FROM VT7 TO VT1.
> >
> > OK look. If you absolutely cannot deal with this DRASTIC change in
> > behavior:
> >
> > 1) add "start on started prefdm" to /etc/event.d/tty1
> > 2) (GNOME) edit /etc/gdm/custom.conf and add
> > FirstVT=7
> > to the top of the file. Or:
> > (KDE) edit /etc/kde/kdm/kdmrc and set
> > ServerVTs=-7
> > ConsoleTTYs=tty1,tty2,tty3,tty4,tty5,tty6
> > 3) Sigh contentedly at the restoration of your precious tradition.
> >
> > If you use runlevel 3 + startx, nothing has changed.
>
> I don't think this is quite how it works in the plymouth/gdm new world
> order. Especially since newer gdm doesn't support FirstVT anymore.
Really? Because I *did* test it before sending mail, and it worked as
expected; X was on VT7 again. But maybe things are different when we
start right after plymouth..
..anyway, it's worth documenting how to change it back.
Since plymouth writes the /var/spool/gdm file on boot and then gdm
removes it, any subsequent starts will put X on the first available
VT, which is tty7 in the common configuration. With my patch, prefdm
writes the file every time it's executed. I don't know if that's the
correct behavior for all cases where prefdm would be run.
I'm looking at upstream gdm right now, and FirstVT isn't respected.
Looking at the rawhide patches, I don't see anything that would enable
that functionality again.
This is probably a good time to mention that the Docs Project would
surely love help in documenting these sorts of changes for the release
notes:
http://fedoraproject.org/wiki/DocsProject/ReleaseNotes/Process
Good to know.
--
Dan
5659
days inactive
5661
days old
116 comments
33 participants
participants (33)
-
Adam Jackson -
Bill Nottingham -
Brian Wheeler -
Callum Lerwick -
Casey Dahlin -
Christopher Stone -
Chuck Anderson -
Colin Walters -
Conrad Meyer -
Dan Horák -
Dan Nicholson -
Dan Williams -
Dax Kelson -
Dmitry Butskoy -
Dominik 'Rathann' Mierzejewski -
Felix Miata -
Gerd Hoffmann -
Jesse Keating -
John Reiser -
Jon Ciesla -
Joost van der Sluis -
Les Mikesell -
Matthew Garrett -
Matthew Woehlke -
Matthias Clasen -
Olivier Galibert -
Paul Wouters -
Pete Zaitcev -
Rahul Sundaram -
Ralf Corsepius -
shmuel siegel -
Till Maas -
Will Woods