ubuntuusers.de

schwarzheit schrieb:

Wer Snap will muss mit Probs leben.

Kann ich in keiner Weise, d. h. weder unter Firefox, noch unter Thunderbird auch nur ansatzweise bestätigen. Beides funktioniert problemlos unter Snap!

Wie kommst du zu dieser Behauptung?

@Webmark

Es geht hier weder um Firefox noch um Thunderbird. Und ich werde hier mit Sicherheit keine Grundsatzdiskussion führen.

Fakt ist, Snap hat immer bestimmte Beschränkungen. Wenn du damit leben kannst - gut. Ist hier aber nicht das Thema.

Dann belege doch diesen "Fakt" auch...

Dann lies doch einfach das Wiki!

Danke für diese nichts sagende Antwort.

schwarzheit muß gar nichts belegen. Der Fakt Restriktionen ist prinzipbedingt und alles andere als ein Geheimnis. Dennoch hat sie auf das Wiki verwiesen.

Daß daraus Probleme entstehen können, muß auch nicht extra nachgewiesen oder zum x-undneunzigsten Mal diskutiert werden. Das kann man von Anbeginn im Forum ständig nachlesen.

Popcornaktien zu mir! Alle!

--ks

Kreuzschnabel schrieb:

Popcornaktien zu mir!

Hiermit bist du sehr gut dabei ISIN: US3499034193. Viel Erfolg.

... man schaue sich das Renditedreieck an.

Nun, mal eine blöde Frage, was genau ist am Snap Thunderbird nicht in Ordnung ? Bei mir läuft alles wunderbar und immer gleich , die Snap-Probleme der Anfangszeit sind schon lange erledigt. Thunderbird ( und alle anderen Snap-Pakete ) verhalten sich immer gleich , auch nach einem Update mit apt.

Deine Version ist interessant aber verkompliziert alles meiner Meinung nach. Weiss nicht ob das wirklich eine gute Sache ist, aber wer es möchte ⇒ nur zu.

Meiner Meinung nach hat man sich so gegen Snap eingeschossen das man das wesentliche übersieht. Wir brauchen Software die immer stabil und gleich läuft, unabhängig davon ob man ein Update fährt oder nicht.

Deb Pakete haben und hatten schon immer ihre Probleme.

Leider wird im D,A,CH Raum kaum Positiv über Snaps berichtet.

Ich habe im Snap Store zwei Pakete erstellt: Kodi und Openpaperwork.

Die "Gerüchte" die aktuell über Snaps kursieren, kann ich nicht bestätigen. Ein Deb Paket zu bauen ist schwer, der Aufwand beachtlich. Ganz zu schweigen davon das "Paket" im Umlauf zu bringen. Wer sich als Neuling mal in ein Debian Forum "gewagt" hat, weiss wovon ich rede, dort kriegt man erst mal eine auf die Mütze.

Ein Snap hat man schnell gebaut. Eine snapcraft.yaml schnell online gestellt.

Vorteil ⇒ Damit kann jeder das Paket schnell und einfach nur mit einem Befehl selber bauen wenn man es denn möchte. Das Snap Pakete immer viel zu gr0ß sind gehört in die Mottenkiste, das stimmt schon lange nicht mehr.. Ich habe spaßeshalber Kodi als DEB Paket gebaut und als Snap (mit allen Addons ) und die Größe verglichen. Das DEB Paket hat dabei 291 MB und das Snap 300 MB. Die 9 MB mehr, ganz ehrlich wen juckt das heute ?

Tibsun75 schrieb:

Vorteil ⇒ Damit kann jeder

Nachteil: Damit kann jeder.

Hallo Tibsun75,

Du vergisst vielleicht das da immer zwei Versionen vorgehalten werden, d.h. dann sind es eben nicht z.B. 300 MB sondern das Doppelte. Dann noch die vielen Versionen des gnome Stack und die Restriktionen. Außerdem wird dann am Snap zu viel "aufgeweicht" damit es normal (userfreundlich) funktioniert ... siehe z.B. Firefox mit Keepassxc. Flatpack ist da vielleicht besser ....

PS: Seit wann kann man mit apt Snaps aktualisieren ?

Gruss Lidux

Tibsun75 schrieb:

Nun, mal eine blöde Frage, was genau ist am Snap Thunderbird nicht in Ordnung ?

Schrieb das jemand im von dir entführten Projektthread?

Bei mir läuft alles wunderbar und immer gleich , die Snap-Probleme der Anfangszeit sind schon lange erledigt.

Ach deshalb tauchen hier immer noch ständig Nutzer mit Snap-Problemen auf: Weil die schon lange problemlos funktionieren. Verstehe.

Thunderbird ( und alle anderen Snap-Pakete ) verhalten sich immer gleich , auch nach einem Update mit apt.

Apt hat mal absolut nichts mit Snap zu tun. Und die Snap-Probleme kommen nicht durch Updates sondern durch deren Ersteller.

Gimp in nur einer Sprache und nicht umstellbar, Grafikprogramme, die nicht drucken dürfen, Musikverwaltungsprogramme, die keinen Zugriff auf externe Medien haben, Brennprogramme, die nicht auf optische Datenträger zugreifen dürfen usw. usf.

Wir brauchen Software die immer stabil und gleich läuft, unabhängig davon ob man ein Update fährt oder nicht.

Der Definition nach brauchen wir also keine Snaps. Wobei: Stabil laufen die ja. Halt nur nicht brauchbar.

Deb Pakete haben und hatten schon immer ihre Probleme.

Die da wären? Sämtliche oben genannte beispielhafte, immer wieder in Snaps vorhandene Probleme gibt und gab es mit .deb-Paketen so nie.

Leider wird im D,A,CH Raum kaum Positiv über Snaps berichtet.

Das könnte an den massiven Problemen damit liegen, die nicht nur hier immer wieder aufgezeigt werden.

Vielleicht würde ja positiver darüber berichtet, wenn das Zeug vernünftig funktionieren würde.

Die "Gerüchte" die aktuell über Snaps kursieren, kann ich nicht bestätigen.

Was auch immer es da für Gerüchte zu geben soll. Es gibt schlichtweg Fakten, die deren Funktionsprobleme belegen.

Ein Deb Paket zu bauen ist schwer, der Aufwand beachtlich.

Da ist nichts schwer dran und Aufwand ist das auch nicht. Es sind im wesentlichen die selben Schritte in der debian/rules anzugeben, die zu manuellen kompilieren notwendig sind. Außerdem das Copyright und die Lizenz einzutragen, ein Changelog zu führen und eine control-Datei, in der Bauabhängigkeiten und Abhängigkeiten des fertigen Paketes festgehalten sind.

Also im Prinzip alles, was sauber dokumentiert, was da gemacht wurde.

Ganz zu schweigen davon das "Paket" im Umlauf zu bringen.

Stimmt. Pakete mit Mining-Software oder anderen ungefragten Zusätzen als Snap an den Kunden zu bringen ist weitaus leichter als ein Paket in die Ubuntu-Quellen zu bringen.

Es gibt auch nirgends Hinweise seitens Canonical dazu, dass es sich bei über den Snapstore angebotener Software im Grunde zum Großteil um komplett ungeprüfte Fremdquellen handelt.

Auch gibt es keinen Hinweis dazu, dass Snaps Software mit Sicherheitslücken in den mitgebrachten Abhängigkeiten mitbringen kann, die in den offiziellen Quellen schon lange gefixt wurden.

Wer sich als Neuling mal in ein Debian Forum "gewagt" hat, weiss wovon ich rede, dort kriegt man erst mal eine auf die Mütze.

Interessant. Zeige doch mal so ein oder zwei Beispiele aus dem größten und ältesten deutschen Debian-Nutzerforum, debianforum.de.

Die sind mir da wohl irgendwie entgangen, aber ich bin da auch erst seit 17 Jahren unterwegs.

Das Snap Pakete immer viel zu gr0ß sind gehört in die Mottenkiste, das stimmt schon lange nicht mehr..

Achso. Die bringen also nicht mehr alles mit, was sie zum laufen brauchen. Moment, dann wären sie ja gar nicht lauffähig, da sie ja nichts von der nativ installierten Software wissen und diese nicht mitnutzen können.

Ich habe spaßeshalber Kodi als DEB Paket gebaut und als Snap (mit allen Addons ) und die Größe verglichen.

Das DEB Paket hat dabei 291 MB und das Snap 300 MB. Die 9 MB mehr, ganz ehrlich wen juckt das heute ?

Keine Ahnung, was du da gemacht hast. Das Kodi-Paket hat in den Repos von Arch Linux eine Größe von 33,9MB. Das Kodi-.deb bei Debian Multimedia hat 99,6MB.

tomtomtom schrieb:

... Auch gibt es keinen Hinweis dazu, dass Snaps Software mit Sicherheitslücken in den mitgebrachten Abhängigkeiten mitbringen kann, die in den offiziellen Quellen schon lange gefixt wurden.

Dazu fällt mir ein: scanning-snaps-for-vulnerabilities

Tibsun75 schrieb:

Nun, mal eine blöde Frage, was genau ist am Snap Thunderbird nicht in Ordnung ?

Mein Rechner fährt nicht bzw verzögert herunter solange Snap Thunderbird läuft. Auf Kubuntu taucht dann ein POP-Up auf das meldet das Thunderbird zu beenden ist oder nach 2 (?) Minuten der Rechner auch so herunter fährt.

tomtomtom schrieb:

Tibsun75 schrieb:

Schrieb das jemand im von dir entführten Projektthread?

Warum dann deine Methode ?

Thunderbird ( und alle anderen Snap-Pakete ) verhalten sich immer gleich , auch nach einem Update mit apt.

Ein Snap Paket verhält sich immer gleich auch wenn der User sein restliches System mit apt aktualisiert hat. Du möchtest hier den Anschein erwecken als ob ein rein Deb,rpm whatever basiertes System keine Probleme hätte. Probiere dann doch mal Kodi oder Openpaperwork nur als Beispiel , als DEB Paket zu installieren . Geht nicht weil es weder Ubuntu noch Debian in einer aktuellen Version pflegt. Und wenn man eine Version außerhalb des Ökosystems ( Stichwort Fremdquelle ) findet die funktioniert, kannst nie sicher sein, das nach einem apt Update alles so ist wie vorher.

Gimp in nur einer Sprache und nicht umstellbar, Grafikprogramme, die nicht drucken dürfen, Musikverwaltungsprogramme, die keinen Zugriff auf externe Medien haben, Brennprogramme, die nicht auf optische Datenträger zugreifen dürfen usw. usf.

Erst einmal arbeiten die Gimp Entwickler seit dem 17.10.2025 an einem eigenen Gimp Paket. Inkl. Anleitung wie damit zu handhaben ist. Schau mal hier : https://gitlab.gnome.org/GNOME/gimp/-/tree/master/build/linux/snap Zweitens könntest du statt hier rum zu jammern auf deren Git ein Bug Report einstellen. Drittens ist es relativ einfach möglich wenn man als Paketbauer in der snapcraft.yaml folgendes einfügt:

    environment:
      LANG:

Falls GIMP Snap nur Englisch zeigt, fehlt vermutlich:

locales-all

und in der stage-packages Sektion das entsprechende language-pack-de etc. , warum auch immer. Am besten stelle ein Bug Report ein.

Der Rest den du aufzählst, kann ich nur erraten weil nicht verwertbar angegeben. Ich selber nutze für mein YouTube Kanal nur noch Snaps : OBS, Audacity, Openshot, Gimp und VLC. Bei keinem dieser 4 Programme gibt es deine aufgezählten Probleme im übrigen. Ich kann also damit immer arbeiten, ohne mit "Überraschungen" konfrontiert zu sein.

Sollte es Probleme geben mit einer Snap-Software dann Poste es halt in deren Bug-System, oftmals ist es Github. Ich pflege das Kodi Snap Paket, klar kommen da Probleme rein. Die, die ich kenne kann ich beseitigen.

Die da wären? Sämtliche oben genannte beispielhafte, immer wieder in Snaps vorhandene Probleme gibt und gab es mit .deb-Paketen so nie.

Spontan fallen mir da folgende Themen bei .deb-Paketen ein: Veraltete nicht mehr gepflegte .deb-Version oder generell nicht verfügbare Version. .deb-Pakete teilen (System)Bibliotheken , das führt unter anderem zu inkompatiblen Version wenn ein Library upgedatet wurde und ein anderes davon abhängiges Programm nicht. Dann gibt es noch Konflikte zwischen Programmen,Broken-Upgrades nach Release-Wechseln, Blockierte Updates, weil andere Pakete abhängig sind . Gleichzeitig unterscheiden sich Compiler-Flags, Toolchain-Level usw. und so fort... Ganz zu schweigen das .deb basierte Pakete in der Regel oftmals mit vollem Dateisystemzugriff arbeiten.... Und als letztes kommt dazu das kaum ein Maintainier für alle Distri's überhaupt Pakete erstellt, und es unmöglich ist es in allen verfügbaren Distri-Kombination sicher zu testen.

Das könnte an den massiven Problemen damit liegen, die nicht nur hier immer wieder aufgezeigt werden.

und die wären ? Außer dem üblichen Quark hast du nichts verwertbares in deinem Pfantlet geschrieben.

Da ist nichts schwer dran und Aufwand ist das auch nicht. Es sind im wesentlichen die selben Schritte in der debian/rules anzugeben, die zu manuellen kompilieren notwendig sind. Außerdem das Copyright und die Lizenz einzutragen, ein Changelog zu führen und eine control-Datei, in der Bauabhängigkeiten und Abhängigkeiten des fertigen Paketes festgehalten sind.

Wieviele Debian Pakete hast du selsbt erstellt und weiviele davon sind in den Debian Quellen aufgenommen worden, so dass es nun auch der Rest nutzen kann ?

Stimmt. Pakete mit Mining-Software oder anderen ungefragten Zusätzen als Snap an den Kunden zu bringen ist weitaus leichter als ein Paket in die Ubuntu-Quellen zu bringen.

Es gibt auch nirgends Hinweise seitens Canonical dazu, dass es sich bei über den Snapstore angebotener Software im Grunde zum Großteil um komplett ungeprüfte Fremdquellen handelt.

Das ist auch wieder Quark von gestern. Das Procedere wurde schon seit Jahren geändert. Wenn es dich interessiert schau im snapcraft forum, fast alles benötigt mittlerweile ein manuelles Review: https://forum.snapcraft.io/c/store-requests/19

Abgesehen davon sage ich nur xz-Utils / liblzma bei Debian...

Auch gibt es keinen Hinweis dazu, dass Snaps Software mit Sicherheitslücken in den mitgebrachten Abhängigkeiten mitbringen kann, die in den offiziellen Quellen schon lange gefixt wurden.

Aha, und welche Hinweise wären das ? Wenn der Snap Paket Ersteller sein Paket nicht pflegt, was auch schon bei Deb's, rpm usw. möglicherweise schon mal vorgekommen ist, kann das passieren. Das ist ein Grundproblem und betrifft eigentlich jede Software. Für Snap Pakete nutzen wir eigentlich das Tool, guck mal hier : https://forum.snapcraft.io/t/scanning-snaps-for-vulnerabilities/49646 Ja es ist völlig normal das sich mit der Zeit Vulnerabilities entwickeln , deswegen ja die Sicherheitsupdates und daraus folgend ein Update der Pakete. Mit Snap ist das ganze halt einfacher , wie beim Rest ( das ist meine persönliche Meinung ) , und man hat eine stabile Basis um sein Paket mit der Welt zu teilen.

Die sind mir da wohl irgendwie entgangen, aber ich bin da auch erst seit 17 Jahren unterwegs.

Ich bin Slackware Nutzer seit 1995 , um Debian und deren Foren mache ich nach zwei Abstechern einen sehr großen Bogen !. Das du seit 17 Jahren dort unterwegs bist glaube ich dir sofort. Einiges von dort scheint auf dich abgefärbt zu haben. Die "Diskussionen" in Debianforen laufen in ähnlicher Manier ab wie gerade hier. Man muss sich für alles rechtfertigen und es gibt immer jemanden, der eh alles besser weiss ! So dümpeln dann halt unendlich viele uralte vergammelte Software Pakete vor sich hin...

Keine Ahnung, was du da gemacht hast. Das Kodi-Paket hat in den Repos von Arch Linux eine Größe von 33,9MB. Das Kodi-.deb bei Debian Multimedia hat 99,6MB.

Du vergleichst Äpfel mit Birnen. Das Grundpaket von Kodi ohne Addosn hat ca. 50MB auch als Snap. Nur kann man ohne die Addons wie pvr usw. nicht viel mit Kodi anfangen. Mein Vergleich bezieht sich auf ein Kodi Paket welches alle offiziellen Kodi Addon's enthält, was die Kodi Entwickler in Ihren Github-Repo's anbieten. Abgesehen davon habe ich in mein Kodi Snap Paket alle Sprachen eingebaut, das Gimp Sprachen Problem hat mein Snap Paket also nicht. ... und weil du schon das Debian Kodi Paket ansprichst. Das ist bei Kodi Entwickklern und deren Foren äußerst unbeliebt. Weil die Debian Paket Maintainer nach eigenem Gutdünken ( ich nenne das jetzt mal so ) die Pakete in Ihrem Wahn so angepasst haben, das es nur noch Probleme und Einschränkungen gibt. Die Kodi Entwickler sehen dass mittlerweile so: Wenn Funktionen fehlen oder kaputt sind, fällt der Ärger trotzdem auf Kodi zurück. Also: lieber kein Debian Paket als ein „kaputtes offizielles".

Somit sind wir wieder bei Start: Deb, rpm usw. sind nicht immer die beste Lösung, weil oftmals auch veraltet, nicht mehr gepflegt oder schlicht nicht verfügbar. Snap Pakete kann man sehr einfach selber bauen und das immer isoliert vom restlichen System sauber neu getrennt . Ich muss also nicht um beim Beispiel Kodi zu bleiben jedes mal 8-12 apt Pakete im Grundsystem downgraden damit ich Kodi kompilieren kann.

Zum Schluss noch mal für dich und die restlichen Snap-Hasser: Ein großteil der Snap-Pakete wird von freiwilligen Helfern erstellt. Es gibt noch die Snapcrafters Gruppe die aus Experten bestehen. ( Dazu zähle ich mich nicht ). Man kann viele der Snap-Themen die ein Snap-Paket betreffen lösen, also schreibt einfach in deren Bug System ein Beschreibung des Problems, was du entdeckt hast. Dieses ganze Müllgerede aussenrum nervt. Snap-Pakte zu bauen ist einfach, deswegen gibt es trotz der Miesmache, nen haufen Entwickler die im Snap-Store Software freiwillig bereitstellen. Die alternative Flatpak ist , sorry das ich das so sagen muss, eine mittlere Katastrophe. Man sitzt zwei drei Tage daran um ein Paket zu erstellen und drei Wochen später kann man herum suchen, um heraus zu finden warum es nicht mehr wie gewünscht neu gebaut werden kann. Naja und Appimages, das ist ein ganz anderes Thema...