+++ Braunschweig, Niedersachsen, 2024-08-01 +++

Gemäß den Anpassungen von 1972 ist eine GMT-Standardisierung obsolet und überholt.
Die Koordinierte Weltzeit UTC (Coordinated Universal Time) gilt seit Jahrzehnten.

Obgleich heutige KI-Suchmaschinen lügen und behaupten es gäbe keinen Unterschied zwischen der GMT und UTC sind dies Falschheiten die von Idioten kolportiert werden:

GMT ist astronomisch.
UTC ist durch Atomuhren definiert (ca. 400 Atomuhren weltweit).

GMT und UTC haben eine Abweichung von bis zu 0,9 s bevor eine Anpassung erzwungen wird. Die Differenz zwischen UTC und UT1 wird aber durch Schaltsekunden auf eben diese Differenz von min. unter 0,9 Sekunden begrenzt.
GMT wurde außerdem in UT1 (Mittlere Sonnenzeit am Nullten Längengrad) bzw. UT umbenannt.

Eine Verwendung der UTC(PTB) des dortigen Stratum-Servierers über NTP ist die einzig technisch korrekte Antwort. Während der letzten beiden Jahre lag die Abweichung UTC - UTC(PTB) stets unter 10 ns (1 ns =1/1 000 000 000 s). Die Differenz UTC-UTC(PTB) hatte beispielsweise am 2. Januar 2013 den Wert 0,8 ns.

1975 empfahl die 15. Generalkonferenz für Maß und Gewicht UTC als Grundlage der bürgerlichen Zeit, und entsprechend erfolgen die Aussendungen von Zeitzeichen koordiniert in UTC.

Von daher bitte ich die Herren Zuse, et al., wie auch assoziierte Mitglieder des Diätkanal-Websystems die Anglo definierte Lügenzeit GMT abzuschaffen. Es ist nicht weiter tragbar, das dieser Missbrauch der britischen Krone weiterhin dieses Bilderbrett schädigt.

https://www.ptb.de/cms/ptb/fachabteilungen/abt4/fb-44/ag-441/darstellung-der-gesetzlichen-zeit/koordinierte-weltzeitskala-utc.html

>>129477
Eher sich selbst belügen lassen aus verschiedenen Gründen wie Bequemlichkeit.

>>129474
>Der Verbraucher hat lieber
>Diese gut. Nehmen Sie!
>Auch wenn gelogen.
Es geht um Schuldabwälzung?

Eingenkontra, weil rettet dem Dativ.

>>129446
Es liegt nicht am mangelnden Angebot sondern am Verbraucher, dass Krebsweichware dominant ist.

Das Primärproblem bei offen gehalten Projekten scheint zu sein, dass man sich da nicht einig. Das verwirrt den Verbraucher. Der Verbraucher hat lieber

> Diese gut. Nehmen Sie!
Auch wenn gelogen.

Das erspart dem Verbraucher die Eigenverantwortung der Entscheidung. Er kann es so auf andere schieben, falls diese doch nicht gut, und hat somit sein Selbstwertgefühl geschützt.

>>129308
Il chanal da dieta è e resta tudestg! Ed el è perfetg uschia sco quai ch'el è! Sche insumma, lura mancass qua sin il pli anc /reto/ per in barat rumantsch! Ed ussa ta morda inavo a la fora, or da la quala ti es rut!

https://imagemagick.org/script/security-policy.php
Wenn es damit geht die Datei gar nicht erst zu laden ist vielleicht ein Schutz vor so einem DoS über file properties möglich.
Ich gönne mir jetzt erstmal Miqo'te am Nachmittag.

>Leider legt systemd keinen Coredump an, weil der systemd-coredump-Prozess vom OOM-Killer auch abgeschossen wird :/
Dann eben doch Lokal in einer VM testen :(
Da kann man RAM ja recht gut limitieren und den Wert des Servierers replizieren. Sollte halt nicht passieren, dass es so große PNG gibt an denen sich ein file property Ausleser verschluckt.

Vielleicht gibt es einen Speicher-sicheren Fallzurück für Eigenschafts-Ausleser. Guhgel findet u.A.
https://www.imagemagick.org/discourse-server/viewtopic.php?t=31438

>weil der systemd-coredump-Prozess vom OOM-Killer auch abgeschossen wird
Äh, wobei, vielleicht auch nicht. Aber auf jeden Fall wird kein Coredump gespeichert aus irgendeinem Grund.

>>129467
Ok, also es ist definitiv ImageMagick, das vom OOM-Killer gekillt wird. Dietchan scheint danach irgendwie zu crashen, aber nur bei dir und nicht bei mir. Leider legt systemd keinen Coredump an, weil der systemd-coredump-Prozess vom OOM-Killer auch abgeschossen wird :/

Nach 5x Versuchen/Crème-Küchlein ist der RAM zugekleistert, wenn man die Hochlad-Warnung ignoriert und es einfach probiert. Scheint wohl trotz Crash was im Speicher rumzulungern. Wenn das Speicherloch zu einer Pâtisserie verkommen ist passt nichts meer rein und OOM lässt erstmal die Vannillesoße ablaufen.

>>129458
Probier es gerne nochmal. Konnte es bisher leider noch nicht exakt reproduzieren. Nur der ImageMagick-Prozess stürzt ab, was zwar ärgerlich ist, aber da kann man nichts machen, Softwareproblem.

>>129455
>Was aber auffiel, war, dass während des Hochladens der magick identify-Subprozess sehr viel Speicher verbrauchte und eine sehr hohe CPU-Auslastung generierte.
Das ist in der Tat ungewöhnlich, der Prozess sammelt ja nur Eigenschaften der Datei.
Ich habe aus Neugierde nachgelesen:
<Filename[frame #] image-format widthxheight page-widthxpage-height+x-offset+y-offset colorspace user-time elapsed-time
>Folglich crashte der Prozess dann auch (noch nicht sicher ob "echter" Crash oder OOM-Kill).
Würde man auf einer heimischen VM als Testserver in den logs soetwas sehen bevor der Crash auftritt? Weiss nicht welcher Prozess was schreibt. Gerade systemd loggt ja ziemlich viel nutzlosen Kram.
>Hilft auf jeden Fall!
Gerne geholfen, wäre arschig wenn mir was auffällt und ich es nicht melde.
>Kein Ding.
Okay solange es nicht wieder passiert, wenn dann war es ein anderer Nutzer ;)
Ich probiere daran jetzt nicht mehr rum.

>>129452
>Sorry für den erneuten Test, aber in der Tat, eine 8599x6709 pixel PNG + (diese) PDF == Speicher am lecken.
Ein Speicherleck in dietchan scheint es nicht direkt zu sein. Habe das gerade auch mal getestet und der Hochlad schlug zwar fehl, aber dietchan ist nicht abgestürzt. Am Speicherverbrauch hat sich auch nichts geändert. Was aber auffiel, war, dass während des Hochladens der magick identify-Subprozess sehr viel Speicher verbrauchte und eine sehr hohe CPU-Auslastung generierte. Folglich crashte der Prozess dann auch (noch nicht sicher ob "echter" Crash oder OOM-Kill). Scheint also ein Problem in ImageMagick zu sein. Was mir noch nicht klar ist, ist, warum das anscheinend manchmal dazu führt, dass der Elternprozess vom OOM-Killer (mit-)abgeschossen wird. Das könnte ein separater Bug in dietchan sein oder irgendeine merkwürdige Heuristik des OOM-Killers.

>Ich hoffe der Fehler lässt sich jetzt im Code fixen mit der Info
Hilft auf jeden Fall!

>Tut mir leid für die zweite Downtime!
Kein Ding.

Sorry für den erneuten Test, aber in der Tat, eine 8599x6709 pixel PNG + (diese) PDF == Speicher am lecken. Ich hoffe der Fehler lässt sich jetzt im Code fixen mit der Info. Tut mir leid für die zweite Downtime!

>>129351
>stößt Felix mal den Faden bevor er ihn durchstöbert
Und was hast du so gelernt?

>>129414
https://www.der-postillon.com/2017/06/russische-hacker.html
Dann war das war bestimmt der Kreml!

>>129411
War das erste mal, dass dieses Problem aufgetreten ist. Ein Speicherleck wurde bisher nicht beobachtet.

>>129407
Hmm, vielleicht mal mit RRD-tool loggen wie Systemmetriken über die Zeit verlaufen. Vielleicht war das Speicherleck schon Stunden vorher da?

>>129403
>>129402
>Hat der upload was gekrasht oder war das nicht relatiert?
Keine Ahnung, der Prozess wurde vom OOM-Killer gekillt. War auch nicht mehr viel freier RAM verfügbar, nicht sicher wieso. Die Datei selbst scheint es nicht ausgelöst zu haben >>129405