Login
Newsletter
Werbung

Thema: Debian-Server-Zertifikate gefährdet: Let's Encrypt schaltet TLS-SNI-01 ab

3 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von irgendwer am Di, 29. Januar 2019 um 09:30 #

Oh, 10 Jahre, glaub ich dir! Ehlich. Aus der Zeit stammen ungefähr deine Erkenntnisse, die du hier an den Tag legst (auf die du zuletzt aber nicht mehr ganz so sehr gepocht hast). Stolz darauf sein musst du aber nicht. Jahre lang nix dazulernen ist jetzt nicht all zu besonders. Es ist sogar ein eher häufig anzutreffendes Phänomen.

Nein ehrlich, guck dir den Thread doch nochmal an. Du hast von Vorn herein in eine Kerbe gehauen, dabei x-mal Beiträge nicht richtig gelesen (dennoch darauf hin wild mit Beschimpfungen um dich geworfen) und offensichtlich ein Problem mit neuen Features (ja nicht nur VM-Techniken, auch CPU-Features generell) bzw. dir fehlen (fehlten?) beim Hauptthema Virtualisierung eindeutig Kenntnisse, die so längst überholt sind (du hast ja noch zig Beiträge lang behauptet, Live-Migration würde dein Vorgehen erzwingen, was eindeutig nicht stimmt; redest ja noch immer von clusterweiter Baseline bzw. Flags pro Blech, als ob man das nicht von VM zu VM einzeln bestimmen könnte). Das ist so Stand der Technik bei bzw. vor der Einführung RHEL 6 gewesen und ja, es verwundert nicht, dass das grob 10 Jahre her ist.

Was willst du noch mehr an Belegen, dass du deine vehemente Verteidigungsstrategie überdenken solltest?

Tu dir selbst einen gefallen, LERNE daraus. Hier zuzugeben, dass du falsch lagst, ist natürlich schwer – für viele zu schwer. Von mir aus antworte gar nicht oder wieder in der Form wie zuletzt: "mimimi - immer 10-mal-mehr als du!!11einself". (Eine häufig anzutreffende Strategie wäre jetzt noch, Rechtschreibfehler zu finden und dich nur noch darauf zu beziehen; es lassen sich aber bestimmt auch noch andere Nebenschauplätze eröffnen).

Aber wenn du hier schon nicht von deinem hohen Ross runter kommen kannst, dann informier dich doch einfach mal selber, was möglich und sinnvoll ist. VM- _und_ CPU-Techniken. Da wird nicht aus Jux und Dollerei weiter dran entwickelt. Da mit Vehemenz neue Techniken erst Jahre später zu adaptieren bringts nun wirklich nicht.

[
| Versenden | Drucken ]
  • 0
    Von Verfluchtnochmal-05995bd7b am Di, 29. Januar 2019 um 15:19 #

    "redest ja noch immer von clusterweiter Baseline bzw. Flags pro Blech, als ob man das nicht von VM zu VM einzeln bestimmen könnte" - Natürlich kannst du blöder Hund das aber du kannst eine Maschine die AVX2 aktiviert hat dann nur mehr auf Hosts migrieren die es unterstützen ohne sie neu zu starten

    Mach mal eine Live-Migration einer VM mit -march=skylake Binaries auf einen Haswell-Host du Vollpfosten und "illegal cpu instruction" Segfaults werden dein neuer Freund

    Natürlich sind neue CPU-Techniken sinnvoll aber eben nicht unconditional wenn du damit a) Einschränkungen bei der Migration in Kauf nehmen und b) mehr Aufwand bei der Pflege von Paketen hast

    Dann musst (oder solltest zumindest) du Genie nämlich den Gewinn neuer CPU-Flags in deinem echten Workload versus den Nachteilen gegenüberstellen und nur wenn der eindeutig höher ist bringt dir die Vorgehensweise auch nur im Ansatz was

    Im echten Leben laufen deine Kisten nicht auf 100% Last und das darfst du dann auch noch bei einem Gewinn von sagen wir mal 5% Broadwell versus Skylake mit einberechnen

    Der Sprung SandyBridge nach Broadwell ist in der Praxis nämlich weit geringer als man meinen möchte und die gesteigerte IPC kommt nicht nur von den neuen CPU-Flags - Einfach mal eigene Benchmarks fahren weil nur dass zB AVX512 verfügbar ist haeisst noch lange nicht dass dein Workload davon profitiert

    Wenn du Pech hast tut er das nur bei kurzen Peaks falls überhaupt weil eigentlich jedem bekannt sein müsste dass nicht alle Kerne im Dauerlauf mit AVX/AVX2/AVX512 die volle Leistung liefern sondern realtiv schnell runter regeln

    [
    | Versenden | Drucken ]
    • 0
      Von Verfluchtnochmal-05995bd7b am Di, 29. Januar 2019 um 15:23 #

      Und nein man bleibt nicht ewig auf einem alten Clustermode aber wenn man zB noch eine Machine hat deren geplanter Austausch in 1-2 Jahren stattfindet ist es eine Überlegung wert es hinaus zu zögern und im Anschluss nach dem Hochsetzen des Clustermode den Compiler nochmals anzuwerfen statt VMs zu fahren die nur auf bestimmten Nodes lauffähig sind

      Wenn dir dann nämlich einer deiner geilen Skylake Hosts wegbricht hast du ein weit grösseres Problem weil du die darauf laufenden VMs auf einen anderen konzentrieren musst und DANN hast du einen grösseren Leistungseinbruch als sie schlichtweg auf alle verbleibenden Nodes verteilen zu können

      [
      | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung