Well, the existing solution that everyone knows and tolerates is "write the stuff you want to test as synchronous logic" but I think we can do a bit better than that if I get some spare cycles to tinker with it.
I keep writing #rust code composed of lovely little async tasks where it becomes impossible to mock the passage of time because of the non-determinism introduced by channels and multithreading. I have a theory that the overarching solution to this is a tokio executor that lets you "await until quiescent" but I haven't figured out a way to do that yet.
Feeling sorry for the old mod team. Commenters who only read the post have ascribed all kinds of malicious motivations. I understand their instincts, but anyone's who ever been helped with their code by burntsushi, looked into his projects, or watched his mod actions on the forum would be aware he's a model open source citizen and utterly professional when dealing with upset folks over the years. When he talks about his obligations to the Rust community you can take it at face value.
Full pre-disclosure post: https://matrix.org/blog/2021/11/18/pre-disclosure-upcoming-security-release-of-synapse-1-47-1
Seeing it all laid out like this, I'm convinced - I'm going to shift all my Rust dev into VMs. All the other potential hardening measures are kind of piecemeal at best. Even if I was absolutely diligent about the transitive dependencies in _my_ code, some days you just have to clone random things on GitHub for bugfixes, etc.
This is pretty impressive work from Google... through hard experience I've always considered rangefinding via BLE RSSI a fool's errand, at least to any serious level of accuracy. Environmental factors aside, different Android phones are all over the place. But to make their exposure notification system work Google has compiled a database with over 12,000 models (!) with correction data to convert them to a common reference point. https://developers.google.com/android/exposure-notifications/ble-attenuation-computation #bluetooth #android
Is anyone aware of any downsides to the Blue Oak Model License? (https://blueoakcouncil.org/license/1.0.0)
One of the authors talks it up and it seems to be legit (https://writing.kemitchell.com/2019/03/09/Deprecation-Notice.html) but it seems uncommon still. Is there any reason for that other than "change is scary"? #licensing #opensource
Blog: tokio::sync::watch as an observable parameter https://thomask.sdf.org/blog/2021/11/01/tokio-watch-as-an-observable-parameter.html
A brief discussion of the new subscribe() and send_replace() methods on the watch Sender #rust
That's cool, they went out of their way to make AOE4 play nicely on integrated graphics, for machines as far back as late 2015 based on the quoted specs https://news.xbox.com/en-us/2021/10/24/age-of-empires-min-spec-mode-more-opportunities-to-play/
Blog: New strategies for mailing list DMARC
Blog: java.util.UUID accepts truncated UUIDs
Noise Protocol is super cool. [A system for creating encrypted channels, kind of equivalent to TLS but simpler.] It supports all the different handshake patterns depending on which sides of the connection need to authenticate each other and whether you need to hide participants' keys from observers. http://noiseprotocol.org/noise.html#interactive-handshake-patterns-fundamental
Australian computer nerd, into Rust stuff. Reformed fossbro. SDFer since '09.
"I appreciate SDF but it's a general-purpose server and the name doesn't make it obvious that it's about art." - Eugen Rochko