OCD programmers and backwards compatibility :-).

[Robin Laing]

Tom Horsley wrote:
>>> In fact, while we're at it - never have another "release", just keep
>>> upgrading rpms forever with individual packages being released,
>>> but nothing called a whole distribution having a release. Individual
>>> rpms just get marked obsolete and replaced with new ones in the
>>> ever updated lists.
>>>
>>> Now *that* would be a Knight in shining armor! Fedora 7 is a mere
>>> feeble imitation in comparison :-).
>> 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. What reason was there for this change? As near as
> I can tell the only reason was a bunch of OCD programmers who broke
> into a sweat every time they saw a directory named /usr/X11R6 instead
> of /usr/share/X11 :-). The software worked just as well with either
> directory name. If the fate of the world isn't at stake, there is no
> reason to make changes like this. The cost to the rest of the world
> is still being calculated as developers who could be doing something
> useful spend their time "fixing" their packaging instead, and users find
> all the tools they used to install don't work till they poke around on
> the web for hours and find the descriptions of how to add symlinks to
> their system to fix the broken installation under Xorg 7.
> 
> Sure, its a fun game, but not everyone likes playing it :-).
> 
> The same sort of attitude prevails in the kernel driver source code
> as well. I've had to patch and rebuild the truecrypt driver several
> times on new kernel releases, and not once has the change been anything
> substantive about the driver model. Once again, it is all ticky-tak
> junk like changing the name of a macro or routine because some moron
> who had the power didn't like the old name and didn't care how much
> work changing it foists off onto the rest of the world.
> 
> If a new kind of linux release mechanism could raise the level of
> outrage over totally gratuitous non-backward compatible changes to
> the point where the size of the outcry could actually make the fools
> stop checking in non-backward compatible changes without fantastically
> good reasons, then we NEED this new linux release mechanism :-).
> 

Now I have not followed the Linux Standards information lately but is 
this change moving more towards a standard across all versions of Linux?

I ask this because it would be nice to go between versions of Linux and 
find that all the files are in the same directories and paths.  I 
shouldn't have to think am I on Gentoo or Fedora?  Where is this file 
stored on this system or where should I put this configuration file on 
that system.

If all versions of Linux used the same standards then the software 
developers have one less issue to deal with and future compatibility is 
improved.  Also this makes it easier for an author to support more distros.

This goes in the same line as ISO standards or the battle between Metric 
and English measurements.  Follow one standard and you have it made.

If you notice Windows is slowly moving away from backward compatibility 
as well.  How many times do you have to update an application when 
Microsoft does an update?

-- 
Robin Laing