Reasons to preseve X on tty7

[Aioanei Rares]

On Wed, Oct 29, 2008 at 7:36 AM, Dax Kelson <dkelson at gurulabs.com> wrote:

> 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


+1
-- 
Aioanei Rares
schaiba at fedoraproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081029/dbe758e5/attachment.htm>