A suggestion regarding new features
Horst H. von Brand
vonbrand at inf.utfsm.cl
Thu Oct 30 13:47:54 UTC 2008
Dax Kelson <dkelson at gurulabs.com> wrote:
> 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!
To make omelette, you have to break some eggs...
> 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
It is not really new, then.
> 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,
Completely different from lilo. Check.
> udev/hal,
Still trying to wrap my brain around that. Check.
> ALSA,
Massive breakage, much gnashing of teeth, extensive flamewars. Check.
> hda -> sda,
Even more massive breakage, gnashing of teeth, extensive flamewars. Check.
> LVM,
There are still people around claiming it breaks their setups so badly they
go to heroic ends to avoid it. Check.
> FACLS
> on /dev files,
Had my own run ins with this, wan't really nice. Check.
> CUPS,
Was a real mess until it got sorted out. Now it is great (if still a bit
misterious to me). Check.
> POSIX CAPs to replace SUID,
Massive change in sysadmining. Check.
> etc. All distros moved
> these features in relative unison so I can toss that old knowledge out
> of my brain (and documentation).
Old documentation has a penchant for hinding in all sorts of nooks and
crannies of the 'net, and comes to light only when $RELATIVE_NEWBIE looks
around for a fix for $MISTERY.
> 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.
Not even your own "step 2" examples qualify... not by a long shot. The pain
is forgotten by now, that is all.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513
More information about the devel
mailing list