<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:dc="http://purl.org/dc/elements/1.1/" version="2.0">
<channel>
<title>Articles by Zev Laderman</title>
<link>http://linux.sys-con.com/</link>
<description>Latest articles from Zev Laderman</description>
<copyright>Copyright 2008 LINUX</copyright>
<lastBuildDate>Sun, 20 Jul 2008 15:00:00 GMT</lastBuildDate>
<generator>LINUX</generator>
<ttl>10</ttl>
<docs>http://backend.userland.com/rss</docs>

<item>
<title>Tackling Dependencies</title>
<guid isPermaLink="true">http://linux.sys-con.com/read/117912.htm</guid><link>http://linux.sys-con.com/read/117912.htm</link>
<pubDate>Fri, 12 Aug 2005 16:00:00 GMT</pubDate>
<description>You don&apos;t have to be around Linux for long before you hear about &apos;the dependency problem,&apos; which is no problem at all for many users - until the day it bites them. In a nutshell, the problem is that most Linux applications depend on the operating system to provide various pieces of functionality that the applications need. These components most often take the form of shared libraries that are dynamically loaded and linked to the application at runtime. Problems occur when one or more of these libraries are replaced with a different (usually newer) version. Provided all the interfaces remain the same and the semantics of the functionality remain the same, there&apos;s no problem. However, due to security fixes, bug fixes, or new or improved functionality, the interfaces and semantics can and do change, and the changes can be enough to break the application.</description>

</item></channel></rss>