A contact just told me that my old "LLMs generate nonsense code" blog post from 2 years ago is now very outdated with GPT5 because it's so awesome and so helpful. So I asked him to give it a test for me, and asked it my favorite test question based on a use-case I had myself recently:

Without adding third-party dependencies, how can I compress a Data stream with zstd in Swift on an iPhone?

and here is the answer from ChatGPT 5: https://chatgpt.com/share/68968506-1834-8004-8390-d27f4a00f480

Very confident, very bold, even claims "Works on iOS 16+".

Problem with that: Just like any other LLM I've tested that provided similar responses, it is - excuse my language but I need to use it - absolute horseshit. No version of any Apple SDK ever supported or supports ZSTD (see https://developer.apple.com/documentation/compression/compression_algorithm for a real piece of knowledge). It was never there. Not even in private code. Not even as a mention of "things we might do in the future" on some developer event. It fundamentally does not exist. It's completely made up nonsense.

This concludes all the testing for GPT5 I have to do. If a tool is able to actively mislead me this easy, which potentially results in me wasting significant amounts of time in trying to make something work that is guaranteed to never work, it's a useless tool. I don't like collaborating with chronic liars who aren't able to openly point out knowledge gaps, so I'm also not interested in burning resources for a LLM that does the same.

I found a Linux kernel security bug (in AF_UNIX) and decided to write a kernel exploit for it that can go straight from "attacker can run arbitrary native code in a seccomp-sandboxed Chrome renderer" to kernel compromise:
https://googleprojectzero.blogspot.com/2025/08/from-chrome-renderer-code-exec-to-kernel.html

This post includes fun things like:

• a nice semi-arbitrary read primitive combined with an annoying write primitive
• slowing down usercopy without FUSE or userfaultfd
• CONFIG_RANDOMIZE_KSTACK_OFFSET as an exploitation aid
• a rarely-used kernel feature that Chrome doesn't need but is reachable in the Chrome sandbox
• sched_getcpu() usable inside Chrome renderers despite getcpu being blocked by seccomp (thanks to vDSO)

I've sent out a funding application to OSFF for Intel ME tooling.
🥳

I had started an Intel ME file system parser for recent and current versions:
https://github.com/fiedka/me_fs_rs 👈🧐

Then I realized how much overlap there is between this, MEAnalyzer, the long unmaintained me_cleaner, and other tools.

So I want to work out a library and integrate it in a release of https://fiedka.app 🐙 and offer a new CLI tool to the coreboot community. All code will be written in Rust. 🦀

https://www.osfw.foundation/funding/

YES!!!!!

I am getting the expected MR values on the RK356x now!!!

Alrighty, we're close to DRAM training!