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