{"id":1213,"date":"2012-11-12T17:12:01","date_gmt":"2012-11-12T23:12:01","guid":{"rendered":"http:\/\/redmonk.com\/dberkholz\/?p=1213"},"modified":"2012-11-12T19:36:13","modified_gmt":"2012-11-13T01:36:13","slug":"on-package-management-negating-the-downsides-of-bundling","status":"publish","type":"post","link":"https:\/\/redmonk.com\/dberkholz\/2012\/11\/12\/on-package-management-negating-the-downsides-of-bundling\/","title":{"rendered":"On package management: Negating the downsides of bundling"},"content":{"rendered":"<p><a href=\"http:\/\/en.wikipedia.org\/wiki\/Package_management_system\">Package management<\/a>\u00a0is the seemingly simple task of administering software installation, upgrade, and removal. Like many things, it&#8217;s only simple when you squint your eyes from half a mile away &#8212; as you get closer to the problem, it grows increasingly complex. This is part of the reason why, almost every week, we hear about a new implementation of package management, from Linux distributions to iOS apps to, more recently, JavaScript (e.g. <a href=\"https:\/\/npmjs.org\/\">npm<\/a>,\u00a0<a href=\"https:\/\/github.com\/twitter\/bower\">bower<\/a>, <a href=\"http:\/\/jamjs.org\/\">jam<\/a>).<\/p>\n<p><strong>Perhaps the largest fallacy of package management is the refusal to learn anything about history<\/strong> &#8212; every new package manager pretends as if the problem had never existed in the past and encounters, even occasionally surmounting, all the same issues as had been solved years, or even decades, in the past. It&#8217;s <a href=\"http:\/\/en.wikipedia.org\/wiki\/Not_invented_here\">NIH syndrome<\/a> at its finest &#8212; but of course, this is simply a microcosm of the <a href=\"http:\/\/redmonk.com\/sogrady\/2012\/10\/24\/html5\/\">tech industry as a whole<\/a>.<\/p>\n<p>One of the overarching issues going under discussion and experimentation in the package-management world is <strong>whether to bundle software dependencies or use global, system-level instances<\/strong>. Think Linux versus iOS &#8212; Linux distros install a single copy of libraries such as zlib or openssl, whereas iOS or OS X apps would tend to bundle the same functionality into every installed package that uses it.<\/p>\n<p>Therefore, on Linux, <a href=\"http:\/\/tldp.org\/HOWTO\/Program-Library-HOWTO\/shared-libraries.html\">shared libraries<\/a> are king &#8212; a single copy of the shared library zlib.so.X.Y.Z would be used by every binary on the system that calls out to zlib&#8217;s compression functions. This provides some distinct <strong>benefits<\/strong> over bundling\u00a0(e.g.\u00a0<a href=\"http:\/\/blog.flameeyes.eu\/2008\/01\/what-to-do-with-shared-code\">here<\/a>,\u00a0<a href=\"http:\/\/blog.flameeyes.eu\/2009\/01\/bundling-libraries-for-despair-and-insecurity\">here<\/a>,\u00a0<a href=\"http:\/\/blog.flameeyes.eu\/2009\/03\/bundling-libraries-the-curse-of-the-ancients\">here<\/a>, and\u00a0<a href=\"http:\/\/blog.flameeyes.eu\/2009\/04\/security-considerations-scanning-bundled-libraries\">here<\/a>) such as <strong>increased security<\/strong>, <strong>increased maintenance<\/strong> costs for any changes in the forked, bundled copy, and\u00a0<strong>decreased size<\/strong> both in memory and on disk (read the previous links for details).<\/p>\n<p>Global copies also have significant <strong>problems<\/strong>\u00a0for the vendor as well as the end user in terms of robustness and reliability, primarily due to API or ABI changes to the library itself. For the vendor, <strong>bundling<\/strong> <strong>increases predictability<\/strong> &#8212; you know very accurately what the relevant environment looks like on every single system, and this decreases your support burden. In addition, <strong>when a global library changes in an incompatible way, it breaks everything<\/strong>\u00a0on the user&#8217;s system that uses it, all at once. This can be somewhat alleviated by keeping a copy of the old library around, but you can run into extremely interesting issues when you have a binary using two versions of the same library at once (via various dependencies). That&#8217;s exactly why OS X uses bundling.<\/p>\n<p>So <strong>what could we do to get the best of both worlds?<\/strong> The ideal scenario for distributors, app developers, and end users would be some kind of blend of the bundling and global approaches that optimizes as many of the above benefits and downsides as possible, for the best possible experience all around. <strong>My proposal<\/strong> is to provide bundled applications (but <strong>not<\/strong> statically linked, rather a directory containing the app and its dependencies), coupled with two things: (1) use of <strong>a <a href=\"http:\/\/en.wikipedia.org\/wiki\/Linker_(computing)\">linker<\/a>\u00a0and <a href=\"http:\/\/en.wikipedia.org\/wiki\/Loader_(computing)\">loader<\/a> that prefer the bundled copy<\/strong> while falling back to the system copy, and (2) <strong>a package manager with a deep understanding of the bundle<\/strong> and what it contains.<\/p>\n<p><strong>This enables, by default, all the benefits of bundling. At the same time, it doesn&#8217;t block the most important advantages of global copies<\/strong> &#8212; it allows for the package manager to learn when bundled copies are vulnerable to security holes, it even enables them to be upgraded to compatible versions (or incompatible versions if the app is open source), and it further allows the libraries to be rebuilt by the package manager to &#8220;vanilla&#8221; versions that are guaranteed to be untouched by the vendor. <strong>While this approach doesn&#8217;t provide the guaranteed predictability that vendors desire, it does place the priorities of the end user first<\/strong> &#8212; a usable, more secure system trumps all.<\/p>\n<p><span style=\"color: #999999;\"><em><strong>Disclosure<\/strong>: Apple is not a client.<\/em><\/span><\/p>\n<div class=\"acc_license\"><a href=\"http:\/\/creativecommons.org\/licenses\/by-sa\/3.0\/\"><img decoding=\"async\" src=\"http:\/\/i.creativecommons.org\/l\/by-sa\/3.0\/88x31.png\" alt=\"by-sa\" \/><\/a><\/div><!--<rdf:RDF xmlns=\"http:\/\/creativecommons.org\/ns#\" xmlns:dc=\"http:\/\/purl.org\/dc\/elements\/1.1\/\" xmlns:rdf=\"http:\/\/www.w3.org\/1999\/02\/22-rdf-syntax-ns#\"><Work rdf:about=\"\"><license rdf:resource=\"http:\/\/creativecommons.org\/licenses\/by-sa\/3.0\/\" \/><\/Work><License rdf:about=\"http:\/\/creativecommons.org\/licenses\/by-sa\/3.0\/\"><requires rdf:resource=\"http:\/\/creativecommons.org\/ns#Attribution\" \/><permits rdf:resource=\"http:\/\/creativecommons.org\/ns#Reproduction\" \/><permits rdf:resource=\"http:\/\/creativecommons.org\/ns#Distribution\" \/><permits rdf:resource=\"http:\/\/creativecommons.org\/ns#DerivativeWorks\" \/><requires rdf:resource=\"http:\/\/creativecommons.org\/ns#ShareAlike\" \/><requires rdf:resource=\"http:\/\/creativecommons.org\/ns#Notice\" \/><\/License><\/rdf:RDF>-->","protected":false},"excerpt":{"rendered":"<p>Package management\u00a0is the seemingly simple task of administering software installation, upgrade, and removal. Like many things, it&#8217;s only simple when you squint your eyes from half a mile away &#8212; as you get closer to the problem, it grows increasingly complex. This is part of the reason why, almost every week, we hear about a<\/p>\n","protected":false},"author":6,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spay_email":"","footnotes":"","jetpack_publicize_message":"","jetpack_is_tweetstorm":false},"categories":[25,13,14,24],"tags":[],"class_list":["post-1213","post","type-post","status-publish","format-standard","hentry","category-apps","category-open-source","category-operating-systems","category-packaging"],"jetpack_featured_media_url":"","jetpack_publicize_connections":[],"jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p23Tsn-jz","_links":{"self":[{"href":"https:\/\/redmonk.com\/dberkholz\/wp-json\/wp\/v2\/posts\/1213","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/redmonk.com\/dberkholz\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/redmonk.com\/dberkholz\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/redmonk.com\/dberkholz\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/redmonk.com\/dberkholz\/wp-json\/wp\/v2\/comments?post=1213"}],"version-history":[{"count":0,"href":"https:\/\/redmonk.com\/dberkholz\/wp-json\/wp\/v2\/posts\/1213\/revisions"}],"wp:attachment":[{"href":"https:\/\/redmonk.com\/dberkholz\/wp-json\/wp\/v2\/media?parent=1213"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/redmonk.com\/dberkholz\/wp-json\/wp\/v2\/categories?post=1213"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/redmonk.com\/dberkholz\/wp-json\/wp\/v2\/tags?post=1213"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}