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@xxxxxxxxx
