NMDaniel

This isn't very different from the West selling guns, tanks and police equipment to allied 3rd world countries. You hope they'll be used for good causes(preventing crime and terrorism) but knowing that these governments tend to be corrupt, you acknowledge the risk that these weapons will be used by bad elements too.

> It's too easy for a bad actor to artificially create "leftover" doses to give to friends and family

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.

You don't even need a system

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.

You're talking about the runtime aspects of executing concurrent code (OS threads vs green threads) but these are orthogonal to the idea of async APIs, which are one way of modelling concurrent programming flows.

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

Sorry, I wasn't aware that YouTube lets you rent movies, I was mostly speaking about normal clips that anyone can watch for free.

Nowhere did I imply that I'd gain copyright over the content.

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?

Assuming this is true(that there's a clause against viewing YouTube with a third party client), then they're free to ban users like me from their service(and suffer the PR backlash), that doesn't mean that breaking that clause is unethical or illegal(I'm not from the US, we don't have draconian internet laws here)

That's not piracy. Youtube is sending you packets, out of their own choice. It's my own right to save those packets(without re-distributing) them and watch them in any form I like.

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)

There are many alternatives to every service Google offers, even though it might not be as good as Google's offering.

KeepassXC does have a browser extension for Firefox & Chrome.

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

That you can keep using Windows seamlessly?

And many developers loathe C++. Why should I have to use such a low level and antiquated language for developing a GUI?

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.

Some formats don't need to be read as plaintext by the average person.

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)

So basically emojis?

That's not how it works, the server wouldn't execute JS that is meant for a browser client, it would just serve it like any other static file.

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)

Yet another tutorial about using a GraphQL client. It's nice but I think the hard part is implementing a GraphQL server. Are there any examples of a full blown GraphQL server, interpreting complex queries as SQL/NoSQL queries in a performant way?

But then you're not answering the question, which is also bad.

If an attacker has root access to your machine, he can easily: * Extract passwords and session tokens from your browsers * Keylog your system and wait for you to type a certain password * MiTM your TLS connection to grab credentials

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

I think this is actually a case for delegated authentication, you can quite simply let Facebook(or Google,MS or some other trusted auth provider) handle these things instead of implementing them yourself. Use some form of social login(OAuth2/OpenID Connect)

On a similar note, Keepass can be used without admin rights with the portable version, so you can keep the portable executable along with the encrypted db file in some secure and accessible email account/web service that your network doesn't block.

I'm no mobile developer but I guess that being able to share classes and libraries(that are non UI/mobile specific, mostly services and domain/business logic) among all the .NET platforms. So you could use the same libraries for an android,ios, windows phone client, a desktop GUI client, a webserver, a static website.

In theory at least...

This doesn't make sense. JSON is used because it's a handy data interchange format, but it doesn't mean it's the best tool for every job. XML is a document markup language that is much, much better than JSON for describing interfaces and alike. And even then it's not really ideal for describing control flow and computations that are needed for any meaningful app that is not a static page (see XAML, AngularJS, FXML, - they do have some power but they're still tied to real programming languages: C#, Javascript, and Java, respectively.)

And all computers and devices made in the last century have no problem dealing with XML, HTML, JS over the wire - in fact this is exactly what web browsers have been doing. So even though you're dealing with native iOS apps and not webpages, that doesn't mean you can't use a similar XML format(or any other document markup language) along with a proper scripting language. And if you insist on staying close to JSON, you could go an all JS approach and use JS(instead of JSON) to describe your views, and also be able to embed JS computations - this is exactly what React does, and does very well.

And again, JSON is not a document markup language, so optimizing it for displaying documents/interfaces seems futile when you can just use XML and save yourself and the interpreter some pain.

There are plenty of great server-side languages and environments. C#,Java,Scala,Python,Ruby,Haskell.

If this was about JavaScript and Front-End I might've agreed with you (there are transpilers but interoperability with JS modules can be tricky), however in the realm of servers there's so much freedom.. so why choose PHP out of them all?