Also Google search degradation is partly due to the web becoming infested with AI slop and most content moving to chat apps, which are walled gardens by default.
Reproducing an ASML machine is a piece of cake. Okay, not a piece of cake but definitely doable. The problem is that you cannot sell your reproduction in rich countries because the US government will threaten you with sanctions and US companies will screech "patents!".
No its not, you have to be extremely precise when making the machine, and only ASML knows how to do that. China already have a big government funded project to reproduce ASML machines and they have failed so far.
Nonsense. Patents are a locked glass door; anyone can get in if they knock hard enough. And Chinese engineers wear heavy gloves and eye protection when going door-to-door.
I used to work for ASML as a design engineer, and I asked my manager why we didn't shred our paperwork, like some other companies I worked at.
"With all the trouble we've had, getting our designs to work? We should publish them to slow down our competitors!"
He wasn't wrong. “Nothing that's good works by itself, you've got to make the damn thing work.” — Thomas A. Edison.
> Reproducing an ASML machine is a piece of cake. Okay, not a piece of cake but definitely doable. The problem is that you cannot sell your reproduction in rich countries because the US government will threaten you with sanctions and US companies will screech "patents!".
... An argument that may not convince China and Russia, who have a track record of ignoring it - I doubt it is a significant reason why they have not achieved semiconductor manufacture tooling parity.
>I doubt it is a significant reason why they have not achieved semiconductor manufacture tooling parity.
It's not enough to reproduce just the work of asml, you basically have to reproduce their entire supply chain, because, same reason, their suppliers will have trouble obtaining export permissions.
No, it isn't. Many middleboxes (including OpenWrt by default) drop unsolicited inbound TCP connections even on IPv6, and therefore the same hole-punching algorithm is needed. The hole being punched is in the stateful firewall's connection tracker, not in the NAT. Basically, both parties need to convince their router that it is an outgoing connection initiated by them, not a prohibited-by-policy incoming connection.
All you should need is for both sides to connect to each other. Side A connecting to side B opens a hole in side A's firewall and is blocked by side B, then B connects to A, opening B's firewall and going through the already open hole in A's firewall.
It might work better with UDP but I don't think those firewalls boxes tear down the mapping immediately on getting an RST - they wait until it times out.
There are two separate problems with IPv4 and only one applies to IPv6. Allowing incoming connections through a restrictive firewall is applicable to both. Address mangling via NAT applies only to one. Note also that in the IPv4 world you might be behind more than one layer of NAT which will make everything infinitely worse.
Honestly ISPs really missed an opportunity to essentially provide IPv6-only as a service and add an IPv4 compatibility layer to that (IPv6 already has a mechanism built in for this but grandma’s old laptop might not fully support it so you might need a local router provided by the ISP to give you native local IPv4 that allows you to access the internet) instead of CGNAT. But they chose to go with duct tape, spit, paper clips, and hope instead of investing in the correct solution. Shame on them and too bad for us.
Exactly. And look, the linked Python script only solves one problem: making both firewalls believe that the party behind them is the one who initiated the connection. Address/port mangling is not addressed at all, both public addresses need to be provided externally.
And it's simply not true that there is no NAT in the wild with IPv6: every OPNsense installation with two uplinks and the need for anything better than an "arbitrary and uncontrollable" choice of the correct uplink for each outbound connection needs network prefix translation, as the residential dual-homing story for IPv6 is vaporware otherwise. NPT is used not for address space conservation, but to defer the decision about the correct source address to the router that has the knowledge of the correct policy.
And in this sense, IPv6 is worse than IPv4: there are too many people assuming no firewall and no NAT for IPv6, and designing their applications based on these almost-working (but de-facto now broken) premises. The correct premises are the same as for IPv4.
If you have two uplinks and running OPNSense (saying this as someone that does exactly this), you have a particular setup that you have clearly taken ownership of. If that breaks your experience with standard tech, that is part of what you traded off when you customized your setup as such.
IPv6 is strictly worse for this precisely because it is treated as a second class citizen. If it was the default in all the tutorials and we started naming IPv4 as the legacy protocol developers would know better.
Not up to you as a hole puncher to decide what a network uses. You just punch holes. IPv6 doesn’t allow you to skip NAT unless you are comfortable with your code not running everywhere.
reply