The thing I haven't seen anyone point out is that the diff for the fix is literally just +8 chars. Any of the kernel engineers Canonical has on their payroll can review it to ensure that it logically does not introduce new failure modes (as can their agents), and it is trivial to backport all the way to the 4.4 kernel. Does Ubuntu really not have an urgent CVE release workflow figured out yet? Surely this isn't the first time something in the base system needed a patch?
I also want to point out that the very complicated instructions Canonical has supplied in the linked post will likely break zfs-dkms, "native" upstream support for which is the only reason a lot of people are using Ubuntu instead of Debian; the instructions would have you enable -proposed just for main, but zfs lives in universe and the version of zfs you have installed will probably not work with the prerelease kernel in -proposed.
> Just like Intel not shipping ECC for client SKUs when DDR5 design makes it really necessary
The ECC in DDR5 is on-die ECC and that's not "real" ECC, it's what DDR5 needs to not fail. Side-band ECC is the standard method, employing extra memory chips and 72bit memory. OEMs mix these in the marketing materials to fool the users into thinking they buy the better option.
Yes, here I'm referring to actual ECC, not the on-die ECC. All DDR5 chips have on-die ECC as a prerequisite just to reach error levels comparable to standard non-ECC DDR4, but from a hardware analysis perspective, even with the on-die ECC, DDR5 still needs ECC more than DDR4 (which already needed it).
Off topic but doesn't intel do something weird where some i3 chips can use ecc but not i5 or i7 until you get into server chips? I remember seeing that when plotting nas builds a couple years ago. Should have pounced on actually building it then....
Yes, I liked using them for NAS builds. Great for ZFS machines.
Intel is weird with their stuff like that, I wrote about how they introduced and then dropped an SHA instruction that could be used to optimize hashing (useful for things like block checksum hashes on storage servers) before: https://neosmart.net/blog/will-amds-ryzen-finally-bring-sha-...
Read this last night. I was completely thrown off when I read this line:
> We expected the engine to return an error for any prompt it could not process, and our long-context tests returned successful responses, so we did not believe this to be an issue
Surely “we expected and error but got a successful response” merits investigating rather than moving on?
My interest was piqued and I tried to read on… Holy mother of all that is slop, I couldn’t even get to the text because of all the interactive slop I had to scroll through.
This is incorrect. You cannot identify the presence of text watermarks if you do not have access to the models so that you can spot where expected tokens diverge from actual tokens based off the weights. That does not preclude Pangram from being able to reliably identify LLM-generated text from models whose outputs they’ve trained their own detection model upon.
e.g.: "You must not use OpenAI models or their outputs to generate, prepare, select, or supply training material or signals for models that are intended as alternatives to or substitutes for OpenAI models or services".
Of course they disallow it. In saying they’re not thick enough to not realize how it looks to publicize their anti-distillation efforts. You must not have seen the tirades and screeds Anthropic posts in comparison, then.
People in HN live in a bubble. Plenty of real world use cannot use subscription plans (not even talking about enterprise agentic use) and is absolutely at the mercy of the cost per task metric.
We agonize over cost per task to the extreme for services/functionality built atop of APIs and can absolutely guarantee you that it is the real world metric that counts most right after “is the model good enough for the task at hand,” and furthermore that, yes, in fact, it is quite often that we see certain models/providers easily using 3x or more tokens on average for the same tasks (or even the exact same task) than a supposedly similarly matched model from another provider. Once you become intimately familiar with the thinking traces from specific models, you can preempt this to some extent with manipulations to the system prompt (essentially heading off entire thinking branches) but the nuking of reasoning traces in the name of preventing against distillation attacks has made this harder.
Pretty sure my Samsung plasma TV from 2011 is safe. It was all downhill from there, just competing over which display looks better with its saturation and brightness boosted all the way up with the floor models all next to each other.
Our own open-source, cross-platform, multi-language, cross-framework SecureStore is an embedded secrets store (sort of like SQLite) that lets you version your secrets alongside your code in git (and deploy updates via CI, accordingly), only securely.
Available for rust, golang, php, python, js/ts (node, bun, or in-browser), C#/.NET, PowerShell, bash, and more. Open Source (MIT), not vibe coded, and lovingly maintained for a decade.
Encrypted secrets in Git with a tool written in Rust under a fully permissive license is the right way to do it. Encrypted copies of secrets in environment variables is okay too, as long as they are encrypted.
The somewhat widely known Mozilla SOPS is a tool in the same broad category.
I hadn't seen securestore-rs before. Thank you for sharing this.
I also want to point out that the very complicated instructions Canonical has supplied in the linked post will likely break zfs-dkms, "native" upstream support for which is the only reason a lot of people are using Ubuntu instead of Debian; the instructions would have you enable -proposed just for main, but zfs lives in universe and the version of zfs you have installed will probably not work with the prerelease kernel in -proposed.
reply