jmts

AM reception is essentially the direct conversion of the strength (amplitude) of a given radio frequency into an audio signal. Any other noise present at the same frequency is added to the signal (superposition/interference) and therefore impacts the strength of that frequency at the receiver. Therefore it is impossible for the receiver to know whether the amplitude it received is just signal or is signal plus noise.

The claim 'the effect of random noise is to amplitude modulate' is probably not 100% correct, because to my understanding it's not actually performing modulation (the modulation happens at the transmitter but the noise happens between the transmitter and receiver), but it is impacting the amplitude at a given frequency and to a receiver this is impossible to know whether said change in amplitude happened before modulation (signal) or after modulation (noise).

FM works better because it is easier to detect the change in frequency independently of any change in the amplitude.

I'm unsure of what the correct terminology would be, but (for my linear algebra brain) you could say something like, for FM the noise dimension is orthogonal to the signal dimension, while for AM the noise and signal dimensions are the same. Therefore for FM any change in amplitude in the noise dimension should be mostly isolated from the signal dimension, while it is essentially impossible to tell what is noise and what is signal for AM - you could probably do some radio equivalent of a differential pair in order to detect noise and remove it, but then why would you bother when FM has improved noise rejection anyway.

Please see the section titled "Faster multiplication"

My understanding of PC game development at the time was that most games would re-implement their own drivers for system hardware, hence why you would often need to select what kind of graphics card, sound card, and their settings during the setup. As such, a game running from a boot disk is closer to just skipping DOS and having no OS rather than implementing a custom OS, although from another perspective you might just say that the game is the OS.

Oi Oi Oi!!!

Ramtha's School of Enlightenment used to come to a university I used to work at between sessions while the students were away. They would have a section of paddock fenced off and would wander around it blindfolded making "PSSHHTT" noises to stop running into each other (I assume). They definitely seemed like a peculiar bunch.

It's hard to tell what's actually happening in that clip. To me it looks like the chain is actually fully off the rear sprocket just before the rear locks up (it appears to have come off around 1:12). At that point in time the rear wheel should just be free spinning. It also appears to be free spinning during the highside, which is strange because I would expect the most likely non-rider-error issue in this case to be the chain binding between the rear sprocket and the swing arm.

I'm almost inclined to call that one rider error. Their general body language and control of the bike don't suggest to me that they're an experienced rider, and it almost looks like they've just panic-braked and locked up the rear, except it's an odd speed and place to have done that too.

Programming is all about abstractions and the ways they interact. Specifically this article talks about what it means for two instances of an object to be "equal", which depends very much on what kind of equal you care about.

Consider the possibility that you order two laptops from your favourite computer store. When you order them, you customise one, then in the shopping cart you hit "+1" to order two of them, so for the purposes of this example they are functionally equivalent. When they arrive though, they have different serial numbers ABC, and XYZ. So then we start asking the question, are they equal?

One way of asking this question is "Do these two things perform the same function?" to which we can answer yes, ABC and XYZ perform the same function - this line of questioning treats the laptops as ValueObjects as described in the article - laptop ABC and laptop XYZ can be swapped for each other without concern about whether they will behave differently.

Another way of asking this question is what amounts to something closer to "Is this thing the one that I care about?". This line of questioning treats the laptops as ReferenceObjects. You've just received both laptops, taken them both out of the box, they're functionally identical except that you've decided that you want to use ABC for work stuff, and XYZ for personal stuff, and now you have some work stuff to do. You pick up one laptop and ask "Is this laptop ABC?" - not because the function of the laptops matter at this point, but now because of what they represent.

Both have their pros and cons (as described, ValueObjects are better when they are immutable, ReferenceObjects might tend to be more complex), and different languages make different choices about whether certain language primitives and standard objects/classes are implemented as ValueObjects or ReferenceObjects, but understanding them both conceptually allows you to write code that forces one kind of behaviour because that's what matters most for your chosen solution, independently of what the language you are writing it in has as its standard behaviour.

MTBF: Mean time between failures

MTTR: Mean time to repair

Hell on Earth.

As an embedded software engineer, my only response to this is that sometimes I'm surprised anything works at all. Bugs in silicon do exist. Often there's nothing a supplier can do about it. Either you find a different part or find a workaround at a higher level.

You're not old. You're elite!

As a guy with a brother, I can't help but read this as yet another ploy to get one-up on the brother, but this time in the name of science!