elevation
[0]: https://www.sunbirddcim.com/blog/nvidia-h200-power-requireme...
The TCP/IP stack has one of the most stable requirements bases of any component -- modern PCs can communicate with decades-old software and hardware, and the composition of layers design means the code can be easily tested, and is a great candidate for analysis via formal methods. And once you have a formally verified implementation, the stable requirements means you can make it safe and then leave it alone.
Claude has already refused to perform incredibly not-security-relevant tasks, so I'm guessing it will simply not help with this now either. Today, I am, for the first time, looking into my own LLM hardware.
Yes, LLMs can easily knock over your on-prem docker appliances.
But you can still put stuff out of reach. I'm currently designing a key on-prem appliance that is can be compiled down to transistors, giving deterministic wire-speed performance while ruling out RCEs. It's cryptographically homomorphic: it processes authorized inputs but doesn't know what they mean, so an attacker who obtains the disk doesn't benefit either. The design will be highly resistant to exploits, and is likely to remain outside the "next-token" prediction training set.
This is the kind of thing AWS won't sit down and engineer for you. But thanks to LLMs I finally have the time.
Could be better to say "we're working with the Cursor team on this incident". Not your intent, but I initially understood that the Claude team was using Cursor-the-product (instead of Claude-the-product) to resolve the backdoors.
Yes, in 2005 you choose PHP, but in 20 years of operation, you don't revisit reconsider your architectural considerations? A fantastic avenue for hardening any product would be to replace a ~2MSLOC component (the PHP interpreter) with a 10K SLOC daemon that does only what you need.
When you're a startup, expediency and funding prevent this, but by the time you're selling "solutions" and baking designs into ASICs you could have prevented this attack by putting a fraction of the effort into software.
I consulted for a client who cut off an offshore consulting firm after they billed 40 hour for a one line CSS border-color fix change. We were suspicious of billing fraud, but the quality of developers we'd observed wouldn't allow us to rule out hanlon's razor.
In case a future user wants to know what a 2026 model would refuse to do, I needed to rotate dozens of passwords last night both on the server and on the clients. When it was time to verify that the rotated credentials worked, I asked for a script that would rate limit the credential checks. Claude/opus5 (opus!!) refused and stopped in its tracks.
In another instance, Claude was making great headway bringing a legacy Windows app up in WINE until it’s saw “auth” somewhere and shut down. In the shutdown state, Claude asked me to reword the prompt to see if I could get it to act on less dangerous instructions. But when I reworded my request, narrowed the scope to be clearly unthreatening, or even redirected the model, it’s still rejected me. I suspect Anthropic uses the less suspicious rephrasing as training material to increase their rejection rate.
I think it's also helpful to be prompt if you'd like to help others; A campaign will use e.g. twilio numbers leased for a matter of hour, then release it. If you wait too long to report spam, you damage the number's reputation without actually punishing the hyperactive spammer.
I love that I have infinite/unmetered email accounts. In practice I run 3-4 accounts on 2-4 domains, but they don't nickel and dime you on it, I've literally setup 1200 forwarders in the past. They have a good sending reputation.
What other provider does this as well?
Also, not supporting new VHDL2008 for years and years, and lagging on newer updates.
My current flow is to use the ‘write_project_tcl’ command to export a tcl script that would rebuild the project from a single command. Tracking this in git along with your RTL and constraints should be enough. But the file is jam packed with hard coded paths that have to be carefully removed, or else the source can’t be built on another machine. I wrote a custom tool to post process “setup.tcl” but it is brittle because with every new release, Vivado tampers with the output format.
Using these cores in particular have revealed a bunch of issues with the Vivado suite:
Inconsistent naming conventions: In a Vivado block diagram, you must figure an IBERT core to use a transceiver by bank number, e.g, Quad 127, Quad 224. But when you get per-lane test results they reference transceivers as X0Y1, X0Y23. The official “packaging and pinout” documentation will help you translate between these identifiers, but you shouldn’t need to: the Towing should use a consistent naming convention in both the design flow and the test flow.
Another issue: incomplete script Support. When you’re viewing the status of an IBERT core over JTAG, you can see a lot of meta data in the details panel, but not all of this information is available in the TCL objects provided to the script console. This means that certain checks cannot be scripted.
Bad UI architecture: all TCL commands run in the UI thread, so long running commands can lock you out of even unrelated actions for minutes at a time.
TCL was novel in the 90s, but it is haggard, and ill-suited to this line of work. Give me python!
Johnathan Blow's talk on the bronze age collapse pushed me to simplify my production stack. I wanted 'just processes', so I stopped using docker there. I'm happy with the result.
> can be trivially MITMed
Crazy how poor security can be even from a purported security vendor.
The American Midwest would like a word.
If you don't mind being a couple hours drive from anywhere Taylor Swift would play, you can find affordable property, a good community, and amazon prime service. Any town that lacks tech work opportunities will still have solid internet from Starlink to support remote work.
There are awesome opportunities if you look.
Embrace, extend, extinguish