ubuntuusers.de

Hallo,

darauf möchte ich mit einem Zitat von Dendemann antworten: "Check' mal die Rhetorik" 😉

Gruß, noisefloor

Ich empfinde dieses Thema - gerade für Ubuntu – wichtig, bin aber mit dieser Seite nicht glücklich, weil

• wegen der Vielzahl der Themen zwangsläufig unübersichtlich,

• und nicht testbar: Die Wahrscheinlichkeit, dass sich willige finden, die alle 5 Installationsmethoden mit allen Untermethoden testen wollen, liegt nur mikroskopisch erahnend (wenn überhaupt) über 0.

Um dem abzuhelfen, schlage ich vor die Seite umzustrukturieren in eine Hauptseite und jeweils eine Unterseite für jede Installationsart mit deren Varianten.

Die Hauptseite listet nur die 5 grundsätzlichen Methoden und vergleicht diese, beschreibt die Unterschiede und ggf. Vor- und Nachteile. Man könnte sich entschließen, auf Tests zu verzichten.

Die Unterseiten beschränken sich jeweils auf eine Methode und unterliegen der normalen Testroutine. Aber jede Seite könnte einen anderen Autor und andere Tester haben.

kB schrieb:

Ich empfinde dieses Thema - gerade für Ubuntu – wichtig, bin aber mit dieser Seite nicht glücklich, weil

• wegen der Vielzahl der Themen zwangsläufig unübersichtlich,

• und nicht testbar: Die Wahrscheinlichkeit, dass sich willige finden, die alle 5 Installationsmethoden mit allen Untermethoden testen wollen, liegt nur mikroskopisch erahnend (wenn überhaupt) über 0.

Ja, da stimme ich zu.

Um dem abzuhelfen, schlage ich vor die Seite umzustrukturieren in eine Hauptseite und jeweils eine Unterseite für jede Installationsart mit deren Varianten. Die Unterseiten beschränken sich jeweils auf eine Methode und unterliegen der normalen Testroutine. Aber jede Seite könnte einen anderen Autor und andere Tester haben.

Das wäre, finde ich, zu viel des Guten. Denn eine ganze Seite nur z.B. für Flatpak würde sich MMN nicht lohnen.

karzer schrieb:

[…] Denn eine ganze Seite nur z.B. für Flatpak würde sich MMN nicht lohnen.

Definiere „nicht lohnen“. Eine Unterseite kostet nichts und frisst kein Brot. Wenn die Unterteilung dazu beiträgt, leichter Tester, wenn auch nur für Teilbereiche, zu finden, lohnt es sich also nach meiner Einschätzung. Das geschätzte Wiki-Team mag es gerne anders einschätzen - dann aber bitte nicht jammern, wenn sich für so einen Artikel kein Tester motivieren sollte.

Wie fändest Du es denn, wenn man einfach nur PPA & Manuell auslagern würde?

Dann könnten Flatpak & Paketquellen (mit einem Verweis auf PPA) im Artikel verbleiben.

Ich fände es sinnvoll den snap-FF im Hauptartikel zu beschreiben, inklusive Einschränkungen, Anpassungen, Vor-/Nachteile, transitional per apt. Alternative Installationsarten können dann ohne subjektive Wertung in Unterseiten erklärt werden.

ChickenLipsRfun2eat schrieb:

Ich fände es sinnvoll den snap-FF im Hauptartikel zu beschreiben, inklusive Einschränkungen, Anpassungen, Vor-/Nachteile, transitional per apt. Alternative Installationsarten können dann ohne subjektive Wertung in Unterseiten erklärt werden.

Gut, würdest Du das übernehmen? Dann könnte ich den DEB-FF machen und Manuell kann man mit geringem Aufwand verschieben.

So, aufgeteilt und teilweise verschoben nach Baustelle/Firefox/Installation/Manuell und Baustelle/Firefox/Installation/PPA.

Außerdem Abschnitt zu Snap hinzugefügt. Anregungen zum Vergleich mit Flatpak und sonstige Kritik erwünscht.

Hallo,

da snap im Gegensatz zu Flatpak "first class citizen" in Ubuntu ist, sollte die snap Installation vielleicht vor die Flatpak Installation.

Soll die ESR Version noch erwähnt werden? Per snap über snap install firefox channel=esr/stable installierbar.

Gruß, noisefloor

Danke für die Anregungen! Habe ich umgesetzt.

#Firefox-als-Standard-festlegen

Könnte man den Absatz sparen und auf Alternativen-System verlinken? Zumal dort das Beispiel ja auch der Browser ist. Und die Einstellung für den Benutzer hat eh Vorrang vor der Systemvorgabe.

fleet_street schrieb:

#Firefox-als-Standard-festlegen

Könnte man den Absatz sparen und auf Alternativen-System verlinken? Zumal dort das Beispiel ja auch der Browser ist. Und die Einstellung für den Benutzer hat eh Vorrang vor der Systemvorgabe.

Vielen Dank für den Vorschlag! Artikel dementsprechend angepasst.

noisefloor schrieb:

Soll die ESR Version noch erwähnt werden? Per snap über snap install firefox channel=esr/stable installierbar.

Über das Mozilla-PPA natürlich auch (das war dessen eigentlicher Zweck vor 22.04). Dafür braucht man allerdings nicht das im Artikel zur Installation aus dem PPA genannte Apt-Pinning.

Artikel nun samt den beiden Unterartikeln veröffentlicht.

Firefox Helferlein 😎

Ein mozilla-firefox-repository-install-helper.sh Script zum hinzufügen vom Mozilla eigenen Firefox Repository für frische DEB-Pakete im DEB822 Format für das funkelnagelneue (K)Ubuntu 24.10 Oracular Oriole .

Das sollte eigentlich™ auch auf dem alten Ubuntu 24.04 Noble Numbat funktionieren. Eventuell sogar auf dafür geeigneten Debian Installationen, die ebenfalls DEB822 unterstützen. Getestet ist es aber bislang nur auf meinem Kubuntu 24.10 Oracular Oriole.

#!/usr/bin/env bash

#---------------------------------------------------
# Ubuntu 24.04 and 24.10 DEB822 little helper script
# Mozilla Firefox repository
#---------------------------------------------------

printf "\n \033[45m\033[1;36m==> Test sudo. \033[0m\033[42m\033[1;36m  ==> ... \033[0m \n \n" && \
sudo echo "sudo Test, OK." && \
printf "\n \033[45m\033[1;36m==> Make mozilla.sources entry. \033[0m\033[42m\033[1;36m  ==> ... \033[0m \n \n" && \
echo "X-Repolib-Name: packages.mozilla.org
Enabled: yes
Types: deb
URIs: https://packages.mozilla.org/apt
Suites: mozilla
Components: main
Signed-By:
$(wget -O- https://packages.mozilla.org/apt/repo-signing-key.gpg | \
sed -e 's/^$/./' -e 's/^/ /')" | \
sudo tee /etc/apt/sources.list.d/mozilla-firefox.sources > /dev/null && \
printf "\n \033[45m\033[1;36m==> Set APT-Pinning. \033[0m\033[42m\033[1;36m  ==> ... \033[0m \n \n" && \
echo '
Package: *
Pin: origin packages.mozilla.org
Pin-Priority: 1200
' | sudo tee /etc/apt/preferences.d/mozilla-firefox && \
printf "\n \033[45m\033[1;36m==> Mozilla Firefox repository active now. \033[0m\033[42m\033[1;36m  ==> Done.\033[0m \n \n" || \
printf "\n \033[41m\033[1;36m==> Sorry somthing failed.\033[0m \n \n"

Speicheren als:

mozilla-firefox-repository-install-helper.sh

... und ausführbar machen:

chmod +x mozilla-firefox-repository-install-helper.sh

Ausführbar ist es dann so:

./mozilla-firefox-repository-install-helper.sh

Mein kleines mozilla-firefox-repository-install-helper.sh generiert die sources Eintrräge für APT im DEB822 Format mit integriertem Signaturschlüssel und legt auch gleich ein APT-Pinning an, um das packages.mozilla.org Repository zu bevorzugen.

Stand heute Morgen hatte das Mozillateam auf Launchpad einen kleinen Rückstand, so dass mich das beim Kaffee saufen motivierte, mir dieses Firefox Helferlein zu schreiben. Damit ist dann die gerade frische Sicherheitslücke mit Firefox 131.0.3 nun geschlossen.

• https://www.soeren-hentzschel.at/firefox/sicherheits-update-firefox-131-0-3/

Schaut es euch an, und denkt mal drüber nach, ob es den Artikel Firefox/Installation ergänzen könnte. Zumindest für (K)Ubuntu Releases mit DEB822 Unterstützung.

Für alle anderen mit dem alten DEB-Repository Format, die noch keine DEB822 Unterstützung haben, gibt es diese Anleitung vom Mozilla Support, um das packages.mozilla.org Repository auf Ubuntu oder Debian hinzuzufügen:

• https://support.mozilla.org/de/kb/firefox-unter-linux-installieren