snizovtsev

The patch itself isn't related to MPTCP, but the bug is hard to exploit. AFAIK, Anthropic is the only ones who claimed exploitation using their unlimited frontier models without safety restrictions. So non-MPTCP configurations may also be vulnerable, but exploiting them could require even more resources. I've tried to trigger KASAN using Qwen 3.8 27B @ local RTX3090 - no success after 96 hours.

You can exercise it against regular, non-Glacier S3. Same flow; the only difference is that you skip one attribute on upload and one request/wait step on download.

I'm polishing my backup system right now, and found that `tar | zstd | gpg` plus a small vibe-coded wrapper is pretty much all I need.

GNU tar has its own incremental index via `--listed-incremental=FILE`. Unlike Borg or Restic, which have their own more complicated repository formats, this leaves me with just one additional file (the `.snar`) alongside a dumb, portable full-disk tar archive.

The nice part is that, unlike repositories that require both read/write access patterns, tar can compute deltas using only the small `.snar` file, while the main `full-disk.tar` can remain buried in write-only Glacier storage. This makes it a much better fit for Glacier's write-once model and 180-day minimum retention.

My current plan is to upload a full-disk tar to an external HDD + Glacier on a weekly cadence, and the `.snar`-based deltas daily. That gives me a pretty simple cloud backup solution for a few bucks a month (after burning through $100+ of free credits).

Not really. FPGAs run some simple proven strategies, but hardware guys can't keep up with how fast quants iterate on new strategies - so CPUs stay relevant.

Most likely gas stations will have to buy these systems to keep their business running.

No, it will be "somehow working solution for case A" and "somehow working solution for case B" but not together.

Yes, but it was expected. It's like prioritising code readability over performance everywhere but the hot path.

Earlier in my career, I managed to use Zopfli once to compress gigabytes of PNG assets into a fast in-memory database supporting a 50K+ RPS web page. We wanted to keep it simple and avoid the complexity of horizontal scaling, and it was OK to drop some rarely used images. So the more images we could pack into a single server, the more coverage we had. In that sense Zopfli was beneficial.

I think half of Tofino's complexity was in their compiler. So it may inspire new hardware vendors to reuse it in some contexts.

Optimal in theory but totally uncookable.

Lower labor cost and heavily subsidized agriculture.

$999 is for soldered 8GB/256GB crap. Add $400 for 16GB/512GB models.

Living in Russia could be very cheap compared to other countries. If you own a flat and you don't need cars or travel, then it's possible to live a few years just on money saved from your previous software job.