Beiträge von Welm

    Tut es... und ich hab wieder was gelernt (weil ich diese Umleitung via status 2 nicht kannte

    Nur damit Du Dir nicht was Falsches merkst: "status 2" gibt es nicht. Die "2" gehört zum ">". ">" lenkt stdout in eine Datei. "2>" lenkt stderr in eine Datei. man kann z.B. auch Sachen schreiben wie

    Code
    befehl > ausgabe.txt 2> fehler.txt

    und hat dann stdout in der einen und stderr in der anderen Datei

    Da Umleitung ( akonadictl status > status.txt ) zum gleichen Ergebnis führt (leere Datei, Ausgabe in Bash), ist meine Vermutung, dass akonadictl irgendwie stout umgeht...

    Vielleicht schreibt er auf stderr statt stdout. Ich hab kein akonadictl und kann nur spekulieren.


    Falls es so ist würde

    Code
    akonadictl status 2> status.txt

    in die Datei schreiben.


    Falls es so ist könnte man in der grep-Zeile stderr auf stdout umlenken:

    Code
    (akonadictl status 2>&1)| grep -i running

    Ich hab ein Verzeichnis mit rund 12000 Bildern und beim Anzeigen der Thumbnails mit gwenview hängt der Rechner fast. Es hat sich aber herausgestellt, dass es nicht die Zahl der Bilder ist ... es sind bestimmte Bilder, die pro Stück zu einem enormen RAM-Verbrauch führen. Irgendwann ist dann auch der Swap voll. Diese Bilder sind schon jahrelang da und vor einigen Wochen gab es das Problem noch nicht.


    Von einem dieser jpg-Bilder mit 7.1 Megapixel / 2.6MB habe ich 22 Exemplare in einem Verzeichnis angelegt und der gwenview bringt dabei einen 16GB-RAM-Rechner von 1.2GiB auf 12.4GiB. Das sind pro Pixel immerhin 77 Byte. Da fallen vergessene Speicherfreigaben im Gwenview als Erklärung eigentlich schon aus, denn was will man mit so vielen Byte pro Pixel? Vielleicht irgendein Kommunikationsproblem von KDE-Komponenten?


    Fast dasselbe Bild nur mit einer etwas anderen Zoom-Einstellung 5 Sekunden vorher aufgenommen ist übrigens völlig unproblematisch.


    digiKam und nomacs haben keine Probleme mit der Thumbnailanzeige.


    Es handelt sich um einen Leap 15.2 Rechner mit gwenview5 20.04.2 lp152.1.1, aber auf einem 15.3er tritt dasselbe Problem auf.


    Hat jemand eine Idee?

    Beim Anschluss sowohl eines A40 als auch eines A41 passiert bei mir ähnliches wie im Beitrag #1 ... aber das Problem ist bei mir umgehbar:

    1.: "Dateien mit Dateiverwaltung durchsuchen" anwählen

    2.: es erscheint ein unbrauchbarer Dophin.

    3.: Telefonbildschirm entsperren

    4.: Erst dann erscheint dort die Frage "Zugriff auf Telefondaten erlauben?"

    5.: Erlauben

    6.: unbrauchbaren Dolphin schließen

    7.: "Dateien mit Dateiverwaltung durchsuchen" erneut anwählen.

    8.: brauchbarer Dolphin erscheint

    Mein bereits installiertes Stockfish 10 (stockfish aus Standard Repository) tue ich am besten erst wieder deinstallieren?

    Ist nicht nötig. Du kannst im Yast unter "Software-Repositories" das "Games" hinzugefügen. Danach im Yast unter "Software installieren oder löschen" "stockfish" suchen, das Paket "stockfish" anwählen, unten "Versionen" anklicken. Da stehen dann beide Versionen und wenn Du die andere wählst wird die eine automatisch abgewählt.

    Das geht mit Sicherheit auch mit zypper statt Yast. Aber da bin ich mir nicht so sicher, dass ich das fehlerfrei hinschreiben kann.


    Das mit den Packman-Sachen verstehe ich immer weniger. Bei https://stockfishchess.org wird als neueste Fassung die 14 genannt ... am 2.7.21 angekündigt.

    Puuuh, 2x Stockfish brauche ich nicht.

    Bekommst Du auch nicht. Ich meinte das Paket mit dem Namen "stockfish" ohne irgendeine Nummer dran. Wenn Du nach dem Hinzufügen von "Games" "stockfish" in der Paketliste auswählst, dann kannst Du unten bei "Versionen" die beiden Versionen dieses Pakets sehen: 10 und 14. Wenn da die 10 gewählt ist und Du die 14 anwählst, fliegt die 10 raus und die 14 kommt rein. Wenn irgendwann in "Games" eine höhere Version von "stockfish" auftaucht, bekommst Du die als Update.


    Dagegen sind bei Packman verschiedene Stockfish-Versionen auch verschiedene Pakete. Wenn Du da eine Version installierst, dann ist das zusätzlich zu schon vorhandenen Paketen. Da würde der von Dir befürchtete Effekt auftreten. Ich weiß nicht, warum die viel kleiner sind und hab sie auch noch nie ausprobiert.

    Wobei ich trotzdem nicht weiß warum bei mir Stockfish 10 angezeigt wird, anstatt 14.

    Im "normalen" Repo liegt der Stockfish 10. Im Repo "Games" gibt es den Stockfish 14. Die URL für den Yast ist

    Code
    http://download.opensuse.org/repositories/games/openSUSE_Leap_15.2/

    Wenn das Repo dann da ist kannst Du in bei "Software installieren..." im Yast nach "stockfish" suchen und hast dann unten bei "Versionen" die Wahl zwischen 10 und 14.


    Als Oberfläche dazu würde ich den "scid" nehmen (Shanes Chess Information Database).

    Das bringt mich auf die Idee, bei einem alten PC die Mainboard-Batterie vorsorglich zu wechseln. Aber kann man das mit Erhaltung der BIOS-Daten hinbekommen?


    Ohne Erhaltung der BIOS-Daten wäre ein vorsorglicher Wechsel ja sinnlos und es wäre eher ein Abphotographieren aller BIOS-Anzeigen angesagt.

    Vorsicht: Das Folgende ist nur eine zusammengegoogelte Arbeitshypothese ...:


    BIOSse dürfen eigentlich nur in den ersten 4k machen was sie wollen.


    Nicht selten benutzen sie mehr und daher nutzt der Kernel sicherheitshalber die ersten 64k nicht. Man kann aber dem System versichern, dass man ein richtig gutes BIOS hat ... dann setzt man "X86_RESERVE_LOW=4K".


    Bei Misstrauen gegenüber dem BIOS kann man CONFIG_X86_CHECK_BIOS_CORRUPTION=y setzen. Der Kernel versucht dann, bekannte Fälle zu erkennen und zu melden.


    Nun wurden BIOSse gefunden, die bei Suspend/Resume und dem An-/Ausstöpseln von Monitoren auch noch in höheren Bereichen den RAM benutzen und dabei Kerneldaten kaputt machen. Deshalb darf man X86_RESERVE_LOW auf bis zu 640K setzen. Das ist aber eher zum Ausprobieren da: "Wenn es hilft, dann ist das BIOS die Ursache der Probleme".


    640K einzustellen verursacht aber evtl. wieder Probleme im Bootprozess. Evtl. wird die Grenze auf 512K statt 640K runtergesetzt.

    Welm

    Dann beantworte mir bitte mal folgende Frage :

    Wie machst du Änderungen, die ein Update überleben, wenn diese Konfigurationsdateien in /usr/ doch Bestandteil des zu aktualisierenden Paketes sind (siehe Dateiliste)?

    Das machen wir beide doch völlig gleich. Ich hab den Eindruck, dass Du auf Stichworte reagierst und nicht auf das, was ich tatsächlich geschrieben habe.