koenigdavidmj

The alerts icon (triangle with a ! in it) shows a text list of the outages. There are many active; only one happened recently. They seem spaced out from each other, not indicative of a burst of Chinese naval activity.

We don’t use the word reasonable anymore the way it was written originally, and the actual meaning is what you’re asking for, except for every conviction, not just capital ones. It doesn’t mean “a small but tolerable level of doubt”. It means doubt backed by reason. “Aliens made me do it” is doubt that is not backed by reason. “There is another plausible way that conforms to the evidence given that he came to possess that laptop” is reasonable doubt.

The San Juans?

Docker runs an ARM kernel and uses qemu in user mode on the individual binary level. Anything CPU-bound is emulated, but as soon as you do a system call, you’re back in native land, so I/O bound stuff should run decently.

That seems to be the spot humans are weakest at—reviewing something where we think the computer did a good job 90% of the time, but quickly noticing when something goes wrong. Similar to level 3 self-driving—requiring full attention, able to instantly snap into full unassisted driving.

Then you have to trust a bunch of people on the ground to be sane, in addition to whoever is in the cockpit.

My wife has had kids in all these settings, except the home birth was through the same provider as the birthing center. All of them were covered by insurance, except the birthing center is out of network. There’s an in-network one the next city over.

(This is a perfectly ordinary HDHP/HSA plan through a large company that you’ve heard of.)

Furkot.com should get you a lot of what you want here, except obviously not offline.

I’m assuming you are proposing to stat each candidate before trying to execve it. I’m also assuming that a stat system call is roughly as expensive as an execve of a nonexistent or non-executable path.

For every failed candidate, you are doing one system call, so roughly the same cost each way.

Now if you just do an execve, you’re just paying that cost. If you stat first, you pay the cost of another system call that doesn’t change the flow of your program at all (a nice way of saying you’re wasting time).

Unless stat is dramatically faster than exec on a nonexistent or non-executable path, there’s never a case where this is better.

The US is large enough to have had its government break promises like this time and again. That’s why you’ll see a lot of people on here that will object to a design requiring you to trust the owners of your infrastructure.

Signal is the chief example of this kind of design. All they can provide a government is the creation date of someone’s account, and the last time they tried to check for messages. Neither message content nor metadata (who sent messages to whom) is accessible, assuming the app follows the design and the design doesn’t have defects.

There was actually a pre processor that used the characters ᐸ and ᐳ as part of faked generics.

Your decision here is based on balancing security and convenience. It's a tradeoff that you have to decide on based on your situation.

Most average users are willing to trade the upside of the SaaS apps (sync is easy and pretty secure) for the downside (have to trust a third party like 1Password, that they won't send you a malicious client that slurps your master password).

We're technical, so we can use Password Store[0] and avoid the downside of the SaaS programs (have to trust a third party) while still having sync. If you're pissing off entities who might conceivably blackmail or hack 1Password, Password Store is the bare minimum.

[0] I'm not addressing that Password Store doesn't encrypt the sites it has logins for, just the fact that it doesn't require entering your master password in a web page.

Something like the Canon Cat. One big file with quasimodal search. Embedded images and probably arbitrary files. Maybe spreadsheet-ish features (ability to dynamically fill out data generated from code).