This is the buried lede. They are excluding basically all cargo shipping.

- Very little of the shipping industry is US-flagged. Most commercial ships sail under flags of convenience such as Panama and Libera, because of their reduced regulations and costs.

- Nobody carries cargo any distance in vessels of less than 1000 gross tons, because that scale would be uneconomical to operate. Modern seagoing cargo ships have about one crew member per 8000 tons of cargo.

async/await doesn't require any OS APIs, or even an OS at all.

You can write async rust that runs on a microcontroller and poll a future directly from an interrupt handler.

And there's a huge advantage to doing so, too: you can write out sequences of operations in a straightforward procedural form, and let the compiler do the work of turning that into a state machine with a minimal state representation, rather than doing that manually.

https://lichess.org/stat/rating/distribution/bullet

It's easy to understand why this happens:

- Player ratings will fluctuate by small amounts as they win and lose individual games.

- People are happy to stop playing when their rating is at e.g. 1503, but if it's 1497, they'd rather play just one more game than leave it that way.

- At any given time, most accounts are not playing, so the distribution shows a bias towards values just over a 100 Elo threshold.

The other neat thing is that you can see this effect reduce as you look at longer time controls:

Blitz (less than 10 min): https://lichess.org/stat/rating/distribution/blitz

Rapid (less than 30 min): https://lichess.org/stat/rating/distribution/rapid

Which makes sense because the time and effort of gambling just one more game to get the rating back over the line is higher at the longer time controls.

― Douglas Adams, The Hitchhiker's Guide to the Galaxy, 1979

All you will do is annoy legitimate users.

https://www.sciencedaily.com/releases/2010/10/101029132924.h...

You can see the two pairs of enamel wires coming out on each side the sides. There are two windings, both wound on a core spool with its axis perpendicular to the board.

What you're seeing looking like the lens of a camera is a hole in the middle of the spool, presumably used during manufacture to hold it while winding.

"Detected 3Com 3c501 (THROW IT AWAY!!!)"

You put together a test case and sure enough, it fails on 4.1.2 but passes on 2.6.4. But when did it get broken, and how? The software is complex and you can't see an obvious problem. And looking at the history, there's 4000 commits between those two tagged releases. It would take forever to test them all.

You can do something smarter, though. You pick a point somewhere in the middle. Maybe it's around version 3.2.0. You test that version, and it passes. So - assuming the bug only got introduced once - the problematic commit lies somewhere between 3.2.0 and 4.1.2. You pick a version between those, and repeat the process. Rather than testing 4000 different versions, you only have to test about log2(4000) = ~12 versions of the code.

The git bisect command is designed to help you with this. If you run the following commands:

$ git bisect start

$ git checkout v3.2.0

$

$ git bisect good

$ git checkout v4.1.2

$

$ git bisect bad

...then git bisect will take over, choose the commit half way between those, check it out for you and prompt you to run your tests and report the result with 'git bisect good' or 'git bisect bad'. Then depending on the result, it will choose the next commit to test, and repeat the process until it can tell you exactly which commit introduced the bug.

But maybe your test takes a while to run. Even with fewer intermediate versions to test, you're going to spend all day running tests, waiting for the results and telling git bisect what to do next.

So you automate your test into a little script. If the test passes, it exits with a result of zero (success). If it fails, it returns non-zero.

And then you run:

$ git bisect run ./my-test-script

and go do something else with your day. When you come back, it will have automatically found the commit that introduced the error. Magic!

But there's a cost. For this to work, you need discipline from day one. You can't have commits in the history that say "WIP, changed some stuff, not finished yet" and others that fix things up later in the branch. You need to make sure each commit is a fully self-contained change that leaves the code in a working, testable state.

If you have a small number of individual commits at which the code won't build cleanly, or which break testing for whatever reason, you can work around them with 'git bisect skip' - and you can implement this in your test script with a special return code. But if this happens too much, the whole approach becomes unmanageable.

[0] https://lwn.net/Articles/776703/

> I think a more refined version of your parent poster's question might be, why doesn't the gasket continue to extrude itself out of the gap, even though its ultimate strength has been exceeded by possibly several orders of magnitude?

It does continue to extrude itself out of the gap. The more you increase the pressure, the more gasket material comes out. And this isn't an elastic, reversible process - it's plastic deformation which leaves the gasket permanently thinner after you unload the cell. So the gasket material has failed, in terms of what we'd usually use "failure" to mean in an everyday mechanical structure.

But your expectation seems to be that beyond the point of failure, the gasket material should basically just flow freely, like a liquid. That's not what happens. Failure is just the point at which permanent damage starts to occur. There's a whole separate region of behaviour beyond that point, which depends on the material and the conditions.

I mentioned that in this work, they go beyond the yield strength of diamond. If you look at Fig 6 in the actual paper [0], they have an electron microsope image of the diamond tip after unloading the cell. It's permanently and severely damaged, with concentric ring cracks around the tip. So the diamond did "fail", in the formal sense of that word. But that doesn't mean it didn't do the job they needed it to do anyway.

> You could say the small center area of pressure is acting on a very thick cross-section of gasket (like a big pipe with a tiny inside diameter), but isn't there a limit to this where the pressure doesn't care how much extra material you pile on?

There probably is! But that's not what failure means, and so it's not what numbers like yield strength refer to. Failure for your big pipe is the point at which the internal pressure starts to permanently bulge the pipe. It's not necessarily the point at which it ruptures. That can happen at any point beyond failure, depending on the material and the conditions.

> Or for a more layman example, Jello has some amount of tensile strength, but you can't exactly build a cannon out of it regardless of how thick the barrel is. Metal at these pressures probably behaves more like jello than metal, so what's keeping it together in this case?

Let's take a layman's example that better fits the question at hand, and requires a bit less hypothesising about jello.

Rubber has some amount of tensile strength, but you can't build a car's engine block out of it.

It works just fine for the head gasket, though, where it has to successfully contain the extreme pressures that occur in the cylinders during the combustion cycle. It works in practice in the conditions where it's compressed between the head and the block.

And that's exactly the role that the rhenium gasket plays in a DAC.

In both cases, there is some pressure beyond which it will no longer do the job. But there probably isn't a simple number you can look up which will tell you when that will happen, based only on the material.

[0] https://sci-hub.se/https://doi.org/10.1038/s41586-019-1927-3

I'm not in this field, but I know several experts in it. I've helped out on experiments and have loaded DACs myself up to 20GPa or so.

I'll describe how it works in practice at that kind of pressure, and then what I understand of the different techniques needed for the extreme pressures used in this paper.

Loading the DAC is fiddly and done by hand. You start off looking through a microscope at the bottom side of the DAC. The lower diamond is pointing up at you. The tip of it is truncated at the point to give a flat end face around 100um across. With tweezers and a steady hand, you place your gasket - basically a rhenium washer with a maybe ~50um inner diameter - on top of that, with the outer edge of the gasket overhanging the edges of the diamond tip.

Then you need to drop two things into the hole in the middle. A little fragment of your sample material, and a tiny piece of ruby. The ruby is your pressure gauge! Ruby fluoresces, at a wavelength that varies with pressure in a known way. So when the cell is loaded, you can shine a laser through the ruby and look for the spectrographic line of the fluorescence to get the pressure.

Now you have your sample and your ruby sitting inside the gasket, but they're surrounded by air. That's not going to work. You need the space around them to be filled with a liquid, to act as a medium to distribute the pressure. So you take a little syringe and plop a drop of whatever your chosen liquid is into the hole. There are different things you might use depending on the experiment.

Now that you have everything in there ready, you can attach the top side of the DAC and bring the second diamond down onto the top of the gasket. The cell will need to have been carefully aligned beforehand to ensure that the diamond tips meet up flat in the middle.

With everything together, you can now start applying pressure. In simple DACs this is literally just a case of tightening screws around the outside by hand. For more precise/automated control, you can get cells with a built in gas membrane.

But your question was about the gasket - what role does it play? Well, firstly you need something there to hold your sample and your ruby and your liquid in place while you prepare and load the cell. If you just pushed the two diamonds together the liquid would just flow out, the diamonds would hit the sample or the ruby and crush them at a point, rather than compressing them under hydrostatic conditions.

But you need the gasket to give way when you start applying pressure, which is what it does. It gets thinner, and material is pushed out of the sides. When you eventually unload the cell, you can look at what's left of the gasket and see the imprints of the ends of the diamonds in it.

You still need the gasket to be made out of something very strong so that it doesn't pull apart completely. But it's playing a very different role to the diamonds. They need to be hard. The gasket needs to be tough.

The diamonds, by the way, usually sit in tungsten carbide seats, because that's hard enough to take the pressure transmitted through the wide end of the diamond, which is still pretty high. The carbide seats then widen out further to the point where the rest of the cell can be made from stainless steel.

But that's all at the measly 20GPa or so that I'm vaguely familiar with.

What I got from chatting to an expert about this paper was something like the following.

425GPa is crazy pressure. That's four million atmospheres. At this point you're actually beyond the compressive yield strength of diamond. If you tried to use flat-ended diamonds like I described, they'd shatter before you got half way to that pressure.

Instead, they use a focused ion beam to machine a recess in the face of each diamond, giving what's called a toroidal cell. You can actually see that in the compressed shape of the gasket in Figure 1a. The force is distributed in a ring around the outside, so that it stays within the range of what the diamonds can handle.

The sample in the middle is being compressed from above and below by the diamonds, and also from the sides by the gasket material being pushed inwards by the raised rings on the diamond faces coming together. So you're actually using it to help pressurise the sample even though you're way past the yield strengths of both materials.

It will have required some incredible capabilities to design, build, align and load that cell. Even aside from the question of metallic hydrogen, there's some serious showing off here just in terms of techniques.

69: Alternate down/right to 18, up/right to 30, up to 32, right, left to 40, up to 46, left to 49, up to 55, left/up to 65, left to 69.

I've also got up to 65 on similar strategies, but that's the best one I've got written down.

I wonder if the author is aware that the bistream formats for both Lattice iCE40 series and Xilinx Virtex 7 series FPGAs have now been reverse engineered, and there is a complete open source toolchain that can be used for these. So Verilog is no longer as low as you can go.

Efforts of this type are also underway for other parts and there is a growing movement in this direction - see talks from Clifford Wolf at recent CCC events.