Step 1. Does $NEWFEATURE implementation change old behaviors or break
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
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
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
Your initial goal SHOULD BE TO AVOID A STEP 3 RESOLUTION IN THE FIRST
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
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.
fedora-devel-list mailing list