ubuntuusers.de

Hallo,

so ist das halt bei Flatpak, snap & Co. Die Technik ist in den jeweiligen Artikeln erklärt, also muss das nicht in jedem einzelnen Artikel, der ein snap / Flatpak / AppImage Installation enthält, erwähnt werden.

Außerdem: wir haben 2023... da würde ich 570 MB nicht als "großvolumig" bezeichnen.

Gruß, noisefloor

Der Abschnitt Installation ist schlecht strukturiert, missverständlich und unvollständig:

• Es fehlen Überschriften, gleichrangig zu „Ohne Installation (portable) und Plugins:

  • Inst. als einzelnen DEB-Paket: In diesem Abschnitt fehlt dann noch ein Hinweis (Verweis ins Wiki), wie man ein einzelnen DEB-Paket installiert.

  • Als Flatpak: In diesem Abschnitt kann die Installation von flatpak als DEB-Paket entfallen und der Hinweis auf Fremdquellen ist gegenstandslos, da hier ja keine verwendet werden.

• Was soll der Satz „Alle benötigten Hilfsprogramme werden bei der Erstellung von Peazip mitgeliefert.“ aussagen?

• Ist „GTK2 oder Qt4“ ernst gemeint oder handelt es sich um Druckfehler?

  • Hier fehlen noch Hinweise für den Leser, in welcher Situation/mit welche Absicht man das eine oder das andere auswählen sollte. Funktional sind wohl immer beide möglich, da ohnehin der Desktop-Kram redundant mitgeliefert wird, richtig? Wenn das so ist, sollte man es auch schreiben, weil das eben nicht üblich ist (und auch zu umfangreichen Downloads führt).

Danke für die Hinweise, ich habe mich bemüht, den Installationsabschnitt zum Besseren umzustrukturieren. Bitte Kritik üben.

karzer schrieb:

[…] Installationsabschnitt zum Besseren umzustrukturieren

Das ist aus meiner Sicht gut gelungen. Noch zwei Kleinigkeiten:

1. Formulierungen wie „PeaZip mit GTK3 hat derzeit noch Alpha-Status …“ gefallen mir nicht, weil der Leser immer rätseln muss, wann denn „derzeit“ mal Gegenwart gewesen sein könnte. Besser so etwas datieren, z.B. „PeaZip mit GTK3 hat derzeit (2023) noch Alpha-Status …“.

2. In der Warnbox muss nicht vor Fremdquellen, sondern i.d.F. vor Fremdpaketen gewarnt werden (Quelle tauschen zu Paket). Dabei geht es grundsätzlich um einen ganz anderen Mechanismus, wenn auch der Wiki-Link derselbe bleibt; der verlinkte Wiki-Artikel behandelt aber auch einzelne DEB-Pakete und alles ist gut.

Vielen Dank für die Rückmeldung! Ich habe die zwei Verbesserungsvorschläge so übernommen.

noisefloor

Außerdem: wir haben 2023... da würde ich 570 MB nicht als "großvolumig" bezeichnen.

Ich nutze Linux-Distro's (und demnächst vorkonfektionierte GUI-BSD-Distro's) vorwiegend dazu um ältere 32bit-ige per MX Fluxbox Linux bzw. 64bit-ige voraussichtlich mit RMD-11 inkompatible Hardware-Kombis per Ubuntu MATE wieder- bzw. weiter zu beleben. Ein halbes GiB DoLa finde ich persönlich für die Nutzung eines Packprogramms etwas arg. In der (kommerziell angehauchten) BSD-Welt ist das aber auch glaube ich so ähnlich "üblich", also das ein vorkompilliertes (Installer-)Runtime-Binary oder so alle Bibliotheken mitbringt, auch wenn derselben dann 100 fach die gleichen Pakete auf der Platte nebeneinander vor sich hinwerkeln. If-the-kids-are-united versus Dependency hell halt, ist vielleicht auch irgendwie diskussionswürdig (Deutungshoheit) was jetzt zeitgemäß ist oder nicht und wen solche Schubsladen überhaupt (noch) interessieren. Ohne hier jemanden seine Community Contribut's irgendwie abwerten zu wollen, aber Flatpacks, Snap usw. sind aus BSD-Sicht glaube ich irgendwie ein "ganz alter Hut".

Peace, Luba, Karaoke, oder sooo 😉

TrueOS bzw. ex-PC-BSD "... All software packages and dependencies were installed from inside of the .pbi files into their own self-contained directories in /Programs. This convention was aimed to decrease confusion about where binary programs reside, and to remove the possibility of a package breaking if system libraries are upgraded or changed, and to prevent dependency hell ..." | "... Alle Softwarepakete und Abhängigkeiten wurden aus den .pbi-Dateien in ihre eigenen, in sich abgeschlossenen Verzeichnisse in /Programme installiert. Diese Konvention sollte die Verwirrung darüber verringern, wo sich die Binärprogramme befinden, und die Möglichkeit ausschließen, dass ein Paket kaputt geht, wenn die Systembibliotheken aktualisiert oder geändert werden, und (damit also) die Abhängigkeitshölle verhindern ..."

Dependency hell - en.wikipedia.org

Dependency hell - EN-DE Übersetzung per Gugel-Transleit.

kB schrieb:

Das ist aus meiner Sicht gut gelungen. Noch zwei Kleinigkeiten:

1. Formulierungen wie „PeaZip mit GTK3 hat derzeit noch Alpha-Status …“ gefallen mir nicht, weil der Leser immer rätseln muss, wann denn „derzeit“ mal Gegenwart gewesen sein könnte. Besser so etwas datieren, z.B. „PeaZip mit GTK3 hat derzeit (2023) noch Alpha-Status …“.

Ich finde jetzt auch "... derzeit (Jahr/Monat) ..." gerechtfertigt. Z.B. ab (Jahr/Januar) kann sich gerade bei Rolling Releases o.a. Point Releases bis zum Januar des Folgejahres doch einiges verändern.

Bitte diesen, meinen Post löschen.

Hallo,

Ich nutze Linux-Distro's (und demnächst vorkonfektionierte GUI-BSD-Distro's) vorwiegend dazu um ältere 32bit-ige per MX Fluxbox Linux bzw. 64bit-ige voraussichtlich mit RMD-11 inkompatible Hardware-Kombis per Ubuntu MATE wieder- bzw. weiter zu beleben.

Kannst du machen. Darauf zielt Ubuntu und dessen Derivate nicht ab. Es gibt kein "leichtgewichtiges" *buntu mehr. Und Flatpak, AppImage, snap und Co. zielen auch nicht auf leichtgewichtige System / Systeme mit knappen Ressourcen - schließt sich per Design ja schon aus.

Von daher: für dich mag der Punkt relevant sein, für Ubuntu und damit am langen Ende auch für das Wiki hier nicht.

Du kannst Peazip aber auch selber aus den Quellen bauen: https://peazip.github.io/peazip-sources.html

Vielleicht läßt sich das auch vorab abfragen wieviel Daten heruntergeladen werden müssen.

Soweit ich weiß: nicht für Flatpaks. Für snap: snap info NAME_DES_SNAPS. Am Ende der Ausgabe im Abschnitt "Channels" steht die Größe des snaps. Der formhalber noch der Hinweis: das ist die Größe des snaps, welche ein SquashFS-Dateisystem enthält, welches zur Laufzeit ins RAM entpackt wird. D.h. du brauchst u.U. wesentlich mehr RAM zum Ausführen als das snap an sich groß ist.

Gruß, noisefloor

noisefloor

Vielleicht läßt sich das auch vorab abfragen wieviel Daten heruntergeladen werden müssen.

Soweit ich weiß: nicht für Flatpaks. Für snap: snap info NAME_DES_SNAPS. Am Ende der Ausgabe im Abschnitt "Channels" steht die Größe des snaps. Der formhalber noch der Hinweis: das ist die Größe des snaps, welche ein SquashFS-Dateisystem enthält, welches zur Laufzeit ins RAM entpackt wird. D.h. du brauchst u.U. wesentlich mehr RAM zum Ausführen als das snap an sich groß ist.

Okay, danke.