Fragen? Antworten! Siehe auch: Alternativlos
AMD hat den Bluff gecallt und jetzt hört sich das schon wieder ganz anders an:
There is no fix for Intel’s crashing 13th and 14th Gen CPUs — any damage is permanentLeuchtet ein. CPUs, die schon einen Schaden haben, werden durch Microcode-Updates nicht wieder heile. Aber es geht noch weiter.And, Intel confirms, too-high voltages aren’t the only reason some of these chips are failing. Intel spokesperson Thomas Hannaford confirms it’s a primary cause, but the company is still investigating. Intel community manager Lex Hoyos also revealed some instability reports can be traced back to an oxidization manufacturing issue that was fixed at an unspecified date last year.Mit anderen Worten: Sie wissen es auch nicht. Oder sie wissen es und es ist peinlicher das zuzugeben als Unwissen zu heucheln. Ist beides eher nicht so überzeugend für Kunden und potentielle Kunden.Stellt sich die Frage, was Intel jetzt machen will. Die Optionen sind alle eher nicht so attraktiv für sie.
Sie könnten den Verkaufe instellen. Sie könnten kaputte CPUs tauschen. Sie können einen Rückruf machen. Darauf angesprochen ist ihre Antwort wie folgt:
Intel has not halted sales or clawed back any inventory. It will not do a recall, period. The company is not currently commenting on whether or how it might extend its warranty.Nicht mal das wollen sie machen! Meine Fresse müssen die mit dem Rücken zur Wand stehen. Oder sie spekulieren, dass ihre Kunden noch mehr mit dem Rücken zur Wand stehen.Das ist jetzt nicht gerade der beste Zeitpunkt für solche Allüren, denn AMD frisst ihnen jetzt seit Monaten mit den Zen-CPUs die Kunden weg. Erst im Desktop-Segment, dann im Laptop-Segment, dann im Server-Segment. Es ist schon länger nicht mehr so, dass irgendwer Intel kaufen muss — außer, ja außer den Bitcoin-Deppen, die sich "Geschäftsmodelle" auf Basis von SGX herbeihalluziniert haben. SGX ist zwar schon dutzendfach gebrochen worden, aber das ist die eine Intel-Sache, die AMD nicht hat. Ist auch gut so, denn das ist eine echt bescheuerte Idee.
But Intel does tell us it’s “confident” that you don’t need to worry about invisible degradation.Ja super. Krisen-PR können die schon bei Intel. Wenn die CPUs failen, dann katastrophal!1!! Und das drücken die noch als Vorteil aus! (Danke, Kris)
Jetzt muss er wohl seinen Rückflugplan ändern, weil die neue Regierung in UK sagt, sie wolle keinen Einspruch gegen den internationalen Haftbefehl des Internationalen Strafgerichtshof gegen Netanjahu einlegen.
Hat der etwa doch Zähne, der Haftbefehl?!
Jetzt macht die Post die Späti-Filialen zu, weil Packstationen billiger sind.
Und irgendwann wird jemandem auffallen, dass man das Porto dafür zahlt, dass die Post dem Empfänger zugestellt wird, nicht irgendeiner versifften Packstation.
Oder hey, vielleicht baut die Post auch "KI" in ihre Packstationen ein. Die auf Fragen genau so verwirrt reagiert wie "echte" Postfilialen. Das sollte nicht weiter schwierig sein oder viel Training brauchen. Geht eigentlich auch ganz ohne Training.
Wild sharks off Brazil coast test positive for cocaine, scientists say
Weil ihr euch gedacht habt, das wird da von Profis gemanaged, da gibt es dann keine Ausfälle mehr?
It's a bold strategy, let's see if it pays off!
Bitkom hat da mal eine Umfrage gemacht. Ergebnis:
4 von 10 Unternehmen berichten von Cloud-AusfällenJa gut, wenn man dermaßen mit heruntergelassenen Hosen erwischt wird, und man auf echt überhaupt gar niemand anderen zeigen kann, weil man das vollständig selbst zu verantworten hat, dann werden an dieser Stelle die Optionen knapp. Da bleibt eigentlich nur eine Strategie aus Blackjack: Double Down!
Als Reaktion entwickeln Betroffene einen Notfallplan – und setzen auf die Multi-CloudJa klar, denn zurück geht ja nicht. Da würden ja alles sehen, was wir für inkompetente Flachpfeifen-Quacksalber sind. Fehler eingestehen? Niemals!!
Außerdem haben wir ja unser Personal ausgedünnt, und wenn wir die jetzt zurück einstellen wollen würden, dann würden die ja marktübliche Gehälter fordern. Das können wir uns gar nicht leisten!1!!
Kurze Frage am Rande: Zahlt sich eigentlich eure Blockchain-Strategie schon aus? Wie hoch ist denn der ROI auf eure "KI"-Strategie so?
Nee, lasst euch nicht aufhalten. Macht lieber weiter wie bisher und hört erst auf mich, wenn das Kind im Brunnen ist.
Update: Eines Tages wird jemandem auffallen, dass es gar keine Inflation gab, sondern dass die Aufpreise einfach nur daher kamen, weil irgendwer ja den Cloud-Aufpreis zahlen musste. Und das werden ganz sicher nicht die sein, die ihn zu verantworten hatten. Logisch.
Umgerechnet fünf Fusionskraftwerke. Aber hey, "KI" braucht ja keinen Strom, gell?
Update: Falls ihr euch übrigens gefragt habt, wo eigentlich das Geld für diese Geldverbrennungsaktion herkommen soll: Das wird bei Internet-Infrastruktur-Programmen wie NGI eingespart, die damit OpenSSL-Audits und so gemacht hatten. Das war eines der ganz wenigen EU-Förderprogramme, das tatsächlich Ergebnisse vorzuweisen hat. Liegt möglicherweise daran, dass das von den Niederländern vorangetrieben wurde, nicht von Deutschland. Bei uns wäre die Kohle bei Fraunhofer versickert, ohne Ergebnisse oberhalb der Nachweisgrenze zu zeitigen.
Update: Man könnte fast vermuten, dass Flinten-Uschi NGI absichtlich weghaben will, weil der Kontrast zu ihren eigenen "Projekten" die Korruption der CDU so deutlich zeigt. Den Präzedenzfall konnte die CDU nicht dulden, dass jemand Fördermittel nimmt und nicht bloß unter seinen Wahlspender verteilt.
Damit war zu rechnen. Das könnte spannend werden.
OpenAI soll etwa sieben Milliarden US-Dollar für die Entwicklung neuer KI-Modelle ausgeben. 1,5 Milliarden US-Dollar bezahlen sie den Mitarbeitern. Laut einem Bericht von The Information kommen aber offensichtlich nur etwa 2,5 Milliarden US-Dollar rein. Das Magazin beruft sich auf Informanten und nicht veröffentlichte Finanzberichte, die nahelegen, OpenAI werde in den kommenden zwölf Monaten kein Geld mehr zur Verfügung haben. Sie schreiben von fünf Milliarden US-Dollar Verlusten in diesem Jahr.7 + 1,5 - 2,5 sind 6 Milliarden Miese, nicht 5.
Die 1,5 Milliarden für Gehälter fand ich ein bisschen viel, aber angeblich hat OpenAI 2500 Angestellte. Das läppert sich.
Meldung 1: Milliardenverlust für die Deutsche Bahn.
Meldung 2: Spielemarkt: Deutsche geben fast 3 Milliarden Euro für Handyspiele aus.
Are you thinking what I'm thinking?
Das feier ich ja gerade. Was für ein großartiger Move. Auf der einen Seite sagen sie ihren Kunden: Bei uns ist das nicht wie bei Intel. Wir shippen lieber funktionierende Produkte und testen vorher.
Auf der anderen Seite liegt die Vermutung nahe, dass die unspezifizierten Qualitätsprobleme nicht bei ihnen sondern bei Intel liegen :-)
Könnte sein, dass AMD gesehen hat, dass Intel unlauter die Benchmarks frisieren will, und lässt die jetzt mal so richtig auflaufen.
Oder die haben wirklich unspezifizierte Qualitätsprobleme. Kann auch sein.
Lasst mich mal kurz die ketzerische Frage stellen, warum die alle betroffen waren!
Ja warum denn, lieber Fefe? Na weil das fucking BSI denen vorgeschrieben hat, sie müssen ihre EDV "nach Stand der Technik" mit Schlangenöl tapezieren!
Und jetzt passiert völlig überraschend, was schon immer klar war: Das Zeug ist Software und hat auch Fehler.
Eigentlich sollte das BSI mal sich selbst in die Pflicht nehmen, wieso sie den Firmen gesagt hat, dass sie diesen Mist brauchen. Glaubt mal gar nicht, dass Carbon Black irgendwie besser ist, oder wie die Konkurrenten alle heißen. Das ist alles derselbe Klärschlamm, der da die Getriebe mit Sand füllt.
Also, liebes BSI. Ich finde auch, dass Microsoft und Crowdstrike in die Pflicht genommen werden sollten. Microsoft sollte endlich für ihre Ranzsoftware haften, und Crowdstrike sollte für die Schäden aufkommen, inklusive der Gehälter der IT-Leute, die hinter ihnen herräumen mussten. Das soll ruhig mehrere Milliarden kosten, Crowdstrike hat eine unfassbar große Marktkapitalisierung.
Aber stoppt da nicht. Nehmt als nächstes das BSI in die Pflicht. Es soll bitte von diesem pseudowissenschaftlichen Esoterik-Scheiß weg und evidenzbasiert arbeiten. Angriffsoberfläche kann man messen, und man kann sie minimieren. Potentielle Auswirkung von Sicherheitslücken kann man quantifizieren und das Risiko minimieren. Aber DAS schlägt das BSI irgendwie nie vor. Sie faseln lieber was von "secure by default" (was völlig sinnentleert ist und nichts konkretes bedeutet) und empfehlen flächendeckende Schlangenöl-Kontamination.
Und wenn dann was passiert, dann zeigen sie auf Microsoft und Crowdstrike.
Wie kommen solche Dinge zustande? Die hatten doch Code Audits von ihrer Software!
Das kann ich aufklären. Bei Code Audits sagen die Auftraggeber, was "in scope" ist und was nicht. Typischerweise sind Config-Dateien nicht in Scope, weil Crowdstrike findet, die können ja schließlich nur von uns kommen, und der Übertragungsweg ist kryptografisch gesichert, also kann da nichts passieren.
Dazu kommen so Überlegungen der Form (je nach Mächtigkeit der Konfigurationsmechanismen): Wenn der Angreifer DA Dinge zu unseren Kunden pushen kann, dann ist eh alles verloren!1!!
Am Anfang meiner Karriere habe ich mich über diesen Scope-Scheiß noch endlos aufgeregt und da gegen Windmühlen gekämpft. Ich habe z.B. wochenlang mit Microsoft verhandelt, dass USB eine Security Boundary ist, d.h. etwas, wo ein erfolgreicher Angriff schlecht ist und verhindert werden sollte. Microsoft fand damals, USB sei ein physischer Angriffsvektor und die seien eh nicht zu verhindern, da könne ja auch jemand mit einem Hammer kommen und das Gerät kaputthauen. Also war USB jahrelang kein Angriffsvektor, und damit auch nicht die Filesysteme und die Autorun-Dateien darauf. Das hat sich erst geändert, als das USB-Forum "wireless USB" standardisierte, also das über Funk erreichbar war. Das kam nie weit, aber hat fundamental Tore aufgemacht bei Microsoft und ich vermute auch bei anderen Betriebssystemherstellern.
Ich habe bei Microsoft auch mal den SMB-Code auditiert, und habe dann einen Riesenschreck gekriegt, als die ETERNALBLUE von der NSA bekannt wurde. Hatte ich das übersehen? Nein, hatte ich nicht. Das Scope endete ca 3cm links davon. Ich sollte SMB angucken, und ETERNALBLUE war ein RPC über eine Named Pipe von SMB. Andere Arbeitsgruppe, out of scope.
Wenn ihr also mal einen Code Audit oder Pentest beauftragt, tut mir einen Gefallen und erzählt den Auditoren nicht, was in Scope ist und was nicht. Ihr habt die eingeladen und beauftragt, weil ihr glaubt, dass die wissen, wo die Bugs sind. Dan lasst sich auch dort gucken, um Himmels willen!
We explore the cost and security of reCAPTCHAv2 and conclude that it has an immense cost and no security. Overall, we believe that this study’s results prompt a natural conclusion: reCAPTCHAv2 and similar reCAPTCHA technology should be deprecated.Ja NO SHIT, Sherlock! Hätte uns doch nur jemand rechtzeitig gewarnt!1!!
Könnt ihr mal gucken, ob in irgendeinem davon die IPs von Crowdstrike gelistet sind?
Die waren ja wohl der größte Threat der letzten Jahre bis Jahrzehnte!
Und? Ist nicht auf der Liste? Na sowas!
Was sagt euch das über den Sinn dieser Threat-Intelligence-Dienste?
77% Of Employees Report AI Has Increased Workloads And Hampered Productivity, Study Finds.
Despite 96% of C-suite executives expecting AI to boost productivity, the study reveals that, 77% of employees using AI say it has added to their workload and created challenges in achieving the expected productivity gains. Not only is AI increasing the workloads of full-time employees, it’s hampering productivity and contributing to employee burnout.To add insult to injury, nearly half (47%) of employees using AI say they don’t know how to achieve the expected productivity gains their employers expect, and 40% feel their company is asking too much of them when it comes to AI. Workers are feeling the strain from rising productivity demands, with one in three full-time employees saying they will likely quit their jobs in the next six months due to feeling overworked and burnt out. The majority of global C-suite leaders (81%) acknowledge they have increased demands on their workers in the past year. Consequently, 71% of full-time employees are burned out, and 65% report struggling with their employer’s demands on their productivity.
Ja Scheiße, Bernd! Hätte uns das doch nur vorher jemand gesagt!Aber wer konnte auch ahnen, dass der nächste Bullshit-Hype, der durchs Dorf getrieben wird, schon wieder ein Vehikel für Scammer sein würde, und am Ende vor allem negative Auswirkungen auf die Mitarbeiter und die Umwelt haben würde!?
Und tatsächlich. Ich habe da temporär ein paar Linux-Kernels runtergeschmissen und dann lief das Update durch.
Ich sage euch: Diagnostik im Fehlerfall. So wichtig!
Immer dieser fiese antisemitische Judenhass, der die ganzen rassistischen Stereotype bedient!!1!
Nein. Tut es leider nicht. Weak Symbols sind etwas anderes und haben nichts mit der Selektion zu tun, aus welcher Library ein Objekt kommt, sondern ob überhaupt ein Objekt für ein Symbol gesucht wird.
Der Mechanismus könnte zur Not auch hier adaptiert werden, das funktioniert dann ungefähr so:
In der libc hast du Funktion fopen, die ruft fopen_init auf, was weak definiert ist.
In libpthread hast du Funktion fopen_init nicht weak, aber die wird dann nicht reingezogen, außer sie ist in einem Objekt, das aus anderen Gründen eh reingezogen wird. Ich könnte das also in dasselbe Objekt tun, in dem auch pthread_create drin ist. Wenn dann jemand einen Thread erzeugt, dann linkt er auch das fopen_init aus libpthread rein, und das aus libc wird nicht mehr angesprungen.
Warum mache ich das also nicht einfach so?
Weil dietlibc angetreten ist, um Bloat zu sparen. Wenn ich das so mache, dann habe ich erstens in dem Object aus libc immer noch die fopen_init-Funktion drin, die jetzt keiner mehr aufruft. In dem Fall vielleicht nicht so schlimm, weil die Funktion aus libpthread die über einen Alias aufrufen könnte.
Aber anders herum: Wenn jemand pthread_create macht aber nie fopen aufrufen wollte, hat er dann trotzdem fopen_init drin. Das ist genau das Gegenteil dessen, was dietlibc erreichen will. Ich will gerne jedes Byte nicht im Binary drinnen haben, das nicht gebraucht wird, und suche daher die ganze Zeit nach Linker-Tricks, mit denen ich das erreichen kann.
dietlibc verwendet im Moment Weak Symbols, ihr könnt ja mal nach weak greppen im Source Tree. Das kann man schon einsetzen, aber man muss dann vorsichtig und mit Bedacht vorgehen, sonst ist man in Nullkommanichts genau so bloatig wie glibc.
Wenn also der Microcode die Performance senkt, wovon ich mal ausgehen würde, dann haben die Zen 5 Vergleichsbenchmarks alle noch die besseren Zahlen von dem aktuellen Microcode drin.
Ich würde mich übrigens auch wundern, wenn Intel das nicht absichtlich gemacht hat, dass die CPUs zu eine so hohe Spannung ziehen. Das ist leider bei Intel und AMD schon lange üblich. Die Technologie wäre so weit, aber dann wären halt soundsoviel Prozent der produzierten CPUs direkt Ausschuss, weil die durch Produktionsmängel nicht so effizient sind.
Weil die Chiphersteller alle noch keinen Dollar gesehen aben, den sie nicht als Profit einsacken wollten, haben wir jetzt alle völlig sinnlos heizende CPUs in unseren Kisten drin.
Mein aktueller Arbeitslaptop ist ein Asus Zephyrus G14 von 2022, den ich mir vor allem deshalb gekauft habe, weil es hieß, AMD habe jetzt raus, wie man sparsame und kühl bleibende CPUs baut, und bei Asus gäbe es ja auch immer Undervolting-Tools. Tatsächlich ist in diesem Laptop von Sparsamkeit nichts zu sehen. Unter 20W habe ich das Gerät noch nicht gekriegt im Idle, und das Kühlsystem ist so unterdimensioniert, dass ich zum Zocken CPU Turbo Boost deaktiviert habe, weil das Teil sonst nach ner Weile überhitzt und Not-Aus macht. Für die Zephyrus-Geräte gibt es in der Tat Undervolting-Tools, aber (als einziges in der Baureihe?) nicht für mein Gerät.
Es ist echt zum Mäusemelken.
Ein ganz anderes Bild liefert mein Reiselaptop, auch AMD, ein Framework 14". Der ist ohne großes Zutun im Idle unter 5W. So hatte ich mir das vorgestellt.
Leider hat Windows offenbar irgendwann von der Anforderungsliste genommen, dass Laptops Suspend können sollen. Es reicht, wenn sie dieses neue Pseudo-Suspend haben, wo das Gerät dann schneller aufwacht, aber nie wirklich suspendiert war. Ich persönlich scheiße ja auf Windows und kann jetzt unter Linux nicht mehr suspend machen und der Akku hält dann über 24h wie bei meinem Reiselaptop davor.
Framework hat inzwischen eine neue BIOS-Version herausgegeben, aber wenn ich die einspiele, kommt das Gerät nicht wieder hoch. Immerhin erkennt es das und bootet nach dem Hart-Not-Aus dann wieder das alte BIOS.
Das muss alles unglaublich schwierig sein, den Leuten das zu verkaufen, was sie gerne haben wollen.
Das Statement sagt im Wesentlichen: Wir machen einen Microcode-Fix.
Vorher ging die Theorie um, dass ihnen die Vias wegkorrodieren (Vias sind Verbindungen innerhalb des Chips; wenn die wegkorridieren, kannst du nur wegschmeißen und neu kaufen). Das bestreitet Intel jetzt explizit, aaaaaaber einer der Kommentatoren darunter zitiert einen Intel-Techie:
A member of Intel staff has commented on this on Reddit. What they said was "...We can confirm that the via Oxidation manufacturing issue affected some early Intel Core 13th Gen desktop processors. However, the issue was root caused and addressed with manufacturing improvements and screens in 2023. We have also looked at it from the instability reports on Intel Core 13th Gen desktop processors and the analysis to-date has determined that only a small number of instability reports can be connected to the manufacturing issue".Das möchte ich hier mal kommentieren. Intel gibt also zu, dass ihnen ihre Vias wegkorrodiert sind, aber sie haben nicht etwa einen Rückruf gemacht oder auch nur ihre Kunden informiert. Sie haben einfach behauptet, das beträfe nur wenige Kunden und haben geschwiegen und gehofft, dass die man die dann halt im Support dazu bringen kann, neue CPUs zu kaufen.Das, meine Damen und Herren, ist die Rechnung dafür, dass wir Intel mit ihrem Meltdown- und Spectre-Scheiß haben durchkommen lassen. Die Welt war betroffen und alle haben sich gemeinsam darauf geeinigt, einfach weiter die alten CPUs zu benutzen, und irgendwelche halbseidenen Mitigations in Mikrocode oder sogar im Kernel von Linux oder Windows zu machen.
Das hat dann zweistellig Prozent Performance gekostet. Ich verweise an der Stelle immer gerne darauf, wie viel Geld Intel fordert, wenn man einen Xeon mit 10% mehr Performance kaufen will! Das sind betäubende Summen! Und die ganze Welt hat einfach den Aufpreis bezahlt und dann die bezahlte Performance verloren und Intel musste überhaupt nichts zahlen.
Das war ein Kardinalfehler. Damit haben wir Intel signalisiert: Wisst ihr was? Es ist egal, wie kaputt eure Prozessoren sind. Ihr lallt dann einfach was von Microcode-Update.
Genau das passiert jetzt. Würde mich nicht mal wundern, wenn das eine komplette Nebelkerze ist mit dem Microcode.
Warum sage ich das? Weil Intel ihre Kunden die ganze Zeit nach Strich und Faden belügt.
Alle bisherigen Aussagen von Intel waren dreiste Lügen, um ihre Profite auf Kosten der Kunden zu maximieren. Ich sehe keinen Grund, wieso die aktuelle Äußerung glaubwürdiger sein sollte als die davor.
Wir leben jetzt in einer Welt der Krisenkommunikation. Alle lügen und betrügen nur noch, dass die Schwarte kracht. Die nächste Äußerung wird dann sein: Ja gut aber das betraf ja nur die bis 2024 verkauften CPUs! In der nächsten Generation haben wir das gefixt!1!!
Ich persönlich glaube Intel gar nichts mehr, und ihr solltet ihnen auch nichts mehr glauben. Wenn es nach mir ginge, würden die Verbraucherschützer und/oder Aufsichtsbehörden da ein paar Milliarden Strafe extrahieren und unter den geprellten Kunden verteilen.
dietlibc hat eine libc.a und eine libpthread.a. Wenn man mit -pthread baut, wird auch libpthread.a reingelinkt.
Mehrere Symbole gibt es sowohl in libc als auch in libpthread, z.B. wenn man fputc aufruft, um ein Zeichen in ein FILE* zu schreiben. Die libc-Variante schreibt halt ein Zeichen, und die libpthread-Variante holt sich einen Mutex, schreibt dann das Zeichen, und lässt den Mutex dann wieder gehen.
Für die Korrektheit des Programms ist es also wichtig, dass die libpthread-Variante gewinnt.
Das ist relativ einfach:
$ gcc -o main main.c -lpthread -lcOK, nächstes Problem: fopen. fopen ruft eine Init-Funktion auf, die ein FILE* alloziert und initialisiert. Die Variante der Init-Funktion in libpthread alloziert mehr Platz für den Mutex und initialisiert den. So und jetzt kommt das Problem: Hier gewinnt bei obigem gcc-Aufruf nicht etwa die Variante aus libpthread sondern die aus libc.
Ich habe mal ein Ticket aufgemacht bei GNU binutils (wo GNU ld herkommt), und die um Rat gebeten. Die meinten, ich soll -lc -lpthread machen.
Ich habe also einen kleinen Demonstrator gebaut, bei dem das auch nicht hilft. Schlimmer noch: Es gibt ja noch andere Linker als GNU ld. Es gibt noch GNU gold (auch aus binutils), lld (von LLVM) und mold (separates Projekt von dem Autor von lld). ld und gold sind sich einig, und lld und mold sind sich in die Gegenrichtung einig.
Das ist jetzt ein ziemlich riesiges Problem für mich, denn wenn ich nicht dafür sorgen kann, dass die Init-Funktion aus libpthread immer gewinnt, dann kriege ich Speicherkorruption, weil die aus libc zu wenig alloziert, aber dann jemand auf dem nicht mitallozierten Mutex herumpolkt. Und das Programm ist natürlich auch kaputt dann.
Falls ihr mal gucken wollt: Hier ist das binutils-Ticket. Ich bin mal sehr gespannt, was die Nerds da jetzt vorschlagen.