NFS is much slower, maybe unless you deploy it which RDMA. I believe even 4.2 doesn’t really support asynchronous calls or has some significant limitations around them - I’ve commonly seen a single large write of a few gigs starve all other operations including lstat for minutes.
Also it’s borderline impossible to tune nfs to go above 30gbps or so consistently, with WebDAV it’s a matter of adding a bunch more streams and you’re past 200gbps pretty easily.
And after all that hardcore engineering work is done, iMessage still has code paths leading to dubious code running in the kernel, enabling 0-click exploits to still be a thing.
None of that ran in the kernel. Everything happens within a single process up until the sandbox escape, which isn't even covered in your article. The article's sequel* goes into detail about that part, which involves subverting a more privileged process by exploiting logic errors to get it to execute code. The only involvement by the kernel is passing IPC messages back and forth.
Put sensitive electronics in a metal box, comms over a fiber (already common), and you’re good to go.
Only tricky thing is if currents induced in motors are too hard to reject in driver circuitry, tho even at the extreme this should be possible to insulate with capacitors (or worse/heavier with transformers)
The motor drive side probably isn't that vulnerable, since that's the output side of large power transistors, but the Hall-effect sensors and current sensing in brushless DC motors might be a problem. But you don't have to use brushless motors. They last longer, but drones are ammo, not assets, today.
Sounds like a great plan if you don't need a camera, positioning and magnetic compass. You also want your cage grounded or very thick, otherwise with sufficiently strong field it will become preemable.
I was thinking a ferrous shield would warp magnetic flux lines but I could be wrong. And guess you could mill the enclosure from brass, tho it's still not clear how would you get an RF ground up there.
It wouldn't, the only way to "shield" from magnetic fields is to get them to induce Eddy currents and but that requires more and more length and as the wavelength gets longer and essentially infinite for the Earth's field which is very slow moving.
> RF ground up there.
"ground" is relative and not at all required for a Faraday cage to work.
However that is still vulnerable to the microwaves. The issue is that this setup catches microwaves and while, yes, it prevents the waves from entering the electronics it does so by converting them to heat. So if this cage has caught 100J * volume (say 100W for slightly over 1.5 minutes), the electronics are above 100 degrees, and the solder joints are releasing.
The advantage of microwaves is that unlike lasers, kilowatt strong microwaves are easy to generate, it is an incredibly well studied problem, because that's how early radar systems worked. They are what secured the skies above London against the Nazi air force.
Israel seems to be trying another approach with lasers. They decided it doesn't matter if the laser is powerful, if you just have hundreds of 2W lasers aimed at the same target.
Basic yes, but drones are precision strike weapons by necessity: they can't carry enough payload to kill everything in a 50m radius for example. They depend on generally nailing a single target with cm-level precision.
And all that stuff is a new supply chain and more weight which isn't payload.
That a countermeasure can be built doesn't mean it's necessarily effective to do so - your drones get less cheap, less numerous, you have to incorporate such systems into tactical and strategic planning.
You're talking about a counterdrone system that's at technology demonstrator stage. I don't think they even have any contract or timeline for delivering production systems. Meanwhile tech used in the Ukraine war is adapting by the month.
"That a countermeasure can be built doesn't mean it's necessarily effective to do so" applies especially to reading a corporate press release about a system doesn't even have a timeline for being on the battlefield.
> Only tricky thing is if currents induced in motors
Many of the drones in the Russia-Ukraine war are powered by ICEs. I'm thinking of Ukraine's long range drones presently deleting Russia's refinery distillation towers, fixed radar installations, parked aircraft, ammo dumps, etc.
Those engines are not purely mechanical, but purely mechanical engines have been widespread and are still commonplace today. A 2-stroke diesel being one example, but even gas turbines can be purely mechanical. So one can imagine such an adaptation in response to microwave countermeasures.
You'd have to make sure the linkages are not conductive and there is not even a 1mm clearance on their ports in the enclosure. Non-metal axles are possible but it's hard to find material that would withstand the torque.
You also need to think through your cooling solution. Enclosed batteries, converters and motors will generate a lot of heat over typical mission, and you don't have the benefit of direct air cooling anymore.
How about using a metal axle that penetrates the cage using an intentionally conductive bearing, i.e. a slip ring? It would need very low RF impedance, but it would only need to last for the expected lifespan of the drone.
At just a few GHz, metal mesh ought to be adequate for the cage material, so cooling isn’t necessarily a huge problem.
Careful posting systemd satire here, there is a high likelihood that your comment becomes the reason this feature gets built and PRed by someone bored enough to also read HN comment section.
You know, Tailscale serve basically does this right now, but if I could skip this step and let systemd expose a local socket via HTTPS, automatically attempting to request a certificate for the hostname, with optional configuration in the socket unit file… I would kinda like that actually
You can basically implement this right now already by using a systemd generator. It’s not even a particularly bad idea, kinda want to try doing it to hook it up to nginx or something, would make adding a reverse proxy route as simple as adding a unit file, and you could depend on it from other units.
I don’t get why so many people keep making this argument. Transformers aren’t just a glorified Markov Chain, they are basically doing multi-step computation - each attention step is propagating information, then the feedforward network does some transformations, all happening multiple times in sequence, essentially applying multiple sequential operations to some state, which is roughly how any computation looks like.
Then sure, the training is for next token prediction, but that doesn’t tell you anything about the emergent properties in those models. You could argue that every time you infer a model you Boltzmann-brain it into existence once for every token, feeding all input to get one token of output then kill the model. Is it conscious? Nah probably not; Does it think or have some concept of being during inference? Maybe? Would an actual Boltzmann-brain spawned to do such task be conscious or qualify as a mind?
(Fun fact, at Petabit/s throughputs hyperscale gpu clusters already are moving amounts of information comparable to all synaptic activity in a human brain, tho parameter wise we still have the upper hand with ~100s of trillions of synapses [1])
I don't think most people grasp how abstractly high even 1 DWPD is compared to enterprise HDDs. On the enterprise side you'll often read that a hard drive is rated for maybe 550TB/year, translating to 0.05~0.1 DRWPD [1] (yes, combined read AND write) and you have to be fine with that. (..yeah admittedly the workloads for each are quite different, you can realistically achieve >1 DWPD on an nvme with e.g. a large LSM database).
What makes NVMe endurance ratings even better (though not for warranty purposes) is when your workload has sequential writes you can expect much higher effective endurance as most DWPD metrics are calculated for random 4k write, which is just about the worst case for flash with multi-megabyte erase blocks. It's my understanding that it's also in large part why there is some push for Zoned (hm-smr like) NVMe, where you can declare much higher DWPD.
I assume that flash translation layers use LSM-like patterns underneath to cope with small random writes. The best case for flash with a good translation layer is data that can be erased/discarded in bulk, since this minimizes write amplification. This is close enough to the "large sequential writes" case but not necessarily equivalent.
Copy-pasting the json of the request into chatgpt, then just sending prompts to it normally does appear to make it enter the same role-play mode as this site appears to have been in
Also it’s borderline impossible to tune nfs to go above 30gbps or so consistently, with WebDAV it’s a matter of adding a bunch more streams and you’re past 200gbps pretty easily.