three14

The only reasonable design is to have two kinds of API keys that cannot be used interchangeably: public API keys, that cannot be configured to use private APIs, and private API keys, that cannot be configured to use public APIs. There's no one who must use a single API key for both purposes, and almost all cases in which someone does configure an API key like that will be a mistake. It would be even better if the API keys started with a different prefix or had some other easy way to distinguish between the two types so that I can stop getting warnings about my Firebase keys being "public".

> Is there something less cooperative than a task that doesn't yield its control back to the main thread? Of course it does yield back to the main thread in my example, at each await point, just like any other cooperative task.

In my case, I specifically want an independent execution of a task. Admittedly, it has to catch its own exceptions and deal with them, as you pointed out, because that's part of being independent.

(Technically, in issue A it doesn't crash the running thread. The event loop catches the exception, but it complains later when the task is garbage collected. Issue B is fine for my use - when the event loop shuts down, it cancels remaining tasks, which is exactly right for my server.)

The thing that burned me with asyncio primitives is that calling an async function doesn't even schedule it (by default). The pattern for fire-and-forget is impossible to guess when coming from any other language - although it's called out in the docs. You must also call create_task AND you must maintain a collection of tasks because otherwise the task might not run, because it can be garbage collected before running, AND you must clean up completed tasks from your collection.

But if you release the O2 and convert it into diamond, then by my highy-suspect back of the envelope calculations, it'd be a diamond that would fit into one square kilometer, 87 meters high. It would make quite the tourist attraction.

If you do speak Hebrew, you would know that Netanyahu and Gallant have been heavily attacked by the extreme right specifically because they have been refusing to cut off food.

My argument is that is not the choice we are given. We are given only the choice between too much regulation and too little.

I am sure that new designs would be better on paper. I am also sure that a regulatory regime in which nuclear plants are allowed to be exactly as unsafe as fossil fuel power plants would somehow turn out in the real world of money and politics to actually be worse than fossil fuel plants.

I don't think we as humans know how to create a regulatory structure for nuclear that would keep away people who are willing to sacrifice principles for money, and at the same time allows new designs to easily be built.

Not to pick on you, but every time this discussion happens on HN, someone argues that the nuclear power industry is burdened by far more red tape than other industries (probably true) and that if we simply reduce the red tape, we could profitably build new nuclear plants (probably true) and they would still be safe (probably not true). This isn't an engineering problem. This is a social problem. Suppose you offer to let people build with minimal regulation - the most profitable plants are going to be the ones that cut the most corners on safety. The great engineering team that made a safe but slightly more expensive reactor than the minimum allowed by regulation will be out of the market.

And unsafe nuclear is really unsafe in a politically terrible way. You are doomed to either have Chernobyls or a lot of non-optimal regulation, or excellent regulation in the world of spherical cows and frictionless planes.

Perhaps one of the new nuclear startups can find a solution to this, but it'll have to be by finding a way to mass produce nuclear within the existing heavy red tape regime. And in the real world, that's not a bad thing.

Complete anecdata, but a few months ago a neighbor of mine successfully resuscitated another neighbor with CPR. There was an AED present, but from what I heard, it did not recommend a shock. The person who collapsed is around 70 years old. Sometimes, it does work! There clearly are some cases where it would be crazy not to try it.

Maybe it knows the answer, but since it was trained on the internet, it's trolling you.

The real story in Israel is more complicated; the courts have taken power from the other branches; it's about time for there to be some kind of correction, and is often the case, the rebound might very well go too far in the other direction, ruining the possibility of a real system of checks and balances. Netanyahu himself may be going along with it to penalize the courts, but it's unlikely to help his court cases directly. The idea that it's supposed to somehow magically help him is a talking point for some of the political parties, but he would probably need some kind of new legislation to grant him immunity.

Quick turnaround!

July 14, 2022: Reported vulnerability to the Computer Emergency Response Team (CERT) Coordination Center.

July 15, 2022: CERT/CC reported vulnerability to SQLite maintainers.

July 18, 2022: SQLite maintainers confirmed the vulnerability and fixed it in source code.

July 21, 2022: SQLite maintainers released SQLite version 3.39.2 with fix.

To hijack the thread a bit, if you are still with Dropbox, could you get them to implement what you did in #2 in the official Dropbox JS SDK? Right now it still does a pre-flight request for everything.