andrewaylett

There are vendors who supply this service as a product -- Wiz, who were one of the groups to independently discover the vulnerability, is one such vendor, there are plenty of others.

I'm not overly keen on the tooling: as far as I can tell the whole industry is prone to flagging false positives as "vulnerabilities" rather than "potential vulnerabilities" and it's a bit too easy to turn those reports into a tick-box "you must update now because the tool says so". But they also do flag true vulnerabilities. And they pay for teams of security researchers to find and fix issues, not least because that's good marketing.

I'm glad Jake's run the numbers — but do make sure you validate your own use-case rather than just following them. My personal experience has been somewhat different, but also my use-case appears to be pretty different so that's OK.

That said, I last benchmarked over a year ago, maybe I should re-evaluate. My experience was that AVIF was too slow for on-the-fly encoding, while JXL was absolutely fine and JPEGLI was also pretty useful.

In my experience, it's competitive on output size but not on compression speed. If you're not compressing online then that's fine, but we're running a service that resizes and recompresses on the fly. We serve JXL if the client indicates support for it, JPEG using JXL's jpegli, WebP, or PNG, depending on various factors.

In Scotland, building regulations now mandate sealed-in lithium batteries (and interlinking) on fire alarms. Which is annoying, given most smart systems still have replaceable batteries.

Right. But riffing off a response that's a cousin of this one — what are you actually trying to achieve with your writing? And I should also note that I agree with you, in substance if not in style.

I'd suggest that Google aren't your primary audience for this kind of post: it's folk like me, who are quite keen on the idea of GrapheneOS but don't actually use it yet (I actually bought a second-hand spare phone last week with the ulterior motive of trying GrapheneOS on it, we'll see...). What do you want your average reader to think about you, from reading what you've written?

I should add that this post (that I'm directly replying to) comes across to me as very much more appropriate than the original blog post, even as it's in many ways a lot harsher. It's putting Google's behaviour in context, rather than drawing comparisons between your own abilities and their poor performance.

You don't need to drag Google down in order to look good; there are many reasons why what Google (and especially their management) have done is bad for society (and not just for you) and also many reasons why what you're doing is excellent on its own merits, not merely compared to Google.

I'll be honest: I saw the prize was a trip to SF and — while I was vanishingly unlikely to enter anyway — that was enough to kill any idea of entering. It's been over 20 years since I was last in the USA, and I have no intention of visiting again any time soon.

No, we shouldn't treat Google like an individual, because it's not. But we can (and should) be mindful of the individuals who make up the various teams within Google.

That's part of the motivation behind HugOps: the people working on fixing a thing are only rarely the people who are responsible for the system that caused the breakage.

Look to "HugOps" as inspiration: when someone else is having a bad day, offer them a hug rather than running them down.

The article uses phrases like "completely broken", "awful", and "<delay> wouldn't be a surprise". Which might be true but it's not helping.

I want one!

Should probably start slightly less ambitiously though :P.

I have fond memories of working on an embedded systems compiler that used the EDG front-end — that would be almost 20 years ago now.

We certainly held it in high regard. It was rare that a compiler bug was in their code rather than ours :).

A human can produce far more code than a human can understand, too, but pre-LLM we always viewed someone overwhelming their colleagues like that as being bad at their job.

That's "chaotic" rather than "non-deterministic".