Matt Levein on Chinese companies’ future U.S. IPO; WireGuard is going native on Windows.
When [U.S. securities regulators] see a broad swath of Chinese companies’ stocks go down for reasons like “a whole sector is not allowed to make profits anymore,” they naturally think “well this is a risk that should be disclosed.”
On the one hand that is a natural thing for them to think.
On the other hand it is awkward because … that was a risk that was pretty well disclosed?
Like a notable fact about Chinese tech companies listing in the U.S. is that they all disclose pretty clear risk factors to the effect of
“we are a Chinese tech company,
we are not actually allowed to be owned by foreign investors,
we’ve got this rickety structure to get around the rules,
we think it works but no one is really sure,
and if it doesn’t work all sorts of terrible things can happen and you’ll never get your profits.”
The rickety structure is called a “variable interest entity,” and it is all pretty well understood and disclosed.
Obviously those risks are (were) ignored a lot, but that is not really a failure of disclosure.
Technically the prospectus was not selling shares of that ride-sharing startup to U.S. investors;
it was selling shares of a shell company with certain management contracts with that startup.
a Gensler-approved founders’ letter might be:
“Our journey started in a Cayman Islands law firm. We were united by a single dream: Being able to sell shares in a U.S.-listed company that has economic exposure to the Chinese ride-sharing business that we also happen to have founded, while complying with our lawyers’ current interpretation of Chinese laws limiting foreign ownership of certain technology businesses.”
And then the whole prospectus would be like that, constantly emphasizing that you are buying shares of a Cayman Islands shell company rather than the underlying Chinese business.
And it would be more jarring to read than the actual Didi prospectus, which understandably focuses on the operating business rather than the legal structure.
[WireGuardNT is] a deeply integrated and highly performant implementation of WireGuard for the NT kernel,
that makes use of the full gamut of NT kernel and NDIS capabilities.
it marks the graduation of WireGuard to being a serious operating system component, meant for more serious usage.
How WireGuard on Windows currently works: We currently have a cross-platform Go codebase, called wireguard-go,
which uses a generic TUN driver we developed called Wintun.
The implementation lives in userspace, and shepherds packets to and from the Wintun interface.
WireGuardNT will (eventually) replace that,
placing all of the WireGuard protocol implementation directly into the networking stack for deeper integration
With the old wireguard-go/Wintun implementation, the fact of being in userspace means that
for each RX UDP packet that arrives in the kernel from the NIC and gets put in a UDP socket buffer,
there's a context switch to userspace to receive it,
and then a trip through the Go scheduler to decrypt it,
and then it's written to Wintun's ring buffer,
where it is then processed upon the next context switch.
For TX, things happen in reverse:
userspace sends a packet,
and there's a context switch to the kernel to hand it off to Wintun,
which places it into a ring buffer,
and then there's another context switch to userspace,
and a trip through the Go scheduler to encrypt it,
and then it's sent through a socket,
which involves another context switch to send it.
All of the ring buffer amortize context switches as much as possible and make this decently fast,
but all and all it still constitutes overhead and latency.
WireGuardNT gets rid of all of that
Windows users with an Ethernet connection generally haven't had much trouble getting close to 1Gbps or so with the old slow wireguard-go/Wintun,
but over WiFi, those same users would commonly see massive slowdowns.
With the significantly decreased latency of WireGuardNT, it appears that these slowdowns are no more.
Power consumption, and hence battery usage, should be lower too.
There will be three phases of the 0.4.z series:
Phase 1) WireGuardNT is hidden behind the "ExperimentalKernelDriver" registry knob.
Phase 2) WireGuardNT is enabled by default and is no longer hidden.
Phase 3) WireGuardNT is enabled, and wireguard-go/Wintun is removed from the client.