Disabling that option makes the `%SystemRoot%\system32\GigabyteUpdateService.exe` binary mentioned by the original article stop appearing, so it seems so.
"system" here is intended to refer to the application using tokio, i.e. if you got rid of tokio and did everything by hand you wouldn't be able to make your application faster.
> the core protocol objects in quinn that directly link to specific socket and address and even event loop reactor objects - and these objects strictly in Rust to boot.
This isn't accurate. The core protocol objects in Quinn are those defined in "quinn-proto", which has absolutely no awareness of how I/O is performed or what event loop is in use: the interface is structurally very similar to Quiche's, with the caller providing data/timeouts by any means and consuming events that result. See https://docs.rs/quinn-proto/0.2.0/quinn_proto/struct.Endpoin... for details.
The high level "quinn" crate interface, which incorporates awareness of UDP sockets and the tokio event loop, is strictly an optional binding; that's why it's a separate crate.
> existing solutions available right now would not be able to offer the level of flexibility and abstraction we need, nor would they likely be able to add the interfaces we need in a reasonable timescale, nor would they likely tolerate our requests to do so.
Support for this type of flexibility, up to and including allowances for a C API suitable for integration with existing software, has actually been an express design goal of Quinn from the start, and I regret that that wasn't clear.
It's worth emphasizing that QUIC is more general than a new transport for HTTP; it has wide ranging applications, due to being far more versatile than TCP.
All Rust programs call out to platform-dependent unsafe code sooner or later in the form of the standard library. Otherwise, you wouldn't be able to allocate memory or do any I/O whatsoever.
Sometimes the standard library doesn't expose functionality you want, like the capability to read/write the ECN bits of your UDP packets, so you have to bind some syscalls yourself. The capability to do this is one of Rust's core strengths, and it does not compromise a program's rustiness any moreso than calling a wrapper around write to print "Hello, world!" does.
The current draft encourages, but does not require, QUIC implementations to employ path MTU discovery along those lines; see https://quicwg.org/base-drafts/draft-ietf-quic-transport.htm... for details. Quinn doesn't yet have this implemented, but it would be pretty cool!
> Binaries are a pain, but that's always true if you aren't running the exact distro that the binary was built for.
This is actually easier to deal with on NixOS than elsewhere, because the tools for handling that case (patchelf, buildFHSUserEnv, supporting multiple versions of a lib, etc) are so well developed.
Even if you're writing your own engine from scratch, VR runtimes provide orientation information directly to the engine as a 4x4 transform matrix. They would have to ignore all the documentation and go far out of their way to somehow regress to euler angles, and are likely introducing other precision issues in doing so.
> There is no support for datagrams, just datastreams.
Datagrams can be easily and effectively encoded as discrete short-lived streams. If you need streams of datagrams, you can encode your own header to do that. I see no reason why this has to be built into the protocol when the provided primitives are sufficient.
> Forward error correction is actually cool but just using XOR is too limited.