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