On Wed, Oct 29, 2008 at 7:36 AM, Dax Kelson <dkelson@xxxxxxxxxxxx> 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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
+1
--
Aioanei Rares
schaiba@xxxxxxxxxxxxxxxxx
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
