yrand

> when NAT is overwhelmingly a feature built into firewalls

This is just not correct. NAT and firewall are simply orthogonal concepts and can and often are deployed separately. A simple example is your average small SOHO router, which usually has NAT but quite a lot of them lack a firewall.

Why do you think NAT is part of a firewall? NAT and firewall are two completely separate things that can exist independently of each other.

Also overlapping ranges are an orthogonal issue that can occur with IPv6 private network range as well.

IPv6 brings not only bigger address range but also a big bag of other things that one cannot ignore, are complicated and which are often a source of problems. That's why people stick with IPv4 even at the cost of NAT, because the number of things they have to care about is much smaller.

There's DNS over HTTPS they can't viably block, so thankfully they get the short end of the stick here.

edit: Thinking of it, anyone knows if it's possible to use that for OS-wide DNS resolves, not just for the browser?

Encountered one specific example about a month ago here on HackerNews - All about automotive lidar. https://news.ycombinator.com/item?id=46110395

Blog posts where I find quality really shows are usually about something I know next to nothing about how it works. A badly written article usually either goes really shallow or skips some facts when going into depth and requires catchup elsewhere to actually understand it. The lidar article from Main Street Autonomy goes beyond basics and explained everything from the ground up in such a connected way that it was a real pleasure reading it.

I'd investigate why it won't run with debug info in the first place. That feels like the core problem here, because it prevents you from using some debug tools.

Of course that may require digging down pretty low, which is difficult in itself.

Edit: also there's split-debuginfo which puts debug info in separate file. It could help if the reason you can't run it is the debug info itself. Which feels unlikely, but :shrug:.

Could you expand on what you meant? I'm curious.

Not related to OP, but debugging is often about finding where an invariant is broken, so it feels like using LLM to navigate a debugging loop may be useful as it's not a complicated but repetitive task. However in the morning I struggle to imagine how to do that.

The problem with making invalid states representable is that the app logic must be able to handle it, everywhere. Which means you have to always take it into account when reasoning about your app and implementing it, otherwise it will blow up in your face when the invalid state actually occurs. Which means your state machine is inherently larger and harder to reason about.

To illustrate what I mean, take the null pointer. It's essentially an Optional<T> and in a lot of languages it's involuntary, meaning any value is implicitly optional. What happens when something returns null, but in some place in your logic you don't take it into account? Null pointer dereference.