(Meanwhile, I'm recompiling Wine to see if I can patch it to address an issue that was hotfixed in Proton two weeks ago but isn't in a CrossOver build yet, so yeah, there's maybe some arguments to be made here that I'd be a potential beneficiary. If I weren't too cheap to spring for an eGPU in today's market, anyway.)

Anyway, one way to detect NAT is to observe different TTLs originating from one device. Is that deep inspection? Probably depends on who you ask. The fact that you have to track information across multiple packets counts for something, though.

Off the top of my head I wouldn't really expect there to be much value in a MITM inspection of the contents of HTTP traffic for the purposes of NAT detection. You could probably come up with some scenarios in which it might be possible, but I'd content those scenarios aren't very practical. Easier to compare TTLs between packets, say, or track connections to known OS "phone home" destinations. While these just use information from the IP layer, they're stateful observations requiring comparisons across multiple packets, and that might count for something.

One way to detect a shitty carrier service, though, is that they're inspecting your traffic for "good" or "bad" uses of their service, because that is a good indicator that they're not just a carrier. I call it Dickish Practices Identification, or DPI.

Having an LLM use a web search tool isn't the same thing as researching a topic, IMO, because it's so ephemeral and needs constant reinforcement. LLMs aren't learning machines, they're static ones.

A consequence of me being a freeloader too is that you don't have to change your plans to please me :-)

I have, however, rejected making a user login. I recognise you're putting in time and energy to make something I'm just taking without payment, and it's your right to try to leverage it into something more - I wish you all the best in doing so - but asking for a user login as a gate to a feature you clearly don't need a user login for is enshittification.

I saw someone on here recently say they like to do the puzzle without looking at the clues, and I've started doing that on and off too, it changes the game in an interesting way.

How serious a risk is poisoned weights?

Can we leverage the cryptobros into using LLM training as a proof of work?

If you fire all your SWEs they won't sit around twiddling their thumbs waiting for an AI collapse, they'll career shift. Maybe to an unemployment line and/or homelessness, maybe to something else productive, but either way they'll lose SWE skills.

If you close down all the SWE junior positions you'll strongly discourage young people training in the field. They'll do something else.

Then if you want to go back, who will you hire for it?

IMO it's because option is a monad, list is a monad, io is a monad, async is a monad, try-except is a monad, why invent different magic syntax and semantics for all of them when there's a perfectly good abstraction that covers the lot, and that lets you write functions that are agnostic to which particular monad they're in to boot.

Other than that it's fine, I guess.

We're putting other providers through the gauntlet. An M4 Studio or two running the latest Qwen3 or whatever counts for state of the art in open models is also looking a little more viable all the time.

Structural changes, in which attention to the small details of a task is directly at odds with the need to consider less overt factors like cohesion and coherence, are where an agent will turn your code base into a dog's breakfast.

The vibe coded software I have for my own use only is like that. Giant hundred-line functions, poor separation of concerns, easy for a change to have unintended behaviour somewhere else. It's probably a step up from the spreadsheet I was using before it, but not by enough to justify current RAM prices.

As far as I can tell the parent post is talking about discovery for agent-to-agent communications, which is not something I have much interest in myself: it feels very "OpenClaw" to replace stable, deterministic APIs with LLMs.