Das längste Thema

  • ich hab leider angst…

    da brauchst keine Angst haben, des is die neue Normalität ^^


    die hiesige Tageszeitung schreibt auch darüber; auf die Idee musst ja mal kommen ;)


    wobei was zeigt uns das: dass da noch einige solche banalen Bugs in den weiten der Quellcodes

    (der vom Linux kernel eingeschlossen) schlummern;

    gerade solche Paradigmenwechsel wie sie bei der x86-Architektur durch die AMD64/EM64T-Erweiterung passierten,

    sind ein Nährboden f. derartigen Quark;


    Windows-User mögen mal in der Eingabeaufforderung folgendes eingeben

    netstat -e

    dass man da seit WinNT nicht draufgekommen ist, dass man des in 64-bit Integer packen hätte können;

    wir haben jetzt 64-bit - zumindest behauptet es die Anzeige in div. Dialogen - und es ist immer noch 32-bit ;)

    (oder aber es ist 64-bit, und der "Vorsicht" halber wurde der höhere 32-bit Teil ignoriert)


    f. diejenigen die ganz tief einsteigen, egal ob jetzt die Syntax unter Linux, Windows, Mac

    diese x86_64-Architektur hat eine wahre Brutquelle an Bugs


    mal etwas Geschichte:

    mit dem 8086 fing alles an, da waren die Register 16-bit breit

    beim allgemeinen 16-bit Register AX konnte man mit AH und AL

    jeweils die höherwertigen bzw. niederwertigen 8-bit getrennt ansprechen;

    ein setzen auf 0 ging z.B. so

    SUB AX,AX

    mit dem 80286 wurde der Protected-mode eingeführt;

    (man konnte damit jetzt segmentiert¹ 16 MByte RAM bzw. 1 GByte virt. Speicher adressieren: ¹ 64 kByte Segmente)


    beim 80386 passierte jetzt etwas grandioses; die Register waren jetzt 32-bit,

    und damit wurden die erweiterten Register mit E... angesprochen;

    das allgemeine 32-bit Register war EAX; das mit AH und AL blieb unverändert;

    für die höherwertigen 16-bit gab es kein Synonym, es konnte nicht direkt angesprochen werden;

    aber ein SUB AX,AX veränderte diesen Teil auch nicht; wollte man hingegen die kompletten 32-bit auf 0 setzen

    brauchte es z.B. das SUB EAX,EAX

    die 32-bit Register konnten auch im sogenannten Real-mode verwendet werden; da sprangen

    auch lange bevor die echten 32-bit Betriebssysteme Einzug hielten einige auf;

    und man verwendete diese 32-bit Register und reduzierte die Laufzeit beim Handling von 32-bit Werten um einiges;

    mit den ersten echten 32-bit Systemen - z.B. WinNT - passierte wieder etwas grandioses

    man erkannte, dass man die Logik für die 32-bit Ganzzahlen jetzt direkt auch auf 64-bit Ganzzahlen mit Hilfe der 32-bit Register an Stelle der 16-bit Register anwenden konnte; und das war bereits 1994(!); die Verwendung von __int64 war ganz normal, und das obwohl die Architektur nur 32-bit war;


    mit dem 80486 wurde die Floating-point-Unit, welche früher nur mit einer weiteren 'Einheit' nachgerüstet werden konnte, in die CPU selbst integriert;

    dies brachte für floating-point lastige Anwendungen ebenfalls einen Geschwindigkeitsvorteil;

    der Pentium brachte erstmals die Geschichte von 2 Pipes und beschleunigte hier nochmals kräftig;

    beim PentiumPro wurde das PAE eingeführt, damit konnte man mehr als die 4 GByte RAM ansprechen, von 64-bit aber noch keine Spur;

    wobei diese PAE-Erweiterung war ihrer Zeit voraus;


    nun kam AMD mit seinem AMD64²; und da wurde kräftig gepfuscht;

    die Register waren jetzt nur bedingt 64-bit; denn in bis dato noch geängigen 32-bit Systemen konnten diese nicht verwendet werden;

    die Verwendung war einem 64-bit Modus der CPU vorbehalten;

    und hatte man diese Register dann doch zur Verfügung, war hier der nächste Murx;

    wer meinte mit z.B. SUB EAX,EAX wie bisher die 32-bit Register auf 0 zu setzen, der hat sich mal gröber geschnitten;

    damit werden auch die höheren 32-bit Teile mit auf 0 gesetzt; und weil es so toll ist, passiert dies ebenso mit z.B. SUB EAX,EBX

    (der höherwertige Teil des RAX-Registers ist hier 0, auch wenn dieser vorher nicht 0 war)

    das jemanden zu erklären bedarf schon etwas; und dann verwundert es auch nicht,

    wenn dann ein 64-bit Register z.B. nur so SUB EAX,EAX auf 0 gesetzt wird;


    dass es bis heute - im Jahr 15 nach Einführung des AMD64 - immer noch keinen general purpose int mit 128-bit gibt,

    hat auch seine Gründe;


    ²dass EM64T so wie es Intel f. seine ersten Xeons nannte, die diese Architektur 'kopierten' der selbe Murx war,

    braucht dann auch nicht zu verwundern;


    die größte Schlappe bei der AMD64/EM64T Sache war ja ganz was anderes; beim Otto-Normal-Anwender, ging das auch spurlos vorüber;

    aber der 64-bit Modus kennt keine Segemntierung mehr; wieso soll man diese denn noch zur Verfügung stellen, wenn sie ohnehin keiner nutzt;

    seit 32-bit heißt das Modewort: Flat-Adressierung;

    wo doch die Segmentierung genau die Waffe gegen Malware schlecht hin gewesen wäre;

    hätte aber Disziplin und Ordnung erfordert, welche nicht gegeben ist;

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • Ja, das erinnert mich an etwas, dass ich Ende 1999 für meinen Rechner schreiben musste. ^^

    Ausschnitt:

  • Sind RHEL8 / AlmaLinux8 / RockyLinux8 User hier? Nutzt jemand die PHP Module aus dem AppStream Repo? Ich wollte gerade bei einem System ein Upgrade von PHP 7.2 -> PHP 7.4 machen. Im Grunde nicht weiter schwierig (dnf module enable php:7.4). Hat soweit auch alles funktioniert. Aber als ich mal genauer hingesehen habe, musste ich feststellen, dass die Version doch etwas sehr alt ist:

    Code
    PHP 7.4.19 (cli) (built: May  4 2021 11:06:37) ( NTS )
    Copyright (c) The PHP Group
    Zend Engine v3.4.0, Copyright (c) Zend Technologies
    Code
    Name         : php
    Version      : 7.4.19
    Release      : 1.module+el8.5.0+696+61e7c9ba
    Architecture : x86_64
    Size         : 1.5 M
    Quelle       : php-7.4.19-1.module+el8.5.0+696+61e7c9ba.src.rpm
    Repository   : appstream
    [...]

    Das hätte ich jetzt so aus einem RedHat Repo nicht erwartet. So ein bisschen habe ich das Gefühl, dass das mit den Modulen zwar gut gemeint war, aber die praktische Umsetzung doch sehr zu wünschen übrig lässt. Wie seht ihr das? :)

  • unterliegt man hier dem "Fehler",

    dass zwar die Version als "alt" aufscheint,

    dennoch die letzten Patches dabei sind?

    war bei CentOS usus

    (da war bei CentOS 6 jahrelang die Version von OpenSSL 1.0.1e vom Jahr 2013, obwohl die im Jahr 2018 kräftig gepatcht wurde);

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • unterliegt man hier dem "Fehler",

    dass zwar die Version als "alt" aufscheint,

    dennoch die letzten Patches dabei sind?

    Ja, hatte ich zunächst auch gedacht. Aber das "built" Datum ist hier doch recht eindeutig. Da wurde nichts zurückportiert :)

    Code
    PHP 7.4.19 (cli) (built: May  4 2021 11:06:37) ( NTS )
  • Werde ich nie verstehen. 77 TB an Forschungsdaten. Die hätten den Fileserver ja nur 1:1 spiegeln müssen und hätten zumindest schon mal wenigstens ein Backup gehabt. Am besten in einem anderen Gebäude. Dann noch einmal verschlüsselt in die Cloud und gut ist.


    Bei uns in der Firma ist das leider auch immer wieder eine Diskussion, weshalb wir mit Acronis nur einmal in die Cloud sichern. Aber ja, nicht mein Problem. Ich warne immer. Wenn das Geld dafür nicht locker gemacht wird, ist das nicht mein Bier.^^

  • Werde ich nie verstehen. 77 TB an Forschungsdaten. Die hätten den Fileserver ja nur 1:1 spiegeln müssen und hätten zumindest schon mal wenigstens ein Backup gehabt. Am besten in einem anderen Gebäude. Dann noch einmal verschlüsselt in die Cloud und gut ist.


    Bei uns in der Firma ist das leider auch immer wieder eine Diskussion, weshalb wir mit Acronis nur einmal in die Cloud sichern. Aber ja, nicht mein Problem. Ich warne immer. Wenn das Geld dafür nicht locker gemacht wird, ist das nicht mein Bier.^^

    spiegelung hilft da aber auch nur sehr begrenzt.
    zum einen muss es asynchron sein, zum anderen willst du genug zeit haben fehler zu erkennen und zu beheben, zum anderen willst du aber möglichst synchron sein.

    sinnvoller ist da ggf. zwei getrennte backups zu betreiben. das eine kommt zur geraden stundenzahl, das andere zu ungeraden stunden. nur wie weit will man das wieder treiben?

    und warum fehlen überhaupt daten, obwohl doch nur das backup gelöscht wurde?

    davon ab hat HPE in letzter zeit scheinbar einiges an softwareproblemen... iLO Rootkit, das thema hier, SSDs die nach x Betriebsstunden zu Briefbeschwerern werden und ihre Firmware läuft weder via virtual Media noch iSUT wirklich zuverlässig durch. wildes, wiederholtes klicken hilft dann aber meist.
    und oneview ist auch nochmal eine eigene baustelle

  • Neujährliches Reinemachen: Gerade gesehen, dass die längste Statistik nicht mehr geht. Seit Oktober.


    • Base Image Rebuild vergessen, weswegen der Parser mit abgelaufenen Lets Encrypt CA Cert hängen geblieben ist
    • Migration auf .NET 6 LTS + Debian Bullseye
    • Jemand hat einen Post löschen lassen, was der Parser noch nicht unterstützt hat


    https://github.com/perryflynn/…dc70e15a0402d7ffdf0..HEAD


    Finde es faszinierend, dass ich von .NET Core 2.2 auf .NET 6 rauf bin und meine vor Ewigkeiten gebauten Packages noch alle kompatibel sind. I like. Fast so stabil wie PHP.

  • Ja, hatte ich zunächst auch gedacht. Aber das "built" Datum ist hier doch recht eindeutig. Da wurde nichts zurückportiert :)

    eindeutig mehrdeutig würd ich sagen, ich würde da meine Hand nicht ins Feuer legen ;)

    lt. php.net ist 7.4.27 aktuell, ich würd mir dennoch keine zu großen Gedanken machen;

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • Eine Info, die vielleicht für alle interssant ist, die öfter mal an den Zeiten (TTL, Retry, Refresh) in der DNS rumschrauben:

    Ich habe am 21.12. bei der 14ct Aktion eine domain von dort hierher transferiert.

    Schien auch alles gut zu laufen, aber seit vorgestern wird die domain nicht mehr aufgelöst. Kein Nameserver kennt sie mehr und wenn ich bei denic nachsehe sind plötzlich wieder (oder sogar immer noch?) die NS von "Sto" eingetragen, obwohl die domain hier liegt. Momentan geht also GARNIX.

    Die Ursache war laut Support:

    Predelegation Check warning [WARNING: 110 Retry value out of range (expected\, found) (\[900..2400\]\, 3600)]


    Der Default-Retry für neue netcup domains liegt allerdings sogar bei 7200, ist also noch höher als der angegebene Maximalwert von 2400 :/

    Hab mal kurz recherchiert und festgestellt: Der Retry-Wert ist an den Refresh-Wert gekoppelt. :huh:

    Ich hatte die TTL runtergesetzt, Retry halbiert auf 3600 und Refresh von 28800 runtergesetzt auf 7200 (Fragt mich bitte nicht wieso ;))

    Das war wohl ein Fehler (Den ich auch bei anderen domains gemacht habe und nun beheben werde)

    Denic: "Retry" soll zwischen 1/8 und 1/3 von "Refresh" betragen.


    Der Support hat selbst den Retry auf 2400 gesetzt und innerhalb von Minuten waren die netcup-Nameserver und die DNS durchpropagiert und die domain wieder erreichbar. :) (Ob es nun wirklich daran lag, oder das nur eine Begleiterscheinung war, kann ich natürlich nicht sagen)

  • Hmmm.. Ich bin verwirrt.

    Habe gerade woanders auf einem neuen Server ein Ubuntu 20.04 Image installiert und dann über die dortige Nutzeroberfläche (analog zum SCP hier) eine ipv6 angelegt.

    Und die funktioniert sofort, ohne dass ich etwas auf dem Server konfiguriert hätte. Im netplan-Verzeichnis ist nix zu finden. Im gesamten /etc-Ast ist das verwendete ipv6-Subnetz über grep nicht zu finden.

    Wie machen die das? :/