A suggestion regarding new features

[Dax Kelson]

Progress is great, new shiny frobnicators are wonderful. What many
people (myself included) object to is when old behaviors and
compatibility is broken NEEDLESSLY.  Let's have our cake and eat it too!

When implementing new features what about using a decision tree that
looks like the following:

======================================================

Step 1. Does $NEWFEATURE implementation change old behaviors or break
compatibility? 

a) NO -> Great go for it! Let's all eat cake!
b) YES -> See step 2

Step 2. Can $NEWFEATURE be implemented so that it doesn't change old
behaviors or break compatibility?

a) NO -> Uh oh, see step 3.
b) YES preserve both -> Excellent. Let's all eat cake!
c) YES preserve compatibility -> Great no "exceptions". Let's all eat
cake!

Examples of "2c" include GRUB, udev/hal, ALSA, hda -> sda, LVM, FACLS
on /dev files, CUPS, POSIX CAPs to replace SUID, etc. All distros moved
these features in relative unison so I can toss that old knowledge out
of my brain (and documentation).

Step 3. Does the benefit of $NEWFEATURE outweigh the cost of changing
the old behavior or breaking compatibility? Obviously this can be
subjective.

a) NO -> Good effort. Have you considered picking one of the other many
areas in Linux that need improving and working on that?
b) YES -> OK, $NEWFEATURE must be really awesome. Please double check
that you can't resolve this in Step 2. So Step 2 is a no go? OK, let's
do it.

======================================================

Your initial goal SHOULD BE TO AVOID A STEP 3 RESOLUTION IN THE FIRST
PLACE.

Many people have voiced concerns that to many $NEWFEATURES are going
straight to Step 3 without exploring a Step 1 or Step 2 resolution. 

No sane person would prefer a Step 3 resolution versus a Step 2
resolution.

The issue with "BetterStartup" having the side effect of moving X to
tty1 vs tty7 can go from the current Step 3 $NEWFEATURE back to a "Step
2b" $NEWFEATURE.  Let's all eat cake!

How? It has already been pointed out that a VT switch doesn't imply a
flicker (aka a mode change). You can switch VTs without "flicker". After
the kernel has set the mode (which happens for all VTs), then plymouth
starts X on tty7 and starts X. No flicker, plus we have preserved
compatibility and not changed behaviors.

Dax Kelson
Guru Labs