Irgendwann zu Anfang als das Gerede über Snappy los ging war da auch mal die Rede von Live Patching wenn ich mich nicht Irre das war genau aus diesem Grunde angedacht damit nicht immer ganze Pakete geladen werden müssen.
So das in einem Falle von einem Update nur die DLL und das Update Skript geladen werden muss genau wie es beim 4rer Kernel auch kommen soll mit dem Live Patching.

>> Dieses vorgehen hat durchaus auch vorteile, da der Anbieter eines Containers genau weis, welche version welcher Bibliothek du hast

Das glaubst du doch selber nicht.
Du musst dir doch nur mal das Beispiel Docker ansehen. Da sagt der Provider eines Containers : Ich brauch nginx, also apt-get install nginx
Welche Bibliotheken damit auf in dem Container landen, darüber hat der Provider doch weder wissen noch Kontrolle, es sei denn er baut seinen Container mit LFS. Das sich diese Provider auf die notwendigen CVE Kanäle subscriben möchte mal ganz stark bezweifeln.

De facto sind Container im Moment brandgefährlich, weil sich offenbar niemand dafür verantwortlich fühlt, die Frage nach Security Upgrades befriedigend zu lösen. Was passiert denn, wenn jemand einen Container mit einem veralteten Sudo oder ein Shellshock Bash auf den "Host" kippt? Ob man will oder nicht, alle Container Inhalte sind schließlich auch für den Host verfügbar...

"und im Zweifelsfall sitzt der Endanwender mit einer veralteten Bibliothek da......."

Genau - und merkt es vermutlich nicht einmal, so wie unter Windows, wo Nutzer jahrelang Ihre uralten Programmversionen einsetzen und dabei kein Stück über die Systemsicherheit nachdenken. Microsoft ist das egal, da es sich ja nicht um Fremdsoftware kümmern muss.

IMO wird Ubuntu ähnlich vorgehen und viele Pakete einfach gar nicht mehr updaten, vor allem die in Universe und Multiverse nicht, so wie das ja fast flächendeckend schon heute der Fall ist. Das dürfte dann die meisten Probleme "lösen".

Auf sicherheitskritischen Rechnersystemen wird IMO Ubuntu dann gar nicht mehr eingesetzt werden, da ein umsichtiger Systemadmin unter Umständen schon weiß, was Ihm blühen kann, nämlich eine Art reversive Dependency Hell beim Update, da er nach einiger Zeit den Überblick darüber verlieren kann, welches Snappy-Paket zu welchem Zeitpunkt mit welchen alten Paketen installiert oder upgedatet wurde. Das ist IMO vergleichbar einem System, in das man unter Umgehung der Paketverwaltung Tarball um Tarball hineininstalliert hat und irgendwann auch nicht mehr weiß, was an Bibliotheken so installiert ist. IMO ist Snappy geradezu prädestiniert für rasche Installationen Dritter, also von Nicht-Distributionssoftware, die man auch malwaremäßig wird ausnutzen können. Einfacher Doppelklick und fertig.

Hätte Ubuntu eine effektive Paketverwaltung wie openSUSE, die in der Lage ist, reversibel unterschiedliche Versionen einer Software jeweils einzeln zu installieren, dann bräuchte Ubuntu kein Snappy. Snappy soll IMO nur den Kardinalfehler von Apt mitbeheben helfen, nicht gleichzeitig mit zig Repositorien auf einfache Weise umgehen zu können. IMO will niemand z.B. Inkscape in zig verschiedenen Versionen nebeneinander installiert haben, sondern jeweils nur die gewünschte alte, aktuelle oder Bleeding-Edge-Version. Und genau die nachträgliche Installation der beiden zuletzt genannten bekommt ein Debian oder Ubuntu "Stable" kaum auf einfache Weise hin. Apt-Pinning ist nichts für Otto Normalnutzer, Priorities über eine funktionierende GUI hingegen schon. Apt und Synaptic bieten hierzu nichts und auch die Red Hat-Paketverwaltung, so wie diese u.a. in RHEL6 als GUI in Erscheinung tritt, ist im Hinblick auf den obigen Sachverhalt an Rückständigkeit nicht zu überbieten.

Bietet Ubuntu hingegen eine Art mehrfach differenzierte Snappy-Serversoftwarecollection an, die für ganz bestimmte Zweck eingesetzt wird und dessen zehn- bis dreizehnjährigen Support Ubuntu dann übernimmt, dann könnte das durchaus erfolgreich sein, als eine Art Speziallösung für besondere Anforderungen.

Was hingegen auf dem Nutzerdesktop ablaufen wird, ist IMO nicht relevant, da hiermit kein Geld verdienen wird. Die Leute bekommen Ihre wahllosen Snappy-Apps über die dafür "verantwortliche" Ubuntu-Community und können sich dann ja dort beschweren, wenn etwas nicht klappt.

Und für die gleichzeitige Installation von unterschiedlich alten Versionen des gleichen Programms gibt es schon lange Konzepte, die Debian und Ubuntu nur niemals einsetzen. Schon zu Suse-Zeiten war das möglich und wurde - falls benötigt - auch massiv praktiziert (Ich verstehe auch nicht, warum der Autor hierauf nicht explizit eingeht, schließlich ist gerade Suse für seine Distributionen, die Altbewährtes nahtlos mit Bleeding Edge-Software verbanden, bekannt gewesen.). IMO ist Snappy nicht eine Lösung für ein vorhandenes Linux-Problem, sondern nur eine Art Versuchslösung für Debian- und Ubuntudefizite in der Paketverwaltung und "Stable"-Distributionszusammenstellung. Sich das riesige Debianarchiv als Sammelsurium an Snappypaketen vorzustellen, ist IMO ein absoluter Alptraum für Maintainer, die Unübersichtlichkeit wäre quasi vorprogrammiert. Wenn ich da nur an die manchmal notwendigen Non-Maintainer-Uploads denke, dann weiß ich, dass Snappy in Debian offiziell keine Chance haben wird.

Zudem gibt es wirkliche Probleme. Ein Beispiel: Noch in Debian Squeeze konnte Synaptic gleichzeitig ohne Fehler Pakete installieren und deinstallieren, das funktioniert in moderneren Versionen gar nicht mehr (so erhalte ich hier plötzlivh sog. Nicht-authentifiziert-Meldungen, obgleich nur Debian Main am Werkeln ist). Die RHEL6-Paketverwaltung verhindert das gleich von vornherein. Aber Ubuntu setzt hier niemals an, das wäre auch zu unspektakulär, zu bodenständig und zu einfach. Ubuntu will wie dereinst Shuttleworth immer nur eines: Zu den Sternen!

Eher wohl eine Lösung wie diese hier:

Es erlaubt Softwareentwicklern, Programme direkt auf ihren eigenen Webseiten zu veröffentlichen und bietet dabei Funktionen, die man von zentralen Repositorien gewöhnt ist, wie z.B. gemeinsam genutzte Bibliotheken, automatische Updates und digitale Signaturen. Es ist als Ergänzung und nicht als Ersatz zur Paketverwaltung des Betriebssystems gedacht. Zero Install-Pakete verursachen nie Konflikte mit Paketen, die von der Distribution zur Verfügung gestellt werden.

Pro-Linux: Zeroinstall