OCD programmers and backwards compatibility :-).

[Les Mikesell]

Steve Siegfried wrote:
>>> There's a great counter-example actually coming up in Fedora 7. The
>>> kernel will switch to calling (nearly? [1]) all hard disks, PATA and
>>> SATA alike, /dev/sdx (or whatever) as part of the switch to libsata.
>>> This should be a lot more powerful, reliable, and maintainable.
>>>       
>> Sounds like a better example of why linux should be more interested
>> in backwards compatibility than it seems to be now. Why change the /dev
>> names just because the underlying mechanism changes?
>>
>> The most recent horrible example of this is Xorg 7 versus 6.9. The content
>> of the initial 7 release was absolutely identical to the content of the
>> final 6.9 release, but with the names of everything changed so as to
>> utterly devastate all 3rd party rpms that expect things to be installed
>> in certain places.

>
> I can think of three reasons this happens:
> 	1- Group-think decisions, usually by "release teams" that have
> 	   little or no knowledge why stuff is as it was before deciding
> 	   it needs to be different "this time around" in order to make
> 	   the foobar package play nice with the rest of the release.
> 	   Of course, the new foobar package breaks compatibility with
> 	   the the last release because the developer didn't understand
> 	   how stuff works, but because the developer has the strongest
> 	   personality in the room at the time, he's managed to con the
> 	   release team into doing things his way.
>
> 	2- Job security.
> and
> 	3- Because we can.  Na-na-nah-boo-boo!
>
> Cynically,
>
>   
You left out the main reason - the people who make these 
backwards-incompatible
and user-hostile changes for arbitrary reasons (and *all* filename 
changes are
arbitrary) obviously don't support any existing large integrated 
systems.  They
think of the computer as their personal playground where they can make
any whimsical change they like.    Someone who actually had to deal with the
consequences and breakage would at least throw a symlink in the old location
for a decade or so.   And there is more to your number 3 than you might 
think.
Anytime you bring up the  damage these  changes cause, you are likely to
get an answer  like "we don't support that  proprietary package" as  though
maintaining interoperable interfaces constitutes support of some particular
thing.   It comes across like they do it on purpose to break other people's
products.

-- 
  Les Mikesell
   lesmikesell at gmail.com