FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 10-29-2008, 04:15 PM
Dax Kelson
 
Default A suggestion regarding new features

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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 02:17 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org