Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.os.unix.linux.misc > #110149 > unrolled thread

Xubuntu 20.04 / GIMP: GEGL 0.4.22?

Back to article view | Back to de.comp.os.unix.linux.misc

Contents

  Xubuntu 20.04 / GIMP: GEGL 0.4.22? Ralph Stahl <post@rstahl.de> - 2020-04-29 00:10 +0200
    Re: Xubuntu 20.04 / GIMP: GEGL 0.4.22? Kay Martinen <kay@martinen.de> - 2020-04-29 00:48 +0200
      Re: Xubuntu 20.04 / GIMP: GEGL 0.4.22? Marcel Mueller <news.5.maazl@spamgourmet.org> - 2020-04-29 07:21 +0200
        Re: Xubuntu 20.04 / GIMP: GEGL 0.4.22? Thomas Wiegner <wiegner@gmx.de> - 2020-04-29 09:50 +0200
      Re: Xubuntu 20.04 / GIMP: GEGL 0.4.22? Ralph Stahl <post@rstahl.de> - 2020-04-29 12:44 +0200
      Re: Xubuntu 20.04 / GIMP: GEGL 0.4.22? Ralph Stahl <post@rstahl.de> - 2020-04-29 12:58 +0200
        Re: Xubuntu 20.04 / GIMP: GEGL 0.4.22? Christian Schumacher <cs.spam@nurfuerspam.de> - 2020-04-29 14:15 +0000
          Re: Xubuntu 20.04 / GIMP: GEGL 0.4.22? Christian Garbs <mitch@cgarbs.de> - 2020-04-29 17:44 +0200
            Re: Xubuntu 20.04 / GIMP: GEGL 0.4.22? Ralph Stahl <post@rstahl.de> - 2020-04-30 13:30 +0200
              Re: Xubuntu 20.04 / GIMP: GEGL 0.4.22? Christian Garbs <mitch@cgarbs.de> - 2020-05-01 19:58 +0200
                Re: Xubuntu 20.04 / GIMP: GEGL 0.4.22? Kay Martinen <kay@martinen.de> - 2020-05-03 01:54 +0200
                  Re: Xubuntu 20.04 / GIMP: GEGL 0.4.22? Christian Garbs <mitch@cgarbs.de> - 2020-05-05 17:44 +0200
                    Re: Xubuntu 20.04 / GIMP: GEGL 0.4.22? Kay Martinen <kay@martinen.de> - 2020-05-07 01:37 +0200
                      Re: Xubuntu 20.04 / GIMP: GEGL 0.4.22? Gunter Gutzeit <gunter.gutzeit@arcor.de> - 2020-05-07 09:24 +0200
                        Re: Xubuntu 20.04 / GIMP: GEGL 0.4.22? Claus Reibenstein <4spamersonly@kabelmail.de> - 2020-05-07 09:59 +0200
                          Re: Xubuntu 20.04 / GIMP: GEGL 0.4.22? Gunter Gutzeit <gunter.gutzeit@arcor.de> - 2020-05-07 15:16 +0200
                          Re: Xubuntu 20.04 / GIMP: GEGL 0.4.22? Marc Haber <mh+usenetspam1118@zugschl.us> - 2020-05-08 08:17 +0200
                        Re: Xubuntu 20.04 / GIMP: GEGL 0.4.22? Christian Garbs <mitch@cgarbs.de> - 2020-05-08 09:12 +0200
                          Re: Xubuntu 20.04 / GIMP: GEGL 0.4.22? Gunter Gutzeit <gunter.gutzeit@arcor.de> - 2020-05-08 15:02 +0200
                          Re: Xubuntu 20.04 / GIMP: GEGL 0.4.22? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2020-05-08 20:13 +0200
                            Re: Xubuntu 20.04 / GIMP: GEGL 0.4.22? Marc Haber <mh+usenetspam1118@zugschl.us> - 2020-05-09 09:15 +0200
                              Re: Xubuntu 20.04 / GIMP: GEGL 0.4.22? Gunter Gutzeit <gunter.gutzeit@arcor.de> - 2020-05-10 06:54 +0200
                        Snap/Ubuntu (was: Re: Xubuntu 20.04 / GIMP: GEGL 0.4.22?) Christian Garbs <mitch@cgarbs.de> - 2020-05-09 09:23 +0200
                          Re: Snap/Ubuntu (was: Re: Xubuntu 20.04 / GIMP: GEGL 0.4.22?) Ralph Stahl <post@rstahl.de> - 2020-05-09 13:33 +0200
                            Re: Snap/Ubuntu Christian Garbs <mitch@cgarbs.de> - 2020-05-09 20:29 +0200
                              Re: Snap/Ubuntu Ralph Stahl <post@rstahl.de> - 2020-05-10 15:03 +0200
                            Re: Snap/Ubuntu (was: Re: Xubuntu 20.04 / GIMP: GEGL 0.4.22?) Ralph Stahl <post@rstahl.de> - 2020-05-10 16:01 +0200
                              Re: Snap/Ubuntu Christian Garbs <mitch@cgarbs.de> - 2020-05-10 21:05 +0200
                          Re: Snap/Ubuntu (was: Re: Xubuntu 20.04 / GIMP: GEGL 0.4.22?) Gunter Gutzeit <gunter.gutzeit@arcor.de> - 2020-05-09 14:14 +0200
                            Re: Snap/Ubuntu Christian Garbs <mitch@cgarbs.de> - 2020-05-09 20:28 +0200
    Re: Xubuntu 20.04 / GIMP: GEGL 0.4.22? Tim Ritberg <tim@server.invalid> - 2020-04-29 12:42 +0200

Page 1 of 2  [1] 2  Next page →

#110149 — Xubuntu 20.04 / GIMP: GEGL 0.4.22?

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.

[toc] | [next] | [standalone]

#110155

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

[toc] | [prev] | [next] | [standalone]

#110157

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

[toc] | [prev] | [next] | [standalone]

#110162

On Wed, 29 Apr 2020, Marcel Mueller <news.5.maazl@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

[toc] | [prev] | [next] | [standalone]

#110171

Am 29.04.20 um 00:48 schrieb 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
> 

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

[toc] | [prev] | [next] | [standalone]

#110172

Am 29.04.20 um 00:48 schrieb 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
> 

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

[toc] | [prev] | [next] | [standalone]

#110176

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

[toc] | [prev] | [next] | [standalone]

#110180

Mahlzeit!

Christian Schumacher <cs.spam@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
-- 
....Christian.Garbs....................................https://www.cgarbs.de
Paranoid schizophrenics outnumber their enemies at least two to one.

[toc] | [prev] | [next] | [standalone]

#110196

Am 29.04.20 um 17:44 schrieb Christian Garbs:
> Mahlzeit!
> 
> Christian Schumacher <cs.spam@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

[toc] | [prev] | [next] | [standalone]

#110204

Mahlzeit!

Ralph Stahl <post@rstahl.de> wrote:
> Am 29.04.20 um 17:44 schrieb Christian Garbs:
>> Christian Schumacher <cs.spam@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.

[toc] | [prev] | [next] | [standalone]

#110225

Am 01.05.20 um 19:58 schrieb Christian Garbs:
> 
> Ralph Stahl <post@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.

Kay

-- 
Posted via SN

[toc] | [prev] | [next] | [standalone]

#110257

Mahlzeit!

Kay Martinen <kay@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)

[toc] | [prev] | [next] | [standalone]

#110277

Am 05.05.20 um 17:44 schrieb Christian Garbs:
> 
> Kay Martinen <kay@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. :-)

Kay

-- 
Posted via SN

[toc] | [prev] | [next] | [standalone]

#110281

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

[toc] | [prev] | [next] | [standalone]

#110282

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

[toc] | [prev] | [next] | [standalone]

#110287

Claus Reibenstein schrieb am Do 07.05.2020 09:59:40 +0200:

> 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?

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

[toc] | [prev] | [next] | [standalone]

#110300

Claus Reibenstein <4spamersonly@kabelmail.de> wrote:
>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?

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

[toc] | [prev] | [next] | [standalone]

#110302

Mahlzeit!

Gunter Gutzeit <gunter.gutzeit@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.

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

[toc] | [prev] | [next] | [standalone]

#110316

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

> Mahlzeit!
> 
> Gunter Gutzeit <gunter.gutzeit@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

[toc] | [prev] | [next] | [standalone]

#110320

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
-----------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | de.comp.os.unix.linux.misc

csiph-web