what possible reading of "I made the call to get these out early when exploits hit in the wild" contorts into "these exploits hit in the wild after i made the call to get these out early" with flipped causality?
sure, i'm happy to recant my rather tepid defense of chainguard in the case that what was said upthread was a blatant fabrication. i'm even open to being convinced that it was.
as it stands though, what i replied to wasn't a useful addition to the discussion. it could easily become so by either being made contingent upon the possibility of that being a lie, or being bundled with an assertion like yours that chainguard is not to be taken at their word. doing neither and simply responding as if a causally opposite statement had been made is just a non sequitur.
I don't think we have to not-believe Chainguard. To me, the problem is more that "in the wild" is a somewhat airy statement that can only be taken to strictly mean that one found it somewhere on a computer that is connected to other computers. This is almost a non-statement, as airgaps are the exception rather than the rule.
Even then, it implies more than it says. It's often used to suggest the exploit came from a remote system one does not directly control and was deployed, successfully, against another system one does not directly control. But even that does not necessarily have to be true, as people can use it, without any bad faith and not trying to twist the phrase, in cases where only one of those conditions hold, e.g. against a system one does directly control where the exploit attempt was unsuccessful.
Not a non sequitur - No one should be taken at their word. Not them, not me, and not you. This is the security world. Nobody is trusted altogether.
Breaching an embargo, makes reverse engineering easier. We don't need to analyse motives or pontificate. Disrupting the supply chain... Disrupts the supply chain.
I can affirm that I'm seeing vibe-coded dashboards designed to ingest and run on top of Excel spreadsheets full of macros, VBA, and "Excel Scripts" interlinks.
I... Cannot call this a step up. They're expanding, not replacing.
Sure, but at least Claude is available to fix the slop instead of needing to depend on people who have gone away a long time ago. ultimately if it's valuable they can invest in someone to come in and build things the right way.
And neither the original example is "Rust compiles extremely slowly" (it does compile slowly), it's another example of "vibecoded software is of poor quality".
This is a tough sell. Yes, those languages (with some small nits about Ada) can accomplish the same safety guarantees, but they're nowhere performant enough in practice or memory efficient compared to Rust. A big part of the original mission of Rust was safety without performance compromises which for the most part its accomplished, though the price is paid during compilation. Further, their runtimes and limitations make it difficult to work directly with operating systems or low level system hardware. And I say this as someone who has written Haskell code in production.
That said, I would love for Idris to continue to develop. I'm a big believer in dependently typed languages and would actually improve correctness, assuming there are reasonable ways to avoid the other trappings of the language.
Espressif did finally added back an FPU to the ESP32-S3. (The original ESP32 also has one).
They tried, with the H- and P- lines to effectively make it a paid extra over the regular productions. At least they accepted when the market disagreed.
reply