Sorry for the late reply, I'm rarely logged in.

There are two reasons why building in the ocean makes economic sense: 1) Economy of scale. There's plenty of room in the ocean to make it as large as you like, and while building costs increase by the square of the width, capacity increases by the cube. 2) The walls can be thin because the pressure is on the convex side.

Build it in the ocean. Wall off a section of the sea and store energy by pumping water out.

Because I expect that the reason it affects only these two domains, is not because they are specifically mentioned in the site data delete procedure, but due to a subtle interaction of complex features.

If I'm wrong, and they literally wrote:

then sure, fixing the bug would end any special treatment, but that kind of code would stand out as a sore thumb in any kind of code review.

Various posts say various. I was curious about the claim that Oracle can't change the OpenZFS license, because there are other copyright holders. (Of course they won't, they're Oracle.) It's hard to tell whether the linked FAQ is backed by the legal opinion of an IP lawyer, or if it's just a random developer shooting their mouth..

And Oracle, being short of lawyers, forgot to include the clause that ensured that their right to re-issue under a different license included any later contributions?

Do you know what's the legal analysis of section 4 in https://opensource.org/licenses/CDDL-1.0? It would seem that gives Oracle some options.

I'm usually the first to reach for Hanlon's razor, and you know, even here I'll give google the benefit of the doubt in that this could be an accidental bug.

But that doesn't get them off the hook: The only way such a bug can exist is because there's code in there that special-cases these google domains. Maybe in a subtle way: It could be a special feature that any site could in theory use, but in practice is only used by google domains, and no-one else knows about it. In that code there's a site-data bug that they'll fix and call it a day.

But even after they've fixed the bug, the special-case code remains. And that's the real issue. The anti-trust case material. The reason not to use Chrome.

Humans also react to an image displayed for 0.42 seconds. The difference is that a human convinces themselves that it's probably nothing and keeps driving.

Sure you can. Drones.

Your car being made to stop. A fate worse than death for an American, I suppose.

What flaw? When faced with contradictory inputs, the car chose to stop. Which is exactly what it should.

That's where I found it.

I'm kinda confused as to how your problems with pip are fundamental to the Python language, when apparently you have the same kind of problems with ant and maven, which are written in a language very much different from Python.

Well, yes I can. I went looking, and the first Python script I found was smtpd.py, which imports sys, os, errno, getopt, time, socket, asyncore and asynchat. Standard library only.

Can you find any C programs that don't use dynamically-linked shared objects installed separately?

And on Windows, ditto. If you write python2 on the shebang line, that's what you get.

Just add that to your existing Python 2 programs, ensure that Python 3 is the default otherwise (which it probably is without you having to do anything), and you're all set. It's not like you're going to be writing new Python 2 programs, is it?

Only thing, that's not a Python language feature.

Some people have a build setup where the CI 'pip installs' everything from scratch every time, or a test setup where they "pip install -r requirements.txt" into a virtualenv every time they run the test. But that's just their build setup. They could stop doing that in an instant, and their program would still run fine.

If someone deploys to production in a way that's automated along those lines, with a requirements file that pulls in the latest and greatest of every package, then it's easy to see how that can go wrong. It's easily fixed, just pin the versions in the requirements file to the versions you tested with. Also, instead of using pypi.org directly, you can install from a local repo with only select vetted versions of packages.

Complain if you like if you see someone with a setup that's a little too dynamic, but it's not Python or pip that's making them do it.

Not necessarily. Sometimes you can get a lot of mileage out of a very few tests. If you test composite functionality that involves many modules, you can get reasonable coverage from a small number of high-level tests. Strictly speaking that's not unit testing, even if you do use a unit testing framework for it, but it works, so who cares what it's called.

Edge case errors are rarely type errors. The way to catch edge case errors is by having unit tests, regardless of language. And of course, by writing clean code that doesn't have too many special cases in the first place.

The people most likely to skip unit testing are the people who trust the static type checker too much.

I don't know what you call large, but I'm quite comfortable working with 100K SLOC Python applications. It does take discipline, but then writing large applications takes discipline in any language, and I'm not convinced that it takes more discipline to write a 100K Python program than it takes to write the 300K C# program with the equivalent functionality.

If I had a more precise number to quote I would have done so instead giving a very rough estimate, but it wasn't worth the effort find one. But you go ahead and dig up a precise number if it's important to you. The point I was making was that the French double-digit percentages are historical; there were a lot a deaths and very little testing in March.

The point is that the overall CFR is a terrible measure that you should not be using for anything. It depends on the testing rate, and the testing rate has fluctuated dramatically.

Contrary to what you seem to think, I'm not dissing US healthcare. I wouldn't dream of doing that based on such poor data.