Re: OCD programmers and backwards compatibility :-).

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux