How? If X people made appointments in a day, then exactly X vaccines should be distributed for that day. Leftover vaccines will only be distributed after all those appointments are over, so it is impossible for any of the X people(assuming they arrived on time) to lose their vaccine.

In Israel, before vaccines were made available to the entire public, people created Facebook groups reporting clinics which had spare vaccines, nurses would even go outside and offer random passerbys an option to get vaccinated.

For example, futures in Rust can be used with both OS threads and lightweight tasks. Tokio is mostly agnostic about the choice of the executor.

It definitely takes some time to grok async Rust (even if you come from C#/JS), but I think it really shines once you get to know it, similar to the benefits you get from learning about iterators & higher level functions as opposed to plain loops.

For instance, I've recently implemented the Raft protocol as part of a distributed algorithms course. Using Tokio and a single threaded executor made the implementation fairly readable, mostly relying on few async constructs(futures, tasks, channels and select loops) to model fairly complex behavior (bidirectional messaging, multiple states, timeouts, etc..) Doing so in a more traditional callback oriented style would've required maintaining a very complex state machine(in addition to the state machine of the algorithm itself)

Also, Async/Await originated in C#, a language which already supports threads(and many other concurrency models), not JavaScript which historically relied on callbacks

What's the difference between downloading and streaming a video? It's OK for the bytes to stay in main memory/network cache, but not in HDD? Would taking a memory dump of the RAM break their TOS?

Playing in the background is not a "feature", it's a basic device capability, the fact that YouTube went out of their way to prevent it does not make it right, imagine if the browser client had stopped playing when you went out of focus - that'd be completely unacceptable. The fact that somehow this is accepted on smartphones probably says more about consumers lack of technological competence and awareness (and maybe historical reasons, as earlier versions of Android/iOS didn't have proper multi-tasking)

I use Syncthing to sync it among devices, it's open source and fairly simple to use(compared to other DIY cloud apps)

Nowadays you don't even have to use JS/TS, there are many languages that target JS and have decent bindings to its ecosystem, such as Scala, Purescript, Clojure. This doesn't seem to be the case with Qt which lacks decent bindings to languages other than Python.

Would the average person edit a .svg by hand? No, he'd use Adobe Illustrator or anything else.

Would he edit a .docx file by treating it as a zip archive and edit content.xml? No, he'd use MS Word/LibreOffice Writer...

Suppose Sqlite used XML/JSON instead of binary files, would you modify them with notepad? No, you'd probably use a SQLite browser software.(Or an application that is more tailored to the domain)

What you're suggesting will actually hamper security, because scripts served from your domain have less limitations(see https://en.wikipedia.org/wiki/Same-origin_policy , https://en.wikipedia.org/wiki/Content_Security_Policy and other mechanisms)

>This is not an argument at all. Let's consider the situation when individual service gets compromised. Attacker has thousands of salted hashes

Wait, who said they are hashed? Perhaps an irresponsible webmaster stored them in plaintext. Now, even if that service itself isn't very important, it's likely that certain users re-used the same(or a similar) passwords in more important services, such as Google.

Now, while you're right that using a single master password does pose a risk, there aren't other viable solutions to secure password authentication, unless you; Memorize a strong password for every service that you use Never share passwords among the services Don't store saved logins in your browser Never link your services to your email (because then if your email account is pwned, your accounts in those services would be pwned too, another "all eggs in one basket" issue)

If you can do all of the above, then great, but most people can't.