Reasons to preseve X on tty7
 

I would argue strongly that this change should not be made for the
following reasons (in no particular order):

* The default behavior of X on tty7 has been in place since the
beginning (almost a decade and a half).

* Long standing behaviors and defaults should not be changed unless
there is a VERY good reason with a significant upside. Developers should
tread respectfully in such hallowed places.

* This specific Linux behavior is well documented in hundreds of
thousand of publications ranging from college text books, HOWTOs, Linux
books sold in retail stores, blogs, forums, guides, and training
manuals. Making a change invalidates all that published knowledge.

* Fedora (and presumably RHEL6) now behaves differently from all the
major distributions. The axiom about those who ignore history are bound
to repeat holds here. UNIX "distros" did the same thing, introducing
frivolous incompatibilities. This fractures the user community, creating
separate pockets of knowledge and experience for each system.

* The "exception to the rule" (such as this one) dramatically increases
the costs of cross-distribution support. It turns 300-page books into
1000-page books. Similarly one must remember and commit to memory all
the "exceptions" and swap them in and out of your mental working set as
needed.

* Fedora is now inconsistent with itself in regards to where X is
running depending on if you booted to runlevel 3 and used startx or if
you booted to runlevel 5. When your uptime is 3 weeks, how do you
remember which method you used to start the GUI?

* Having tty1 be the user's "primary console" (as mentioned in BZ
465547) is not a worthy goal as desktop (GUI only) users should not and
do not care what tty X is on.

* Experienced users will try CONTROL-ALT-F1 and nothing will happen, the
first thing that comes to mind is "something is broke".

* With the current rawhide behavior, what happens when you combine this
with fast user switching? The first user's desktop is on tty1, and then
is the second desktop is on tty7, and the third on tty8? I tried to test
this in my lab but I suspect video driver problems (radeon) because my
test machine would lock up.

* Having the X server start on tty7 *from the very beginning* would get
one less "flicker" without making an incompatible change.

I support progress, but I hate to see two steps forward and one back. I
understand change is natural but the change should be well reasoned with
implications considered and weighed.

To put my comments in "context" and to show that I'm not just a nutter
with an uniformed opinion, and in a way of introduction, here's a bit
about myself. I've used (typically in production) every single version
of Red Hat and/or Fedora ever created (go Mother's Day!). I started an
ISP and grew it to 10,000 users using (initially) Red Hat 4.2 (not
RHEL), and I was the first person/customer of Red Hat to earn an RHCE
(Feb 1999). I have minor patches in many different projects and several
hundred bugs in bugzilla.redhat.com. I was the official GNOME RPM
maintainer for a few years around the turn of the century creating GNOME
RPMs for several distributions for each new GNOME release.

For the past 9 years I have made a living writing Linux courseware for
multiple Linux distributions and teaching Linux training classes along
with the rest of the dozen full time instructors at Guru Labs, a company
I founded with a college friend of mine. I've sold tens of thousands of
Linux training books. Unfortunately, I don't have the time to
participate on the lists as much as I would like too. However, because
of my daily work I get to observe the low level changes and development
process of many different Linux distributions giving me a broad
perspective.

Our coureware features extensive labs which have thousands of lab steps
that exercise virtually all the major software components and features
thereof. As we update/validate our courseware to work on the latest
Linux distribution versions, our courseware ends up acting like a giant
regression test. We end up patching and/or filing many many bug reports
in many bug trackers.

Uneeded and frivolous incompatibilities between Linux distros are
particularly annoying to me on many levels. One practical reason is the
bloat it causes in our courseware. The LSB is fine for developers who
want to run binaries across multiple distributions, but Linux Sys Admins
deserve something akin to the LSB that provides greater consistency at
the Sys Admin level by removing squashing these frivolous
incompatibilities. This is something that has been brewing in the back
of my mind and I (using Guru Labs funding/resources and other interested
parties) might tackle at some point.

Dax Kelson
Guru Labs

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Reasons to preseve X on tty7
 

On Tue, 2008-10-28 at 23:36 -0600, Dax Kelson wrote:
> I would argue strongly that this change should not be made for the
> following reasons (in no particular order):
>


I'm sure we'll be inundated with 'fedora is all about the bleeding edge'
comments but I have to give Dax my support with this comment. He's not
saying "preserve compatibility/behavior at all costs". He's saying that
the stated reason for this behavior change is not enough to justify the
cost of the loss of consistency with the past.

In short: +1

-sv


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Reasons to preseve X on tty7
 

seth vidal wrote:

On Tue, 2008-10-28 at 23:36 -0600, Dax Kelson wrote:

I would argue strongly that this change should not be made for the
following reasons (in no particular order):




I'm sure we'll be inundated with 'fedora is all about the bleeding edge'
comments but I have to give Dax my support with this comment. He's not
saying "preserve compatibility/behavior at all costs". He's saying that
the stated reason for this behavior change is not enough to justify the
cost of the loss of consistency with the past.

In short: +1


But fedora is all about the bleeding edge!

;)

--
Nathanael d. Noblet
Gnat Solutions, Inc
T: 403.875.4613

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Reasons to preseve X on tty7
 

--- On Wed, 10/29/08, Dax Kelson <dkelson@gurulabs.com> wrote:

> From: Dax Kelson <dkelson@gurulabs.com>
> Subject: Reasons to preseve X on tty7
> To: "Development discussions related to Fedora" <fedora-devel-list@redhat.com>
> Date: Wednesday, October 29, 2008, 1:36 AM
> I would argue strongly that this change should not be made
> for the
> following reasons (in no particular order):
>
> * The default behavior of X on tty7 has been in place since
> the
> beginning (almost a decade and a half).
>
> * Long standing behaviors and defaults should not be
> changed unless
> there is a VERY good reason with a significant upside.
> Developers should
> tread respectfully in such hallowed places.
>
> * This specific Linux behavior is well documented in
> hundreds of
> thousand of publications ranging from college text books,
> HOWTOs, Linux
> books sold in retail stores, blogs, forums, guides, and
> training
> manuals. Making a change invalidates all that published
> knowledge.
>
> * Fedora (and presumably RHEL6) now behaves differently
> from all the
> major distributions. The axiom about those who ignore
> history are bound
> to repeat holds here. UNIX "distros" did the same
> thing, introducing
> frivolous incompatibilities. This fractures the user
> community, creating
> separate pockets of knowledge and experience for each
> system.
>
> * The "exception to the rule" (such as this one)
> dramatically increases
> the costs of cross-distribution support. It turns 300-page
> books into
> 1000-page books. Similarly one must remember and commit to
> memory all
> the "exceptions" and swap them in and out of your
> mental working set as
> needed.
>
> * Fedora is now inconsistent with itself in regards to
> where X is
> running depending on if you booted to runlevel 3 and used
> startx or if
> you booted to runlevel 5. When your uptime is 3 weeks, how
> do you
> remember which method you used to start the GUI?
>
> * Having tty1 be the user's "primary console"
> (as mentioned in BZ
> 465547) is not a worthy goal as desktop (GUI only) users
> should not and
> do not care what tty X is on.
>
> * Experienced users will try CONTROL-ALT-F1 and nothing
> will happen, the
> first thing that comes to mind is "something is
> broke".
>
> * With the current rawhide behavior, what happens when you
> combine this
> with fast user switching? The first user's desktop is
> on tty1, and then
> is the second desktop is on tty7, and the third on tty8? I
> tried to test
> this in my lab but I suspect video driver problems (radeon)
> because my
> test machine would lock up.
>
> * Having the X server start on tty7 *from the very
> beginning* would get
> one less "flicker" without making an incompatible
> change.
>
> I support progress, but I hate to see two steps forward and
> one back. I
> understand change is natural but the change should be well
> reasoned with
> implications considered and weighed.
>
> To put my comments in "context" and to show that
> I'm not just a nutter
> with an uniformed opinion, and in a way of introduction,
> here's a bit
> about myself. I've used (typically in production) every
> single version
> of Red Hat and/or Fedora ever created (go Mother's
> Day!). I started an
> ISP and grew it to 10,000 users using (initially) Red Hat
> 4.2 (not
> RHEL), and I was the first person/customer of Red Hat to
> earn an RHCE
> (Feb 1999). I have minor patches in many different projects
> and several
> hundred bugs in bugzilla.redhat.com. I was the official
> GNOME RPM
> maintainer for a few years around the turn of the century
> creating GNOME
> RPMs for several distributions for each new GNOME release.
>
> For the past 9 years I have made a living writing Linux
> courseware for
> multiple Linux distributions and teaching Linux training
> classes along
> with the rest of the dozen full time instructors at Guru
> Labs, a company
> I founded with a college friend of mine. I've sold tens
> of thousands of
> Linux training books. Unfortunately, I don't have the
> time to
> participate on the lists as much as I would like too.
> However, because
> of my daily work I get to observe the low level changes and
> development
> process of many different Linux distributions giving me a
> broad
> perspective.
>
> Our coureware features extensive labs which have thousands
> of lab steps
> that exercise virtually all the major software components
> and features
> thereof. As we update/validate our courseware to work on
> the latest
> Linux distribution versions, our courseware ends up acting
> like a giant
> regression test. We end up patching and/or filing many many
> bug reports
> in many bug trackers.
>
> Uneeded and frivolous incompatibilities between Linux
> distros are
> particularly annoying to me on many levels. One practical
> reason is the
> bloat it causes in our courseware. The LSB is fine for
> developers who
> want to run binaries across multiple distributions, but
> Linux Sys Admins
> deserve something akin to the LSB that provides greater
> consistency at
> the Sys Admin level by removing squashing these frivolous
> incompatibilities. This is something that has been brewing
> in the back
> of my mind and I (using Guru Labs funding/resources and
> other interested
> parties) might tackle at some point.
>
> Dax Kelson
> Guru Labs
>


While I respect your opinions and experience I do think that the reasoning for this behavior change is good enough. I remember the first time I was told how to switch to tty1 some 7-8 years ago. Immediately after switching to tty1 my curiosity boosted up and I tried all the combinations ctrl+alt+F2 through ctrl+alt+F12. I am sure many of us went through a similar experience.

If someone tries one of these combinations (s)he *will* try the other combinations. There are not too many of them. It won't take too long until the user will end up where (s)he wanted. And if people still think that this change will bring an utter catastrophe we might as well put a warning message (just for F10 and maybe for F11) at tty7 saying that X is not here anymore and is moved to tty1. Won't this solve all the problems?

Orcan





--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Reasons to preseve X on tty7
 

Dax Kelson wrote, at 10/29/2008 02:36 PM +9:00:

> * Fedora is now inconsistent with itself in regards to where X is
> running depending on if you booted to runlevel 3 and used startx or if
> you booted to runlevel 5. When your uptime is 3 weeks, how do you
> remember which method you used to start the GUI?

Well, actually I usually reboot with runlevel 3 then after switch runlevel
to 5. In such case tty1 is console and I have never noticed that
tty1 behavior changed until I read the discussion from yesterday...

I also think that tty1 should be console as before. So +1

Mamoru

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Reasons to preseve X on tty7
 

On Wed, 29 Oct 2008 01:42:23 -0400, seth vidal wrote:
> > I would argue strongly that this change should not be made for the
> > following reasons (in no particular order):
> >
> I'm sure we'll be inundated with 'fedora is all about the bleeding
> edge' comments but I have to give Dax my support with this comment.
> He's not saying "preserve compatibility/behavior at all costs". He's
> saying that the stated reason for this behavior change is not enough
> to justify the cost of the loss of consistency with the past.
>
> In short: +1

I think one flicker doesn't weigh much in contrast of what gets lost in
terms of historical background and compatibility...

+1 from me too

Cheers,
Christian

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Reasons to preseve X on tty7
 

On Wed, 2008-10-29 at 01:42 -0400, Seth Vidal wrote:
> I'm sure we'll be inundated with 'fedora is all about the bleeding edge'
> comments but I have to give Dax my support with this comment. He's not
> saying "preserve compatibility/behavior at all costs". He's saying that
> the stated reason for this behavior change is not enough to justify the
> cost of the loss of consistency with the past.

I could not have said it better myself, Seth. Another +1 for Dax's
argument from me.
--
Peter Gordon (codergeek42)
「ゴードン・ピーター�
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Reasons to preseve X on tty7
 

On Tue, Oct 28, 2008 at 9:36 PM, Dax Kelson
> * With the current rawhide behavior, what happens when you combine > this with fast user switching?
> The first user's desktop is on tty1, and then
> is the second desktop is on tty7, and the third on tty8? I tried to test
> this in my lab but I suspect video driver problems (radeon) because > my test machine would lock up.

I can confirm... second user's gdm login appears on vt7.

But is this actually a problem? All the UI elements for screen locking
and logging out provide a switch user option back to the first user. I
never needed to use the vt1 or vt7 short cut keys. The gui is self
consistent with regard to user switching regardless of what vts are
used.

As a graphical interface user, the only time I need to worry about
knowing about vt's is if I need to explicitly drop out of the gui.
And I only need to do that if things lock up so badly that I cant
start a terminal...but not so badly that the keyboard isn't locked up
as well.

The only reason I know the vt's are there is because I know the vt's
are there. And since I know the vt's are there.. I know to cycle
through them.

-jef"is just going to turn off all his gettys and see if he can adapt"spaleta

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Reasons to preseve X on tty7
 

On 29.10.2008 08:40, Jeff Spaleta wrote:

On Tue, Oct 28, 2008 at 9:36 PM, Dax Kelson

* With the current rawhide behavior, what happens when you combine > this with fast user switching?
The first user's desktop is on tty1, and then
is the second desktop is on tty7, and the third on tty8? I tried to test
this in my lab but I suspect video driver problems (radeon) because > my test machine would lock up.


I can confirm... second user's gdm login appears on vt7.

But is this actually a problem? All the UI elements for screen locking
and logging out provide a switch user option back to the first user. I
never needed to use the vt1 or vt7 short cut keys. The gui is self
consistent with regard to user switching regardless of what vts are
used. [...]


I hereby propose we add a Checkbox (¹) "Old-School Linux user" somewhere
to anaconda; users that want to preserve the traditional behavior for
this and other things (like "show grub by default") can then just check
that to get the old behavior.


CU
knurd

P.S.: You wonder if I meant that serious? I'm not sure myself. I think
the answer is: A little bit maybe ;-)

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Reasons to preseve X on tty7
 

On Tue, 2008-10-28 at 23:36 -0600, Dax Kelson wrote:
> I would argue strongly that this change should not be made for the
> following reasons (in no particular order):
>

/+1.

- Gilboa

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list