NAT is a crutch to circumvent the problem of "there are not enough addresses for each device".
I _assume_ you are referring to a default deny inbound firewall (so that devices are not reachable from the outside), but these are very different, completely orthogonal concerns (and independent of the IP version in use).
Everyone I've talked to with this opinion are typically mobile devs thinking about cell phones. Ipv6 works great there, but NATs are often used in corporate networks for isolation and in particular obfuscation. You can't tell what's behind a NAT by inspecting traffic coming from inside it like you can with no NAT networks. Some of the networks I administrate are contractually obligated to be so isolated.
I am aware that NAT is often used in corporate networks, but it does not automatically make any more sense there - the isolation is achieved by the firewall, not by NAT.
NAT (address or port translation) and a firewall (allowing traffic from/to those addresses or ports) are orthogonal concepts.
You can do NAT on IPv6, if you so desire.
It _should_ make no difference whether any adversary knows "what's behind a NAT", because it is your firewalls job to block any unwanted traffic.
Relying on "nobody knows what is inside our network so it can't be attacked" is not a viable strategy.
> I administrate are contractually obligated to be so isolated
Yeah, I've seen those contracts. They just reference a SeCuRiTy doc that's 20+ years old, and has never been re-evaluated. Things are secure because they follow the doc, not because they have actually evaluated the reasonable attack space.
I've fighting customers for years on their ideas of proper TLS usage and it's always the same thing. They've got a security doc that never changes and has never evaluated any of the trade-offs. Almost to the point that the people who wrote them choose things that increase downtime and KTLO work without helping security.
Ah-yup. The equivalent in my world is contracts that insist we make our employees rotate their passwords every 2 months or whatever, which was a popular (but still dumb) idea 20 years ago and is strongly recommended against today.
On week one of my current job, I turned that off for the whole company. Here's the citation you can give your security department to show them why they're doing it wrong.
NIST Special Publication 800-63B, the July 2025 version, section 3.1.1.2, says:
"Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically. However, verifiers SHALL force a change if there is evidence that the authenticator has been compromised."
The previous version from June 2017, section 5.1.1.2, says:
"Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator."
So 9 years ago, NIST said to stop requiring that. Last year, they clarified that to say, no, really, freaking stop it. Any company still making people do that today is 9 years out of date, and 1 year out of compliance.
I am not sure this approach can take you very far.
In my experience, CC makes it very very easy to _add_ things, resulting in much more code / features.
CC can obviously read/understand a codebase much faster than we do, but this also has a limit (how much context we can feed into it) - I think your approch is in essence a bet that future models' ability to read/understand code (size of context) improves as fast or faster than the current models' ability to create new code.
Ouch. I guess this came across as "my approach". I haven't done enough agentic coding to feel like I know enough to have a worthwhile, but at the moment I'm squarely in your camp. I don't believe it's going to work to let an agent loose expanding a teetering codebase with little to no concern for maintainability. We're going to have to painfully relearn the lessons of pre-AI coding, whatever that means with AI in the mix.
OTOH, consider that in the "pick the majority from 3 CPUs" approach that seems to have been used in earlier missions (as mentioned in the article) would fail the same way if two CPUs compute the same erroneous result.
So the next and final commit should be a message at the top of the README saying the library is unmaintained and contains serious vulnerabilities and users are advised to move to alternative XYZ.
Would have to be F32, no?
I cannot think of any way to enforce "non-zero-ness" of the result without making it return an optional Result<NonZeroF32>, and at that point we are basically back to square one...
> I cannot think of any way to enforce "non-zero-ness" of the result without making it return an optional Result<NonZeroF32>, and at that point we are basically back to square one...
`NonZeroU32::checked_add(self, other: u32)` basically does this, although I'll note it returns an `Option` instead of a `Result` ( https://doc.rust-lang.org/std/num/type.NonZeroU32.html#metho... ), leaving you to `.map_err(...)` or otherwise handle the edge case to your heart's content. Niche, but occasionally what you want.
> `NonZeroU32::saturating_add(self, other: u32)` is able to return `NonZeroU32` though!
I was confused at first how that could work, but then I realized that of course, with _unsigned_ integers this works fine because you cannot add a negative number...
You'd still have to check for overflow, I imagine.
And there are other gotchas, for instance it seems natural to assume that NonZeroF32 * NonZeroF32 can return a NonZeroF32, but 1e-25 * 1e-25 = 0 because of underflow.
That is my charitable interpretation, but it's always one or two changes across a module that has hundreds, maybe thousands of lines of code. I'd expect an auto-formatter to be more obvious.
In any case, just looking over your own PR briefly before submitting it catches these quickly. The lack of attention to detail is the part I find more frustrating than the actual unnecessary format changes.
Why would you are about blank lines? Sounds like aborted attempts at a change to me. Then realizing you don’t need them. Seeing them in your PR, and figuring they don’t actually do anything to me.
Agree that "splitting for splittings' sake" (only to stay below an arbitrary line count) does indeed not make sense.
On the other hand I often see functions like you describe - something has to be executed step-by-step (and the functionality is only used there) - where I _whish_ it was split up into separate functions, so we could have meaningful tests for each step, not only for the "whole thing".
If I have a huge function, and I can peel parts off into sensible well-encapsulated sub-functions, and I name them well, then my ability to comprehend the whole goes up.
If I do that, future me will thank me, because I will almost inevitably be back to that function at some point.
But for this to work, the sub-functions have to really do what they say, and not do anything more. I have to be able to trust that I can understand them by just their name and arguments.
I ran into some code recently where this pattern caused me so much headache - class A has an attribute which is an instance of class B, and class B has a "parent" attribute (which points to the instance of class A that class B is an attribute of):
class Foo:
def __init__(self, bar):
self.bar = bar
class Bar:
def __init__(self, foo):
self.foo = foo
Obviously both called into each other to do $THINGS... Pure madness.
So my suggestion: Try not to have interdependent classes :D
Well, at times having a parent pointer is rather useful! E.g. a callback registration will be able to unregister itself from everywhere where it has been registered to, upon request. (One would want to use weak references in this case.)
On the other hand, I tend to take it as a hint that I should look at my module structure, and see if I can avoid the cyclic import (even if before adding type hints there was no error, there still already was a "semantic dependency"...)
I _assume_ you are referring to a default deny inbound firewall (so that devices are not reachable from the outside), but these are very different, completely orthogonal concerns (and independent of the IP version in use).