News Canonical: Snappy soll universelles Paketformat werden

fethomm

Commander
Registriert
Okt. 2012
Beiträge
2.597
Canonical hat mit der Ankündigung, Snappy zum universellen Paketformat für Linux machen zu wollen, für Aufregung in der Linux-Szene gesorgt. Damit soll eine weitere Eigenentwicklung Canonicals in den Markt gedrückt werden. Bisher war das Unternehmen damit nicht sonderlich erfolgreich.

Zur News: Canonical: Snappy soll universelles Paketformat werden
 
Snappy ist ein Vorstoß für kommerzielle Softwareunternehmen mit proprietärer Software unter Linux zu etablieren.
So gleich mit App Store Zwang wie bei Windows Mobile, IOS und in Maßen auf Android wenn möglich.
Das ist sowas von wahnsinnige Hybris, man glaubt es kaum.

Mal eine Gegenfrage: wann hat sich irgendwas, was Canonical entwickelt hat, in der Linux Community durchgesetzt? Upstart, Mir, Unity, etc. Irgendwie fällt mir einfach nix ein.
 
Manche Ideen sind ja gut, aber wie man es mit der Community umsetzt, da müssen die noch immer viel lernen.
 
Das Schöne an Linux ist, man hat die Wahl, sprich man braucht solch ein Paketsystem nicht zu benutzen.
 
Die Idee finde ich ja gut. Aber Eigenenbrödlerei hat unter Linux nix verloren.
Besser wäre eine offene Einheitslösung aller großen Distris.
Diese Abhängigkeiten vom klassischen Paketmanager der Distri muss aufgebrochen werden.
Hat vielleicht im Firmenumfeld Sinn wo sowieso administriert wird aber wieviel % aller Desktops sind das schon.
Und es macht es Herstellern einfacher ihre Closed Source zu warten/vertreiben.

Wo liegt eigentlich der technische Unterschied zwischen FLATPAK und SNAPPY
Laufen diese Flatpak-Apps immer in ner Sandbox und was macht Snappy anders?

Irgendwie kommt mir vor dass es mit heutigen Betriebssystemen keine guten Lösungen gibt.
Denn selbst wenn man die Apps/Programme nicht als Admin/Root installieren muss haben diese meist Leserechte Querbeet durch das Filesystem (Spionage) und teils noch Schreibrechte (Virengefahr).
Wäre es nicht so würde es keine Probleme mit den Verschlüsselungstrojanern geben.
 
Zuletzt bearbeitet:
HominiLupus schrieb:
Mal eine Gegenfrage: wann hat sich irgendwas, was Canonical entwickelt hat, in der Linux Community durchgesetzt? Upstart, Mir, Unity, etc. Irgendwie fällt mir einfach nix ein.

Naja, indirket schon. Upstart und Mir waren zwar im Alleingang mit der Brechstange reingebracht worden, haben aber dafür gesorgt, dass die offenen Alternativen Systemd und Wayland mehr Rückenwind bekommen haben. InitV und X sind halt altbacken und in ihrer Entwicklung quasi am Ende, obwohl man mittlerweile andere Anforderungen hat. So gesehen hat das "Feindbild" Canonical dafür gesorgt, dass man* dann doch lieber verstärkt freie(re) Alternativen gepusht hat.
Ich hoffe auf Bewegung in Punkto ZFS.

Bei Snaps bin ich mir nicht sicher.
- Platz: Ein einfaches Commandline-Tool kann schon mal zu einem 240MB großen Snap werden. Das kann noch ganz andere Dimensionen annehmen.
- Pflege: Klar. So ein Entwickler kümmert sich nun plötzlich selbst um die Aktualität und Securityupdates ALLER seiner mitgelieferten Abhängigkeiten. Das klappt unter Garantie nicht. Jedes Snap bringt also seine ganz eigenen Sicherheitslücken aus vergangenen Versionen irgendeines alten anderen Tools mit.
- Kompatibilität: Die Vision sagt, dass das Snap dann "überall" laufen kann. Mal abwarten, wie es wirklich klappt.

Andererseits:
Laden, Starten, Läuft. <- Genau so wünschen sich dass doch viele. Auch viele kommerzielle Anbieter könnten so endlich auch mal Linux als Basis OS in betracht ziehen. Snap raushauen und fertig. Sowohl für Server als auch für Clients
AD-kompatibler Server auf windows-Basis? Fertiges Snap laden, per Assistent einrichten. Fertig.
Gehärteter Webserver von Security-Spezialisten? Fertiges Snap laden, per Assistent einrichten. Fertig.
Server für Verwaltungstools in allen möglichen Nischen? Fertiges Snap laden, per Assistent einrichten. Fertig.
Management Tools für externe Hardware? Fertiges Snap laden, per Assistent einrichten. Fertig.
Eigener Mailserver? Fertiges Snap laden, per Assistent einrichten. Fertig.
Eigener Cloudspeicher mit ordentlicher Verschlüsselung? Fertiges Snap laden, per Assistent einrichten. Fertig.
Verschlüsselungs-Client für den Encrypted-CloudStorage? Fertiges Snap laden, per Assistent einrichten. Fertig.
Firmen Browser mit vordefinierten Links, Zertifikaten, Einstellungen und entspr. Härtung? Fertiges Snap laden, per Assistent einrichten. Fertig.

* der Fokus vieler einflussreicher aktiver Entwickler
 
Snappy ist was dynamisch verlinkte Bibliotheken angeht ein Graus. Wenn jedes Paket sein eigenes GTK+ und OpenSSL mitbringt, ist das ein Rückschritt, der zwei Jahrzehnte Arbeit der Distributionen ignoriert, möglichst nur ein Exemplar eines Stück Codes auf dem System zu haben.

Softwareanbieter freuen sich natürlich darüber. Jetzt können sie endlich alle wichtigen Distributionen mit einem einzigen Paket abdecken (bzw. eins je Architektur). Ob das in einem Jahr noch sicher ist, ist denen egal.

Mark Shuttleworth hat dieses Jahr auf der FOSDEM zur Sicherheit von Snappy Stellung genommen. Sein Argument war, dass etwaige Sicherheitsprobleme auf den Snappy-Container und dessen Rechte beschränkt bleiben...
 
Zuletzt bearbeitet:
raph schrieb:
- Pflege: Klar. So ein Entwickler kümmert sich nun plötzlich selbst um die Aktualität und Securityupdates ALLER seiner mitgelieferten Abhängigkeiten. Das klappt unter Garantie nicht. Jedes Snap bringt also seine ganz eigenen Sicherheitslücken aus vergangenen Versionen irgendeines alten anderen Tools mit.

Die Gefahren von ClosedSource Programmen gibt es doch unter Windows auch.
Seit Jahrzehnten. Darum müssen die Dinger auch ständig aktuell gehalten werden.
Richtig schlimm wird es aber wenn alte Versionen auch noch Adminrechte besitzen.

Wir brauchen etwas was außschließlich mit eingeschränkten Rechten läuft und sich auch damit installieren lässt.
Und zusätzlich am spionieren gehindert wird.
Schreibrechte eventuell nur ein gemeinsamer Ordner irgendwo.
Der ganze SUDO/UAC Quatsch ist nur nervig und wenn da mal eine Lücke drin ist dann gute Nacht.

Ok bei systemnahen Apps wie Firewall oder anderen Diensten wird es schwierig.

p.s. Grundsätzlich kann man sowieso keiner Software vertrauen. Ob nun OSS oder CSS.
Ob signiert oder nicht und keine Ahnung was man noch unternimmt. Hintertüren und Lücken können trotzdem immer vorhanden sein.
 
Zuletzt bearbeitet:
Ich finde Snappy eigentlich eine schicke Sache, habe mich aber auch noch nicht so ausführlich mit Flatpak beschäftigt. Kennt jemand die technischen Feinheiten? So wie ich es in Erinnerung habe sind die Sandbox-Fähigkeiten von Snappy weiter fortgeschritten.

Der Speicherbedarf ist aktuell wirklich noch unschön, aber daran wird ja bereits gearbeitet. Ich denke, dass das kein Dauerzustand wird. Fatal ist es bei heutigen Speicherpreisen ohnehin nicht mehr.

Primär wird es wohl wirklich darum gehen den (sinnlosen) Aufwand der Umpaketierung zu eliminieren und den Weg für kommerzielle, closed source Linux-Software zu ebnen. Bevor gleich Einwände und Beispiele kommen: Natürlich ist das auch heute bereits möglich. Es ist nur recht kompliziert und hässlich. Steam bringt daher auch eine ganze Reihe eigener Bibliotheken mit und unterstützt offiziell nur Ubuntu.

@chithanh
Das Problem ließe sich beispielsweise über Deduplikation lösen. Mehrere Versionen einer Bibliothek landen dann aber natürlich dennoch auf deinem Rechner. Das ist ja auch mehr oder weniger der Sinn der Sache.

Edit: Thema Sicherheit und Sandboxing. Meines Wissens nach ist Snappy unter X11 nicht mal wirklich sicherer als herkömmlich verteilte Software. Da gab es auch einen längeren Artikel zu. Das Argument von Shuttleworth zieht also wenn überhaupt erst unter Mir/Wayland. Dass eine Lücke auch innerhalb einer Sandbox unschön ist, ist denke ich allen bewusst. Es gibt nunmal keine perfekte Lösung, und das ist einer der Kompromisse, die man macht.

@cbtestarossa
Ich verstehe wie so oft nicht worauf du hinaus willst. Prinzipiell befürworte ja auch ich diesen Ansatz, aber warum sind die Abhängigkeiten im Firmenumfeld ok und für Privatanwender nicht? Dem DAU kann total egal sein wie der Paketmanager und die zugehörigen Pakete funktionieren. Bildchen im "App Store" anklicken, Download drücken, fertig.

Eingeschränkte Rechte sind auf jeden Fall eine gute Sache und auch Teil des Plans. Aber es gibt nunmal Dinge, die du schlecht beschränken kannst. Mein Dateimanager sollte wohl doch überall lesen und schreiben können, sonst ist der ziemlich witzlos. Und ich will auch direkt aus meinem Texteditor an einen beliebigen Ort speichern können.
 
Zuletzt bearbeitet:
Die Vorteile sind schon klar - man ist nicht mehr darauf angewiesen, daß sein Linuxsystem alle Voraussetzungen und Bibliotheken mitbringt, wenn man ein Programm installieren will.

Aber für den Fall, daß sich das durchsetzt, wieviele "Kopien" einundderselben Bibliothek wird es dann künftig in einem System geben? Mir gefällt das nicht.

Und wie soll das überhaupt mit der Überprüfung funktionieren? Der OpenSource-Gedanke beinhaltet ja auch, daß jeder die Quelle (auf mögliche Lücken, Hintertüren o.ä.) überprüfen kann. Wenn bei jedem Programmupdate der ganze Wust an Bibliotheken mitgeschleppt wird, darf man diese ja jedes mal auch wieder gegentesten?
 
Sowas gibt es schon seit Ewigkeiten in verschiedenen Formen, z. B. http://0install.net
Aber nein, man muss natürlich sein eigenes Ding machen. Aber wenn man kurz drüber nachdenkt, ist auch klar warum: Canonical möchte her über den App Store sein und darüber dann Geld verdienen.

Ich denke am Ende wird sich Flatpak durchsetzen, genauso wie bei systemd vs. upstart und Wayland vs. Mir.
 
cbtestarossa schrieb:
Die Gefahren von ClosedSource Programmen gibt es doch unter Windows auch.
Seit Jahrzehnten. Darum müssen die Dinger auch ständig aktuell gehalten werden.
Richtig schlimm wird es aber wenn alte Versionen auch noch Adminrechte besitzen.

Davon sprach ich nicht. Ist CS vs OSS ist eher weites Thema.

Die von mir erwähnte Problematik ist ja die, dass auch mit Hilfe von ausschließlich offenen Abhängigkeiten im Snap nicht ausgeschlossen werden kann, dass alte Sicherheitslücken im Paket vorhanden sind.
Wenn die Entwickler ihre eigene Sandbox nicht pflegen, ist es grob gesagt völlig wurscht, wie offen die Software ist. Alte Software bleibt alt.
Im Rahmen von kommerzieller Software ist es ja nicht unüblich, den Support ausschließlich auf mitgelieferte Versionen zu beschränken. Die wurden getestet. Alles andere wird nicht supportet. <-Punkt

Somit importieren Snaps das groß contra-CSS-Argument: Du weißt nicht was drin ist, und auch nicht, welche Lücken.
Schlimmer, Du kannst mit genügend Aufwand herausfinden, was drin ist, und welche Lücken es hat, kannst es aber nicht ändern, obwohl es prinzipiell für den Entwickler möglich wäre. Macht er aber nicht. bedeutet Viel Testarbeit. rechnet sich nicht. Issue fixed in next version.

Und dass die Software in einer Sandbox läuft ist nur bedingt beruhigend: Dein im Snap laufender Applikations-Webserver mit Kunden- und Unternehmensdaten ist ja ggf. auch in der Sandbox (wenn der Dev kein Bock hat, alle möglichen SQL-Versionen zu supporten, liefert er seinen getesteten DB-Server im Snap einfach mit.)
 
CloakingDevice schrieb:
Ich verstehe wie so oft nicht worauf du hinaus willst. Prinzipiell befürworte ja auch ich diesen Ansatz, aber warum sind die Abhängigkeiten im Firmenumfeld ok und für Privatanwender nicht? Dem DAU kann total egal sein wie der Paketmanager und die zugehörigen Pakete funktionieren. Bildchen im "App Store" anklicken, Download drücken, fertig.

Ich meinte es so..
Im Firmenumfeld hat der USER sowieso nix zu installieren und hat auch kein ADMIN/ROOT/SUDO Passwort und soll auch keine FLAPPY-Aps nachinstallieren können.
Alles was da besteht wird sowieso vom ADMIN eingerichtet. System Updates werden wahrscheinlich eh automatisch im Hintergrund eingespielt.

Im Privatbereich sieht das anders aus.
Da will man eventuell Tante Frieda einen PC vorinstallieren, ihr aber kein ADMIN/ROOT/SUDO Passwort geben. Die arbeitet als eingeschränkter USER ohne SUDO. System-Updates sollen trotzdem automatisch installiert werden (geht über die Distri).
Sie soll aber die Möglichkeit haben zusätzliche Software (die zb die Distri nicht bietet) bequem als normaler eingeschränkter USER installieren und nutzen können.

Das ein Dateimanager übergreifende Filesystem-Rechte braucht ist mir klar.
So etwas braucht Tante Frieda aber nicht nachinstallieren denn Dolphin etc. bietet meist jede Distri an.

Es geht rein um irgendwelche Software die eben NICHT in der Distri enthalten ist.
Könnte ein Spiel sein oder ein Anwendungsprogramm (von mir aus auch portable).
 
Zuletzt bearbeitet:
Im Endeffekt wäre man mit Snappy wieder dort, wo Windows ist: Bei Installern, die alle Abhängigkeiten mitbringen, was unter Windows schon immer zur DLL-Hell geführt hat. Warum nicht gleich die Paketverwaltung abschaffen? Was für die Entwickler Vorteile hat, hat für die Nutzer leider gravierende Nachteile...
 
@Photon

Darum gehören die Flappy-Apps m.M.n. auch komplett vom OS isoliert.
Damit schließt man natürlich schon diverse Programme komplett aus.

Oder man verfeinert das Rechtesystem damit man jeder APP Rechte im Filesystem zuweisen kann.
Will man einer APP Schreib Leserecht in einem Ordner erlauben dann muss dies eben einmal vergeben werden können.

Wäre auch für normale Programme ideal. Also zusätzlich zu Benutzern/Gruppen.

Aber die DLL Hell bleibt trotzdem bestehen auch wenn die Apps ihre eigenen in ihrem eigenen Ordner mitbringen.
Nur ins OS sollte da nix reinrutschen dürfen.

CloakingDevice schrieb:
Eingeschränkte Rechte sind auf jeden Fall eine gute Sache und auch Teil des Plans. Aber es gibt nunmal Dinge, die du schlecht beschränken kannst. Mein Dateimanager sollte wohl doch überall lesen und schreiben können, sonst ist der ziemlich witzlos. Und ich will auch direkt aus meinem Texteditor an einen beliebigen Ort speichern können.

Das wollen die Verschlüsselungstrojaner auch.
Überall wo sie Schreibzugriff haben wird halt verschlüsselt.
Oder diverse GameClients die mal ganz nebenbei deine gesamte Festplatte durchforsten.
Oder irgend ein Tool welches schnell mal deine Emails liest.

Rechtesystem verbessern könnte helfen.
Nicht jedes Programm braucht Lesezugriff auf jeden Ordner. Von Schreibrecht ganz zu schweigen.
 
Zuletzt bearbeitet:
Programme im Sandkasten sind so lange gut und nützlich, wie sie auf ein Runtime angewiesen sind, dessen Lücken vom Distributor gestopft werde (können). Das, was Canonical mit Snappy abliefert, ist unnützer Mist, der mir nicht auf die Platte kommt. Von xdg-app bzw. Flatpak erwarte ich auf jeden Fall mehr (Redhat hat mich bisher nicht enttäuscht).
 
@cbtestarossa
Ich denke da muss man einfach einen Trade-Off machen. Wenn sich das ganze automatisch ohne Passwort installiert, dann bekomme ich eventuell auch Updates, die ich nicht will. Das kann von unliebsamen Änderungen (entfernte Features in Nautilus), über Zwangsupgrades des Betriebssystems bis hin zu manipulierten Updates reichen.

Ein Passwort ist nicht wirklich schön, aber es erfüllt einen Zweck. Selbst iOS bittet um Bestätigung. Ich denke mir das ganze so, man muss dem Nutzer keine Steine in den Weg legen, aber ein gewisses Mindestmaß an Bildung darf man dann dennoch erwarten. Tante Frieda liest doch vermutlich auch die Anleitung ihres Küchenautomats, bevor sie ihn in Betrieb nimmt.

Das würde auch solchen Verschlüsselungsverbrechern ordentlich die Tour versauen. Üblicherweise findet die Schadsoftware ja durch den User erst auf die Platte. Da ist es vielleicht sogar besser, wenn der völlig planlose nichts installieren kann, weil er mit einem Passwort überfordert ist.

Dass nicht jedes Programm überall Zugriff braucht ist sicher richtig. Aber einige dann dennoch. Es würde ja reichen ein solches mit Schadcode auszustatten und anzubieten. Der Ansatz kann die Angriffsfläche womöglich reduzieren, aber beseitigt nicht das eigentliche Problem. Sandboxes sind schon ein guter Ansatz, wobei man natürlich auch hier darauf vertrauen muss, dass keine weiteren kritischen Daten in der Sandbox sind. Und darauf, dass es kein Entkommen aus dem virtuellen Gefängnis gibt.

Snaps werden wohl Berechtigungen unterstützen, so wie man es von iOS und Android gewohnt ist. Leider drücken auch dort zu viele Benutzer bei jedem Pop-Up auf "Ja" und "OK". Ein Sicherheitsgurt ist auch eine super Sache, aber nur wenn man ihn dann auch wirklich anlegt. Wer das nicht für nötig hält, geht ein erhöhtes Risiko ein. ;)
 
Opensuse zb fragt bei der Installation ob der USER das RootPW verwenden soll.
Somit kann der USER schon mal nix gravierendes installieren bzw. verstellen wenn man 2 getrennte PW macht.
Denn er kennt das Root PW NICHT. Da kann er 100 mal SUDO oder SU reintippen

Du kennst doch die User. Heute mal etwas gehört Morgen vergessen.
Und bei Popups, da wird nix gelesen nur weiter weiter geklickt weil 90% der Meldungen aus diversen Gründen eh nicht verständlich sind.
Hat der User dann ein Passwort dass ihn zum Admin/Root macht oder im Falle von UAC er gleich ohne PW auf WEITER klicken kann dann wird er es auch tun.

Ja SystemUpdates können manchmal nerven aber Sicherheit geht vor.
Opensuse ändert aber selten etwas wie Nautilus-Funktionen. Wobei, hat der überhaupt welche?
Speziell Opensuse macht bei Updates seit einiger Zeit fast gar keine Probleme mehr.

Bei Sandboxen wirst du aber auch eine Tür nach draußen benötigen um Daten zu speichern.

Es bleibt ein Problem mit den Rechten im Filesystem. Ob nun noch eine Schicht darüber ist ist mMn egal.
 
Zuletzt bearbeitet:
Es übersehen einige, man kann auch Runtimes anbieten und mit Snaps anbieten. Die Anwendungen würden dann z.b. runtime-201704 voraussetzen und die Anwendung selbst ist dann nicht so groß bzw man kann dann dennoch Zentral Updates einspielen. Aber klar, man kann auch alles oberhalb des Kernels in sein Snap stecken ...
 
Zurück
Oben