<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 29, 2015 at 11:10 AM, Michael Catanzaro <span dir="ltr">&lt;<a href="mailto:mcatanzaro@gnome.org" target="_blank">mcatanzaro@gnome.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":in" class="a3s" style="overflow:hidden">The point is that you can update to the newest versions of applications<br>
as they are released upstream, without having to worry about whether there could be incompatibilities with system<br>
libraries.</div></blockquote></div><br>Well, someone still has to create the &quot;snappy&quot; packages, correct?  I don&#39;t see how the fact that applications can be</div><div class="gmail_extra">containerized speeds up the process.  One could point out that the fact each application is isolated that removes </div><div class="gmail_extra">some of the burden from the packager to check requisites and dependencies - however what you get is duplication of</div><div class="gmail_extra">libraries - with each application living in it&#39;s own little world.  I don&#39;t see how that ensures that distributed packages are</div><div class="gmail_extra">newer.  If anything, it takes more disk space with applications potentially running old versions of libraries because the</div><div class="gmail_extra">developers didn&#39;t want to invest the effort to upgrade their application to be compatible with the latest version.  Case in </div><div class="gmail_extra">point, java apps which require specific java versions.  </div></div>