<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.3.2" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments on: Yet more on the importance of backward compatibility</title>
	<link>http://ianmurdock.com/2007/01/29/yet-more-on-the-importance-of-backward-compatibility/</link>
	<description>on emerging platforms, the open source business opportunity, and the commoditization of software</description>
	<pubDate>Thu, 24 Jul 2008 00:59:04 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.3.2</generator>
		<item>
		<title>By: Mael</title>
		<link>http://ianmurdock.com/2007/01/29/yet-more-on-the-importance-of-backward-compatibility/#comment-1269</link>
		<dc:creator>Mael</dc:creator>
		<pubDate>Wed, 31 Jan 2007 20:35:10 +0000</pubDate>
		<guid>http://ianmurdock.com/2007/01/29/yet-more-on-the-importance-of-backward-compatibility/#comment-1269</guid>
		<description>Ewan Marshall said:
Developers generally upgrade software to still be compatible very quickly. Hence it is not as much of a problem anyway.

This can also be a huge problem for some users. I use Linux distro known as Scientific Linux CERN 4 (essentially a distro built using RHEL4 sources + some modifications) on my laptop because of my work. Generally everything that is bundled with the system works really well but whenever I need to install extra software (something that is not bundled with the system or new version of some tool with new functionality I need) I'm in trouble. Desktop software (things like graphics programs e.g. Inkscape come to mind) is really difficult to install. There are no readily available binaries for RHEL4 and building new versions from source is difficult because I have to upgrade shitload of libraries (not available in RPM-format for RHEL4 so ./configure &#38;&#38; make &#38;&#38; make install is the only way) and their dependencies as well. The reason for this seems to be that some (actually most) desktop software developers seem to think that everyone has the latest version of libraries. So the compatibility with new library versions comes quickly but at the same time old distros become obsolete too fast.</description>
		<content:encoded><![CDATA[<p>Ewan Marshall said:<br />
Developers generally upgrade software to still be compatible very quickly. Hence it is not as much of a problem anyway.</p>
<p>This can also be a huge problem for some users. I use Linux distro known as Scientific Linux CERN 4 (essentially a distro built using RHEL4 sources + some modifications) on my laptop because of my work. Generally everything that is bundled with the system works really well but whenever I need to install extra software (something that is not bundled with the system or new version of some tool with new functionality I need) I&#8217;m in trouble. Desktop software (things like graphics programs e.g. Inkscape come to mind) is really difficult to install. There are no readily available binaries for RHEL4 and building new versions from source is difficult because I have to upgrade shitload of libraries (not available in RPM-format for RHEL4 so ./configure &amp;&amp; make &amp;&amp; make install is the only way) and their dependencies as well. The reason for this seems to be that some (actually most) desktop software developers seem to think that everyone has the latest version of libraries. So the compatibility with new library versions comes quickly but at the same time old distros become obsolete too fast.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: David</title>
		<link>http://ianmurdock.com/2007/01/29/yet-more-on-the-importance-of-backward-compatibility/#comment-1268</link>
		<dc:creator>David</dc:creator>
		<pubDate>Tue, 30 Jan 2007 22:27:16 +0000</pubDate>
		<guid>http://ianmurdock.com/2007/01/29/yet-more-on-the-importance-of-backward-compatibility/#comment-1268</guid>
		<description>Back in 1985 or 1986, a whole bunch of Macintosh software quit working on new systems.

A major C-compiler violated Apple's guidelines and every application compiled with it wouldn't work with the new Macintosh Plus.

It was an early and expesive lesson in "rules are there for a reason."</description>
		<content:encoded><![CDATA[<p>Back in 1985 or 1986, a whole bunch of Macintosh software quit working on new systems.</p>
<p>A major C-compiler violated Apple&#8217;s guidelines and every application compiled with it wouldn&#8217;t work with the new Macintosh Plus.</p>
<p>It was an early and expesive lesson in &#8220;rules are there for a reason.&#8221;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ewan Marshall</title>
		<link>http://ianmurdock.com/2007/01/29/yet-more-on-the-importance-of-backward-compatibility/#comment-1267</link>
		<dc:creator>Ewan Marshall</dc:creator>
		<pubDate>Tue, 30 Jan 2007 22:12:20 +0000</pubDate>
		<guid>http://ianmurdock.com/2007/01/29/yet-more-on-the-importance-of-backward-compatibility/#comment-1267</guid>
		<description>If you upgrade due to the free software philosophy Developers generally upgrade software to still be compatible very quickly. Hence it is not as much of a problem anyway.

e.g. Amarok are looking to move to new KDE4 libraries as soon as KDE4 is released but both will continue to support Arts and DCOP until the last line of the new code is written.</description>
		<content:encoded><![CDATA[<p>If you upgrade due to the free software philosophy Developers generally upgrade software to still be compatible very quickly. Hence it is not as much of a problem anyway.</p>
<p>e.g. Amarok are looking to move to new KDE4 libraries as soon as KDE4 is released but both will continue to support Arts and DCOP until the last line of the new code is written.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Scope Of Backward Compatibility on iface thoughts</title>
		<link>http://ianmurdock.com/2007/01/29/yet-more-on-the-importance-of-backward-compatibility/#comment-1266</link>
		<dc:creator>Scope Of Backward Compatibility on iface thoughts</dc:creator>
		<pubDate>Tue, 30 Jan 2007 09:39:32 +0000</pubDate>
		<guid>http://ianmurdock.com/2007/01/29/yet-more-on-the-importance-of-backward-compatibility/#comment-1266</guid>
		<description>[...] Ian Murdock covers an awkward situation that forces backward compatibility. Changes in Vista are causing problems for a third-party software that works on Intuit Quickbooks. The backward compatibility can always be guaranteed within a scope. This scope is usually the interface offered, usually in the form of an API or a framework. If anyone uses anything other than this interface should expect problems with upgrades. [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] Ian Murdock covers an awkward situation that forces backward compatibility. Changes in Vista are causing problems for a third-party software that works on Intuit Quickbooks. The backward compatibility can always be guaranteed within a scope. This scope is usually the interface offered, usually in the form of an API or a framework. If anyone uses anything other than this interface should expect problems with upgrades. [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bob</title>
		<link>http://ianmurdock.com/2007/01/29/yet-more-on-the-importance-of-backward-compatibility/#comment-1264</link>
		<dc:creator>Bob</dc:creator>
		<pubDate>Mon, 29 Jan 2007 23:24:40 +0000</pubDate>
		<guid>http://ianmurdock.com/2007/01/29/yet-more-on-the-importance-of-backward-compatibility/#comment-1264</guid>
		<description>Certification with Microsoft? They can't get Word do its thing without crashing, and they want others to certify with them? Oh dear....</description>
		<content:encoded><![CDATA[<p>Certification with Microsoft? They can&#8217;t get Word do its thing without crashing, and they want others to certify with them? Oh dear&#8230;.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Don Marti</title>
		<link>http://ianmurdock.com/2007/01/29/yet-more-on-the-importance-of-backward-compatibility/#comment-1262</link>
		<dc:creator>Don Marti</dc:creator>
		<pubDate>Mon, 29 Jan 2007 23:10:02 +0000</pubDate>
		<guid>http://ianmurdock.com/2007/01/29/yet-more-on-the-importance-of-backward-compatibility/#comment-1262</guid>
		<description>Another lesson might be to have lighter weight certification programs.  Why didn't Intuit go for the certification that would have revealed the problem?  Too much expense and bureaucracy?  (LSB's</description>
		<content:encoded><![CDATA[<p>Another lesson might be to have lighter weight certification programs.  Why didn&#8217;t Intuit go for the certification that would have revealed the problem?  Too much expense and bureaucracy?  (LSB&#8217;s</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bob</title>
		<link>http://ianmurdock.com/2007/01/29/yet-more-on-the-importance-of-backward-compatibility/#comment-1261</link>
		<dc:creator>Bob</dc:creator>
		<pubDate>Mon, 29 Jan 2007 22:57:31 +0000</pubDate>
		<guid>http://ianmurdock.com/2007/01/29/yet-more-on-the-importance-of-backward-compatibility/#comment-1261</guid>
		<description>Q: What would you like for lunch, Sir? 
A: Umm. Online accounting with industrial espionage on the side.
Q: Excellent choice, Sir. May I suggest a sprinkle of BigBrother with it?
A: Yeah, wouldn't it be tasty?</description>
		<content:encoded><![CDATA[<p>Q: What would you like for lunch, Sir?<br />
A: Umm. Online accounting with industrial espionage on the side.<br />
Q: Excellent choice, Sir. May I suggest a sprinkle of BigBrother with it?<br />
A: Yeah, wouldn&#8217;t it be tasty?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Roy Schestowitz</title>
		<link>http://ianmurdock.com/2007/01/29/yet-more-on-the-importance-of-backward-compatibility/#comment-1259</link>
		<dc:creator>Roy Schestowitz</dc:creator>
		<pubDate>Mon, 29 Jan 2007 21:31:36 +0000</pubDate>
		<guid>http://ianmurdock.com/2007/01/29/yet-more-on-the-importance-of-backward-compatibility/#comment-1259</guid>
		<description>The thing about Linux is, if one wishes to run software that uses different mutually-incompatible libraries, then one can virtualise or multiboot on the same box. The cost remains zero, so the 'punishment' incurred by lack of backward compatibility is low(er).</description>
		<content:encoded><![CDATA[<p>The thing about Linux is, if one wishes to run software that uses different mutually-incompatible libraries, then one can virtualise or multiboot on the same box. The cost remains zero, so the &#8216;punishment&#8217; incurred by lack of backward compatibility is low(er).</p>
]]></content:encoded>
	</item>
</channel>
</rss>
