Kommt wieder eine Zeit, in der Rechenkosten teurer sind als die Zeitkosten von Entwicklern ...
Wenn ja, könnte vielleicht künftig die Ära der entwicklerfreundlichen Sprachen zu Ende gehen,
und stattdessen eine Zeit kommen, in der man mit LLMs in Sprachen wie C oder Rust programmiert.
https://product.kyobobook.co.kr/detail/S000201558138
Datenanalyse mit Python-Bibliotheken
Das ist ein Buch von Wes McKinney, dem Schöpfer von Pandas, und auch als Einstieg in Data Science sehr zu empfehlen. Ich habe es gelesen, als die 2. Auflage gerade erschienen war ... und wie ich jetzt sehe, gibt es inzwischen schon die 3. Auflage.
Wenn man das Schema auch per DTD definiert und auf der Parser-Seite zwischenspeichert, hätte das zudem den Effekt, dass das Schema nur einmal übertragen werden muss.
Der Schaden entstand durch einen erfolgreichen Angriff auf eine tatsächliche Schwachstelle in React Server Components.
Da der Zeitpunkt des Artikels ähnlich ist, halte ich eine Verwechslung für durchaus möglich. https://www.dailysecu.com/news/articleView.html?idxno=203111
Zur Einordnung: Beim vorherigen Ausfall waren alle Dienste betroffen, die hinter dem Cloudflare-CDN hingen.
Aus dieser Perspektive betrachtet man also, ob der gesamte Dienst ausgefallen ist oder nur ein Teil davon.
Ich kann den Autor des ursprünglichen Beitrags verstehen, aber ich weiß nicht, warum andere ohne jede Grundlage so spöttisch reagieren.
Das hier ist wirklich eine der wenigen verbliebenen entwicklungsbezogenen Communities, in denen es auch noch an Etikette nicht fehlt.
Ich habe im zuerst verfassten Beitrag den allgemeinen Inhalt später per Update offengelegt.
Ein Teil der Nutzer (28 % des gesamten Traffics) war betroffen, und als Ursache wurde genannt, dass dies während eines Versuchs passiert sei, eine Schwachstelle in React Server Components zu blockieren.
Als Entwickler sollte man doch nicht nur einfach Code schreiben, sondern auch bei der Ursachenanalyse oder beim Entwurf von Logik logisch vorgehen oder zumindest klare Belege vorlegen können, oder nicht?
Ich habe meinen ersten Kommentar deshalb so geschrieben, weil bei der Prüfung nach Veröffentlichung dieses Beitrags auf dem von mir verwalteten Server zwar ein CDN vorgeschaltet ist, ich aber keine Störung feststellen konnte.
Offiziell heißt es doch, dass es Fehler bei API und Dashboard gab — sind das falsche Informationen?
Wenn es ein Dashboard-Fehler ist, kann es doch natürlich zu einer Cloudflare-Störung kommen, und da DownDetector das auch als cloudflarebezogen verarbeitet, kann dort ebenfalls eine Störung angezeigt werden (zumal es beim letzten Vorfall ja tatsächlich ausgefallen ist) — ist das nicht so?
Wäre es nicht wichtiger, statt einfach nur zwischen richtig und falsch zu unterscheiden, den klaren Grund zu ermitteln?
Cloudflare hat in seinem Blog geschrieben, dass bei 28 % des HTTP-Traffics 500er-Antworten zurückgegeben wurden.
Auch bei meinem produktiven Dienst trat ein Cloudflare-500-Fehler auf.
Ich stimme dem Punkt im Artikel sehr zu, dass es bei der Behebung kleiner Ärgernisse hilft.
Anstatt AI große Aufgaben zu überlassen, scheint es besonders hilfreich zu sein, wenn es um kleine Komfortfunktionen, Skripting, Refactoring und andere lästige, aber später nützliche Arbeiten geht.
Auch die von der API unabhängige Orange Cloud war von einem großflächigen Ausfall betroffen
Notion, LinkedIn usw.
Sie haben in Ihrem Kommentar selbst falsche Informationen gepostet.
Der Artikel nennt zwar einige Fakten, lenkt aber mit Links zu früheren Vorfällen ab und macht es für die Nutzer dadurch verwirrend.
Ich habe nicht alles abgestritten, sondern nur die Behauptung, dass komplett alles ausgefallen sei.
Wenn man sich ansieht, dass sich die Daten auf Downdetector tatsächlich wieder erholt haben, bleibt bei Cloudflare zwar ein Ausfall verzeichnet, aber wenn man weiter nach unten scrollt, sieht man, dass Roblox oder Instagram nicht betroffen waren; deshalb habe ich das so gesagt.
Wenn man den offiziellen Angaben von Cloudflare nicht glaubt, kann man nichts machen.
Es könnte sein, dass sie lügen.
Was ich aber sagen wollte, ist nur, dass die Dinge ausgefallen sind, die von der Cloudflare-API betroffen waren, egal ob über eine Bibliothek oder direkt genutzt.
Laut den offiziellen Angaben.
Das ist kein Kommentar, den ich geschrieben habe, um zu streiten.
Es wurde nur Dashboard und API angezeigt, aber auch Claude, die Cloudflare-Website, meine Website und Downdetector waren nicht erreichbar.
Jetzt scheint alles wiederhergestellt zu sein, denn alles ist wieder normal erreichbar.
Wie bei allen Tools gibt es auch hier keine Universallösung, aber ich halte Protobuf trotzdem für ein durchaus gutes Werkzeug.
Insbesondere gab es einmal den Fall, dass wir in einer Embedded-Umgebung große Datenmengen mit hoher Frequenz (20-mal pro Sekunde) an verschiedene Sprachen/Clients senden mussten, und das haben wir mit nanopb sauber umgesetzt.
„Debugging ist zwar schwierig“
Ausgeschieden
Kommt wieder eine Zeit, in der Rechenkosten teurer sind als die Zeitkosten von Entwicklern ...
Wenn ja, könnte vielleicht künftig die Ära der entwicklerfreundlichen Sprachen zu Ende gehen,
und stattdessen eine Zeit kommen, in der man mit LLMs in Sprachen wie C oder Rust programmiert.
https://product.kyobobook.co.kr/detail/S000201558138
Datenanalyse mit Python-Bibliotheken
Das ist ein Buch von Wes McKinney, dem Schöpfer von Pandas, und auch als Einstieg in Data Science sehr zu empfehlen. Ich habe es gelesen, als die 2. Auflage gerade erschienen war ... und wie ich jetzt sehe, gibt es inzwischen schon die 3. Auflage.
Admin-Skill-Issue
Wenn man das Schema auch per DTD definiert und auf der Parser-Seite zwischenspeichert, hätte das zudem den Effekt, dass das Schema nur einmal übertragen werden muss.
Ganz schön ehrlich.
Der Schaden entstand durch einen erfolgreichen Angriff auf eine tatsächliche Schwachstelle in React Server Components.
Da der Zeitpunkt des Artikels ähnlich ist, halte ich eine Verwechslung für durchaus möglich.
https://www.dailysecu.com/news/articleView.html?idxno=203111
Zur Einordnung: Beim vorherigen Ausfall waren alle Dienste betroffen, die hinter dem Cloudflare-CDN hingen.
Aus dieser Perspektive betrachtet man also, ob der gesamte Dienst ausgefallen ist oder nur ein Teil davon.
Ich kann den Autor des ursprünglichen Beitrags verstehen, aber ich weiß nicht, warum andere ohne jede Grundlage so spöttisch reagieren.
Das hier ist wirklich eine der wenigen verbliebenen entwicklungsbezogenen Communities, in denen es auch noch an Etikette nicht fehlt.
Ich habe im zuerst verfassten Beitrag den allgemeinen Inhalt später per Update offengelegt.
Ein Teil der Nutzer (28 % des gesamten Traffics) war betroffen, und als Ursache wurde genannt, dass dies während eines Versuchs passiert sei, eine Schwachstelle in React Server Components zu blockieren.
Als Entwickler sollte man doch nicht nur einfach Code schreiben, sondern auch bei der Ursachenanalyse oder beim Entwurf von Logik logisch vorgehen oder zumindest klare Belege vorlegen können, oder nicht?
Ich habe meinen ersten Kommentar deshalb so geschrieben, weil bei der Prüfung nach Veröffentlichung dieses Beitrags auf dem von mir verwalteten Server zwar ein CDN vorgeschaltet ist, ich aber keine Störung feststellen konnte.
Offiziell heißt es doch, dass es Fehler bei API und Dashboard gab — sind das falsche Informationen?
Wenn es ein Dashboard-Fehler ist, kann es doch natürlich zu einer Cloudflare-Störung kommen, und da DownDetector das auch als cloudflarebezogen verarbeitet, kann dort ebenfalls eine Störung angezeigt werden (zumal es beim letzten Vorfall ja tatsächlich ausgefallen ist) — ist das nicht so?
Wäre es nicht wichtiger, statt einfach nur zwischen richtig und falsch zu unterscheiden, den klaren Grund zu ermitteln?
https://blog.cloudflare.com/5-december-2025-outage/
Cloudflare hat in seinem Blog geschrieben, dass bei 28 % des HTTP-Traffics 500er-Antworten zurückgegeben wurden.
Auch bei meinem produktiven Dienst trat ein Cloudflare-500-Fehler auf.
Ich stimme dem Punkt im Artikel sehr zu, dass es bei der Behebung kleiner Ärgernisse hilft.
Anstatt AI große Aufgaben zu überlassen, scheint es besonders hilfreich zu sein, wenn es um kleine Komfortfunktionen, Skripting, Refactoring und andere lästige, aber später nützliche Arbeiten geht.
https://www.cloudflarestatus.com/incidents/k9ppxftx8bs5
Da kommt gleich noch ein weiteres Problem hinterher.
Schade, dass es keine Alternative gibt.
Auch die von der API unabhängige Orange Cloud war von einem großflächigen Ausfall betroffen
Notion, LinkedIn usw.
Sie haben in Ihrem Kommentar selbst falsche Informationen gepostet.
Der Artikel nennt zwar einige Fakten, lenkt aber mit Links zu früheren Vorfällen ab und macht es für die Nutzer dadurch verwirrend.
Ich habe nicht alles abgestritten, sondern nur die Behauptung, dass komplett alles ausgefallen sei.
Wenn man sich ansieht, dass sich die Daten auf Downdetector tatsächlich wieder erholt haben, bleibt bei Cloudflare zwar ein Ausfall verzeichnet, aber wenn man weiter nach unten scrollt, sieht man, dass Roblox oder Instagram nicht betroffen waren; deshalb habe ich das so gesagt.
Wenn man den offiziellen Angaben von Cloudflare nicht glaubt, kann man nichts machen.
Es könnte sein, dass sie lügen.
Was ich aber sagen wollte, ist nur, dass die Dinge ausgefallen sind, die von der Cloudflare-API betroffen waren, egal ob über eine Bibliothek oder direkt genutzt.
Laut den offiziellen Angaben.
Das ist kein Kommentar, den ich geschrieben habe, um zu streiten.
Es wurde nur Dashboard und API angezeigt, aber auch Claude, die Cloudflare-Website, meine Website und Downdetector waren nicht erreichbar.
Jetzt scheint alles wiederhergestellt zu sein, denn alles ist wieder normal erreichbar.
Prüft die Nachrichten.
https://independent.co.uk/tech/…
Diesmal scheint nicht alles ausgefallen zu sein; betroffen scheinen eher die Bereiche zu sein, die die Cloudflare-API nutzen, sowie das Cloudflare-Dashboard.
https://www.cloudflarestatus.com/incidents/lfrm31y6sw9q
Es ist zwar unerquicklich, aber immerhin gut, dass es behoben wurde. Vermutlich gibt es mehr solcher Fälle, sie sind nur nicht bekannt geworden.
Das trifft wirklich den Kern.
Wie bei allen Tools gibt es auch hier keine Universallösung, aber ich halte Protobuf trotzdem für ein durchaus gutes Werkzeug.
Insbesondere gab es einmal den Fall, dass wir in einer Embedded-Umgebung große Datenmengen mit hoher Frequenz (20-mal pro Sekunde) an verschiedene Sprachen/Clients senden mussten, und das haben wir mit nanopb sauber umgesetzt.
Wenn man es so streng handhabt, kommt dann nicht am Ende XML dabei heraus? Haha