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.

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

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.