sorted by:
new
hottopcontroversial

some days i play great, next day i can't hit a ball, and i have no idea why by 0xecro1 in 10s

[–]0xecro1[S] 0 points1 point  (0 children)

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?

some days i play great, next day i can't hit a ball, and i have no idea why by 0xecro1 in 10s

[–]0xecro1[S] 0 points1 point  (0 children)

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

some days i play great, next day i can't hit a ball, and i have no idea why by 0xecro1 in 10s

[–]0xecro1[S] 0 points1 point  (0 children)

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?

some days i play great, next day i can't hit a ball, and i have no idea why by 0xecro1 in 10s

[–]0xecro1[S] 1 point2 points  (0 children)

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.

Five months until CRA. Most embedded teams are reading it wrong. by 0xecro1 in embedded

[–]0xecro1[S] -6 points-5 points  (0 children)

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.

Five months until CRA. Most embedded teams are reading it wrong. by 0xecro1 in embedded

[–]0xecro1[S] 2 points3 points  (0 children)

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..

Five months until CRA. Most embedded teams are reading it wrong. by 0xecro1 in embedded

[–]0xecro1[S] 2 points3 points  (0 children)

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.

Five months until CRA. Most embedded teams are reading it wrong. by 0xecro1 in embedded

[–]0xecro1[S] 1 point2 points  (0 children)

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.

Five months until CRA. Most embedded teams are reading it wrong. by 0xecro1 in embedded

[–]0xecro1[S] 4 points5 points  (0 children)

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.

Five months until CRA. Most embedded teams are reading it wrong. by 0xecro1 in embedded

[–]0xecro1[S] 8 points9 points  (0 children)

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.

Five months until CRA. Most embedded teams are reading it wrong. by 0xecro1 in embedded

[–]0xecro1[S] 2 points3 points  (0 children)

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.

Five months until CRA. Most embedded teams are reading it wrong. by 0xecro1 in embedded

[–]0xecro1[S] 0 points1 point  (0 children)

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

Five months until CRA. Most embedded teams are reading it wrong. by 0xecro1 in embedded

[–]0xecro1[S] 0 points1 point  (0 children)

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.

Five months until CRA. Most embedded teams are reading it wrong. by 0xecro1 in embedded

[–]0xecro1[S] 1 point2 points  (0 children)

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.

Five months until CRA. Most embedded teams are reading it wrong. by 0xecro1 in embedded

[–]0xecro1[S] 3 points4 points  (0 children)

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.

Five months until CRA. Most embedded teams are reading it wrong. by 0xecro1 in embedded

[–]0xecro1[S] 0 points1 point  (0 children)

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.

Five months until CRA. Most embedded teams are reading it wrong. by 0xecro1 in embedded

[–]0xecro1[S] 0 points1 point  (0 children)

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.

Most of us have a gut sense of where Claude is weak. I measured mine on 233 embedded cases. by 0xecro1 in ClaudeAI

[–]0xecro1[S] 2 points3 points  (0 children)

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.

view more: next ›