News Ubuntu 21.10 („Impish Indri“): Firefox wird wie Google Chrome als Snap ausgeliefert

Ich finde, es ist ein großer Unterschied, ob Snap nur ein Zusatzangebot ist, um an aktuellere Programmversionen zu kommen -als Alternative zu einem PPA- oder ob wichtige Teile des Systems schon als Snap kommen. Dasselbe gilt für Flatpak.

Mal sehen, was da nächstes Jahr mit Ubuntu 22.04 noch kommt. Das wird dann wieder die Grundlage sein für die zahlreichen Ubuntu-basierten Distros, z.B. Linux Mint 21.

Bei Linux Mint haben sich die Entwickler klar gegen Snap gestellt, unterstützen aber Flatpak via Anwendungsverwaltung als Zusatzangebot.
Chromium (Snap) hatte da schon zu größeren Diskussionen geführt. Jetzt wird Chromium (Deb) über das Mint-Repo bereitgestellt.
 
  • Gefällt mir
Reaktionen: pseudopseudonym und Bigfoot29
Serana schrieb:
@flaphoschi
Mit "Old School" meine ich auch mehr, daß man bei Distributionen wie Arch oder Debian nicht diesen Drang nach Containerformaten wie Snap oder Flatpak hat wie bei Ubuntu oder Fedora. Derartigen "Unsinn" überläßt man eben den anderen.
Also gerade als Debiannutzer auf meinem Main PC kann ich dir sagen: ohne Flatpak würde ich ganz schön alt aussehen.
 
  • Gefällt mir
Reaktionen: andy_m4
nipponpasi schrieb:
ohne Flatpak würde ich ganz schön alt aussehen.
:-)
Die Frage ist natürlich, ob Debian dann für Dich die richtige Distribution ist.

Aber ja. Ich verstehe natürlich den Ansatz: Stabile Distribution und darauf aufbauend hier und punktuell da wo es nötig/praktisch ist via "Contained-Apps" sich davon die neuste Version holen.
 
  • Gefällt mir
Reaktionen: Bigfoot29 und nipponpasi
@nipponpasi
Laß mich raten. Du nutzt Debian Stable (evtl. ohne Backports) und brauchst von irgendeiner Software die neueste Version.
 
  • Gefällt mir
Reaktionen: Linuxfreakgraz und nipponpasi
Serana schrieb:
@nipponpasi
Laß mich raten. Du nutzt Debian Stable (evtl. ohne Backports) und brauchst von irgendeiner Software die neueste Version.
Genau
Ergänzung ()

andy_m4 schrieb:
:-)
Die Frage ist natürlich, ob Debian dann für Dich die richtige Distribution ist.
Ich wäre dann aufs AUR angewiesen. Da weiß ich nicht wem ich trauen kann. Hab da schon einiges gehört.
 
Zuletzt bearbeitet von einem Moderator:
garfield121 schrieb:
Bei Linux Mint haben sich die Entwickler klar gegen Snap gestellt, unterstützen aber Flatpak via Anwendungsverwaltung als Zusatzangebot.
Der Grund, weswegen ich von Ubuntu zu Mint gewandert bin. Vielleicht gucke ich mir am WE auch noch Pop OS auf einem neueren Gerät an, um Ubuntu 21.04 ohne Snap zu bekommen.
Schade, dass man sich die Arbeit machen muss, um davon loszukommen.

Als Zusatzangebot hätte ich übrigens nichts gegen Snap. Aber das ohne Not und ohne Vorteile für den Nutzer so ins System zu drücken, erinnert mich an andere Plattformen. Brauch ich nicht!
Gar nicht mal primär aus "ideologischen" Gründen, sondern weil's auch noch bescheiden funktioniert.
 
  • Gefällt mir
Reaktionen: ghecko
pseudopseudonym schrieb:
Als Zusatzangebot hätte ich übrigens nichts gegen Snap. Aber das ohne Not und ohne Vorteile für den Nutzer so ins System zu drücken, erinnert mich an andere Plattformen. Brauch ich nicht!
Jup. 20.04 wird dann wohl auch mein letzter U-Unterbau bleiben. Meine bisherigen Gehversuche Richtung Arch waren zwar nicht sehr erfolgreich, aber das muss ich jetzt wohl ernsthafter angehen.
 
@ghecko
Hoffentlich kann ich mit solchen Umwegen noch ne Weile bei einem Ubuntu-Unterbau bleiben. An sich funktioniert der für mich gut und auch auf sämtlichen Geräten in der Familie. Gerade der letzte Punkt ist sehr wichtig, weil einige von denen nicht gerade um die Ecke wohnen, sich aber auch nicht unbedingt nur mit einem Webbrowser zufrieden geben.

Für mich selbst hab ich aber ehrlich gesagt auch keine Lust, mich zeitnah komplett umzuorietieren. Das ist dann auch nicht nur ein Gerät, also etwas mehr Zeit.
Hüstel, vielleicht bekomme ich im Winter endlich mal meinem Hobby-PC von Linux Mint 19.3 hochgezogen ... oder warte gleich auf den Nachfolger von Mint 20.x.
Eigentlich ne Sache von max. nem Abend, eher ein 1-2h, aber du siehst, wie's um meine Lust darauf steht.

Schade, wie Ubuntu sich entwickelt, aber immerhin sind wir in der Opensource-Welt und haben Forks und komplett andere Distros. Unter Windows/Mac müssten wir's fressen.
 
Ja, ich hab auch das Problem das sämtliche von mir betreute Systeme auf Xubuntu aufbauen, wie mein Hauptsystem. Die Umstellung wird also für mich etwas Arbeitsintensiv. Alle anderen werden den Unterschied nicht bemerken, da ich ohnehin bei allen eine angepasste XFCE-Umgebung läuft. Die spielen nicht mal Software selber auf.
 
Schon Chromium als "Snap" ist ne mittlere Katastrophe. Fügt sich so quasi garnicht ins System ein, so manche Dinge gehen einfach kaputt (Screen sharing, automatische Neustarts vom Browser etc.). Und dann noch die Frechheit, das mitten im Release-Zyklus einfach auszutauschen.
Offline-Installationen über einen Mirror kann man ebenfalls vergessen.
Zusammen mit dem völlig unnötigen Rausschmiss vom netinstaller in der RC-Phase(!!!) einer LTS(!!!) Version (und nein, der "Ersatz", der erstmal hunderte von MB bis GB ins RAM dumpt ist einfach nur Kernschrott) gibt es nur eine mögliche Konsequenz: Umstieg auf Debian. Auf dem Server ist das mir eh schon seit immer gesetzt, auf einem Notebook habe ich es ebenfalls schon testweise.
 
  • Gefällt mir
Reaktionen: Linuxfreakgraz
Irgendwo auf Seite 2 gabs mal die Idee, dass Rechner mit Snaps im eigenen familiären Umfeld, das man für seine Verwandten teilverwaltet, einfacher sei. Ich würde dem widersprechen, weil ichj in meinem fam iliären Umfeld sehe, dass dort, wo "irgendwas Linux" verwendet wird, alle Software aktuell ist, während mir meine Windows-Verwandschaft immer stolz erzählt, dass ihr Rechner Updates installiert, dann aber beispielsweise der VLC doch auf irgendeiner veralteten Version festhängt. Das muss nicht gegen Sachen wie FlatPak und Snap sprechen, es muss nur trotz solcher Systeme sichergestellt sein, dass die Snaps und FlatPaks über die Software-Verwaltung instralliert und gepflegt werden und nicht vor zwei Jahren mal einfach von der Website geladen und installiert wurden, um dann nicht zu bemerken, dass Gnome Softwqare sie beim AutoUpdate vielleicht doch nicht berücksichtigt.

Wenn aber auch die Snaps und Flatpkaks von der zentralen Software-Verwaltung verwaltet werden - das fuinktioniert ja! - dann gibt es ein Software-Paket, das momentan glühend die Notwendigkeit von sowas wie Flatpak in den Himmel strahlt: GIMP

GIMP ist in seiner aktuellen Version immernoch von gtk+ 2 abhängig und gtk+ 2 wird nicht mehr unterstützt, darf also zurecht aus aktuellen Distro-Repos ausgespart werden. Aussparen kann man gtk+ 2 aber nur, wenn dann GIMP als Flatpak installiert wird - was auf Fedora deshalb auch standardmäßig gemacht wird. Es geht nicht darum, dass irgendjemand ein Sicherheitsfix von gtk+ vergessen hat und die Distro gtk+ besser bereitstellt, sondern darum, dass Gimp für produktive Anwender eben vor der Veröäffentlichung von GIMP 3.0 noch in einer Funktionsära festhängt, die von einem Betriebssystem nicht mehr für alle Anwendungen bereitgestellt werden sollte, und gleichzeitig für viele Anwender, die Bilder bearbeiten, unverzichtbar ist.
kim88 schrieb:
...
Natürlich liefert Fedora Firmware Blobs mit die Closed Source sind - eine Liste dazu finde man hier.
...
Das Wort Blob ist misverständlich. Es erweckt den Eindruck, es würde hier wie bei den Blobs von Android um Kernelmodule gehen, was nicht der Fall ist. Wine WLAN-Karten-Firmware läuft nicht im Betrtiebssystem sondern auf der WLAN-Karte. Deswegen steht bei alsa-tools-firmware auch als Beschreibung: "tools for uploading firmware to some soundcards" - wieso hochladen, wenn es Teil des Betriebssystems ist? Weils eben nicht Teil des Betriebssystems ist. Man mag das in der Beschäftigung mit der ARM-Welt, in der keine Firmware-Schnittstelle (BIOS/OFW/UEFI) genutzt wird, vergessen, aber wie, also auf welche Art und Weise, meine Festplatte oder meine SSD Sachen wie NCQ oder WearLevelling betreibt, geht das Betriebssystem eigentlich nichts an, sondern nur das Laufwerk selbst und schwubbs reicht auch ein "Standardmäßiger SATA AHCI- Controller" (sic) um mal mein Microsoft Windows zu zitieren. Treiber sind die Art von Software, die zwischen Firmware und Betriebssystem kommuniziert, und manchmal ist nicht jede Firmware (-Version) einer WLAN-Karte kompatibel mit einem GPL-kompatiblen Treiber, welcher aber GPL-kompatibel sein muss, sobald er als Kernelmodul von der Distribution mit Hauptsitz im US-Bundesstaat North Carolina offiziell angeboten werden dürfen soll.
 
MountWalker schrieb:
die von einem Betriebssystem nicht mehr für alle Anwendungen bereitgestellt werden sollte,
Offensichtlich teilen bei Fedora nicht alle diese Ansicht. Gimp wird jedenfalls auch in Fedora 36 noch als RPM-Package bereitgestellt. Natürlich kann jemand der GTK+ 2 absolut nicht auf seinem System haben will zum Flatpak greifen, aber dafür handelt er sich eben potentielle Probleme bzgl. der Integration ins System ein.

Wobei ich die Begründung bzgl. Gimp und GTK+ 2 eher für vorgeschoben halte um eben irgendwie zu rechtfertigen, daß das RPM-Package unbedingt weg sollte. Oder welche stichhaltige Begründung gibt es bei den Gnome-Apps um diese als Flatpak bereitzustellen? Welche Altlasten schleppt denn der gnome-calculator mit sich herum, daß man ihn unbedingt in ein Flatpak packen muß?

Bitte nicht falsch verstehen. Wenn Fedora und Ubuntu ihre Zukunft eher als Framework für Flatpak- oder Snap-Container sehen, dann ist das prinzipiell kein Problem. Es gibt ja schließlich genügend andere Distributionen die man nutzen kann. Nur sollte man dann eben so ehrlich sein und sagen, daß es sich hier einfach um eine Richtungsentscheidung handelt und nicht irgendwelche Sicherheitsbedenken vorschieben.
 
andy_m4 schrieb:
In Komponenten unterteilen und die mit den jeweiligen möglichst niedrigsten Rechten laufen lassen (wie halt das klassische Beispiel Browser) macht durchaus Sinn und behebt schon die größten Sicherheitsprobleme. Darüber hinaus finde ich es aber durchaus nicht verkehrt auch Sandboxing-Möglichkeiten zu haben. Damit man halt für den Restlichen Code weiter einschränken kann, aber vor allem aus dem Grund, da nicht alle Programme so vorbildlich haben und in der oben beschriebene Weise implementiert sind.
Naja, tatsächlich verwenden ja insbesondere Browser schon diverse Sandboxing Mechanismen. Zwar nichts, was vom Kernel/libc (chroot(), jail(), lxc & co) ausgeht, aber dafür diverse privsep Dinge, Tab Sandboxing & Co, die durchaus sinnvoll sind. Fing damals bei Plugins an. Erinnert sich jemand noch an die Zeiten, als die Plugins nicht separiert waren? Oder die JS Engine etc? Und auch das Interface zum Filesystem ist mittlerweile eben gekapselt und kann nicht mehr von jeder X Beliebigen Browserkomponente einfach angesprochen werden.
 
Serana schrieb:
Wobei ich die Begründung bzgl. Gimp und GTK+ 2 eher für vorgeschoben halte
Im Zweifelsfall kann man ja auch Dependencies direkt mit ausliefern. Z.B. beim dpkg für Gitlab ist sogar Postgres, Redis, nginx und noch viel mehr direkt in eigener Version für die GitLab-Instanz dabei. Nicht schön, aber funktioniert. Und selbst dafür braucht man kein Snap oder Flatpak.
Serana schrieb:
Welche Altlasten schleppt denn der gnome-calculator mit sich herum, daß man ihn unbedingt in ein Flatpak packen muß?
Der Calculator war wohl einfach einer der ersten Testballons, es ging an der Stelle nicht um Notwendigkeiten.
Serana schrieb:
Wenn Fedora und Ubuntu ihre Zukunft eher als Framework für Flatpak- oder Snap-Container sehen, dann ist das prinzipiell kein Problem.
Doch schon: beide Distributionen werden für Server-Einsatz dadurch völlig indiskutabel.
 
Vielleicht bin ich hier etwas altmodisch aber ich installiere Software meist über die offiziellen PPAs.
Gut, bei mir ist das nicht viel mit Google Chrome und Spotify aber ich brauche Flatpaks/Snaps/AppImages nicht.
 
Serana schrieb:
Bitte nicht falsch verstehen. Wenn Fedora und Ubuntu ihre Zukunft eher als Framework für Flatpak- oder Snap-Container sehen, dann ist das prinzipiell kein Problem. Es gibt ja schließlich genügend andere Distributionen die man nutzen kann. Nur sollte man dann eben so ehrlich sein und sagen, daß es sich hier einfach um eine Richtungsentscheidung handelt und nicht irgendwelche Sicherheitsbedenken vorschieben.

Naja Fedora plant das ja schon länger bzw. testen es mit "Fedora Silverblue" dort wird das Basis-System noch mit Packages ausgeliefert (funktioniert auch ein bisschen anders als gewohnt - aber ja) und die Anwendungen als Flatpaks.

Sicherheit ist da schon ein Punkt. Einerseits weil es eben (egal ob Flatpak oder Snap) die Apps in Containern laufen. Wieso soll mein Taschenrechner auf meinen Browserverlauf zugreifen können, und stell dir mal vor jemand schmuggelt da bösen Code in die APP rein und es werden wirklich Daten abgegriffen.

Ich finde die Berechtigungen der Container müssten noch etwas Benutzerfreundlicher gelöst werden, wenn eine App bei MacOS auf ein Verzeichnis zugreifen will kommt eine Abfrage "Darf App XY auf das Verzeichnis Desktop zugreifen?" -> da kann man dann Ja/ - oder Nein sagen. Und so BErechtigungen für jede App einzel flexibel erteilen. Finde ich persönlich eine angenehme Methode -> und dürfte man gerne kopieren.

Der andere Sicherheits-Punkt ist klar die Update-Zyklen. Gerade bei Browsern die ja einen 4-6 Wochen Zyklus haben (mal abgesehen von Safari - aber der ist bei Linux eh nicht relevant). Das dauert egal ob bei Ubuntu oder Fedora immer ein paar Tage bis das Updates ausgerollt wird (neue Build erstellen, Build testen, etc).
Gerade wenn Firefox Sicherheitskritische Updates herausbringt ist das immer wieder ein Thema. Teilweise rollt Ubuntu ein FF Update endlich aus, und an einem Tag später kommt ein kritischer .01-> Fix von Mozilla und man wartet dann wieder 3-4 Tage.
Diese Probleme umgeht man natürlich wenn der Hersteller die Pakete direkt selber für die Plattform baut und veröffentlicht -> wie es Mozilla ja auch für Windows, macOS, Android und iPhone/iPad macht.

Aber neben den Sicherheitsüberlegungen gibt es sicherlich noch weitere Gründe. Einer dürfte sein, dass man natürlich viele Arbeitsstunden sparrt, indem Canonical oder RedHat Mitarbeiter nicht Zeit damit verplempern ständig neue Firefox Pakete zu bauen.

Es gibt aber auch noch eine andere positive Seite und das sind Bug-Reports. Teilweise sind Linux-User-Bugreports für Browser mühsam. Weil das Problem nicht bei Mozilla sondern bei Ubuntu landet. Oder wenn es bei Mozilla landet eine veraltete Version betrifft, oder etwas das Ubuntu gepatcht hat und gar nicht Mozilla verantwortlich ist, etc.
So ist relativ klar. Du hast ein Problem mit Firefox egal auf welcher Plattform melde dich bei Mozilla und gut ist.

Man büsst aber auch gewisse Dinge ein. Viele Distributionen machen eigene Patches in den Browser (z.b. eigene Suchmaschinendeals wie bei Linux Mint, etc um damit Geld zu verdienen) diese Option gibt es dann natürlich nicht mehr wenn das Paket direkt vom Software-Hersteller kommt.
Eine andere Einbusse ist der erhöhte Fetplattenspeicher-Verbrauch. Was mich persönlich betrifft, dass ist mir wirklich egal -> davon hab ich mehr als genug.
 
  • Gefällt mir
Reaktionen: nipponpasi und Linuxfreakgraz
kim88 schrieb:
Wieso soll mein Taschenrechner auf meinen Browserverlauf zugreifen können, und stell dir mal vor jemand schmuggelt da bösen Code in die APP rein und es werden wirklich Daten abgegriffen.
Wenn ich dem Taschenrechner (oder generell der Software in der Distribution) nicht mehr trauen kann wäre es idiotisch ihn überhaupt erst zu installieren. Und wenn es z.B. Upstream jemand schafft Code einzuschmuggeln, dann wäre das ein Grund die komplette App aus der Distribution raus zu werfen. Jedenfalls solange bis lückenlos geklärt wurde wie das passieren konnte und sichergestellt ist, daß so etwas in Zukunft nicht noch einmal passiert.

kim88 schrieb:
Diese Probleme umgeht man natürlich wenn der Hersteller die Pakete direkt selber für die Plattform baut und veröffentlicht -> wie es Mozilla ja auch für Windows, macOS, Android und iPhone/iPad macht.
Und da soll ich mich dann darauf verlassen, daß der jeweilige Entwickler sämtliche Abhängigkeiten im Auge behält und jedesmal eine neue Version bringt wenn sich da etwas geändert hat? Denn genau darauf basieren ja diese Containerformate, daß sämtliche (oder die meisten) Abhängigkeiten schon mit in dem Container drin stecken. Beim herkömmlichen Modell gibt es im System z.B. genau eine Version der libssl auf die alle Programme dynamisch gelinkt sind. Gibt es ein Problem, dann muß ich nur ein Update einspielen und alle Programme nutzen die gefixte Version. So muß ich dann bei jeder App die die libssl nutzt darauf hoffen, daß der Entwickler zeitnah ein Update herausgibt. Macht er das nicht bleibt mir als Fix eigentlich nur die Deinstallation der App. Schöne neue Welt.

Im Extremfall habe ich dann einen ganzen Zoo an Sicherheitslücken in dutzenden von Containern. Mir als Nutzer bleibt dann nur die Hoffnung, daß es wirklich so unmöglich ist aus dem Container auszubrechen wie gerne behauptet wird. Was soll da schon schiefgehen...

kim88 schrieb:
So ist relativ klar. Du hast ein Problem mit Firefox egal auf welcher Plattform melde dich bei Mozilla und gut ist.
Auch beim herkömmlichen Modell gibt es eigentlich keine Unklarheiten. Habe ich ein Problem mit einem Distributionspaket, dann landet der Bugreport natürlich nicht beim Entwickler, sondern bei der Distribution, dort wurde das Paket doch gebaut. Klar gibt es immer wieder Leute, die sich direkt an die Entwickler wenden, selbst wenn die gar nicht für sie zuständig sind.

Aber wie hilfreich sind Bugreports von Nutzern die nicht einmal wissen an welche Adresse sie sich bei Problemen wenden müssen? Ich wage einfach mal zu behaupten, daß mindestens die Hälfte der Bugreports nur Arbeit aber keinerlei Erkenntnisgewinn bringen. Abgesehen vielleicht von der Erkenntnis, daß es an irgendeiner Stelle mit der Software wohl ein Problem gibt.

Man sieht es doch hier im Forum immer wieder. Fehlerbeschreibungen sind oftmals derart nichtssagend, daß man fast geneigt ist einfach nur spöttisch zu schreiben: "Mit deinem Computer gibt es anscheinend ein Problem. Das tut uns leid."
 
  • Gefällt mir
Reaktionen: Bigfoot29
@kim88 genau das ist mein Problem mit Snap es kommt keine Abfrage ob man eine Berechtigung vergeben will, es lässt sich nicht konfigurieren so das die Snap Apps die Berechtigung auf anderen Festplatten zugreifen können. Tja und fast alle meine Datein liegen eben nicht auf der 128GB SSD sondern auf der 4 TB Platte, also für mich unbenutzbar.

@Serana Es gab schon diverse Hacks das Schadprogramme aus Sandboxes ausbrechen können. Die Sandbox ist nur so gut wie sie Programmiert ist und auch in solchen gibt es Lücken wie in jeder Software.

Es gab mal einen Bericht von Microsoft in der klar aus den Telemetriedaten hervorgeht das sich User Schadcode einfangen weil sie Ihn selbst installiert haben. Dagegen hilft das beste Sicherheitsfeature nichts.
 
Linuxfreakgraz schrieb:
Es gab mal einen Bericht von Microsoft in der klar aus den Telemetriedaten hervorgeht das sich User Schadcode einfangen weil sie Ihn selbst installiert haben. Dagegen hilft das beste Sicherheitsfeature nichts.
Genau das ist ja das Problem. Man sieht ja hier auch sehr schön, daß einige Leute Snap und Flatpak anscheinend als Sicherheitsfeature ansehen. Nur lautet die Begründung für Snap und Flatpak ja unter anderem, daß den Distributionen damit Arbeit erspart würde und Canonicals Umgang mit dem Snapstore legt ebenfalls nahe, daß eine Prüfung anscheinend nicht wirklich stattfindet.

https://computer-service-remscheid.de/ubuntu-augen-auf-bei-der-verwendung-von-snaps/

Insofern halte ich es für fahrlässig den Leuten zu erzählen, Containerformate seien schon für sich ein Sicherheitsfeature. Genau das ist eben leider nicht der Fall. Der Mangel an Schadsoftware unter Linux ist eher der mangelnden Verbreitung geschuldet und der Tatsache, daß es eher schwierig ist Schadsoftware in die Repositories der Distributionen einzuschmuggeln.
 
  • Gefällt mir
Reaktionen: Bigfoot29 und Linuxfreakgraz
Serana schrieb:
daß es eher schwierig ist Schadsoftware in die Repositories der Distributionen einzuschmuggeln.
Selbst wenn: Solange man 3rd Party repos nutzt (und das machen eben viele), auch sowas wie AUR, oder die Pakete aus kompromittierten Upstream Repos gebaut wurden, hilft auch das nichts. Alles genannte kam in der Vergangenheit schon desöfteren vor.
 
  • Gefällt mir
Reaktionen: nipponpasi und Linuxfreakgraz
Zurück
Oben