Ist Snap über andere UNIX portierbar (Beispiel macOS)?

8

Ich liebe die Idee hinter Snap und spielte damit auf einer Ubuntu-VM.

  

Snapcraft Übersicht

     

Snapcraft ist ein Tool zum Bauen und Verpacken, mit dem Sie Ihre Verpackung verpacken können   Software als Kinderspiel. Es erleichtert die Integration von Komponenten aus   verschiedene Quellen und bauen Technologien oder Lösungen. Schlüsselkonzepte

     

Ein .snap-Paket für das Ubuntu Core-System enthält all seine   Abhängigkeiten. Dies hat ein paar Vorteile gegenüber herkömmlichen deb oder   rpm-basierte Abhängigkeitsverarbeitung, die wichtigste ist, dass a   Entwickler können immer sicher sein, dass es keine Regressionen gibt   ausgelöst durch Änderungen am System unter ihrer App.

     

Snapcraft erleichtert das Bündeln dieser Abhängigkeiten, indem es Ihnen erlaubt   Geben Sie sie in der Datei "snapcraft.yaml" als "Teile" an. Bissig

     

Snappy Ubuntu Core ist eine neue Version von Ubuntu mit Transaktionsfunktionen   Updates - ein minimales Server-Image mit den gleichen Bibliotheken wie heute   Ubuntu, aber Anwendungen werden durch einen einfacheren Mechanismus zur Verfügung gestellt.

     

Snappy Apps und Ubuntu Core selbst können atomar aktualisiert werden und   bei Bedarf zurückgerollt. Apps sind auch streng begrenzt und Sandboxed   um Ihre Daten und Ihr System zu schützen.

IoT> Apps erstellen

Welche Technologien basieren auf Snap? Wie sehen die Architektur und die Toolkits aus? Ist Snap abhängig von Linux-Kernel-Funktionen?

Ich frage, weil ich mich frage, ob ich in Zukunft die gleichen Snap-Pakete auch auf macOS verwenden kann?

Klärung, nach dem ersten Kommentar:

Ich weiß, dass macOS und Ubuntu nicht binärkompatibel sind. Ein Neukompilieren ist erforderlich. Es gibt fast jede verfügbare Open Source für macOS mit Homebrew . Der Entwickler könnte unter macOS entwickeln und auf Ubuntu bereitstellen, wenn snap (in Zukunft) für macOS verfügbar sein wird.

    
Ivanov 25.06.2016, 21:13

2 Antworten

18

Ja, dank der Stabilität der Linux-Syscall-Schnittstelle ist dies möglich.

Eine der großen Verpflichtungen von Linus Torvalds gegenüber Linux-Benutzern ist, dass die vom Kernel angebotenen Schnittstellen stabil sind. Viele Menschen schätzen den Wert oder die Herausforderung als Leiter eines offenen Projekts, um dieses Engagement zu erreichen. Stellen Sie sich zum Beispiel vor, wie unvorhersehbar Änderungen an den GNOME-APIs sind! Wenn man hört, dass Linus auf einer Mailing-Liste intensiv wird, dann ist es fast immer so, dass ein Committer zum Kernel sich dafür entschieden hat, ein solches Interface zu ändern, "weil sie eine bessere Idee hatten". Linus sagt, Sie können INNERHALB des Kernels stark innovieren, aber bitte unterbrechen Sie nicht die 'Userspace'-Apps, die von bestehenden Systemaufrufen abhängig sind.

Als Konsequenz dieser Stabilität ist es möglich, dass andere Kernel dieselben Systemaufrufe anbieten, so dass auf Linux gebaute Anwendungen auf diesen anderen Kernen ausgeführt werden können.

Ein Beispiel dafür ist das Projekt Joyent Triton, das Linux-kompatible Systemaufrufe in Containern auf SmartOS (einem Nachkommen von IllumOS, einem Nachkommen von Solaris) anbietet.

Ein bekannteres Beispiel ist das neue Linux-Subsystem in Windows .

Natürlich, wie viele der Systemaufrufe angeboten werden und wie Bug-for-Bug kompatibel sind, ist die eigentliche Frage. Zumindest für den Moment gibt es keine andere Umgebung, in der alle notwendigen Syscalls vorhanden sind, weil die Snaps, die sie verwenden, relativ neu und tief in der Art sind, wie der Kernel über die Dinge denkt, die er verwaltet.

Aber sie werden mit Sicherheit rechtzeitig kommen, und ich denke, dass Schnappschüsse damit in einer Vielzahl von Kontexten verwendbar sein werden.

Was ist sehr cool, Patches willkommen:)

    
Mark Shuttleworth 26.06.2016, 12:49
9

Ich kann zwar keine Informationen über macOS finden, aber dieses OMG! Ubuntu Artikel hat ein interessantes Zitat von Mark Shuttleworth:

  

Wie zum Ausführen von Snaps unter Windows 10? "Es ist absolut plausibel"   Shuttleworth sagte.

     

"Snaps verwenden moderne Funktionen im Linux-Kernel, um Sicherheit zu gewährleisten   Eingrenzung, Einrichten des Dateisystemzugriffs usw., und das alles beinhaltet   Verwendung moderner Mechanismen im Kernel. Und Canonical führt eine Menge   [diese Arbeit]. Es wird eine Weile dauern, bis Microsoft [sich einklinken kann   es]. "

Wenn es "plausibel" ist, es in Windows laufen zu lassen, würde ich dasselbe für macOS sagen, außer dass Microsoft mit Canonical zusammenzuarbeiten scheint, was ich nicht von Apple gehört habe.

Die Dokumentation zu Snap Sicherheitsrichtlinie und Sandboxing und Der Arch Wiki Eintrag auf Snapd ist informativ:

Aus dem Arch Wiki:

  

Beachten Sie, dass snap-confine mit der Option --disable-confinement erstellt wird.   Die vollständige Beschränkung basiert auf einem AppArmor-aktivierten Kernel und verwandten   Profil für den Snap.

Aus der Richtlinie:

  

Unter der Haube der Launcher:

     
  • Richtet verschiedene Umgebungsvariablen ein: [...]
  •   
  • Wenn dem Snapshot Hardware zugewiesen wird, wird eine Geräte-C-Gruppe mit Standardgeräten (z. B. / dev / null, / dev / urandom usw.) und allen Geräten eingerichtet   die diesem Snap zugeordnet sind
  •   
  • Richtet ein private / tmp mit einem privaten Mount-Namespace pro Befehl und einem Verzeichnis pro Befehl unter / tmp
  • ein   
  • Richtet eine pro-Befehl-devpte neue Instanz ein
  •   
  • Richtet den seccomp-Filter für den Befehl
  • ein   
  • Führt den Befehl unter dem befehlsspezifischen AppArmor-Profil unter einem standardmäßigen nice-Wert
  • aus   

Diese Kombination restriktiver AppArmor-Profile (die Datei vermitteln   Zugriff, Anwendungsausführung, Linux-Funktionen (7), mount, ptrace,   IPC, Signale, grobkörnige Vernetzung), klar definiert   Anwendungsspezifische Dateisystembereiche, Whitelist-Syscall-Filterung über   seccomp, private / tmp, neue Instanz devpts und Device cgroups bietet   für starke Anwendungseinschränkung und -isolierung.

Während AppArmor und seccomp nur Linux sind, sieht es so aus, als könnte Confinement optional sein, also können wir das ignorieren. Dann gibt es die Verwendung von devpts, cgroups und mount namespaces. Wenn es irgendwelche Blockaden gibt, denke ich, dass es für diejenigen wäre. Ich bin nicht genug vertraut mit den BSDs zu sagen, was die Entsprechungen sind.

Die snapd -Anwendung selbst ist in Go geschrieben, was sie einigermaßen plattformübergreifend machen sollte. Tatsächlich haben einige Dateien sehr interessante Build-Ziele :

>

osutil/group_other.go :

// -*- Mode: Go; indent-tabs-mode: t -*-
// +build !linux,!darwin,!freebsd

osutil/group_linux.go :

// -*- Mode: Go; indent-tabs-mode: t -*-
// +build darwin freebsd linux
// +build cgo

Es sieht also so aus, als hätte jemand Interesse daran.

    
muru 25.06.2016 22:28

Tags und Links