/fefe/ – Fefes Kommentarfunktion

Biden wirft hin [0].

[0] https://www.tagesschau.de/eilmeldung/biden-verzicht-kandidatur-100.html

https://blog.fefe.de/?ts=98639216

Ein Leser hatte den sachdienlichen Hinweis, dass das BIOS-Update auf dem Framework-Laptop vielleicht deswegen failed, weil auf der EFI-Partition nicht genug Platz ist.

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!

https://blog.fefe.de/?ts=985e2484

Gleich mehrere Leser weisen darauf hin, dass Intel das Problem, das sie jetzt mit magischem Microcode lösen wollen, so lange ausgesessen und hinausgezögert haben, dass der magische Microcode erst nach den Benchmarks der Fachpresse für Zen 5 stattfinden.

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.

https://blog.fefe.de/?ts=9861270f

Mehrere Leser vermuteten, dass ich bei meinem dietlibc-Linker-Problem einfach die libc-Version als Weak Symbol deklarieren muss, dann geht das Problem weg.

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.

https://blog.fefe.de/?ts=9861291a

Zu der Intel-Situation gibt es jetzt ein Update. Das ist soweit explodiert, dass Intel nicht länger "gehen Sie weiter, gibt nichts zu sehen hier" machen konnte, und sie haben ein Statement publiziert [0].

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.

* Problem? Welches Problem? Gibt kein Problem!
* Das sind bestimmt die Übertakter. Das haben wir denen ja gleich gesagt!
* Das Übertakten, das waren die fiesen Mainboardhersteller!
* (Jetzt sind wir bei) Wir fixen das kurz im Mikrocode.

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.

[0] https://community.intel.com/t5/Processors/July-2024-Update-on-Instability-Reports-on-Intel-Core-13th-and/m-p/1617113#M74792

https://blog.fefe.de/?ts=98614804

Wie schlimm ist die Lage? So schlimm [0]:

>Immer mehr Cybercrime - und immer öfter mit KI

Nanu? Wo kommt den mein plötzliches Kopfweh her?

[0] https://www.tagesschau.de/ausland/europa/europol-cybercrime-100.html

https://blog.fefe.de/?ts=9860585f

Aufgepasst im Straßenverkehr! Da können einem in den USA gerade gehäuft Trump-Fans mit Ohrbandage [0] über den Weg laufen.

Soll nochmal einer sagen, die Amerikaner hätten keine Empathie und Solidarität!1!!

Oh und wo wir gerade in den USA waren: Trumps Vizepräsident Vance hat seinen Venmo-Account nicht auf non-public geschaltet [1]. Die Leute merken halt immer erst, dass Datenschutz eine Berechtigung hat, wenn es ihre Daten sind, die weggekommen sind.

[0] https://www.bbc.com/news/videos/cldy39vpv4qo
[1] https://www.wired.com/story/jd-vance-venmo/

https://blog.fefe.de/?ts=9867b37d

Wie kommt das eigentlich, dass Ransomware mit ihrer Einmal-Zahlung negativ gesehen wird aber Schlangenöl mit ihren Abomodellen als positiv?

Das ist doch dasselbe Geschäftsmodell! "Schöne EDV-Infrastruktur haben Sie da! Wäre ja schade, wenn der etwas zustöße!"

Gut, außer dass die Schlangenölindustrie euch Software gibt, die eure Angriffsoberfläche maximiert und damit zukünftige Angriffe ermöglicht, wo sie vorher nicht möglich waren. Nur mit Schlangenöl kannst du über ein Wordperfect-File gehackt werden, ohne Wordperfect einzusetzen!

Ich frage mich ja manchmal, ob die Schlangenölbranche der Ransomwarebranche Kick-Backs zahlt. Oder vielleicht andersherum?

https://blog.fefe.de/?ts=986510cd

So langsam gucken Leute [0] nach den ökonomischen Vorteilen von "KI". Und finden keine.

Ach. Ach was. Na das ist ja bemerkenswert! Hätte uns das nur vorher jemand sagen können!

Immerhin sind sie dabei auf einen interessanten Gedankengang gekommen, den ich hier mal wiedergeben will.

Die "Performance" von "KI" hängt im Wesentlichen davon ab, wie viel Trainingsdaten man hatte. Tätigkeiten, bei denen es Trainingsdaten wie Sand am Meer gibt, sind aber schon fast per Definition nicht wertvolle Bausteine der Wertschöpfungskette, sondern halt allerweltsscheiß.

[0] https://www.theintrinsicperspective.com/p/all-the-existential-risk-none-of

https://blog.fefe.de/?ts=986071d7

Wisst ihr, wer an dem Crowdstrike-Desaster eigentlich Schuld war?

Die EU (findet Microsoft) [0].

>Microsoft könne seine Produkte nicht im gleichen Maße abschirmen wie Apple, sagte ein Firmensprecher dem Wall Street Journal (Paywall). Nach einer Beschwerde habe Microsoft im Jahr 2009 eine Vereinbarung mit der EU getroffen, wonach Hersteller von Sicherheitssoftware den gleichen Zugang wie Microsoft zu Windows erhalten müssen.

Das ist ja wohl er absolute Oberlacher! Die Nummer 1 Quelle von Sicherheitsproblemen, um die sich eine ganze Industrie gegründet hat, um deren Kunden vor deren Ramschsicherheit zu beschützen, DIE haben jetzt die Stirn und sagen, SIE hätten UNS nicht vor dem Schlangenöl-Ramsch beschützen können wegen der EU!

Alter, den Schlangenöl-Scheiß GÄBE es gar nicht, wenn ihr ordentliche Produkte bauen würdet!

[0] https://www.golem.de/news/kernel-zugang-microsoft-gibt-eu-mitschuld-am-crowdstrike-debakel-2407-187296.html

https://blog.fefe.de/?ts=98609704