Vor einigen Wochen kündigte Canonical eine distributionsübergreifende Unterstützung für den Anwendungsbereitstellungsmechanismus Snap an, der mobile, Desktop- und Server-basierte Anwendungen unterstützen könnte. Die Ankündigung sorgte in der Linux-Gemeinschaft für Aufregung, da es kaum Anzeichen dafür gab, dass andere Linux-Distributionen Snaps unterstützen.
Snap ist der Versuch von Canonical, den Mechanismus zur Verpackung und Bereitstellung von Anwendungen auf der Linux-Plattform zu verbessern. Der Ursprung von Snap liegt in Click, einer Lösung, die Canonical 2014 für seine mobile Plattform entwickelt hat, um die Komplexität der Bereitstellung von Apps für Ubuntu-Telefon- und Tablet-Benutzer zu bewältigen – ein Ökosystem, das sich von Desktops und Servern deutlich unterscheidet. Darüber hinaus mussten Apps für Mobilgeräte eingegrenzt und in einer Sandbox untergebracht werden, damit sie nicht die gesamte Plattform gefährden.
Click ermöglichte es Entwicklern, alle Abhängigkeiten in einem einzigen App-Paket zu bündeln, so dass sich Nutzer und Entwickler keine Gedanken über kollidierende Systeme und App-Bibliotheken machen mussten. Es ermöglichte Entwicklern, die neuesten Bibliotheken in ihren Apps zu verwenden, um neue Funktionen anzubieten, da sie von den auf dem System installierten Bibliotheken entkoppelt waren.
Über Mobile hinaus zu Servern und IoT
Click entwickelte sich zu Snap und Canonical weitete seine Einsatzmöglichkeiten auf die Bereiche Server, Cloud, Internet of Things (IoT) und Desktop aus. Mit der Veröffentlichung von Ubuntu 16.04 im April hat Canonical Snap offiziell auf den Ubuntu-Desktop gebracht.
Canonical entwickelt außerdem Snappy Ubuntu Core, ein winziges Linux-basiertes Betriebssystem für groß angelegte Cloud-Container-Implementierungen, IoT-Geräte und vieles mehr sowie für alles, was übergangsweise aktualisiert werden soll und einen geringen Platzbedarf hat. Snappy Ubuntu Core funktioniert mehr oder weniger wie Googles Chrome OS und CoreOS, wo es übergangsweise Image-basierte Updates für das System und Anwendungen anbietet, die zurückgerollt werden können. Gleichzeitig bietet es die Begrenzung, die in der Container-Welt bekannt ist.
Snap ist die Seele dieser Technologie.
Das Linux-Durcheinander der App-Bereitstellung
Das bestehende App-Bereitstellungsmodell unter Linux hat viele Mängel. Die Linux-Welt ist meist in zwei Lager der App-Paketierung unterteilt: rpm und deb. Außerdem gibt es verschiedene Versionen derselben Distributionen, die unterschiedliche Bibliotheken verwenden, so dass es für App-Entwickler eine ziemliche Herausforderung ist, Apps für Linux zu paketieren.
Infolgedessen können App-Entwickler nicht von den neuesten Bibliotheken profitieren und ihren Benutzern mehr Funktionen anbieten, wenn die Distribution noch ältere Bibliotheken verwendet.
In den meisten Fällen paketieren Open-Source-App-Entwickler ihre Apps nicht für Distributionen. Beliebte oder seit langem etablierte Anwendungen werden normalerweise von den Entwicklern der Distributionen gepackt. Neuere oder weniger populäre Anwendungen werden entweder von den Upstream-Entwicklern für jede Distribution, die sie unterstützen wollen, gepackt oder gar nicht erst als Distribution angeboten. Wenn eine neue Version einer Anwendung veröffentlicht wird, testen diese Entwickler die Anwendung und stellen sie dann für die Distro zur Verfügung. Wie Sie sehen, schreibt nicht nur ein App-Entwickler eine App für die gesamte Plattform, in diesem Fall Linux, sondern es gibt viele Leute, die diese App den Nutzern zur Verfügung stellen.
Das erhöht die Komplexität.
Es gibt Fälle, in denen Windows und MacOS die neuesten Versionen sofort erhalten, da die Apps von den Hauptentwicklern gepackt werden, während Linux-Distros eine Weile brauchen können. Manche Distributionen bekommen sie schnell, andere müssen Wochen oder Monate warten.
Bei kommerziellen Anwendungen wie Skype, Dropbox oder Chrome liegt es in der Verantwortung des Hauptentwicklers, die Anwendungen zu paketieren und Binärdateien für verschiedene Distributionen anzubieten. Viele Apps funktionieren nicht auf älteren, aber dennoch unterstützten Versionen vieler Distributionen.
Mit einem Wort, es ist ein Chaos.
Selbst der Schöpfer von Linux, Linus Torvalds, ist mit dem bestehenden Modell zur Bereitstellung von Apps unter Linux nicht zufrieden. Er bietet unter Hinweis auf dieses Chaos keine Binärdateien seiner Anwendungen für die Linux-Plattform an. Dirk Hohndel, der Betreuer von Subsurface (einem von Linus ins Leben gerufenen Projekt), erklärte: „Die derzeitige Situation mit Dutzenden von Distributionen, jede mit anderen Regeln, jede mit anderen Versionen verschiedener Bibliotheken, bei einigen fehlen bestimmte Bibliotheken, jede mit anderen Paketierungswerkzeugen und Paketierungsformaten … das sagt App-Entwicklern im Grunde: ‚Geht weg, konzentriert euch auf Plattformen, die sich um Anwendungen kümmern.
„Die Paketierung von Anwendungen ist enorm wichtig, aber auch die Herkunft und Wartung aller beteiligten Komponenten“, stimmt Gunnar Hellekson, Director of Product Management bei Red Hat Enterprise Linux, zu.
Snap wurde entwickelt, um etwas Ordnung in diesen Zustand zu bringen. Aber ob es angenommen wird, ist eine ganz andere Frage.
Hellekson argumentierte, dass Tools wie Snap „Interoperabilitätsprobleme zwischen Linux-Distributionen nicht auf magische Weise lösen, sondern den Anbietern von Anwendungen mehr Verantwortung für Wartung und Sicherheit übertragen. Auf diese Weise könnten sie die Entwicklung unter Linux trotz der vielen Vorteile für die Benutzer noch schwieriger machen.“
„Die Vorteile von Snap stehen in direktem Zusammenhang mit seinen Nachteilen … im Wesentlichen ist Snap das Äquivalent von statischem Linking – es ist einerseits bequem, andererseits schafft es Duplikation und Herausforderungen in Bezug auf Sicherheit (und Sicherheits-Patching)“, sagte Gerald Pfeifer, SUSE Vice President of Products and Technology Programs.
Doch nicht jeder ist derselben Meinung. Brandon Philips, Mitbegründer und Chief Technology Officer von CoreOS, sagte uns, dass Container die Zukunft von Anwendungen unter Linux sind. Aber Docker-Container können nicht überall eingesetzt werden. Sie haben ihre Grenzen. Was wir brauchen, ist eine Container-ähnliche Lösung, so etwas wie Snap.
In einem anderen Interview sagte uns der führende Linux-Kernel-Entwickler Greg Kroah-Hartman, dass Android bereits seit acht oder neun Jahren Container „für Ihre Anwendungen einsetzt. Jede Anwendung läuft in ihrem eigenen Namespace. Sie kann nicht über diesen hinaus sehen. Das ist die Art und Weise, wie man es machen muss. Das ist die Zukunft von Linux und der Art und Weise, wie Systeme funktionieren.“ Er sagte, Snap sei das gleiche Konzept, die gleiche Idee.
Snap Goes Cross Platform
Der Erfolg von Snap hängt stark davon ab, ob es von der größeren Open-Source-Gemeinschaft angenommen wird. Was nützt ein App-Format, wenn es niemand nutzt? Als reine Ubuntu-Technologie, die möglicherweise nicht einmal von ihren Derivaten wie Linux Mint, KDE neon oder elementary OS offiziell unterstützt wird, könnte Snap eine nicht so erfolgreiche Karriere bevorstehen.
Als Canonical Snap ankündigte, behauptete es in einer Pressekonferenz, dass es mit verschiedenen Distributionen zusammenarbeitet, um Unterstützung für Snap hinzuzufügen.
Canonical sagte, dass Snaps nativ für Arch, Debian, Fedora, Kubuntu, Lubuntu, Ubuntu GNOME, Ubuntu Kylin, Ubuntu MATE, Ubuntu Unity und Xubuntu verfügbar sind. Canonical arbeitet auch an der Validierung von Snaps auf CentOS, Elementary, Gentoo, Mint, OpenSUSE, OpenWrt und Red Hat Enterprise Linux.
Canonical und SUSE sind derzeit nicht in die Entwicklung rund um die Zusammenarbeit bei Snaps involviert, und in der Tat sieht es so aus, als ob dies nicht das Ergebnis eines offenen Community-Designs und einer offenen Entwicklung war“, so Gerald Pfeifer, SUSE.
Die Ankündigung von Canonical, mit anderen Distributionen zusammenzuarbeiten, stieß bei einigen Mitgliedern der Open-Source-Community auf Kritik. Fedora-Entwickler nahmen diese Ankündigung nicht gut auf und kritisierten Canonical mit der Begründung, dass es keinerlei Zusammenarbeit zwischen den beiden Projekten gebe.
Als wir den Gründer von Canonical, Mark Shuttleworth, zu diesen Vorwürfen befragten, antwortete er: „Wir haben uns mit dem Desktop-Team von Red Hat kurzgeschlossen und sind immer offen für eine Zusammenarbeit mit allen Linux-Distributionen, um Snaps zu ermöglichen.“
Für Red Hat, das die Fedora-Distribution betreut, war dies jedoch eine Neuigkeit.
„Wir arbeiten mit Canonical in mehreren Communities zusammen, waren aber genauso überrascht wie alle anderen, als sie unsere Beteiligung an dieser speziellen Initiative bekannt gaben. Wir sind offen für weitere Diskussionen und wollen sehen, wie die Linux-Gemeinschaft insgesamt zusammenarbeiten möchte“, sagte Hellekson.
SUSE-Vertreter spielten ebenfalls jegliche Zusammenarbeit herunter. „Canonical und SUSE sind derzeit nicht an der Entwicklung von Snaps beteiligt, und es sieht tatsächlich so aus, als ob dies nicht das Ergebnis einer offenen Community-Entwicklung war“, sagte Pfeifer.
Was passiert zu sein scheint, ist, dass Canonical mit einigen Entwicklern, vielleicht nur einer Handvoll, anderer Projekte zusammengearbeitet hat und diese bei der Paketierung von Snaps für andere Distributionen geholfen haben.
Canonical ist nicht perfekt
Ein Teil des Rückschlags, den Canonical erhalten hat, könnte ein Nebenprodukt der Art und Weise sein, wie das Unternehmen Geschäfte macht.
Zum einen halten andere Linux-Unternehmen, wie Red Hat und SUSE, eine sehr klare Gewaltenteilung aufrecht, wenn es um Fedora und openSUSE geht. Fedora und openSUSE sind ziemlich unabhängige, von der Community betriebene Projekte, bei denen die Entscheidungen von den Community-Mitgliedern und nicht von den sponsernden Unternehmen getroffen werden.
Im Gegensatz dazu ist Ubuntu ein Produkt von Canonical, das zufällig auch ein Community-Projekt ist. Dadurch hat Canonical im Gegensatz zu openSUSE und Fedora die direkte Kontrolle über Ubuntu. Wir haben bereits im Fall von ownCloud gelernt, dass es sehr schwer ist, die Balance zwischen den Bedürfnissen der Community und des Unternehmens zu halten; das endet oft in einem Desaster wie ownCloud.
Es stellt sich die Frage, wie man mit einem Projekt ‚arbeitet‘?
Auch haben viele das Gefühl, dass es bei Ubuntu an Transparenz fehlt. Zeitweise haben viele führende Ubuntu-Mitwirkende ihre Frustration darüber zum Ausdruck gebracht, dass Canonical wichtige Ankündigungen rund um Ubuntu unter Verschluss gehalten hat, sogar vor den Kernmitgliedern versteckt. Ubuntu-Mitglieder hatten keine Ahnung von Ubuntu für Windows oder dem unglücklichen Edge-Projekt.
„Wir halten nichts zurück“, antwortete Jim Whitehurst, CEO von Red Hat, auf eine Frage über den Ansatz des Unternehmens in Bezug auf Open Source. „Wenn wir etwas bauen, verstecken wir es nicht vor den Leuten, um eine große Enthüllung zu machen und zu sagen: ‚Hier ist der Code.‘ Das tun wir nicht. Wir arbeiten vom ersten Tag an in Communities, die ganze Zeit über. Ich denke, wir versuchen, wirklich gute Teilnehmer zu sein, und ich denke, das kommt durch.“
Zusätzlich zu diesen Unterschieden ist Canonical auch dafür bekannt, einige Fehltritte zu begehen, wenn es um die Veröffentlichung von Informationen geht. Dies scheint bei der Ankündigung der distributionsübergreifenden Unterstützung für Snap der Fall zu sein; die Formulierung, die Fedora-Entwickler verärgerte, lautete „Entwickler von mehreren Linux-Distributionen“. Um das klarzustellen: Canonical hat in seiner Pressemitteilung nie ausdrücklich erwähnt, dass es mit Fedora zusammenarbeitet. Und basierend auf den Informationen, die wir gesammelt haben, gab es keine „offizielle“ Zusammenarbeit mit Linux-Distributionen wie Fedora, Red Hat, SUSE oder anderen.
Abgesehen davon stellt sich die Frage, wie man mit einem Projekt „arbeitet“? Wenn ein Entwickler, der an einer App arbeitet, mit einem Ubuntu-Entwickler, einem Fedora-Entwickler und einem openSUSE-Entwickler zusammenarbeitet, um diese App auf diese Plattformen zu bringen, wäre es dann falsch zu sagen, dass der Entwickler mit mehreren Distributionen zusammengearbeitet hat, um die App auf diese Plattformen zu bringen? Oder braucht der Entwickler eine offizielle Zusammenarbeit mit den Projektleitern dieser Distributionen, um eine solche Aussage treffen zu können? Es handelt sich schließlich um eine verteilte Open-Source-Gemeinschaft.
Wo ist Snap?
Die größere Frage ist, ob Snap offiziell von anderen Distributionen übernommen wird? Das ist der Punkt, an dem die Dinge ein wenig kompliziert werden. Es wird eine technologische und politische Frage.
Zunächst einmal ist Snap nicht die einzige Lösung, die es gibt. Es gibt viele Projekte, die versuchen, ein distro-agnostisches Paketierungs-Ökosystem für das Linux-Ökosystem anzubieten. Aber es kann schwierig sein, einen Konsens innerhalb der Linux-Distro-Welt zu finden. Es gibt AppImage und Flatpak, die geeignete Alternativen zu Snap bieten; diese Projekte gibt es schon viel länger als Snap.
Warum hat Canonical also nicht diese Lösungen übernommen, anstatt Click oder Snap zu starten?
„Wir haben uns das angeschaut und festgestellt, dass AppImage perfekt für ‚leaf-node‘ Desktop-Anwendungen funktioniert“, sagte Shuttleworth. Eine Leaf-Node-Anwendung ist eine Anwendung, die nicht mit einer anderen Anwendung integriert werden muss. Snap wurde eher für die Bündelung von Anwendungen mit Abhängigkeiten und verwandten Anwendungen entwickelt. „Snaps haben eine Reihe von Möglichkeiten, diese Verbindungen zu beschreiben – Schnittstellen, Stecker und Steckplätze sowie gemeinsam genutzte Dateien und so weiter.“
Darüber hinaus erklärte Shuttleworth, dass Snap im Vergleich zu AppImage für ein höheres Maß an Sicherheit konzipiert wurde, zum einen, weil das Team, das an dem Mobiltelefon arbeitete, sich auf Sicherheit und Effizienz konzentrierte, und zum anderen, weil Snap neuere Kernel-Funktionen nutzt.
Flatpak fiel angeblich der Rivalität zwischen Canonical und Red Hat zum Opfer, als es von Fedora-Leuten entwickelt wurde. Als ich nachfragte, wies Shuttleworth es als ein Projekt ab, das von einem einzigen Entwickler entwickelt wurde.
Das erklärt, warum Canonical mit Snap vorangegangen ist.
Werden nun andere Distributionen es übernehmen? Fedora-Entwickler haben bereits erklärt, dass sie Snap nicht verwenden werden. Ein Fedora-Entwickler schrieb auf der Mailingliste: „Wir haben natürlich keinerlei Pläne, Snappy in Fedora zu übernehmen, und tatsächlich arbeiten mehrere Fedora-Entwickler an einer konkurrierenden Lösung, Flatpak.“
Red Hat hat zuvor ein Canonical-Projekt für die Systeminitialisierung namens Upstart übernommen. Hellekson sagte: „Dies sind noch sehr frühe Tage für all diese Paketierungsbemühungen, und wir freuen uns auf die Zusammenarbeit mit allen verwandten Gemeinschaften, um das Leben für Linux-Benutzer so einfach wie möglich zu machen.“
Abgesehen von der Rivalität zwischen Red Hat und Canonical gibt es einige technische Probleme, die andere Projekte von einer Zusammenarbeit bei Snap abhalten könnten. Einer dieser Gründe ist, dass Entwickler ein CLA (Contributor License Agreement) unterschreiben müssen, wenn sie zum Snap-Projekt beitragen. Michael Hall, ein Canonical-Entwickler, sagte, dass ein CLA benötigt wird, wenn ein Entwickler zum Snap-Projekt selbst beitragen möchte. Es ist kein CLA erforderlich, um Snaps von Anwendungen zu erstellen oder zu vertreiben.“
CLAs erlauben Canonical, die Lizenz des Projekts zu ändern. Das ist vorteilhaft für Canonical, da sie ein Projekt neu lizenzieren können, so dass es mit unfreien oder inkompatiblen Lizenzen verwendet werden kann. Entwickler mögen CLAs in der Regel nicht.
Frank Karlitschek von Nextcloud teilte uns mit, dass er CLAs bei Nextcloud kündigt, da er der Meinung ist, dass CLAs in der Open-Source-Gemeinschaft keinen guten Ruf haben.
Auf unsere Frage an Red Hat, ob CLAs die Zusammenarbeit rund um Snap beeinträchtigen, sagte Hellekson: „Contributor License Agreements erschweren uns die Teilnahme. Wir glauben, dass eine unkomplizierte Open-Source-Lizenzierung ein besserer, umfassenderer Ansatz ist.“
Die Antwort von SUSE war ähnlich. Pfeifer sagte: „SUSE-Ingenieure und -Mitarbeiter tragen weiterhin zu einer Vielzahl von Open-Source-Projekten bei, sowohl in der Zeit des Unternehmens als auch in unserer eigenen, und wo nötig haben wir CLAs unterzeichnet. Wo und wann immer wir Projekte initiieren oder beeinflussen, versuchen wir jedoch, uns von CLAs fernzuhalten.
Als wir Shuttleworth fragten, ob er in Erwägung ziehen würde, CLAs von Snap fallen zu lassen, um eine breitere Unterstützung von anderen Distros zu erhalten, erklärte er zunächst, warum CLAs gut sind, sagte dann aber auch, dass „wenn das einen Unterschied machen würde, dann ja, wir einen Weg finden würden, sie fallen zu lassen.“
Und dann war da noch einer?
Mit der Zeit, der Reife, der Popularität und der technischen Überlegenheit des einen gegenüber dem anderen, bleibt uns vielleicht nur eine Lösung. Wir haben das schon einmal bei Upstart und systemd gesehen, wo sich systemd als überlegene Technologie herauskristallisierte und zum Standard in allen drei führenden Linux-Distributionen wurde: Ubuntu, RHEL und SUSE.
In jedem Fall befinden sich beide Technologien in einem sehr frühen Entwicklungsstadium, und es ist schwer zu sagen, welches Projekt sich durchsetzen wird. Es ist jedoch ziemlich klar, dass Linux in der Container-zentrierten Welt einen neuen Mechanismus für die Bereitstellung von Anwendungen benötigt.
Viele Unternehmen und Communities haben ihre Unterstützung für Lösungen wie Snap zum Ausdruck gebracht. Samsung und Dell schlossen sich Canonical in der Pressekonferenz an und betonten die Notwendigkeit einer solchen Lösung. Auf der Desktop-Seite haben Projekte wie LibreOffice und Firefox bereits ihre Unterstützung für Snap bekundet.
Die Zeit wird zeigen, ob Snap außerhalb von Ubuntu angenommen wird oder nicht. Was auch immer die Zukunft für Snap bereithält, wir sollten Canonical gebührend dafür loben, dass es die Grenzen überschritten und den Rest der Linux-Gemeinschaft dazu gezwungen hat, sich endlich auf die Lösung eines Problems zu konzentrieren, mit dem wir entweder so vertraut geworden waren oder vielleicht nie die Motivation hatten, es zu lösen.
CoreOS und Red Hat sind Sponsoren von The New Stack.