The not-so-short story Ender's Game was great. The novel Ender's Game was awful. I hope someone told him it was too long, too repetitive, and too Gary Stu. I wish he had taken that feedback to heart.
The novella is the only version I've read. I came away both not understanding why a longer, novel-length version would exist, and with no interest in reading anything even slightly worse than that from the same author (which I'm given to understand describes most of his other work).
You measure the charge (if it is there) before it is completely gone (if it were ever there). Capacitors always leak, these capacitors leak fast.
Measuring the charge also removes some of the charge -- fast, compared to the leak spead.
DRAM chips have a circuit that writes the value back -- charges the capacitor up if there's supposed to be a charge, drains it if there's not supposed to be a charge.
Refreshes and normal reads are the same, except that normal reads sends the value(s) to the output pin(s) on the chip.
He has "only" shown the basic grid of capacitors and transistors. The chip he shown has no circuit to measure charges or to write them back afterwards. This makes it easier to test the basic grip and the basic capcacitors.
Pretty sure the proper read out and write back circuit comes in the next video.
The oceans are unreasonably large, you would need an astronomical number of hydrophones to get any type of coverage. Hydrophones are primarily placed in choke points for this reason.
Both the US and China have newer more advanced capabilities than a 50 year old system...
> [SOSUS] was the primary cuing system that antisubmarine forces used to localize and potentially destroy targets for over forty years, but secrecy largely kept that fact from the fleet. The lack of strong fleet support was a factor when budget cuts after the Cold War fell heavily on the surveillance program.
Driving cars down every street in every advanced country to take photos seems ridiculous, but Google did it (StreetView) and the US DoD has more money than Google...
If the carrier is aware of the overflight (and I assume the USN isn't run by complete idiots), it can adjust course after the overflight. And at 30 knots, can be 100s of miles away from its initial location when the satellite returns.
Now satellite constellations make it harder, since their numbers limit this strategy. But currently, none of the know systems utilize SAR like the LEO satellites, so they wouldn't function well in bad weather. They'd have to rely on optics which can be severely degraded.
A carrier can likely get far enough to generate a miss. Missiles and drones have very limited sensors so in order to hit anything another platform has to cue them with a fairly precise target location. In other words, an adversary like China would need to have enough satellites, submarines, and/or patrol aircraft to maintain a continuous target track long enough to make a decision, launch the weapons, and have them fly out to the target. Current thinking is that China could probably do this inside the first island chain but would struggle to put the pieces together further out in the open Pacific Ocean.
My understanding is to track something like a carrier the satellite has to be in low earth orbit. Those circle the earth about every two hours. So it is not so much the carrier outruns the satellite; it is the satellite outruns the carrier.
A typical LEO optical satellite has maybe a 60km swath at high resolution. And it isn't just a couple of hours - an orbit doesn't go over the same spot every two hours. You only may get 1-2 passes a day with a given type of constellation.
China would be using their Yaogan-41 (geostationary) to try to track, which might work, in good weather, during daytime, IF the carrier group was south of Japan (it's equatorial). Carriers deliberately transit through weather, strike groups disperse broadly and use decoy behavior in wartime, and a geostationary optical satellite won't know which blip is the carrier and which is a support ship 50km away.
Every night, you lose the carrier group and have to find it again in the morning, if you can. Usually you can't, even with China's layered approach using optical, SAR, ELINT, and OTH radar.
Electrifying the economy with renewables (and I’ll count nuclear as renewable) is the single most important thing countries can do right now to ensure their own military and economic security.
Distributed solar and wind are more difficult to bomb than nuclear, so they’re probably a slightly better choice (especially if they’re built to island / work off grid).
Non-nuclear renewables ("intermittables") need something else as back up. That is almost always natural gas.
That's been causing a lot of problems for Europe for years now.
There's the dependence on Russia, there's the dependence on the North Sea supply -- and the full-scale invasion started while the Danish fields were off-line -- and there's the dependency on LNG imports from actors that are either unreliable (the US) or far away (the US and Qatar) or both. LNG is also quite expensive.
There’s some blue text with an underline labeled “AV2 Specification”. That’s called a link. If you click that, you’ll see the date the spec was ratified and some details about it.
Are you suggesting that I read the whole spec and then read the whole AV1 spec and diff it in my head? Or are you referring to the only text in that link describing differences with AV1: "enhanced support for AR/VR applications, split-screen delivery of multiple programs, improved handling of screen content, and an ability to operate over a wider visual quality range"? This is not a description of technical features, it's a high level statement of aspirations. I'm asking what features they added to achieve these goals.
I was hoping someone familiar with AV2 might be frequenting this site alongside the much larger population of smartass pedants, and they might be able to summarize the new features in a way useful to me and others.
I don't agree. Null is an artefact of the type system and the type system evaporates at runtime. Even C's NULL macro just expands to zero which is defined in the type system as the null pointer.
Address zero exists in the CPU, but that's not the null pointer, that's an embarrassment if you happen to need to talk about address zero in a language where that has the same spelling as a null pointer because you can't say what you meant.
Null doesn't expand to zero on some weird systems. tese days zero is special on most hardware so having zero and nullptr be the same is importnt - even though on some of them zero is also legal.
Historically C's null pointer literal, provided as the pre-processor constant NULL, is the integer literal 0 (optionally cast to a void pointer in newer standards) even though the hardware representation may not be the zero address.
It's OK that you didn't know this if you mostly write C++ and somewhat OK that you didn't know this even if you mostly write C but stick to pre-defined stuff like that NULL constant, if you write important tools in or for C this was a pretty important gap in your understanding.
In C23 the committee gave C the C++ nullptr constant, and the associated nullptr_t type, and basically rewrote history to make this entire mess, in reality the fault of C++ now "because it's for compatibility with C". This is a pretty routine outcome, you can see that WG14 members who are sick of this tend to just walk away from the committee because fighting it is largely futile and they could just retire and write in C89 or even K&R C without thinking about Bjarne at all.
reply