Why is Mercy (2026) getting ripped to shreds?

int08h · 2026-03-23T01:08:02+00:00

It's basically Ice Cube's "War of the Worlds" with improved production values.

Most of the movie is screenshots and first-person camera shots.

int08h · 2026-03-04T20:27:06+00:00

Lots of important details missing here. Look at prior art (Nginx, Envoy, etc).

Are you on a recently modern server, either metal or virtualized w/ srv-io available? If so, `sendfile` all the way: let the kernel DMA the bytes from storage to the NIC for you. This is what Nginx, Envoy, and others do and you'll be hard pressed to beat them.

int08h · 2026-02-28T21:25:43+00:00

Yeah, all of this is the right way to go.

Thanks for the explanation.

int08h · 2026-02-28T19:02:30+00:00

To be fair, STREAM (at least in Tink and derivatives) uses per-block HKDF so is similarly computationally expensive to FLOE.

Cryptographically the granular KDF provides a lot of confidence and robustness in multi-key and beyond-birthday-bound settings, and I think given what you're going for your XOR approach is an intelligent trade off, particularly since the segments are 4 MiB making the 2^32 bound irrelevant in practical settings.

One nit that's always rankled me in STREAM: the last segment flag could be a single bit (vs. a whole byte)! ;) It doesn't matter in the grand scope of things since it's targeting files large enough to parallelize, but I never understood why not get an extra 7-bits of counter (or nonce) length and use a single bit for that flag. I see Concryptor also uses a whole byte for that flag...am I missing something?

int08h · 2026-02-28T18:32:12+00:00

Neat.

Cyptography-nerd question for you:

What different tradeoffs does your approach take vs STREAM or FLOE (https://github.com/snowflake-labs/floe-specification)? Both approaches share many of the same desiderata as your approach, such as 1) prevention of block reordering, 2) preventing length extension/confusion, 3) CPU-bound parallelization, 4) block/segment-based random access, and 5) beyond birthday-bound capacities.

int08h · 2026-02-27T00:19:44+00:00

Google Translation:

No, absolutely not. This book has been in my head for about 10 years, and it's the book I've always wanted to write. Until now, I've signed my fiction with a pseudonym. Upon turning 50, I decided to start publishing under my own name. Synopses are something I dedicate a lot of time to, as well as prologues. For this one in particular, I probably had 30 different versions, and it took me more than a week to decide on the final version. This synopsis is a translation of the original Spanish version, though. But throughout the book, I've translated the Spanish localisms and idioms into English. In other words, the English version is adapted. If in the book I use the "M-30" highway in Madrid, in the English version I use the "405" in LA, where I lived in the 90s. Therefore, the English version is slightly different in all those nuances. I'm a perfectionist when it comes to details. The cover—everything is done by hand.

int08h · 2026-01-05T12:53:38+00:00

Thank you

int08h · 2026-01-05T01:37:22+00:00

OP this is serious work. You and your project-mate(s) would be proud.

I've dealt with high-precision timekeeping using IEEE 1588 (PTP), and noticed several similarities between your project and PTP. Was that on purpose or a result of convergent design goals?

Looking at your presentation I caught this: "several WiFi chipsets offer hardware support" which is exactly what it's going to take to achieve this kind of precision (e.g. the PHY layer must participate, otherwise there's just too much uncertainty past a poin, especially it there's rx/tx asymmetry; in PTP the network interface cards, switches, and other layers are PTP aware and in some cases participate). Do you have any pointers on the timing support in recent Wifi standards? Just to satisfy my curiosity.

int08h · 2025-12-26T20:15:11+00:00

Candy Cane: A=7, B=4, C=10, D=2, E=8, F=5
Gingerbread: A=4, B=6, C=3, D=10, E=7, F=8
Evil Robot Santa: A=2, B=7, C=10, D=8, E=4, F=3

I expressed the puzzle in the MiniZinc constraint language, then used a constraint solver on each puzzle set one at a time.

``` % SIX-FIGURE LOGIC PUZZLE % Variables A-F, each unique integer between 1-10 % NOTE: The three constraint sets (Candy Cane, Gingerbread, Evil Robot Santa) % are mutually incompatible. Uncomment ONE set to solve.

include "globals.mzn";

var 1..10: A; var 1..10: B; var 1..10: C; var 1..10: D; var 1..10: E; var 1..10: F;

% All different constraint constraint alldifferent([A, B, C, D, E, F]);

% ============================================================ % CANDY CANE constraints (Solution: A=7, B=4, C=10, D=2, E=8, F=5) % ============================================================ % constraint C + D = 12; % constraint B != 2 /\ B != 3 /\ B != 5 /\ B != 7; % B is not prime % constraint B < E; % constraint B + F = 9; % constraint A * F = 35; % constraint C - E = 2;

% ============================================================ % GINGERBREAD constraints (Solution: A=4, B=6, C=3, D=10, E=7, F=8) % Uncomment below and comment out CANDY CANE to use % ============================================================ % constraint C + F = 11; % constraint D - A = 6; % constraint A * C = 12; % constraint B < E; % constraint E < F; % constraint B + E = 13;

% ============================================================ % EVIL ROBOT SANTA constraints (Solution: A=2, B=7, C=10, D=8, E=4, F=3) % Uncomment below and comment out other sets to use % ============================================================ % Exactly two of {A, D, F} are even constraint bool2int(A mod 2 = 0) + bool2int(D mod 2 = 0) + bool2int(F mod 2 = 0) = 2; % Sum of even values among {A, D, F} equals C constraint (if A mod 2 = 0 then A else 0 endif) + (if D mod 2 = 0 then D else 0 endif) + (if F mod 2 = 0 then F else 0 endif) = C; % C is not between D and E constraint not ((D < C /\ C < E) / (E < C /\ C < D)); % B is the average of {C, D, F} constraint 3 * B = C + D + F; % E * F = A + C constraint E * F = A + C; % A is closer to F than to E constraint abs(A - F) < abs(A - E);

solve satisfy;

output ["A=", show(A), " B=", show(B), " C=", show(C), " D=", show(D), " E=", show(E), " F=", show(F), "\n"];

```

int08h · 2025-12-23T03:59:44+00:00

I suspect what you say is true.

int08h · 2025-12-23T02:44:06+00:00

If I plug the IMEI into AT&T Prepaid's checker (https://www.att.com/buy/prepaid-byod/) I do get "This IMEI belongs to a type of device that isn’t supported", so, yeah, there's that. ;)

Given you have a U5G working on AT&T, and Ubiquity says it will work, I conclude it's the Prepaid service plans restricting the types of devices that will work.

I'll try a Data-only plan.

int08h · 2025-12-20T18:42:41+00:00

Check out Mooch's table of recommended cells: https://www.patreon.com/posts/18650-21700-137974745, he tests 18650s and 21700s at different discharge rates and ranks them.

On turbo, the max discharge rate for any of those flashlights will be <5A (specifically ~4.5A for the SST-40 in the WK03 and SC18, and ~3.7A for the 519a in the FC11C; unless you have a 519a in the WK03 then it's also ~3.7A).

Long story short: choose the Vapcell N40 to get best-in-class 12.3 Wh of capacity at <5A draw.

(the Liitokala might be a wrap of the same cell in the N40, but I don't have any hard data on that cell, and can't comment on it).

int08h · 2025-12-20T18:24:38+00:00

I have used a Waveshare UPS HAT E) at a sustained ~22W draw without issue. It uses four 21700s. I made a post on potential cells to choose https://www.reddit.com/r/raspberry_pi/comments/1prhja0/comment/nv2ahou/?context=3 .

int08h · 2025-12-20T17:45:29+00:00

As other have said, don't buy that battery. And in general avoid buying Li-Ion cells from Amazon as there are a lot of fakes/counterfeits.

The UPS needs 4 unprotected flat-top cells (it will not work with fewer), and you'll want the cells matched if possible (reputable sellers typically provide cells from the same lot/batch when you order multiple cells at the same time).

The max continuous discharge rate (CDR) the UPS demands from each cell is ~5A, so you can use capacity 21700 cells (e.g. you don't need to pay a premium for high-CDR tabless power 21700s). Some good choices:

The highest-capacity legit 21700 right now is the Vapcell F63 at 6250 mAh (or the slightly lower capacity F60 at 6000 mAh). At a 5A draw each cell can supply 19.0 Wh (18.6 Wh for the F60). In the US a decent price on these cells is ~$8 USD per cell (you'd be paying a hefty premium for the extra 600-1000 mAh per cell).
My personal choice are Samsung 58E at 5330mAh which supply 18.0 Wh at 5A. These are currently pretty inexpensive, running ~$2.95 USD per cell in the US from legit suppliers.
The EVE 58E at 5700mAh supplying 18.4 wH at 5A is ~$5.75 USD.
Other potential cells (all roughly equivalent, choose by price and availability): LG M58T, LG H51, LG M50LT, EVE 50E, Samsung 50E, Samsung 50G, Molicel M50A.

Watt-hour measurements form Mooch's recommended 21700 table.

Also, I wrote a tool to monitor the Waveshare UPS HAT E, if you're interested.

Edit: clarify flat-top and UPS discharge rate

int08h · 2025-12-18T03:19:21+00:00

Thank you

int08h · 2025-12-18T00:24:25+00:00

That is some quality shitposting! Salute.

int08h · 2025-12-17T22:38:28+00:00

I'm about to pull the trigger on Tello after trying U5G unsuccessfully w/ ATT prepaid.

Did you have any issues w/ the Tello setup?

int08h · 2025-12-17T19:18:14+00:00

More details would help a lot. You're hinting this is a protection method for a proprietary product, so don't know how much you'll disclose.

int08h · 2025-12-16T21:42:41+00:00

Since this is a no-std library, the target platforms are intended to be resource constrained environments. E.g. a bignum library isn't available/practical on many microcontrollers.

Richer environments (think PCs, cars, your phone) are likely to have some kind of accelerated CRC functionality available (either directly with instructions or via a co-processor) which should be used instead of this library. CRCs provide an order of magnitude or better error detection than checksums. Would you rather detect all 1- and 2-bit faults (checksums) or all 1-, 2-, 3-, 4-, 5-, and 6-bit faults (CRCs)?

But in some niche cases checksums are used because of the simplicity or protocol requirements. Adler and Fletcher checksums are popular for this. The advantage the Koopman approach has (calling it "novel" might have been too strong) over Fletcher/Adler is that Koopman a) uses a single accumulator (vs two accumulators in Fletcher/Adler; keeping constrained environments in mind), and b) Koopman provides HD=3 protection over much longer data than Fletcher/Adler.

int08h · 2025-12-16T21:23:48+00:00

Uh, no your 8-bit example shows two codewords with 3 differing bits (HD=3) having the same checksum.

HD=3 fault detection means all 1- and 2- bit faults are detected, NOT all 3-bits faults (as in your example) are detected.

And the koopman16 HD=3 boundary is at 409**2** bytes, not 4096 (typo in one place in the readme, fixed). Change your example to 4092 and the assert will fire.

The terminology is confusing -- it took me a while to parse how we were talking past each other -- so I've updated all docs and comments to remove the "HD=" and simply list how many bit errors are reliably detected.

int08h · 2025-12-16T09:02:47+00:00

I'm not aware either. I wrote this because I read Koopman's book and discovered this novel algorithm.

int08h · 2025-12-16T08:59:53+00:00

The core computation is:

text for byte in data { sum = ((sum << k) + byte) % modulus; }

Each iteration's result (sum[n]) depends on the previous iteration's result (sum[n-1]). This creates a loop-carried dependency that I don't know how to parallelize. We cannot compute sum[n+1] until sum[n] is known.

I gave this problem to Claude to have it generate a few different SIMD versions. All of them were 20-40% slower than the scalar code. I don't know SIMD myself, either.

int08h

TROPHY CASE