There's a (configurable, easily bypassed) limit for newly created file size to catch that common mistake.

Disabling that option makes the `%SystemRoot%\system32\GigabyteUpdateService.exe` binary mentioned by the original article stop appearing, so it seems so.

Thank you for letting me know!

There's even been experiments with binding futures to glib or various GUI event loops!

I have also heard some talk on building executors for embedded devices where you can't allocate memory on the heap.

Yes, this was a big constraint on the design of the overall system; there's been a couple that have popped up.

"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.

Ahhh; thank you!

Missed opportunity to render pixel art in the calendar display.

Thanks for the details!

> 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!

> But for C/C++ projects I would just compile in an Ubuntu container as well.

Setting up a reproducible build environment with nix-shell is much more convenient than screwing around with containers.

I meant to test outside NixOS.

I already use default.nix + direnv for my C++ projects.