Am 23.12.23 um 18:11 schrieb Joerg Walther:
> Marcel Mueller wrote:
>
>>> Ich habe hier jetzt ~20 GB in /snap liegen auf einer 500 GB SSD. So
>>> what? Alles läuft perfekt, auf einem knapp 6 Jahre alten Thinkpad...
>>
>> Und schön langsam.
>
> Nö, i7-8650U und 32 GB Ram, flottes Teil,
Ja genau, und den brauche ich, damit er sämtlichen Code in verschiedenen
Snap-Paketen zehnmal redundant ausführen kann.
Das letzte Notebook mit fälschlich geliefertem Core i7 und nVidia Grafik
habe ich zum Händler zurück geschickt, weil ich ganz gezielt was anderes
bestellt hatte. Eben genau, um mir nicht auf der Couch die Flossen zu
verbrennen oder im Sommer einfach nur zu schwitzen und nach (damals) 3½
Stunden mit leerem Akku dazusitzen (mehr war mit der Kiste beim besten
Willen nicht zu holen).
Das (korrekt ausgestattete) Gerät habe ich immer noch. Dank sparsamer,
aktueller Software kann ich mit einem kühlen Gerät, dessen Lüfter kaum
mal läuft, und gealtertem Akku immer noch 5 Stunden auf der Couch sitzen.
> konvertiert hier im
> Hintergrund Videos mit Handbrake oder vier Audidateien gleichzeitig mit
> SoundKonverter, ohne dass der Lüfter auf Max geht.
Alles prima, aber so Sachen mache ich auf dem Server im Keller.
>> Alleine der Browser-Start braucht mehr als doppelt so
>> lange.
>
> Kann ich nicht vergleichen, Vivaldi kommt per Repository und startet
> deutlich schneller als auf meinem gleich alten und kaum mehr benutzten
> Windows-Rechner, ich schätze mal 3 Sekunden mit 10 offenen und 15
> gepinnten Tabs.
>
> Firefox probiere ich jetzt mal, der kommt als Snap: 4 Sekunden und er
> war da,
In der Zeit schaffe ich es auf einem ~8 Jahre alten NB ohne Core i7 auch
- ohne Snap.
> auch mindestens 1, 2 Sekunden schneller als das Windows-Pendant.
> Und warum sollte Snap auch langsamer sein? Die ausführbare Datei und die
> Bibliotheken müssen so oder so geladen werden, da ist es doch völlig
> Wurst, wo die auf der Platte liegen.
Nein. Snap ist eine Chroot-Umgebung für jedes einzelne Programm. Im
Prinzip ein komplettes Image einer fertigen Installation, eher zu
vergleichen mit einem Docker-Container. Nur der Kernel ist noch gemeinsam.
Ohne solche Container würden sich verschiedene Programme Bibliotheken
teilen. Und es gibt jede Menge davon, die in ganz vielen Programmen
verwendet werden (z.B. JPEG, TLS, AAC...). Die müssen jetzt für jedes
Programm neu geladen werden und stehen auch langfristig parallel im
Speicher, üblicherweise in geringfügig unterschiedlichen Versionen. Das
reduziert auch die Cache-Effizienz der CPU erheblich, weil nun nicht
mehr derselbe Code ausgeführt wird, sondern nur der gleiche.
Ich habe mal bei einer Software In-Memory-Deduplication eingebaut. Wir
haben damals damit gerechnet, dass dass die Software etwas langsamer
macht (für die Doublettensuche) und den Speicherverbrauch deutlich
reduziert, weil in hunderttausenden von Datensätzen eigentlich immer
Redundanz steckt.
Nun, das ist nicht passiert. Die Software wurde schneller und hat viel
weniger Speicher verbraucht. Offenkundig hat die dadurch stark
gesteigerte Cache-Effizienz den Zusatzaufwand für die Deduplizierung
deutlich überwogen.
> Wenn du nur ne 40 GB SSD hast, ist es natürlich klar, dass Snap da nicht
> passt, aber die Dinger kosten doch nix mehr, die hätte ich schon längst
> auf was Größeres geklont.
Nur wegen Snap?
Ich habe praktisch keine Userdaten lokal. Was will ich da mit einer
großen SSD?
> (Gerade mal bei Amazon geschaut: 256 GB für 15
> bis 25 Euro, Markenware).
Natürlich kann ich mir jedes mal was Neues kaufen, wenn die Software mal
wieder einen Faktor 10 zusätzliche Ressourcenverschwendung für sich
entdeckt hat. Üblicherweise mache ich das aber nur, wenn etwas defekt
ist oder sich meine Anforderungen geändert haben.
Natürlich haben Container-Formate auch Vorteile. Da sie alles dabei
haben, sind Kompatibilitätsprobleme mit aktualisierten Bibliotheken
selten, da selbige nicht aktualisiert werden. Das passiert nur, wenn der
Hersteller einen neuen Container mit neuen Bibliotheksversionen baut.
Das ist aber auch gleichzeitig einer ihrer größten Nachteile. Wenn ohne
Container ein Sicherheitsloch in einer zentralen Bibliothek wie JPEG per
Update gefixt wird, gilt das automatisch für alle Programme auf dem
Rechner, auch jene, deren Hersteller sich nicht mehr um solche
Aktualisierungen kümmert. Bei einem Container arbeitet man einfach mit
der defekten Bibliothek weiter, bis alle Container, die sie nutzen, vom
jeweiligen Hersteller aktualisiert wurden. Wenn ein Paket nicht mehr aus
dem main Repository kommt, ist es damit Essig.
Nun kann man argumentieren, dass natürlich auch in der nicht mehr
gepflegten Software ein Sicherheitsloch klaffen kann, stimmt. Nur werden
Löcher in zentralen Bibliotheken um Größenordnungen öfter ausgenutzt,
schlicht weil das viel mehr Reichweite hat.
Im Prinzip ist das ein Downgrade des Sicherheitsniveaus auf das von
Windows. Das verfolgt mit WinSxS seit vielen Jahren einen ähnlichen
Ansatz, wenn auch nicht ganz so konsequent. Will ich das als Anwender?
Marcel