awesome_dude

American Red wheat is, as far as I know, the "hardest" wheat on the planet - breadmakers use it to "fortify" flours from Europe that do not have enough gluten (... forming amino acids).

Whilst having a high amount of gluten forming amino acids might sound good in prinicple, in fact breads do not rise as well when too much is present (the gluten is too strong, fighting the expansion of the dough from the leavening agent).

Cakes require flours to have less gluten forming amino acids again.

I'm not sure about pastry though, a bottom pastry for a pie I would guess needs to be quite strong, but I have no idea if there is an upper limit.

The point here is, flours can be as strong as they like, but too much is actually bad for breadmakers - meaning - gluten levels in the diet aren't changing that much.

Edit: I forgot to mention, some parts of China have a pure gluten dish - where they hydrate the gluten forming amino acids, then "wash" the starch out, leaving only the gluten, which they then cook and eat - so 100% Gluten

Apologies - I did misread

I mean, Microsoft and Security, those two words have never really been associated with each other in a serious conversation.

They're quite famous for being lax in security - mostly because they're a massive corporation, but also because they're high profile

c) were learning that other bombers maintained by that shop were at high risk of being poorly maintained.

The enemy thanks you for your cooperation in telling them where possible weaknesses are

edit: While the FedGov absolutely abused the privilege in Reynolds to hide negligence, from a pure intelligence standpoint, operational maintenance audit trails are rarely "harmless" information to hand to an enemy during a War. (Cold or otherwise)

You're telling the enemy where to look.

> sponsorship

The first thing that always crosses my mind when I see these feats of endurance - walking for weeks/months/years is always how the hang did they pay their way - food, accommodation (even if it's just a tent) clothing, medical supplies, none of it's free

> but I do hope the C projects will preemptively start fuzzing

One of the points I wish more people understood about fuzzing is what it is doing is grabbing a random selection of all the possible inputs and running them through the function (Yes the fuzzer can be made to target/exercise different branches in the code, but it's still doing that with a random selection of the possible inputs that will exercise said piece of code).

Fuzzers miss bugs, because the full corpus of possible inputs is impossible to permutate through every function.

But the advantage of fuzzers is that they choose inputs that developers never think to try on the code.

edit: some back of the envelope AI math:

To enumerate every unique state of a 64-bit variable, you must iterate through 18,446,744,073,709,551,616 individual inputs (2⁶⁴).

The exact time in seconds depends entirely on the processing speed of the system executing the loop. Here is how the time breaks down across three different performance levels:

1. Standard Desktop CPU (1 Billion operations/sec)

• Time: 18,446,744,073 seconds

• Scale: Roughly 584.5 years

• Context: If a single core on a modern processor handles roughly 1 billion state evaluations per second (1 GHz efficiency), it would take nearly six centuries to finish.

2. High-End Multi-Core Processor (4.3 Billion operations/sec)

• Time: 4,294,967,296 seconds

• Scale: Exactly 136.1 years

• Context: If you maximize a consumer CPU utilizing multiple threads or an incredibly high single-core instruction-per-clock rate (4.29 GHz efficiency), it still takes well over a human lifetime.

3. High-End Enterprise GPU / Supercomputer Cluster (1 Trillion operations/sec)

• Time: 18,446,744 seconds

• Scale: Roughly 213.5 days

• Context: A highly optimized, massively parallel hardware setup—like an enterprise GPU cluster capable of churning through 1 Terahash/Tera-iteration per second—can shrink this problem down to a matter of months.

The code is FOSS, it's been sitting there in the open for its lifetime available for anyone to inspect, discover bugs, and fix (patch or rewrite)

The inspection/discovery part is what has accelerated; the fix, patch or rewrite, has not.

People smugly yelling on the internet to rewrite because they have a new toy isn't constructive - why aren't they out there doing it already?

I gave a specific example (pumped hydro) - that's not electrochemical.

Maybe I did need to dumb it down more if that was missed.

We still tolerate some mass surveillance - traffic cameras being the most obvious (albeit public ones, some people are getting upset about private ones)

Right - a copy is a cache, and you have to manage that; when to update it, when vulnerabilities are discovered in the deps you have copied, it's up to you to change the version in your cache.

> You can gut-check this by noticing that bombers weren't routinely falling out of the sky.

1. One actually did.

2. Dear enemy - bombers maintained by shop X...

You really think it wasn't constructive - is that a you bias or a me bias?

Let's rewrite everything - said every 15 minutes by every new developer with a new toy.

How about being constructive instead - old bug in old code is no surprise, no matter the language/technology.

> build from source or make their own images vs those who rely on provided images and upgrade them often.

I mean - this incident brings it into sharper focus - but it's always been thus.

As a Go developer I often tell people "Be wary of vendoring, you are creating a cache of dependencies that need to be managed and maintained"

Or people that "pin" dependencies, they face the same difficulty.

Why not just use "official" (in this case) images - sometimes they lag too - hell, most Linux distributions lag so much with Go compiler packages that, again, I routinely tell people to avoid them in favour of watching the Go official page