nominatronic

That's exactly how Challenger was lost.

> The researchers analyzed US-flagged ships less than 1,000 gross tonnage, which includes primarily passenger ships and three types of tugboats.

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.

It's only I/Q on the receive side. The TX side is FM only.

> Fibers and async/await are backed by the same OS APIs

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.

Yes, but that doesn't change the fact that out of all the accounts included, most of them won't be actively playing games right now.

A similar fun example is the distribution of Elo ratings on a chess site, e.g. here's the weekly distribution on Lichess for Bullet games (less than 3 minutes):

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.

“For instance, on the planet Earth, man had always assumed that he was more intelligent than dolphins because he had achieved so much—the wheel, New York, wars and so on—whilst all the dolphins had ever done was muck about in the water having a good time. But conversely, the dolphins had always believed that they were far more intelligent than man—for precisely the same reasons.”

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

The cracked versions will simply disable all these anti-features.

All you will do is annoy legitimate users.

Jamie Zawinski wrote a similar shim layer to port xscreensaver from OpenGL to OpenGL ES, and had quite a rant about it: https://www.jwz.org/blog/2012/06/i-have-ported-xscreensaver-...

Giant predatory dragonflies the size of seagulls, if the fossil record is anything to go by.

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

It's a transformer - I'm guessing it's the magnetics for the 10base2 port.

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.

Circa the late 1990s, there used to be not just this shade in the source, but a message that would be printed in the logs if a 3c501 were used. It read something like:

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

Say someone finds a bug in your software. They're running release 4.1.2. They'd just upgraded from 2.6.4, which is three years old, where what they're doing used to work.

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

$ <run test, which passes>

$ git bisect good

$ git checkout v4.1.2

$ <run test, which fails>

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

This is basically the idea of io_uring [0], although that mechanism is specific to certain I/O operations rather than being a generic queuing system for syscalls.

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

I'm not a materials scientist, so I probably don't really know the right answers to these questions or what the correct terms are. All I can do is try give you an idea of what happens in practice from my limited experience, and my working understanding of it.

> 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

The gasket does deform. But that doesn't let the pressure out.

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.

71: same as above up to 55, then left to 60, up to 65 and right to 71.

Diagonal moves by alternating directions are helpful.

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.

63: Down to 5, right to 20, up to 25, right to 30, left to 38, up to 45, left to 48, up to 57, left to 63.

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

"Vendors keep bitstream formats secret, so Verilog is as low in the abstraction hierarchy as you can go. The problem with Verilog as an ISA is that it is too far removed from the hardware."

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.

Executive summary:

Cessna: How fast.

Tower: 6

Beechcraft: How fast

Tower: 8

Hornet: Yo how fast bro

Tower: Eh, 30

Sled: mfw

Sled: How fast sir

Tower: Like 9000

Sled: More like 9001 amirite.

Tower: ayyyyy

Sled: ayyyyy

> Slow as molasses

Slow as custard, surely.

It's a classic, but per rules the title should include "(2003)". I remember this doing the rounds on Livejournal.

The word you're looking for is "missiles".

The idea of dogfighting drones makes very little sense. If you build a lot of expendable tiny planes with a high thrust to weight ratio and high-G maneuvering, there's no point having those then try to shoot some secondary projectiles at the target. It's far simplier to just fly them into it or detonate them close enough to cause fatal damage.

There's no problem in principle with using public key cryptography to sign messages sent by ham radio. So authentication is possible although it's not common in practice. It's encrypting the content of messages that's not permitted.

Nope. It takes far more delta-V to get to the Sun than to get to Mars.

To get to Mars you need to change your solar orbit from that of Earth to match that of Mars. The difference is a small fraction of Earth's orbital velocity.

By comparison, you only need to add about 41% of Earth's velocity to escape the solar system entirely.

But to get to the Sun, you need to subtract 100% of Earth's orbital velocity. It's a colossal amount of delta-V.

> You do at least get rid of the Lovecraftian clock distribution tree that's getting problematic for current synchronous logic.

No, you don't. You make it even bigger and far more complex.

You can take any synchronous design, and refine the clock gating further and further, to the point where no part of it gets a clock transition unless it actually needs it on that cycle.

And then when you're finished, congratulations, you've made an asynchronous circuit.

Fully asynchronous design and perfect clock gating are one and the same thing.

The clock distribution and gating approaches we already have are actually a sign of progress towards asynchronous design; they're just quite coarse-grained.

Of course, it's probably not the case that a clock-gating transform of an conventional synchronous design is also the best possible solution to a problem, so there's clearly still scope for improvement. But a lot of the possible improvements are probably equally applicable, or have equivalents in, optimising clock distribution and gating in synchronous design - because that's ultimately the same thing as moving towards asynchronicity.

So talking about clock distribution issues as a problem that will just go away with asynchronous design is misleading.