Abo
  1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › Ryzen 3000: AMD behebt fehlerhaften…

Der Fehler verhindert das Booten

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Der Fehler verhindert das Booten

    Autor: Neutrinoseuche 12.07.19 - 15:28

    "Der Fehler verhindert das Booten von neueren Linux-Systemen sowie des Spiels Destiny 2"

    Nö macht er nicht. Der Fehler verhindert lediglich dass SystemD eine korrekte Zufallszahl bekommt. Das Booten verhindert SystemD.

    Klar ist der Bug nicht schön, aber das Problem hier ist die sture Festlegung von SystemD auf nur eine Quelle. Warum nicht die RND Funktion des Kernels nutzen die solche Fehler umgeht? Nein man muss unbedingt was eigenes am Kernel vorbei bauen, was dann keine Fehler abfangen kann.

    Und ja, die Funktion kann melden dass sie erfolgreich ausgeführt wurde wenn dem so ist. Auch wenn da 100x hindereinander -1 kommt, kann das eine korrekte Zufallszahl sein. Ob das dann von der darauf aufbauenden Anwendung auch sinnvoll genutzt werden kann, dass muss die Anwendung prüfen. Was SystemD anscheinend "vergessen" hat.



    2 mal bearbeitet, zuletzt am 12.07.19 15:32 durch Neutrinoseuche.

  2. Re: Der Fehler verhindert das Booten

    Autor: tritratrulala 12.07.19 - 15:56

    Neutrinoseuche schrieb:
    --------------------------------------------------------------------------------
    > Klar ist der Bug nicht schön, aber das Problem hier ist die sture
    > Festlegung von SystemD auf nur eine Quelle. Warum nicht die RND Funktion
    > des Kernels nutzen die solche Fehler umgeht? Nein man muss unbedingt was
    > eigenes am Kernel vorbei bauen, was dann keine Fehler abfangen kann.
    >

    Das wurde doch schon bis ans Ende der Welt und zurück diskutiert. systemd macht grundsätzlich nichts falsches. Zur Wiederholung

    - systemd nutzt nicht die Kernel-randomness, weil so kurz nach dem Booten wenig Entropie im Kernel vorhandem ist, was das Booten stark verlangsamt
    - systemd nutzt nicht nur eine Quelle für Entropie, aber bevorzugt RDRAND, wenn vorhanden und wenn die Instruktion keinen Fehler zurückgibt
    - Durch den Bug bei den Zen-2-CPUs gibt die RDRAND-Instruktion keinen Fehler zurück, aber die "Zufallszahl" ist immer konstant -1.
    - Weil kein Fehler von der Instruktion kommt, nutzt systemd diese Zahl und kommt in Folge durcheinander, weil da eben nix zufällig ist

    > Und ja, die Funktion kann melden dass sie erfolgreich ausgeführt wurde wenn
    > dem so ist. Auch wenn da 100x hindereinander -1 kommt, kann das eine
    > korrekte Zufallszahl sein. Ob das dann von der darauf aufbauenden Anwendung
    > auch sinnvoll genutzt werden kann, dass muss die Anwendung prüfen. Was
    > SystemD anscheinend "vergessen" hat.

    Man kann den systemd-Entwicklern eventuell ankreiden, dass sie Zufallszahlen verwenden und keinen Nonce-Generator, aber sonst haben die alles richtig gemacht. Zen 2 hält sich eben nicht an den Contract der Instruktion. Ansonsten ist es schließlich astronomisch unwahrscheinlich, dass RDRAND eine lange Folge an konstanten Werten zurückgibt. Ich weiß nicht, wie man hier AMD noch dafür verteidigen sollte, dass sie eine fehlerhaft implementierte Instruktion haben.

    Und nur noch einmal so nebenbei: es ist eben nicht nur systemd betroffen! Neben systemd und Destiny 2 gibt es sicher noch die eine oder andere Software, die RDRAND nutzt.

  3. Re: Der Fehler verhindert das Booten

    Autor: yumiko 12.07.19 - 16:31

    tritratrulala schrieb:
    --------------------------------------------------------------------------------
    > Neutrinoseuche schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Klar ist der Bug nicht schön, aber das Problem hier ist die sture
    > > Festlegung von SystemD auf nur eine Quelle. Warum nicht die RND Funktion
    > > des Kernels nutzen die solche Fehler umgeht? Nein man muss unbedingt was
    > > eigenes am Kernel vorbei bauen, was dann keine Fehler abfangen kann.
    > >
    >
    > Das wurde doch schon bis ans Ende der Welt und zurück diskutiert. systemd
    > macht grundsätzlich nichts falsches. Zur Wiederholung
    >
    > - systemd nutzt nicht die Kernel-randomness, weil so kurz nach dem Booten
    > wenig Entropie im Kernel vorhandem ist, was das Booten stark verlangsamt
    > - systemd nutzt nicht nur eine Quelle für Entropie, aber bevorzugt RDRAND,
    > wenn vorhanden und wenn die Instruktion keinen Fehler zurückgibt
    > - Durch den Bug bei den Zen-2-CPUs gibt die RDRAND-Instruktion keinen
    > Fehler zurück, aber die "Zufallszahl" ist immer konstant -1.
    > - Weil kein Fehler von der Instruktion kommt, nutzt systemd diese Zahl und
    > kommt in Folge durcheinander, weil da eben nix zufällig ist
    >
    > > Und ja, die Funktion kann melden dass sie erfolgreich ausgeführt wurde
    > wenn
    > > dem so ist. Auch wenn da 100x hindereinander -1 kommt, kann das eine
    > > korrekte Zufallszahl sein. Ob das dann von der darauf aufbauenden
    > Anwendung
    > > auch sinnvoll genutzt werden kann, dass muss die Anwendung prüfen. Was
    > > SystemD anscheinend "vergessen" hat.
    >
    > Man kann den systemd-Entwicklern eventuell ankreiden, dass sie
    > Zufallszahlen verwenden und keinen Nonce-Generator, aber sonst haben die
    > alles richtig gemacht. Zen 2 hält sich eben nicht an den Contract der
    > Instruktion. Ansonsten ist es schließlich astronomisch unwahrscheinlich,
    > dass RDRAND eine lange Folge an konstanten Werten zurückgibt. Ich weiß
    > nicht, wie man hier AMD noch dafür verteidigen sollte, dass sie eine
    > fehlerhaft implementierte Instruktion haben.
    >
    > Und nur noch einmal so nebenbei: es ist eben nicht nur systemd betroffen!
    > Neben systemd und Destiny 2 gibt es sicher noch die eine oder andere
    > Software, die RDRAND nutzt.

    Ich würde den systemd-Entwicklern ankreiden, dass sie Zufallszahl mit unique-ID verwechseln.
    Wenn da immer "-1" zurückkommt, ist das eine legitime Zufallszahl, nur kryptographisch "schlecht".

  4. Re: Der Fehler verhindert das Booten

    Autor: Spawn182 12.07.19 - 16:51

    Wenn ich es richtig verstehe, dann liefert ja der Prozessor nicht nur eben keine sinnvolle Zufallszahl, sondern flagged diese per Carry Flag (CF) als eben doch valide und da liegt einfach der Fehler und dieser ist definitiv AMD anzulasten, sie müssten nur CF auf 0 setzen und alles Seiten wären zufrieden. Vermutlich wird dies nun so auch gefixt.

    PS An die Autoren, "AMD behebt den Fehler nicht" sondern wird ihn beheben. Kleiner aber entscheidender Unterschied.



    1 mal bearbeitet, zuletzt am 12.07.19 16:52 durch Spawn182.

  5. Re: Der Fehler verhindert das Booten

    Autor: yoyoyo 12.07.19 - 16:55

    Nein, bei fast allen gängigen uid Implementierungen wird der Fall, dass es eine Kollision bei mehr Versuchen als Teilchen in der Galaxie multipliziert mit ihrer Lebenszeit in Sekunden gibt hingenommen.
    Das ist kein Fehler, sondern einfach um Größenordnungen effizienter und ermöglicht verteiltes Rechnen in vielen Fällen erst.

  6. Re: Der Fehler verhindert das Booten

    Autor: nixidee 12.07.19 - 17:20

    Nein, einzig der Fehler ist Schuld daran. Die Entwickler können doch nicht alle schweren Hardwarefehler vorausahnen. Die Entwickler haben immerhin einen Work arround implementiert.

  7. Re: Der Fehler verhindert das Booten

    Autor: ML82 12.07.19 - 17:30

    mal ne frage am rande, wie beweist man eigendlich vollständig, dass seine zufallsfunktion wirklich zufällige werte generiert, bzw. wie beweist man zu 100% sicher, dass angeblich zufällige werte nicht zufällig sind?

    empirik stellt kein beweis dar, maximal einen hinweis/indiz, die theorie kann n mal standhalten, beim n+1 sten mal kann sie versagen.

    d.h. selbst wenn hexdecimaloctohexaquadrorilliarden mal -1 geliefert wird könnte das irgendwann nicht mehr so sein, rein durch zufall, sonne explodiert, rechner hört auf zu existieren und liefert keine -1 mehr zurück, ist das zufall oder berechenbar, bzw. wann _genau_ expoldiert die sonne, und trifft die erde vorher wirklich kein fetter asteroid, wie schon mindestens einmal?

    bzw. ist ein deterministisch berechneter zufall überhaupt zufall oder nur ein ergebnis was kommen musste?



    2 mal bearbeitet, zuletzt am 12.07.19 17:48 durch ML82.

  8. Re: Der Fehler verhindert das Booten

    Autor: Zoj 12.07.19 - 18:28

    Ein Beweis ist gar nicht vonnöten.

    Man kann empirisch mit sehr hoher Wahrscheinlichkeit eine Aussage darüber treffen, ob der Zufall zufällig ist.

    Für so etwas gibt es den schönen Term "an Sicherheit grenzende Wahrscheinlichkeit".

  9. Re: Der Fehler verhindert das Booten

    Autor: Graveangel 12.07.19 - 18:37

    Zoj schrieb:
    --------------------------------------------------------------------------------
    > Ein Beweis ist gar nicht vonnöten.
    >
    > Man kann empirisch mit sehr hoher Wahrscheinlichkeit eine Aussage darüber
    > treffen, ob der Zufall zufällig ist.
    >
    > Für so etwas gibt es den schönen Term "an Sicherheit grenzende
    > Wahrscheinlichkeit".


    Trotzdem wäre der PC nicht gestartet, wenn zufällig 4x die gleiche andere Zahl aufgetreten wäre.
    Was ja schon ungünstig wäre?

  10. Re: Der Fehler verhindert das Booten

    Autor: katze_sonne 12.07.19 - 19:36

    ML82 schrieb:
    --------------------------------------------------------------------------------
    > mal ne frage am rande, wie beweist man eigendlich vollständig, dass seine
    > zufallsfunktion wirklich zufällige werte generiert, bzw. wie beweist man zu
    > 100% sicher, dass angeblich zufällige werte nicht zufällig sind?
    >
    > empirik stellt kein beweis dar, maximal einen hinweis/indiz, die theorie
    > kann n mal standhalten, beim n+1 sten mal kann sie versagen.
    >
    > d.h. selbst wenn hexdecimaloctohexaquadrorilliarden mal -1 geliefert wird
    > könnte das irgendwann nicht mehr so sein, rein durch zufall, sonne
    > explodiert, rechner hört auf zu existieren und liefert keine -1 mehr
    > zurück, ist das zufall oder berechenbar, bzw. wann _genau_ expoldiert die
    > sonne, und trifft die erde vorher wirklich kein fetter asteroid, wie schon
    > mindestens einmal?
    >
    > bzw. ist ein deterministisch berechneter zufall überhaupt zufall oder nur
    > ein ergebnis was kommen musste?

    Gar nicht. Und weil Linus Torvalds den CPU-Herstellern nicht traut (NSA, ...), machen sie die Zufälle selber.

  11. Re: Der Fehler verhindert das Booten

    Autor: nille02 12.07.19 - 19:55

    nixidee schrieb:
    --------------------------------------------------------------------------------
    > Nein, einzig der Fehler ist Schuld daran. Die Entwickler können doch nicht
    > alle schweren Hardwarefehler vorausahnen.

    Wenn ich direkt eine Funktion nutzen will in der Fehler bekannt sind, sollte ich das vorher prüfen. Besonders wenn die fehlerfreie Funktion Voraussetzung für die eigene Funktion ist und man im Fehlerfall das ganze System nicht startet.

    > Die Entwickler haben immerhin
    > einen Work arround implementiert.

    Ist der denn inzwischen im Hauptentwicklungszweig? Denn das eigene Problem, dass das System dann nicht startet, will man nicht einsehen. Auch gibt es andere Möglichkeiten eine UUID zu erstellen für den Fall das es nicht gelingt.

  12. Re: Der Fehler verhindert das Booten

    Autor: nille02 12.07.19 - 20:05

    tritratrulala schrieb:
    --------------------------------------------------------------------------------
    > Ich weiß
    > nicht, wie man hier AMD noch dafür verteidigen sollte, dass sie eine
    > fehlerhaft implementierte Instruktion haben.

    Das verteidigt niemand. Und wie im Artikel auch schon erwähnt, bin ich alles andere als begeistert darüber wie Zugeknöpft AMD sich dazu gibt. Auch der Vorwurf keine oder nur mangelhaft Tests durchgeführt zu haben muss AMD sich gefallen lassen.

    Ich kreide es aber systemd an, als wichtige Schlüsselkomponente, keine Anstalten zu machen solch eine wichtiges Ergebnis zu validieren. Eine UUID ist 128bit lang und mich würde es nicht wundern wenn sie dafür einfach das Ergebnis von 2 RDRAND aufrufen nutzen. Es hätte niemanden weh getan wenn man die zwei Ergebnisse miteinander verglichen hätte. Wenn man nach X versuchen kein gültiges Ergebnis bekommt, nutzt man halt den Fallback.
    Und ja, man hätte darauf kommen können. Allein der Fehler mit dem -1 ist seit 5 Jahren bekannt und durch aus möglich.

    Man hätte auf den Fehler einfach anders Reagieren müssen, als sich nur auf sein hohes Ross zu setzen und zu behaupten man hat ja alles richtig gemacht.

  13. Re: Der Fehler verhindert das Booten

    Autor: barfoo 12.07.19 - 20:12

    Aber da so ein Zufall eben nur einmal aller x Mrd Jahre auftreten wird/würde, also nur einmal ein System aller x Jahre nicht booten würde, würde da 1. nicht auffallen und 2. nicht weiter tragisch. So ist das halt typischer AMD Unfähigkeitsfrickelmist.

  14. Re: Der Fehler verhindert das Booten

    Autor: Geistesgegenwart 12.07.19 - 21:43

    ML82 schrieb:
    --------------------------------------------------------------------------------
    > mal ne frage am rande, wie beweist man eigendlich vollständig, dass seine
    > zufallsfunktion wirklich zufällige werte generiert, bzw. wie beweist man zu
    > 100% sicher, dass angeblich zufällige werte nicht zufällig sind?

    Ein Computer kann erstmal immer nur Pseudo Zufallszahlen generieren. Das ist ein generelles Problem in der Informatik. Gibt ja experimentelle Bauteile die versuchen mit physikalischen Effekten wie Zerfallswahrscheinlichkeiten/Geigerzählern tatsächl "zufällige" Zahlen zu liefern - also nicht mehr "pseudo".

    >
    > empirik stellt kein beweis dar, maximal einen hinweis/indiz, die theorie
    > kann n mal standhalten, beim n+1 sten mal kann sie versagen.
    >
    > d.h. selbst wenn hexdecimaloctohexaquadrorilliarden mal -1 geliefert wird
    > könnte das irgendwann nicht mehr so sein, rein durch zufall, sonne
    > explodiert, rechner hört auf zu existieren und liefert keine -1 mehr
    > zurück, ist das zufall oder berechenbar, bzw. wann _genau_ expoldiert die
    > sonne, und trifft die erde vorher wirklich kein fetter asteroid, wie schon
    > mindestens einmal?
    >
    > bzw. ist ein deterministisch berechneter zufall überhaupt zufall oder nur
    > ein ergebnis was kommen musste?

    Dazu gibt es statistische Analysemethoden. Zufallszahlen gelten als schlecht wenn z.B. die Varianz gering ist (im obigen -1 beispiel ist Var(X) = 0, also es gibt keine Varianz). Man berücksichtigt auch Korrelation. Z.B die Sequenz -1,1,-1,1 etc. ist schlecht weil auf 1 immer -1 folgt. Das geht auch mit langen Sequenzen so die sich immer wiederholen: 1,2,3,4,5,6,1,2,3,4,5,6 etc. Die Korrelation kann man grafisch hübsch darstellen, z.B. im Cartesischen wenn du X_0 und X_1 als paar plottest. Man erkennt bei schlechten RNDs sofort eine Ebenenbildung.

    Prinzipiell sind RNGs eine Wissenschaft für sich, gerade für kryptografische Zwecke wird das massiv in der Forschung diskutiert und viel dazu publiziert. Aber auch die nicht-crypto RNGs sind extrem wichtig, nur gelten hier teilweise andere Anforderungen als maximale Entropie wie z.B.: gewollte reproduzierbarkeit von Sequenzen, hohe Performance, gute/energieffiziente Implementierung in Hardware/FPGA möglich, einstellbare Parameter über den Ausgabestrom etc.

  15. Re: Der Fehler verhindert das Booten

    Autor: ML82 13.07.19 - 00:35

    dann ist es doch äußerst grenzdebil auch nur irgendetwas von "random/zufall" dabei zu schwadronieren, egal wie, eingaben legen das ergebnis fest, egal ob dazu noch ein diskreter wert eines *thermometers* als eingabe herangezogen wird, oder nicht?

    ich meine mich zu entsinnen, das es sogar genuntzt wird, dass zahlengeneratoren ebend nicht zufällig arbeiten, und mit sogn. seeds als eingabe/einstellung immer das gleiche bild wieder ganz *zufällig* damit hergestellt werden kann.



    2 mal bearbeitet, zuletzt am 13.07.19 00:48 durch ML82.

  16. Re: Der Fehler verhindert das Booten

    Autor: barfoo 13.07.19 - 01:10

    Es gibt einen Unterschied zwischen Pseudo Random und immer -1....

  17. Re: Der Fehler verhindert das Booten

    Autor: ML82 13.07.19 - 01:58

    hart gefragt inwiefern existiert der von dir behauptete unterschied, doch nur wie weit du bliken kannst, bzw. inwiefern ist deine betrachtung relevant?

    und es war eine frage am rande, nicht direkt zum -1 problem der amd implementierung gestellt, die trotz aller empirik immernoch und auf immer ewig zufällig -1 (error) ausgeben könnte ... wie _beweist man zu 100% sicher, dass auch das kein zufall sein kann, für immer und ewig, zu jeder zeit und unter allen bedingungen, omnidirektional, allgemeingültig usw. ???
    1+1 ist nicht zwei sondern unter der raumzeitdehnung die während der bearbeitung dieser frage anliegt mehr als zwei, oder nicht? bzw. was ist überhaupt 1?



    2 mal bearbeitet, zuletzt am 13.07.19 02:18 durch ML82.

  18. Re: Der Fehler verhindert das Booten

    Autor: cyclux 13.07.19 - 04:56

    Andere haben es ja schon angedeutet: Es lässt sich grundsätzlich nicht strikt (mathematisch) beweisen. Mit steigender Anzahl der "sample size" lässt sich durch stochastische Methoden immer "konfidenter" aussagen ob der Generator nun zufällige Werte ausspuckt oder weniger zufällige. Bei stochastischen Fragestellungen (mit hinreichender "sample size") gibt es in der Regel nicht 100% ja oder nein, sondern nur Alles dazwischen.

  19. Re: Der Fehler verhindert das Booten

    Autor: Copper 13.07.19 - 10:00

    ML82 schrieb:
    --------------------------------------------------------------------------------
    > und es war eine frage am rande, nicht direkt zum -1 problem der amd
    > implementierung gestellt, die trotz aller empirik immernoch und auf immer
    > ewig zufällig -1 (error) ausgeben könnte ... wie _beweist man zu 100%
    > sicher, dass auch das kein zufall sein kann, für immer und ewig, zu jeder
    > zeit und unter allen bedingungen, omnidirektional, allgemeingültig usw.
    > ???

    Die Antwort ist realtiv einfach: es geht nicht. Das ist ja gerade die Krux an Zufallszahlen. Wenn bei n Versuchen n mal die gleiche Zahl rauskommt, dann kann es sich um Zufallszahlen handeln. Das ist zwar je nach Größe von n und der Größe des zulässigen Intervalls für n möglicherweise extremst unwahrscheinlich, aber nicht unmöglich. Für Kryptographie extrem unschön, aber durchaus möglich. Insofern muss man versuchen, solche Clusterbildungen abzufangen.

    Bezüglich AMD: Offensichtlich ist es ein Fehler, dass immer nur -1 zurückgegeben wird. Die Frage ist aber, was passiert, wenn die funktionierende RDRAND-Funktion per Zufall mehrmals hintereinander dieselbe Zahl ausgibt, dann kommt doch SystemD genauso ins Straucheln?

  20. Re: Der Fehler verhindert das Booten

    Autor: Geistesgegenwart 13.07.19 - 10:17

    ML82 schrieb:
    --------------------------------------------------------------------------------
    > dann ist es doch äußerst grenzdebil auch nur irgendetwas von
    > "random/zufall" dabei zu schwadronieren, egal wie, eingaben legen das
    > ergebnis fest, egal ob dazu noch ein diskreter wert eines *thermometers*
    > als eingabe herangezogen wird, oder nicht?
    >
    > ich meine mich zu entsinnen, das es sogar genuntzt wird, dass
    > zahlengeneratoren ebend nicht zufällig arbeiten, und mit sogn. seeds als
    > eingabe/einstellung immer das gleiche bild wieder ganz *zufällig* damit
    > hergestellt werden kann.


    Richtig, die Eingaben legen natürlich exakt die Zufallszahlensequenz fest. Der Trick ist, diese Eingaben (seeds) so zu wählen, das es möglichst unmöglich ist diese vorherzusagen. Deswegen nimmt man ein ganzen Array von Werten die das System liefert die hoffentlich niemand kennt: Systemzeit auf nanosekundenbasis, thermische Fluktationen im Prozessor, Interrupt Timings, Mouse/Keyboardeingaben, Ankunftszeiten von NEtzwerkpaketen etc. Einzeln sind diese Werte leicht vorherzusagen, aber zusammengenommen wird das schwierig ALLE zu erraten.

    Problem ist, das eben nach dem Boot nur wenige solcher Seeds zur verfügung stehen (vor dem Boot gabs kaum ausgelöste Interrupts, keine Mouse/Keyboardeingaben, keine Datenpakete auf dem Netzwerk etc.).

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Hays AG, Fürth
  2. über Dr. Maier & Partner GmbH Executive Search, Region Stuttgart
  3. Interhyp Gruppe, München
  4. spectrumK GmbH, Berlin

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. ab 369€ + Versand
  2. 349,00€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Endpoint Security: IT-Sicherheit ist ein Cocktail mit vielen Zutaten
Endpoint Security
IT-Sicherheit ist ein Cocktail mit vielen Zutaten

Tausende Geräte in hundert verschiedenen Modellen mit Dutzenden unterschiedlichen Betriebssystemen. Das ist in großen Unternehmen Alltag und stellt alle, die für die IT-Sicherheit zuständig sind, vor Herausforderungen.
Von Anna Biselli

  1. Datendiebstahl Kundendaten zahlreicher deutscher Firmen offen im Netz
  2. Metro & Dish Tisch-Reservierung auf Google übernehmen
  3. Identitätsdiebstahl SIM-Dieb kommt zehn Jahre in Haft

Erneuerbare Energien: Die Energiewende braucht Wasserstoff
Erneuerbare Energien
Die Energiewende braucht Wasserstoff

Kein anderes Element ist so universell und dabei simpel aufgebaut wie Wasserstoff und das energiereiche Gas lässt sich aus fast jedem Energieträger gewinnen. Genauso vielseitig gestaltet sich seine Nutzung.
Ein Bericht von Jan Oliver Löfken

  1. Strom-Boje Mittelrhein Schwimmende Kraftwerke liefern Strom aus dem Rhein
  2. Speicherung von Überschussstrom Wasserstoff soll bei Engpässen helfen
  3. Energiewende DLR-Forscher bauen Kohlekraftwerke zu Stromspeichern um

Erasure Coding: Das Ende von Raid kommt durch Mathematik
Erasure Coding
Das Ende von Raid kommt durch Mathematik

In vielen Anwendungsszenarien sind Raid-Systeme mittlerweile nicht mehr die optimale Lösung. Zu langsam und starr sind sie. Abhilfe schaffen können mathematische Verfahren wie Erasure Coding. Noch existieren für beide Techniken Anwendungsgebiete. Am Ende wird Raid aber wohl verschwinden.
Eine Analyse von Oliver Nickel

  1. Agentur für Cybersicherheit Cyberwaffen-Entwicklung zieht in den Osten Deutschlands
  2. Yahoo Richterin lässt Vergleich zu Datenleck platzen

  1. TLS-Zertifikat: Gesamter Internetverkehr in Kasachstan kann überwacht werden
    TLS-Zertifikat
    Gesamter Internetverkehr in Kasachstan kann überwacht werden

    In Kasachstan müssen Internetnutzer ab sofort ein spezielles TLS-Zertifikat installieren, um verschlüsselte Webseiten aufrufen zu können. Das Zertifikat ermöglicht eine staatliche Überwachung des gesamten Internetverkehrs in dem Land.

  2. Ari 458: Elektro-Lieferwagen aus Leipzig kostet knapp 14.000 Euro
    Ari 458
    Elektro-Lieferwagen aus Leipzig kostet knapp 14.000 Euro

    Ari 458 ist ein kleiner Lieferwagen mit Elektroantrieb, den der Hersteller mit Aufbauten für verschiedene Einsatzzwecke anbietet. Die Ausstattung ist einfach, dafür ist das Auto günstig.

  3. Quake: Tim Willits verlässt id Software
    Quake
    Tim Willits verlässt id Software

    Seit 24 Jahren ist Tim Willits einer der entscheidenden Macher bei id Software, nun kündigt er seinen Rückzug an. Was er künftig vorhat, will der ehemalige Leveldesigner und studierte Computerwissenschaftler erst nach der Quakecon verraten.


  1. 17:52

  2. 15:50

  3. 15:24

  4. 15:01

  5. 14:19

  6. 13:05

  7. 12:01

  8. 11:33