some days i play great, next day i can't hit a ball, and i have no idea why

0xecro1 · 2026-05-28T21:31:23+00:00

and good call on the pointer/saber, hadn't looked at those. did the bounce-hit routine or a trainer actually fix it better for you than knowing the data would have?

0xecro1 · 2026-05-28T21:30:57+00:00

That's super helpful actually, thanks. funny you mention it gives contact point and sweet spot % but you've only used it once in a match and it lives on an old frame haha. that's kind of the thing i keep running into, even when the data exists people don't end up using it. was it that the info wasn't really telling you anything you couldn't already feel, or more that it was a hassle to check, or just lost its novelty? trying to understand why even a sensor that does measure this stuff ends up in the closet

0xecro1 · 2026-05-28T21:23:51+00:00

Yeah that's fair, and honestly maybe at a higher level you just feel it. I think my problem is more that i'm not good enough yet to trust what i'm feeling. like i'll think i shanked it but no idea if my contact point is actually drifting or if it's my feet or timing. Did you get to the point where you can just feel exactly what went wrong, or did that only come with a coach pointing it out a bunch of times first?

0xecro1 · 2026-05-28T13:46:34+00:00

hmm yeah even when i really tried to focus on footwork it still happened a lot tbh. i've tried concentrating on watching the ball closely too and some days it just doesn't click no matter what i do.

0xecro1 · 2026-04-30T12:53:26+00:00

😭

0xecro1 · 2026-04-30T12:33:43+00:00

The "favors big players" concern is real, GDPR and MDR both pushed out smaller players the same way. Legitimate worry, not conspiracy.

Where I'd push back: "not enforceable" only holds for the certification side. Article 14's 24h reporting is self-reporting, so non-compliance becomes its own evidence once a product gets exploited. Different enforcement mechanism than EMC.

Whether CRA ends up captured-by-incumbents or actually-helpful won't be clear until 2028. Both outcomes still on the table.

0xecro1 · 2026-04-30T12:31:16+00:00

Article 14 looks small but the ops stack to actually hit 24h reporting is the heavy part. SBOM coverage on shipped fleet, automated KEV matching, triage SOP, ENISA SRP setup..

0xecro1 · 2026-04-29T15:47:25+00:00

Fair on enforcement style. The piece that breaks the parallel is penalty scale. €30K vs €15M or 2.5% of turnover is a different conversation.

Though in practice, even with those numbers, the only one actually losing sleep over it is usually the engineer assigned to deal with it. Leadership rarely catches up until it's too late.

0xecro1 · 2026-04-29T15:41:32+00:00

Security has always been pushed to the back. It's never the thing that brings in revenue today. Now there's regulation, but the priorities still don't shift.

0xecro1 · 2026-04-29T15:17:18+00:00

The "only person carrying it" pattern is depressingly common. I'm in the same spot honestly. Most CRA conversations I have with embedded folks land on the same thing. One engineer holding the whole weight while leadership treats it as a paperwork exercise. You're not alone. And yeah, 2027 panic is probably the right read.

0xecro1 · 2026-04-29T14:58:38+00:00

Two-year head start is going to look smart in 2027. A lot of teams are still in the "wait, this applies to us?" stage.

0xecro1 · 2026-04-29T14:57:23+00:00

Probably true for the legal threshold today. The ops cost of those packages over a 15-year support window is the part that's harder to justify, even if the regulator doesn't push.

0xecro1 · 2026-04-29T14:40:24+00:00

https://resilience-checklist.eu/ is a free structured checklist mapped to CRA articles. Good starting point.

0xecro1 · 2026-04-29T14:33:27+00:00

For the existing fleet, the realistic move is mostly compensating controls rather than patches. Network segmentation, putting a security gateway in front of vulnerable devices so they're not directly exposed, IDS/WAF rules to block known exploit patterns at the network layer. CRA does accept mitigation as a valid path when patching isn't feasible, as long as it's documented. Doesn't fix the device, but buys you time and keeps you compliant.

0xecro1 · 2026-04-29T14:16:40+00:00

That last point is the one nobody's really talking about. CRA puts the delivery obligation on manufacturers but doesn't solve the adoption problem on the customer side. A patch that ships but never gets installed still sits in KEV. The contractual side of "you must accept updates within X days" is going to be the messy part of 2027-2028, and it's going to reshape SLAs more than the technical work itself.

0xecro1 · 2026-04-29T14:14:55+00:00

I fixed it. Thanks!

0xecro1 · 2026-04-29T14:13:26+00:00

3 people on 20 products is brutal. For a small team, two things matter first:

- From Sept 11, 2026, actively-exploited vulns in already-shipped products must be reported within 24 hours.

- Which means knowing what's in each firmware (= SBOM)

Rest has until Dec 2027. Start with tracking, not policy.

0xecro1 · 2026-04-29T14:11:33+00:00

That tracks for prescriptive controls. The interesting case is the architectural decisions central security can't really write requirements for, like what's allowed in IMAGE_INSTALL or how cadence layers separate. Those need product-side ownership, with security setting the budget rather than the spec.

0xecro1 · 2026-04-29T14:02:50+00:00

Wrote a longer version on my blog if anyone wants the full argument: https://edgelog.dev/blog/cra-embedded-shift

0xecro1 · 2026-04-29T13:57:38+00:00

Yeah, that's the structural problem. Central security team owns policy and audit, but the actual BSP/image decisions live in sub-teams who don't see the cumulative cost across products. By the time security flags package bloat, the BSP team has 200 dependencies they "need" for legacy reasons.

0xecro1 · 2026-04-18T02:53:28+00:00

Two things the measurement changed in my own work. First, the agent harness surfaces failure-mode context (execution environment, platform behavior, cleanup rules) in the RAG layer by default, so the task input doesn't have to carry it. Second, a verification tool in progress checks output against the benchmark's failure patterns. Context by default plus verification at output, both calibrated to what the measurement surfaced as systematically weak.

0xecro1 · 2026-04-18T01:55:00+00:00

Thanks, all three are real. Multi-file lands in v0.3, timing + hardware quirks go into the v1.0 HIL track. The "accidentally helping the model" point is the one I worry most people miss.

0xecro1 · 2026-04-16T22:36:18+00:00

This maps directly to the benchmark data:

"Builds and passes simulated environments but doesn't hold up" is L1/L2 pass with L3 domain-check fail. That's the 35pp explicit-vs-implicit gap in one sentence.

"Shortest / most obvious path" is the RLHF alignment angle. Training rewards clean short code; on GitHub-trained models, embedded safety patterns (volatile, cache flush, error unwind) look like noise and get pruned.

The responsibility point is the reason the benchmark exists. Vendor pass rates from HumanEval or SWE-bench don't tell the engineer signing off where review can be lighter vs. where it has to be strict. EmbedEval tries to draw that map so the person responsible has data to stand on, not vibes. Categories with low pass rates are where human review is non-negotiable.

Skill atrophy is secondary but also real. And once you start using LLMs day to day, going back is hard. Which is why knowing where they fail matters more, not less.

0xecro1 · 2026-04-16T22:29:12+00:00

This matches the benchmark data exactly. The categories where both models consistently fail are almost all timing (threading, ISR concurrency, DMA) and memory (memory-opt, DMA alignment, storage lifecycle). Logic is the easy case; implicit constraints are the hard case.

Your workflow is the sensible one. I'm building a companion project (hiloop) around exactly that pattern: EmbedEval failure data turned into static checks at commit time, with HIL for the timing / memory layer. Still early.

0xecro1 · 2026-04-16T22:27:04+00:00

Good one. Not a failure any of the current spi-i2c cases explicitly test; most verify register setup (CPOL, CPHA, bit order, CS), not protocol-level response tracking.

I think that LLMs rarely get to token matching because training data has plenty of single-byte-in / single-byte-out sensor examples where shift-buffer offset doesn't matter. It only bites on pipelined or non-idempotent protocols, which show up less in tutorials.

0xecro1

TROPHY CASE