Xubuntu 20.04 / GIMP: GEGL 0.4.22?

[Ralph Stahl]

Moin!

Endlich habe ich das Upgrade von Xubuntu 18.04 auf 20.04 gemacht und
freue mich. Fast. Denn ich bekomme Gimp nicht mehr zum Laufen. Das
meckert mich an, dass die Bibliothek GEGL >0.4.22 gebraucht wird, aber
nur 0.4.18 installiert sei, was stimmt *). Die höhere Version gibt es
nur als Source an diversen Stellen - ich kann aber nicht recht glauben,
dass sich Gimp nicht ohne solche Kopfstände installieren lässt.

Es soll Gimp 2.10 installiert werden, das hatte ich vorher auch schon,
allerdings über das PPA otto-kesselgulasch/gimp.

Gibt es Abhilfe? Ich freue mich auf Tips. Danke!

Ralph




*) Zitat:

GEGL version too old!

GIMP requires GEGL version 0.4.22 or later.
Installed GEGL version is 0.4.18.

Somehow you or your software packager managed
to install GIMP with an older GEGL version.

Please upgrade to GEGL version 0.4.22 or later.

[Kay Martinen]

Am 29.04.20 um 00:10 schrieb Ralph Stahl:

> Endlich habe ich das Upgrade von Xubuntu 18.04 auf 20.04 gemacht und
> freue mich. Fast. Denn ich bekomme Gimp nicht mehr zum Laufen. Das
> meckert mich an, dass die Bibliothek GEGL >0.4.22 gebraucht wird, aber
> nur 0.4.18 installiert sei, was stimmt *). Die höhere Version gibt es
> nur als Source an diversen Stellen - ich kann aber nicht recht glauben,
> dass sich Gimp nicht ohne solche Kopfstände installieren lässt.
>
> Es soll Gimp 2.10 installiert werden, das hatte ich vorher auch schon,
> allerdings über das PPA otto-kesselgulasch/gimp.

So was kann passieren wenn man PPA's nutzt. Das steht ja nicht umsonst
für PERSONAL oder PRIVAT PACKET Archive. Wenn dort im PPA die nötigen
Libs u.a. nicht zu finden sind dann bleibt nur source oder s.u.

> Gibt es Abhilfe? Ich freue mich auf Tips. Danke!

Vermutlich. Installiere Gimp aus den Ubuntu Repos. Da werden bestimmt
die richtigen libs u.a. mit installiert.

Ich würd's so machen.

1. Gimp deinstallieren
2. das PPA deaktivieren
3. update der Paketlisten
4. Gimp installieren.

Kay

--
Posted via SN

[Marcel Mueller]

Am 29.04.20 um 00:48 schrieb Kay Martinen:

> Vermutlich. Installiere Gimp aus den Ubuntu Repos. Da werden bestimmt
> die richtigen libs u.a. mit installiert.

Ack.

> Ich würd's so machen.
>
> 1. Gimp deinstallieren
> 2. das PPA deaktivieren
> 3. update der Paketlisten

Man korrigiere mich, aber meines Wissens wird man einmal geladene
Paketlisten so nicht wieder los, wenn man die Quelle entfernt. Es kommen
dann nur keine Updates mehr rein. Oder ist das bei PPA anders?

> 4. Gimp installieren.

Mutmaßlich kann man in aptitude o.ä. einfach die andere Version von GIMP
auswählen. Die ist ja parallel immer noch verfügbar.


Marcel

[Thomas Wiegner]

On Wed, 29 Apr 2020, Marcel Mueller <news.5...@spamgourmet.org> wrote:
> Am 29.04.20 um 00:48 schrieb Kay Martinen:
>

>> Ich würd's so machen.
>>
>> 1. Gimp deinstallieren
>> 2. das PPA deaktivieren
>> 3. update der Paketlisten
>
> Man korrigiere mich, aber meines Wissens wird man einmal geladene
> Paketlisten so nicht wieder los, wenn man die Quelle entfernt. Es kommen
> dann nur keine Updates mehr rein. Oder ist das bei PPA anders?

Nein. Du musst den Kram, den Du über das ppa installiert hast dann schon
zu Fuss deinstallieren.

Man kann sich das mit aptitude ganz gut anzeigen lassen (hier mal am
Beispiel des Handbrake ppa bei mir)

| aptitude search "?origin (handbrake-releases) ?installed"
| i handbrake-gtk - versatile DVD ripper and video transcoder - GTK GUI

>> 4. Gimp installieren.
>
> Mutmaßlich kann man in aptitude o.ä. einfach die andere Version von GIMP
> auswählen. Die ist ja parallel immer noch verfügbar.

Da ubuntu 20.04 ja ganz frisch rausgekommen ist, macht es momentan
vermutlich nicht mal viel Sinn für gimp ein ppa zu verwenden, da
zu diesem Zeitpunkt die offizielle gimp Version akutell ist.


--
[X] Nail here for new Monitor

[Tim Ritberg]

Am 29.04.20 um 00:10 schrieb Ralph Stahl:

> Moin!
>
> Endlich habe ich das Upgrade von Xubuntu 18.04 auf 20.04 gemacht und
> freue mich. Fast. Denn ich bekomme Gimp nicht mehr zum Laufen. Das
> meckert mich an, dass die Bibliothek GEGL >0.4.22 gebraucht wird, aber

Ach das muss ich auch noch, hab extra gewartet :-D

Tim

[Ralph Stahl]

Am 29.04.20 um 00:48 schrieb Kay Martinen:

Ich hatte das PPA *vor* 20.04, weil es lange Gimp 2.10 nicht in für
Xubuntu 18.04 gab. Ich habe das PPA entfernt, vorher natürlich Gimp
gelöscht (apt purge), dann über die Paketquellen von 20.04 installiert
und die Lib fehlt trotzdem - die ist auch mit der Synaptic-Suche nach
GEGL nicht verfügbar. So ist also Gimp 2.10 nicht mehr nutzbar.

Ralph

[Ralph Stahl]

Am 29.04.20 um 00:48 schrieb Kay Martinen:

Hier https://www.tecrobust.com/how-to-install-gimp-for-ubuntu-20-04-lts/
habe ich eine Alternative gefunden:

sudo snap install gimp

also nicht über apt. Funktioniert :-) (warum?).

Ralph

[Christian Schumacher]

Am Wed, 29 Apr 2020 12:58:24 +0200 schrieb Ralph Stahl:

> sudo snap install gimp
>

> also nicht über apt. Funktioniert (warum?).

Wenn ich das richtig verstanden habe, wird bei snap alles mitgebracht, was
das Paket braucht. Um eben nicht in irgendwelchen Abhängigkeitsfallen zu
landen.

Gruß
Christian

[Christian Garbs]

Mahlzeit!

Wir kompilieren jetzt wieder alles statisch, damit es beim nächsten
Security-Bug in lib-irgendwas nicht reicht, die lib-irgendwas per
Paketmanager zu updaten, sondern man jedes installierte Snap einzeln
abklappern kann, um zu gucken, ob der Hersteller schon eine neue
gefixte Version gebaut hat :-/ (ja, vermutlich kann man alle Snaps mit
einem Kommando auf die neueste Version updaten; nein, damit weiß man
noch nicht, wo die neue lib-irgendwas schon drin ist und wo nicht)

Das hat die gleichen Vor- und Nachteile wie dass es jetzt alle
möglichen Webanwendungen als komplettes Docker-Image gibt, statt wie
früher ein paar Zeilen Konfiguration im Apache einzubauen und einen
neuen Datenbankuser anzulegen.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
Paranoid schizophrenics outnumber their enemies at least two to one.

[Ralph Stahl]

Am 29.04.20 um 17:44 schrieb Christian Garbs:

> Mahlzeit!
>
> Christian Schumacher <cs....@nurfuerspam.de> wrote:
>> Am Wed, 29 Apr 2020 12:58:24 +0200 schrieb Ralph Stahl:
>
>>> sudo snap install gimp
>>>
>>> also nicht über apt. Funktioniert (warum?).
>
>> Wenn ich das richtig verstanden habe, wird bei snap alles mitgebracht, was
>> das Paket braucht. Um eben nicht in irgendwelchen Abhängigkeitsfallen zu
>> landen.
>
> Wir kompilieren jetzt wieder alles statisch, damit es beim nächsten
> Security-Bug in lib-irgendwas nicht reicht, die lib-irgendwas per
> Paketmanager zu updaten, sondern man jedes installierte Snap einzeln
> abklappern kann, um zu gucken, ob der Hersteller schon eine neue
> gefixte Version gebaut hat :-/ (ja, vermutlich kann man alle Snaps mit
> einem Kommando auf die neueste Version updaten; nein, damit weiß man
> noch nicht, wo die neue lib-irgendwas schon drin ist und wo nicht)
>
> Das hat die gleichen Vor- und Nachteile wie dass es jetzt alle
> möglichen Webanwendungen als komplettes Docker-Image gibt, statt wie
> früher ein paar Zeilen Konfiguration im Apache einzubauen und einen
> neuen Datenbankuser anzulegen.
>
> Gruß
> Christian
>

Das war mir so noch nicht bekannt. Also sollte ich snap eher als
Notlösung betrachten? Bis jetzt habe ich nur Chromium und Gimp so
installiert, weil die in den 20er Paketquellen nicht verfügbar sind. Ich
kann es ja immer mal wieder testen und ggf dann mit apt installieren,
wenn es funktioniert.

Danke für die Aufklärung!

Ralph

[Christian Garbs]

Mahlzeit!

Ralph Stahl <po...@rstahl.de> wrote:
> Am 29.04.20 um 17:44 schrieb Christian Garbs:

>> Christian Schumacher <cs....@nurfuerspam.de> wrote:

>>> Wenn ich das richtig verstanden habe, wird bei snap alles
>>> mitgebracht, was das Paket braucht. Um eben nicht in irgendwelchen
>>> Abhängigkeitsfallen zu landen.

>> Wir kompilieren jetzt wieder alles statisch, damit es beim nächsten
>> Security-Bug in lib-irgendwas nicht reicht, die lib-irgendwas per
>> Paketmanager zu updaten, sondern man jedes installierte Snap einzeln
>> abklappern kann, um zu gucken, ob der Hersteller schon eine neue
>> gefixte Version gebaut hat :-/ (ja, vermutlich kann man alle Snaps mit
>> einem Kommando auf die neueste Version updaten; nein, damit weiß man
>> noch nicht, wo die neue lib-irgendwas schon drin ist und wo nicht)
>>
>> Das hat die gleichen Vor- und Nachteile wie dass es jetzt alle
>> möglichen Webanwendungen als komplettes Docker-Image gibt, statt wie
>> früher ein paar Zeilen Konfiguration im Apache einzubauen und einen
>> neuen Datenbankuser anzulegen.

> Das war mir so noch nicht bekannt. Also sollte ich snap eher als
> Notlösung betrachten?

Das musst Du Dir selber überlegen :-)

Im Falle einzelner Anwendungen ist das sicher ganz praktisch, wenn die
Alternative z.B. wäre, die Software selbst zu kompilieren, denn dann
müsstest Du ja auch regelmäßig selber updaten. Schlimmer noch, wenn
Du nur für die eine Anwendung erst irgendeine exotische Buildumgebung
aufbauen musst.

Bei „so viel wie möglich über Snap installieren wie geht“ hingegen
würde ich mir ein „bloß nicht“ entlocken lassen :)


Was mir noch eingefallen ist: Eine Tolle Sache™ an dem Konzept der
shared libraries ist ja, dass sich mehrere Prozesse die Library im
Speicher teilen. Wenn Du z.B. eine KDE-Anwendung laufen hast, die die
ganzen KDE-Libraries geladen hat, dann benutzt die nächste
KDE-Anwendung die Libraries mit, ohne sie nochmal neu zu laden.

Wenn jetzt ein Snap alle Libraries selber mitbringt, dürfte das nicht
mehr funktionieren. Jede Anwendung würde soweit ich das verstehe dann
einmal den vollen Speicher für sämtliche Libraries (X11, GTK, KDE,
Gnome, Qt, boost, …) extra verbraten.

Schon wieder ein Punkt, wo sich das ähnlich wie Docker-Images oder
virtuelle Maschinen verhält. Ist hat ein ähnliches Prinzip, nur auf
einer anderen Größenordnung (einzelne Anwendung statt gesamter
Rechner).

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Wie fängt man Krokodile?
Man lockt sie unter einen Baum und schüttelt die Elefanten raus.

[Kay Martinen]

Am 01.05.20 um 19:58 schrieb Christian Garbs:

>
> Ralph Stahl <po...@rstahl.de> wrote:
>
>> Das war mir so noch nicht bekannt. Also sollte ich snap eher als
>> Notlösung betrachten?

Meiner Meinung nach sollte man das ganz lassen denn es führt in
Versuchung wie alles was bequem ist und bringt die Entwicklung nicht
voran sondern ist eigentlich ein Rückschritt.

> Das musst Du Dir selber überlegen :-)

:-(

> Im Falle einzelner Anwendungen ist das sicher ganz praktisch, wenn die
> Alternative z.B. wäre, die Software selbst zu kompilieren, denn dann

> Bei „so viel wie möglich über Snap installieren wie geht“ hingegen
> würde ich mir ein „bloß nicht“ entlocken lassen :)

Mir klappen schon die Zehennägel hoch wenn ich nur an Snap u.a. denke!

> Was mir noch eingefallen ist: Eine Tolle Sache™ an dem Konzept der
> shared libraries ist ja, dass sich mehrere Prozesse die Library im
> Speicher teilen. Wenn Du z.B. eine KDE-Anwendung laufen hast, die die
> ganzen KDE-Libraries geladen hat, dann benutzt die nächste
> KDE-Anwendung die Libraries mit, ohne sie nochmal neu zu laden.

Eben. Darum nennt man diese Libraries ja auch "shared". Im Gegensatz zu
Static-Libraries.

> Wenn jetzt ein Snap alle Libraries selber mitbringt, dürfte das nicht
> mehr funktionieren. Jede Anwendung würde soweit ich das verstehe dann
> einmal den vollen Speicher für sämtliche Libraries (X11, GTK, KDE,
> Gnome, Qt, boost, …) extra verbraten.

BLOAT! Mein VM-Server weist teilweise hunderte Megabyte als KSM aus. Als
Kernel-samepage Merging Wenn ich nur 2 oder 3 VMs mit dem gleichen
Basis-Betriebssystem laufen habe. Da wird m.W. schon auf kernel-ebene
eine page in der z.b. eine lib geladen ist von mehr als einer VM
genutzt. Was ja ansich kein Problem ist weil die nur ausgeführt, aber
nicht beschreibbar sind.

https://www.thomas-krenn.com/de/wiki/KSM_(Kernel_Samepage_Merging)

> Schon wieder ein Punkt, wo sich das ähnlich wie Docker-Images oder
> virtuelle Maschinen verhält. Ist hat ein ähnliches Prinzip, nur auf
> einer anderen Größenordnung (einzelne Anwendung statt gesamter
> Rechner).

Ja, eben. Da sind Snap u.a. mit alten Windows-Anwendungen vergleichbar
die ihre eigene VisualBasic Runtime oder was auch immer mit bringen und
dieses ggf. sogar direkt im eigenen Programmordner installierten. Damit
auch ja alles beisammen ist. Und bei Versionsunterschieden und mehreren
Gestarteten Programmen wundert man sich das der üppige Arbeitsspeicher
schon voll ist und die Kiste anfängt mit 1000-fach langsamerem Tempo zu
swappen.

Aber, ist natürlich ein Super Argument um Noch mehr RAM und noch
Schnellere CPUs und noch schnellere SSDs zu verkaufen.

Ein Marketing-Gag, ein SoftRAM Nachfolger(Vaporware) ist das in meinen
Augen. Verbrennt unnötig Ressourcen wegen der Engstirnigkeit von
Entwicklern oder deren Firmen die meinen alles in eine Tüte werfen zu
müssen. Aber sie werden es tun weil es diese Techniken gibt. Und weil es
die gibt werden die auch angewendet.

Wieder ein Punkt wo der User mit den Füßen abstimmen könnte und sagt
"Den Scheiß will ich nicht" aber das hat schon bei anderen Gelegenheiten
nicht funktioniert. Da mache ich mir keine Illusionen, es bleibt nur ein
Rest Hoffnung.

[Christian Garbs]

Mahlzeit!

Kay Martinen <k...@martinen.de> wrote:

> BLOAT! Mein VM-Server weist teilweise hunderte Megabyte als KSM aus. Als
> Kernel-samepage Merging Wenn ich nur 2 oder 3 VMs mit dem gleichen
> Basis-Betriebssystem laufen habe. Da wird m.W. schon auf kernel-ebene
> eine page in der z.b. eine lib geladen ist von mehr als einer VM
> genutzt. Was ja ansich kein Problem ist weil die nur ausgeführt, aber
> nicht beschreibbar sind.
>
> https://www.thomas-krenn.com/de/wiki/KSM_(Kernel_Samepage_Merging)

Interessant, das kannte ich noch nicht.

KSM müsste ja eigentlich auch die doppelten und dreifachen
Snap-Bibliotheken deduplizieren, oder?

Mir fehlt gerade der Ansporn, das auszuprobieren, insbesondere weil
auch noch vor diversen Angriffsmöglichkeiten gewarnt wird: Wikipedia
nennt RowHammer, Timing-Attacken und ASLR-Umgehung; die RedHat-Doku
spricht allgemein von Sidechannel-Attacken.

Im Debian-Kernel ist's drinnen, aber ohne ksmtuned tut es wohl nichts.

> [Snap]

>
> Ein Marketing-Gag, ein SoftRAM Nachfolger(Vaporware) ist das in meinen
> Augen.

Eher wäre KSM als SoftRAM zu bezeichnen - sogar in funktionierend ;-)

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Abstraction is selective ignorance.
(Andrew Koenig)

[Kay Martinen]

Am 05.05.20 um 17:44 schrieb Christian Garbs:

>
> Kay Martinen <k...@martinen.de> wrote:
>
>> BLOAT! Mein VM-Server weist teilweise hunderte Megabyte als KSM aus. Als
>> Kernel-samepage Merging Wenn ich nur 2 oder 3 VMs mit dem gleichen
>> Basis-Betriebssystem laufen habe. Da wird m.W. schon auf kernel-ebene
>> eine page in der z.b. eine lib geladen ist von mehr als einer VM
>> genutzt. Was ja ansich kein Problem ist weil die nur ausgeführt, aber
>> nicht beschreibbar sind.
>>
>> https://www.thomas-krenn.com/de/wiki/KSM_(Kernel_Samepage_Merging)
>
> Interessant, das kannte ich noch nicht.
>
> KSM müsste ja eigentlich auch die doppelten und dreifachen
> Snap-Bibliotheken deduplizieren, oder?

Das weiß ich nicht. Vermutlich nur wenn die bibliothek bitgenau die
gleiche ist, also keine minimal verschiedene Versionen - was doch bei
mehreren solcher SNAP Programme noch eher wahrscheinlich ist.

Dabei geht's ja um speicherseiten und nicht primär um dateien - nur
deren inhalt im RAM. Ich weiß auch zu wenig davon um zu beurteilen ob
und was KSM deduplizieren könnte, oder kann.

> Mir fehlt gerade der Ansporn, das auszuprobieren, insbesondere weil
> auch noch vor diversen Angriffsmöglichkeiten gewarnt wird: Wikipedia
> nennt RowHammer, Timing-Attacken und ASLR-Umgehung; die RedHat-Doku
> spricht allgemein von Sidechannel-Attacken.

Ich hab drauf gesetzt das du selbst drauf kommst weil mir das
naheliegend schien. Sicher gibts das und auf einem öffentlich
erreichbaren VM host ist das wohl keine gute Idee. Und ob Firmen das auf
ihrer; evtl. outgesourcten; Hardware einsetzen wollten ist wohl deren
Entscheidung - wenn sie davon wissen.

Privat sehe ich da eher weniger ein Problem drin. Wenn man den Systemen
die man selbst installierte nicht mehr Vertraut muß man sie eben löschen
oder wissen was man sonst machen kann.

IMHO müsste so ein Schädling dann aber in einer VM oder lib drin
stecken. Wenn die dedupliziert würde wäre der auch in einer anderen VM
drin. Aber wenn's keine lib sondern ein programm ist dann müsste es
immer noch von einer VM in die andere kommen um daten ab zu greifen. Mit
obigem Methoden, oder mit CPU-Lücken... was davon ist wohl schneller
oder einfacher. Weißt du es? Ich nicht.

> Im Debian-Kernel ist's drinnen, aber ohne ksmtuned tut es wohl nichts.

ProxmoxVE ist Debian-basiert.

>> [Snap]
>>
>> Ein Marketing-Gag, ein SoftRAM Nachfolger(Vaporware) ist das in meinen
>> Augen.
>
> Eher wäre KSM als SoftRAM zu bezeichnen - sogar in funktionierend ;-)

Naja, auch wenn mein Vergleich ein wenig hinkte. Aber SoftRAM hat nicht
mehr RAM frei gemacht oder gar erzeugt, es hat eher noch mehr RAM
verschwendet soweit ich noch aus dem c't Artikel weiß. KSM kann dagegen
wirklich RAM sparen.

Wenn KSM bei SNAP nicht hilft bleibt es Speicherplatzverschwendung.
Und wenn man ein SNAP installiert weil man Programm X in Version Y haben
will das Lib Z braucht die das System so aber nicht bietet dann... ist
SNAP einfach nur BLOAT. :-)

[Gunter Gutzeit]

Kay Martinen schrieb am Do 07.05.2020 01:37:39 +0200:

> Und wenn man ein SNAP installiert weil man Programm X in Version Y haben
> will das Lib Z braucht die das System so aber nicht bietet dann... ist
> SNAP einfach nur BLOAT. :-)

Wenn man Program X in Version Y haben will, das Lib Z braucht, die das
Stable-System so aber nicht bietet und ich mir das Programm X in Version
Y aus den Sid-Quellen installiere, wird apt das Lib Z ebenfalls in
mein Stable-System installieren (müssen) und wenn ich Pech habe die
Stabilität meines gesamten Stable-Systems (unter Umständen) gefährden.

... dann ist SNAP eben nicht einfach nur BLOAT, da das Lib Z
abgesichert vom Gesamtsystem (AppArmor) genau wie mit Flatpak (hier
abgeschottet in einer Sandbox) theoretisch keine Chance hat, das
Gesamtsystem kaputt zu machen.

--
Gunter
https://guntergutzeit.de.cool

[Claus Reibenstein]

Gunter Gutzeit schrieb am 07.05.2020 um 09:24:

> Wenn man Program X in Version Y haben will, das Lib Z braucht, die das
> Stable-System so aber nicht bietet und ich mir das Programm X in Version
> Y aus den Sid-Quellen installiere, wird apt das Lib Z ebenfalls in
> mein Stable-System installieren (müssen) und wenn ich Pech habe die
> Stabilität meines gesamten Stable-Systems (unter Umständen) gefährden.

Warum und inwiefern sollte Lib Z, die nur von Programm X in Version Y
benötigt und sonst nicht weiter benutzt wird, Dein Stable-System gefährden?

Gruß
Claus

[Gunter Gutzeit]

Warum und inwiefern macht es wohl Sinn, wenn im Gesamtkontext eines
möglichst funktionstüchtigen Debian ein neues Lib Z in mehreren
Varianten (Releases) parallel unterschiedliche Erprobungsphasen
durchläuft: stable (‚stabil‘), testing (‚Erprobung‘) und unstable
(‚instabil‘)?

Ich sage ja nicht, dass Lib Z mein Stable-System zwingend gefährdet,
auch wenn es nur in der unstable Version existiert. Die Debian-
Entwickler sagen das ja auch nicht. Es geht doch wohl nur darum
potenzielle Risiken für eine künftige stable-Variante zu minimieren.
Auch wenn Lib Z jemals das Stable-Stadium erreichen sollte, gibt es
keine absolute Garantie, dass LibZ-Stable mein Debian-Stable-System
nicht gefährdet. Warum gäbe bei Debian sonst ein Sicherheits-Audit-
Team, wenn es da keine Gefährdungen gäbe?

Ein Aspekt Snap oder Flatpak zu nutzen, ist eben dieser, potenziell
größere Gefährdungspotenziale (z.B. aus Fremdquellen) zu minimieren.
Minimieren bedeutet aber nicht ausschließen. AppArmor oder Bubblewrap
könnten ja auch vom jeweiligen Snap- bzw Flatpak-Maintainer mit
Sicherheitslöchern konfiguriert worden sein - oder?

--
Gunter
https://guntergutzeit.de.cool

[Marc Haber]

setze Z gleich c.

Das kommt vor, und zwar nicht zu selten.

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Christian Garbs]

Mahlzeit!

Genau, gerade so ein Einzelfall scheint eine sinnvolle Anwendung zu sein.

Der Bloat relativiert sich dann auch: Wenn ich nur für ein einzelnes
Paket 15 Libraries in neueren Versionen installiere, dann belegen die
auch als shared libs extra Speicher nur für diesen Fall, da sie sonst
kein anderes Programm im ganzen System benutzt (sonst wären sie ja
schon installiert gewesen).

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Klingonisch für Anfänger VII:
Mangelnde strukturelle Integrität der oberen Abschirmflächen:
DACHCHMORRRSCHSCH

[Gunter Gutzeit]

Christian Garbs schrieb am Fr 08.05.2020 09:12:44 +0200:

> Mahlzeit!
>
> Gunter Gutzeit <gunter....@arcor.de> wrote:
>> Kay Martinen schrieb am Do 07.05.2020 01:37:39 +0200:
>
>>> Und wenn man ein SNAP installiert weil man Programm X in Version Y haben
>>> will das Lib Z braucht die das System so aber nicht bietet dann... ist
>>> SNAP einfach nur BLOAT. :-)
>>
>> Wenn man Program X in Version Y haben will, das Lib Z braucht, die das
>> Stable-System so aber nicht bietet und ich mir das Programm X in Version
>> Y aus den Sid-Quellen installiere, wird apt das Lib Z ebenfalls in
>> mein Stable-System installieren (müssen) und wenn ich Pech habe die
>> Stabilität meines gesamten Stable-Systems (unter Umständen) gefährden.
>>
>> ... dann ist SNAP eben nicht einfach nur BLOAT, da das Lib Z
>> abgesichert vom Gesamtsystem (AppArmor) genau wie mit Flatpak (hier
>> abgeschottet in einer Sandbox) theoretisch keine Chance hat, das
>> Gesamtsystem kaputt zu machen.
>
> Genau, gerade so ein Einzelfall scheint eine sinnvolle Anwendung zu sein.

Ja, ich schrieb bereits in anderem Zusammenhang darüber, dass Flatpak
durchaus Sinn machen kann (gilt für Snap entsprechend). Aus meiner
Flatpak Testinstallation mit den Flatpak-Containern für sicherheits-
kritische abgeschottete Internet-Programme (Firefox, Thunderbird,
Torbrowser, Claws, Gajim, qTox jeweils in gesonderten Containern)
laufen neben/mit einem winzigen Container Linux (hier einem frugalen
AntiX) ganz zuverlässig und ganz hervorragend. Darüberhinaus kann ich
vermelden, dass das Flathub Repository wirklich gut gepflegt wird und
was meine Testanwendungen betrifft topaktuell ist. Die letzten Updates
des Firefox, Thunderbird und Torbrowser sind heute morgen bei mir sauber
durchgelaufen. Claws, Gajim und qTox laufen ebenfalls in aktuelleren
Programmversionen als im aktuellen Debian-Stable. Also da gibt es m.E.
nix zu meckern :-)

> Der Bloat relativiert sich dann auch: Wenn ich nur für ein einzelnes
> Paket 15 Libraries in neueren Versionen installiere, dann belegen die
> auch als shared libs extra Speicher nur für diesen Fall, da sie sonst
> kein anderes Programm im ganzen System benutzt (sonst wären sie ja
> schon installiert gewesen).

Ja genau, ist m.E. eine reine Interessen-Abwägung. Bin ich
gegebenenfalls für etwas mehr Sicherheit bereit, etwas mehr Ressourcen
zu opfern? Je nach Einzelfall und individuellem Anwendungszusammenhang
kann das durchaus Sinn machen.

--
Gunter
https://guntergutzeit.de.cool

[Sieghard Schicktanz]

Hallo Christian,

Du schriebst am Fri, 8 May 2020 09:12:44 +0200 (CEST):

> Genau, gerade so ein Einzelfall scheint eine sinnvolle Anwendung zu sein.

Zumindest wenn dem Einzelfall nicht ganz zu trauen ist...

> Der Bloat relativiert sich dann auch: Wenn ich nur für ein einzelnes
> Paket 15 Libraries in neueren Versionen installiere, dann belegen die
> auch als shared libs extra Speicher nur für diesen Fall, da sie sonst
> kein anderes Programm im ganzen System benutzt (sonst wären sie ja
> schon installiert gewesen).

Und das wiederun relativiert sich in dem Moment, wo Du ein neues Programm
installierst, das eine dieser "15 Libraries" auch benutzen möchte - und
dann nicht kann und dzf. diese nach- und damit doppelt installieren muß.
Anscheinend ist das eine politische Konstruktion: Zu kurz gedacht als
Qualitätsmerkmal.

--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

[Marc Haber]

Sieghard Schicktanz <Sieghard....@SchS.de> wrote:
>Hallo Christian,
>
>Du schriebst am Fri, 8 May 2020 09:12:44 +0200 (CEST):
>
>> Genau, gerade so ein Einzelfall scheint eine sinnvolle Anwendung zu sein.
>
>Zumindest wenn dem Einzelfall nicht ganz zu trauen ist...
>
>> Der Bloat relativiert sich dann auch: Wenn ich nur für ein einzelnes
>> Paket 15 Libraries in neueren Versionen installiere, dann belegen die
>> auch als shared libs extra Speicher nur für diesen Fall, da sie sonst
>> kein anderes Programm im ganzen System benutzt (sonst wären sie ja
>> schon installiert gewesen).
>
>Und das wiederun relativiert sich in dem Moment, wo Du ein neues Programm
>installierst, das eine dieser "15 Libraries" auch benutzen möchte - und
>dann nicht kann und dzf. diese nach- und damit doppelt installieren muß.
>Anscheinend ist das eine politische Konstruktion: Zu kurz gedacht als
>Qualitätsmerkmal.

Flatpak/Snap existiert, um Lieferanten kommerzieller Software das
Testen einfach zu machen, indem die Kontaktfläche zum darunter
liegenden Betriebssystem minimiert wird. Der Anwender bezahlt das mit
höherem Speicherbedarf, und zwar sowohl auf dem Massen- als auch im
Arbeitsspeicher.

[Christian Garbs]

Mahlzeit!

Gunter Gutzeit <gunter....@arcor.de> wrote:

> ... dann ist SNAP eben nicht einfach nur BLOAT, da das Lib Z
> abgesichert vom Gesamtsystem (AppArmor) genau wie mit Flatpak (hier
> abgeschottet in einer Sandbox) theoretisch keine Chance hat, das
> Gesamtsystem kaputt zu machen.

Weiterer Spaß mit Snap:
https://www.onli-blogging.de/1918/Snap-und-Ubuntu-Nachbesserungen-erforderlich.html

- Die Snaps landen wohl allesamt in /home/$USER/snap. Das ist nicht
mal ein unsichtbarer Ordner und damit ziemlich übergriffig.
- Das ist absichtlich nicht konfigurierbar.
- Wenn ich das richtig verstanden habe, wird nicht mal $HOME
ausgewertet – viel Spaß also, wenn die Home-Directories woanders
liegen.

- Die Auto-Updates sind nicht abschalt-, verschieb- oder pausierbar.
Viel Spaß am Beamer in der Firma, wenn sich die
Präsentationssoftware mittendrin neu startet.

Und das alles ist wohl Absicht seitens der Snap-Programmierer, weil
die besser als ihre User wissen, was ihre User brauchen.

Kommt mir irgendwie bekannt vor :-/ (mit systemd hab ich mich langsam
arrangiert, das hat auch Vorteile, auch wenn systemd es weiterhin
nicht schafft, meine ZFS-Mounts _vor_ dem Start der Programme, die von
den daraufliegenden Dateisystemen abhängen, durchzuführen …)

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Why do Marxists drink only herbal tea?
Because proper tea is theft!

[Ralph Stahl]

Am 09.05.20 um 09:23 schrieb Christian Garbs:

> Mahlzeit!
>
> Gunter Gutzeit <gunter....@arcor.de> wrote:
>
>> ... dann ist SNAP eben nicht einfach nur BLOAT, da das Lib Z
>> abgesichert vom Gesamtsystem (AppArmor) genau wie mit Flatpak (hier
>> abgeschottet in einer Sandbox) theoretisch keine Chance hat, das
>> Gesamtsystem kaputt zu machen.
>
> Weiterer Spaß mit Snap:
> https://www.onli-blogging.de/1918/Snap-und-Ubuntu-Nachbesserungen-erforderlich.html
>
> - Die Snaps landen wohl allesamt in /home/$USER/snap. Das ist nicht
> mal ein unsichtbarer Ordner und damit ziemlich übergriffig.

Bei mir /snap/ UND ~/snap/ mit gleichem Inhalt. Also echt doppelt
gemoppelt, wobei z.B. "which gimp" auf ersteres zeigt. Warum?
Xubuntu 20.04.

[...]

Ralph

[Gunter Gutzeit]

Christian Garbs schrieb am Sa 09.05.2020 09:23:37 +0200:

> Weiterer Spaß mit Snap:
> https://www.onli-blogging.de/1918/Snap-und-Ubuntu-Nachbesserungen-erforderlich.html
>
> - Die Snaps landen wohl allesamt in /home/$USER/snap. Das ist nicht
> mal ein unsichtbarer Ordner und damit ziemlich übergriffig.

In meiner Flatpak-Testinstallation lassen sich die einzelnen
Flatpak-Container (mit Programmen mit Internet-Bezug) auch räumlich
(auf dem Datenträger) außerhalb des AntiX-Datei-Systems also
außerhalb des Betriebssystem-Containers (ausschließlich mit Programmen
ohne Internet-Bezug) installieren und administrieren.

Wie das geht? Adding a custom installation:

https://docs.flatpak.org/en/latest/tips-and-tricks.html

Niemand muss besonders gehärtete Linux-Betriebssysteme gut finden.
Niemand muss besonders gefährdete Programme mit Internet-Bezug in einer
Sandbox absichern. Niemand sollte jedoch sagen, dass das alles perse
einfach Scheiße ist.

--
Gunter
https://guntergutzeit.de.cool

[Christian Garbs]

Mahlzeit!

Gunter Gutzeit <gunter....@arcor.de> wrote:

> Christian Garbs schrieb am Sa 09.05.2020 09:23:37 +0200:

>> Weiterer Spaß mit Snap:
>> https://www.onli-blogging.de/1918/Snap-und-Ubuntu-Nachbesserungen-erforderlich.html
>>
>> - Die Snaps landen wohl allesamt in /home/$USER/snap. Das ist nicht
>> mal ein unsichtbarer Ordner und damit ziemlich übergriffig.

> In meiner Flatpak-Testinstallation lassen sich die einzelnen
> Flatpak-Container (mit Programmen mit Internet-Bezug) auch räumlich
> (auf dem Datenträger) außerhalb des AntiX-Datei-Systems also
> außerhalb des Betriebssystem-Containers (ausschließlich mit Programmen
> ohne Internet-Bezug) installieren und administrieren.

Das mag Flatpak können, das bringt Dich aber bei Snap nicht weiter :)

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Do not believe in miracles -- rely on them.

[Christian Garbs]

Mahlzeit!

Ralph Stahl <po...@rstahl.de> wrote:

> Am 09.05.20 um 09:23 schrieb Christian Garbs:

>> - Die Snaps landen wohl allesamt in /home/$USER/snap. Das ist nicht
>> mal ein unsichtbarer Ordner und damit ziemlich übergriffig.

> Bei mir /snap/ UND ~/snap/ mit gleichem Inhalt. Also echt doppelt
> gemoppelt, wobei z.B. "which gimp" auf ersteres zeigt. Warum?
> Xubuntu 20.04.

Kann es sein, dass das nur doppelt gemounted ist und tatsächlich nur
einmal auf Platte? Schau mal, was `mount` dazu sagt.
(Ich hab hier kein Snap zum Gucken.)

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

"Hello, handsome. If things have gone totally wrong,
I'm talking to myself and you've got a wet towel wrapped
around your head." (Quaid, Total Recall)

[Gunter Gutzeit]

Marc Haber schrieb am Sa 09.05.2020 09:15:59 +0200:

> Sieghard Schicktanz <Sieghard....@SchS.de> wrote:
>> Hallo Christian,
>>
>> Du schriebst am Fri, 8 May 2020 09:12:44 +0200 (CEST):
>>
>>> Genau, gerade so ein Einzelfall scheint eine sinnvolle Anwendung zu sein.
>>
>> Zumindest wenn dem Einzelfall nicht ganz zu trauen ist...
>>
>>> Der Bloat relativiert sich dann auch: Wenn ich nur für ein einzelnes
>>> Paket 15 Libraries in neueren Versionen installiere, dann belegen die
>>> auch als shared libs extra Speicher nur für diesen Fall, da sie sonst
>>> kein anderes Programm im ganzen System benutzt (sonst wären sie ja
>>> schon installiert gewesen).
>>
>> Und das wiederun relativiert sich in dem Moment, wo Du ein neues Programm
>> installierst, das eine dieser "15 Libraries" auch benutzen möchte - und
>> dann nicht kann und dzf. diese nach- und damit doppelt installieren muß.
>> Anscheinend ist das eine politische Konstruktion: Zu kurz gedacht als
>> Qualitätsmerkmal.
>
> Flatpak/Snap existiert, um Lieferanten kommerzieller Software das
> Testen einfach zu machen, indem die Kontaktfläche zum darunter
> liegenden Betriebssystem minimiert wird. Der Anwender bezahlt das mit
> höherem Speicherbedarf, und zwar sowohl auf dem Massen- als auch im
> Arbeitsspeicher.

Wobei der höhere Speicherbedarf sowohl auf dem Massen- als auch im
Arbeitsspeicher relativ gering ist, zumal bei den heutzutage üblichen
Rechenleistungen und wenn man bedenkt, mit was für einem sonstigen Mist
sich die Leute heutzutage gedankenlos ihre Festplatte und ihren
Arbeitsspeicher zuknallen.

Wenn ich mit dieser üblichen Gedankenlosigkeit Snap und Flatpak
"systemwidrig" aus reiner Bequemlichkeit benutze, ist das aus rein
dogmatischen (von mir aus auch politischen und ideologischen,
stammtischtauglichen Gesichtspunkten) verwerflich. Und mein Gott,
wenn einige kommerzielle Software-Hersteller das Format zu
Werbezwecken nutzen, freuen sich auch jene Menschen, die sich sonst
immer gerne über das langweilige und ach so veraltete Debian erregen.

--
Gunter
https://guntergutzeit.de.cool

[Ralph Stahl]

Am 09.05.20 um 20:29 schrieb Christian Garbs:

> Mahlzeit!
>
> Ralph Stahl <po...@rstahl.de> wrote:
>> Am 09.05.20 um 09:23 schrieb Christian Garbs:
>
>>> - Die Snaps landen wohl allesamt in /home/$USER/snap. Das ist nicht
>>> mal ein unsichtbarer Ordner und damit ziemlich übergriffig.
>
>> Bei mir /snap/ UND ~/snap/ mit gleichem Inhalt. Also echt doppelt
>> gemoppelt, wobei z.B. "which gimp" auf ersteres zeigt. Warum?
>> Xubuntu 20.04.
>
> Kann es sein, dass das nur doppelt gemounted ist und tatsächlich nur
> einmal auf Platte? Schau mal, was `mount` dazu sagt.
> (Ich hab hier kein Snap zum Gucken.)
>
> Gruß
> Christian
>

rollo: ~] mount | grep snap
/var/lib/snapd/snaps/core18_1705.snap on /snap/core18/1705 type squashfs
(ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/gtk-common-themes_1506.snap on
/snap/gtk-common-themes/1506 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/snapd_7264.snap on /snap/snapd/7264 type squashfs
(ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/gimp_252.snap on /snap/gimp/252 type squashfs
(ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/core18_1754.snap on /snap/core18/1754 type squashfs
(ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/gnome-3-28-1804_116.snap on
/snap/gnome-3-28-1804/116 type squashfs (ro,nodev,relatime,x-gdu.hide)

Es ist nur 1x gemounted, aber tatsächlich 2x physisch vorhanden. ???

Ralph

[Ralph Stahl]

Am 09.05.20 um 13:33 schrieb Ralph Stahl:

Gleicher Inhalt ist falsch, das täuscht. Hier ist das schön erklärt
https://www.freecodecamp.org/news/managing-ubuntu-snaps/ (eng.)


>
> [...]
>
> Ralph
>

[Christian Garbs]

Mahlzeit!

Ralph Stahl <po...@rstahl.de> wrote:

> Am 09.05.20 um 13:33 schrieb Ralph Stahl:

>> Bei mir /snap/ UND ~/snap/ mit gleichem Inhalt. Also echt doppelt
>> gemoppelt, wobei z.B. "which gimp" auf ersteres zeigt. Warum?
>> Xubuntu 20.04.
>
> Gleicher Inhalt ist falsch, das täuscht. Hier ist das schön erklärt
> https://www.freecodecamp.org/news/managing-ubuntu-snaps/ (eng.)

Danke für den Link - sehr erhellend, ich habe Snap bisher nur für
Desktop-Tools wie Skype und Gimp wahrgenommen. Wenn auch NextCloud
als Snap daherkommt, lag ich mit meinem "so ähnlich wie Docker" ja gar
nicht weit daneben.

Ich weiß noch nicht, ob ich das ob dieser Erkenntnis jetzt gut finden
oder schreiend wegrennen soll ;-)

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

I've finished Legend of Zelda - Ocarina of Time
and didn't even get a kiss from the Princess.