The Turis Omnia runs a derivative of OpenWrt. They provide a custom UI with an option to switch to LuCI. It's easy to flash it to upstream OpenWRT, which is what I do.
The journal regularly includes commentaries and editorials on political and economic topics [1][2]. Political talks regularly occur at the conference [3].
In fact, the trigger to all of this was a scheduled talk by Jay Bhattacharya, Director of the NIH and a controversial political figure.
It seems silly to imply that politics are to be excluded from the conference at all costs when the ADA regularly invites political speakers to that same conference.
Do you believe that handing out copies of this editorial constituted inappropriate behavior? If so, why?
So you're concerned about my use of the word "paper." That's fair I guess.
But the editorial in question was in fact published in a peer-reviewed scientific journal.
Just so that we're all clear on the facts:
- The editorial was published in Diabetes Care, Volume 49, Issue 6. [1]
- Diabetes Care is a publication of the American Diabetes Association (ADA). It is a peer-reviewed scientific journal with an IF of 16. [2]
- The paper being distributed was an editorial, not research. [3]
- Steven Kahn, first author of the editorial and one of those thrown out of the conference, is the editor-in-chief of Diabetes Care. [4]
- The conference in question was The American Diabetes Association’s Scientific Sessions. [5]
The important question: Should the distribution of an editorial published in an ADA journal be considered a code of conduct violation at the ADA conference?
The editor-in-chief of a journal handing out a paper that was published in that journal at a conference for that journal... is quite different from ranting about space lizards in a public square.
Your argument is a strawman: you are refuting an argument different from the one actually under discussion. The argument isn't "is protesting at a conference acceptable?" The argument is "does this behavior constitute an unacceptable protest?"
The only thing I can find on Google is a website straight out of 1999 and lawsuit from 1995. They're obviously a US military contractor, but that's all I can tell.
In Javascript, promises are eager and start executing immediately. They return control back to the caller when they need to wait. So in practice, all of your promises are running concurrently as soon as you create them.
In Rust, futures are lazy don't start executing until they are awaited. You have to use various features of your chosen runtime to run multiple futures concurrently (functions like `spawn` or `select`). But that interface isn't standardized and leads to the the ecosystem fragmentation issue discussed in the article. There was an attempt to standardize the interface in the `futures` crate, but none of the major runtimes actually implement the interface.
IIUC, this crate has similar restrictions to the std Mutex. So it depends on what you mean by "work with async code."
First, lock acquisition seems to be a blocking method. And I don't see a `try_lock` method, so the naive pattern of spinning on `try_lock` and yielding on failure won't work. It'll still work in an async function, you'll just block the executor if the lock is contested and be sad.
Second, the key and guard types are not Send, otherwise it would be possible to send a key of a lower level to a thread that has already acquired a lock of a higher level, allowing deadlocks. (Or to pass a mutex guard of a higher level to a thread that has a key of a lower level.)
Therefore, holding a lock or a key across an await point makes your Future not Send.
Technically, this is fine. Nothing about Rust async in general requires that your Futures are Send. But in practice, most of the popular async runtimes require this. So if you want to use this with Tokio, for example, then you have to design your system to not hold locks or keys across await points.
This first restriction seems like it could be improved with the addition of an `AsyncLockable` trait. But the second restriction seems to me to be fundamental to the design.
Yeah, it's a pretty versatile phrase that's hard to explain. But it does often have a connotation of childishness or naivety, even when used sincerely.
It is often used an expression of thanks or appreciation, but I associate that more with an elder speaking to someone younger.
Most of the time, it is an genuine expression of true empathy, but it's not uncommon to be used as a passive aggressive expression of false empathy. It's that childish connotation that give it the extra bite when used passive aggressively.
And that plausible deniability, where the phrase is used in a genuine context often enough that sometimes you can't tell that someone is throwing shade, is very much a reflection of southern culture.
Source: Grew up in Georgia and North Carolina, with some family in Alabama.
Defining BE integer data types seems like a bad approach.
I wouldn't want to maintain those types. The maintainer would either have to implement all of the arithmetic operations or assume that your users would try to hack their way to arithmetic. But really, you shouldn't ever do arithmetic with non-native endianness anyway.
Instead, define all your interfaces to work with native endianness integers and just do byte swapping at the serialization boundaries.
https://cbarrick.dev