You obviously do not understand the difference between a submarine and a submersible at all. Nor do you appear to understand the difference between a camera control, meant to entertain the guests, and a safety-critical system.

So, I'm going to posit that it is you who should say no more about this situation.

No, most of the HD factories (run by multiple companies) were located in Thailand (not Taiwan) for historical reasons, and all of the factories were damaged due to flooding in Thailand.

>>> ....the Beatles are the most insipid, obnoxious band in the past 80 years.

Hard to disagree if you're talking about their "I wanna hold your hand" period. Hard disagree on the later albums, but that may be because my personal preference is the moodier, more cynical, more thoughtful style they embodied.

>>> That thing's ridiculous - looks alone will kill it.
Have you SEEN the latest Ram/F-150/Silverado? The manufacturers have gone completely loony in trying to make the most humongous, most "bad boy" looking, most intimidating, trucks on the planet. They're so far over the top that in 20 years people will be laughing at them like they laugh at the ridiculous "fin wars" of the 1950's/1960's. And why do they make them that way? Because truck buyers buy them. Heck, the Cybertruck looks almost pleasing compared to some of those monstrosities.

Do all isotopes of Element 115 has such a short half-life, including the ones we haven't created yet?
U-223 has a half-life of about half a millisecond, U-236 has a half-life of about 10^7 years. A few neutrons can make a remarkable difference.

Chicago (and Boston, and Denver) are terrible places to live. They have plenty of water, but the cold temperatures require huge amounts of energy to keep all those 100 year old houses warm.

Oklahoma and much of the rest of the midwest are terrible places to live. The storms and tornadoes kill dozens of people yearly, and almost every house takes up what could be productive farmland. Besides, they probably raise most of the flat-earthers because no one from there can conceive of anything but flat land. ;)

The Gulf Coast and Southest coast are terrible places to live. Hurricanes blowing through have caused more financial damages than any other form of natural disaster in the USA.

California is a terrible place to live. Between occasional earthquakes that essentially destroy a city, and an environment that rocks back and forth between arid and desert yet tries to support a zillion people, it's almost unliveable.

So where's left that I should live? I'm sure I can find those flaws also.

And I thought only the USA was going through a caveman anti-intellectual, anti-science phase.

>>> When I develop software, I make sure that my error message contains as much data as possible about what went wrong

So, when you get to 50,000,000 lines of code, which likely contain 1,000,000 error conditions, how much will your program be bloated by those 1,000,000 detailed error messages? And how much will it cost you to localize those error messages into 100 different languages? And how often will the best you can do be "The credential is invalid", because the error is coming from a mid layer that doesn't know what the app layer is doing, or why the lower layer is unhappy?

I hate Microsoft error numbers with a passion, but I'm not sure that there's a better answer at their scale.

I'll agree with you that, sadly, there are few 'decent' fingerprint scanners in the wild. I will submit that Apple devices and HP Enterprise / Lenovo Enterprise laptops with fingerprint sensors have 'decent' fingerprint scanners, though, which makes them not rare.

>>> that just makes them an improved scanner
Well, that's your uninformed opinion. I like to think mine is just a bit better informed.

I will agree that a biometric is not a perfect authentication device; it can be spoofed, it can't be changed, and as this attack shows there is a non-zero False Accept Rate. However, in a world where the most common passwords are: https://cybernews.com/best-pas... , the remarkable people like yourself, who can remember dozens of complex passwords and have information that Mossad is interested in, aren't common. For you, a biometric is probably not the right answer (although, cautionary tale: https://xkcd.com/538/).
For the billions of less capable people (https://www.youtube.com/watch?v=_JNGI1dI-e8) who are more interested in not having hackers from halfway around the world take over their XBox account, biometrics combined with something like webauthn are a remarkable advance.

Pairing isn't really a problem.

All of the secure sensors we sold were paired with the host. Some of them used public key processes to assure that the sensor would only work with a host from the particular OEM - not our choice, but they were writing the checks.

Apple chose the path of pairing at manufacturing - so replacing the fingerprint sensor is not something you could do as a third-party repair. That was their choice.

Pairing a new sensor can easily be done securely on the screen, but OEMs chose not to do that. In our architecture, swapping out a sensor generally meant that the data encrypted by that sensor (for example, the fingerprint templates, as well as credentials that signed you into the host) were lost. It was not possible to replace the fingerprint sensor and immediately have access to the host. You could, however, replace the sensor, log into the host using alternate credentials (password, etc) and enroll. If you didn't have alternate credentials, well, you had a problem.
I doubt very much that any current generation mass market fingerprint sensors (other than Apples, if they're currently shipping fingerprint sensors in anything) implement this level of security.

Yes, you can. As a matter of fact, there is a group in Germany who captured a photo of Angela Merkel's hand as she was waving at a public event, and were able to generate a spoof fingerprint from the photo (https://www.theregister.com/2014/12/29/german_minister_fingered_as_hackers_steal_her_thumbprint_from_a_photo/).
The problem with having a fingerprint is then turning it into a usable spoof. In the early days of fingerprint sensors, it was easy; an image or an easily created Gumi bear (gummy bear) mold could be used. By the time I got out of the business (maybe 5 or 6 years ago), spoofs could still be created, but one had to get pretty exotic about the materials used to be successful. No problem for a three-letter agency, but your standard hacker was going to have problems.
Then, of course, the OEMs wanted cheaper and cheaper fingerprint sensors, and things like resistance to spoofs got dropped by the wayside in the quest for saving a few pennies. I really don't have any sense for how difficult it is for currently available fingerprint sensors.

There's lots of magic involved in making a fingerprint sensor work, but the deepest, blackest magic is in the piece of software called the "Matcher" that compares the image from the sensor with the stored fingerprint template (the stored template is generally not an image, it's a processed description of the multiple fingerprint images taken during enrollment). I don't know what sensor is in the Kensington, or what matcher software was used, but primitive matchers had the kinds of issues that you're describing. They tried to store an image of your fingerprint, then match against that in succeeding days. That didn't work well, as you're noting, because fingerprints change from day to day - humidity can cause the skin to expand or contract, daily damage can cause images to change, etc. More sophisticated matchers work hard to extract information from the enrollment images that doesn't change over time - ours involved various neural nets and a process that, even after having it explained to me several times, I didn't fully grasp.
Yes, it is possible to update stored templates over time, but it's very risky - there are various methods that an attacker could use to modify the template over time to make it easier and easier for them to log in. We looked into it, but never pulled the trigger on that.
The iPhone has a sophisticated fingerprint sensor and matcher - it came from Authentec, who had been doing fingerprint sensors for a long time before being acquired. I have an iPhone 8 with their sensor, and it always matches (unless my finger is wet), despite not having re-enrolled in years. I doubt very much that it's updating the template over time, we didn't have to and had similar performance.
So, short answer, the Kensington has a crappy Matcher, and there's not much you can do about it.

Disclaimer: I worked on fingerprint sensors in the 00's, shipping a couple hundred million units to major Phone and Laptop manufacturers.

Our top line sensors fully encrypted all communications between the sensor and the host, similar to what the Authentec sensor in Apple devices used. Note that the researchers had zero success against Apple devices. We sold tens of millions of these to the likes of HP and Lenovo. But the mobile world wanted cheaper, cheaper, cheaper and simpler, simpler, simpler - the mobile customers neither wanted to pay an extra dime for encryption, nor did they want to deal with the hassle of encryption. So we sold them hundreds of millions of sensors with no encryption, and eventually exited the business when we could no longer compete at the sub-$1 price points.

What these researchers were attacking were the bottom-of-the-barrel sensors, selling for pennies, that the manufacturers demanded. The result isn't too surprising. It's mostly an attack on the architecture of the Android fingerprint stack, written by Google and common to all manufacturers - whoever thought that enforcing retry lockouts AFTER matching wasn't thinking very deeply. That's like accepting passwords, validating them, then deciding whether or not the user is locked out due to too many bad passwords in a row; there are way too many side channels attacks to even think that this is a good idea in the 2020's.

We built custom chips with a licensed processor in them (not ARM, but similar). Every time we created a new chip (once or twice a year), there was a license fee to be paid. Our chips sold for about $1, so every license fee was a significant hit to profits. We would have switched in an instant.
Now, imagine an embedded MCU supplier like NXP - they build the 50 or so MCU's that you might find in your car running everything from the antilock brakes to the personalized seating. Perhaps they charge $4 for their MCU; but ARM comes along and starts selling a similar device for $3.50 because they don't have to pay a license fee to themselves. If NXP wants to stay in business, they'll switch to RISC-V in a heartbeat just to stay price-competitive. And it's not like absolute performance is much of an issue in moving six motors in the drivers seat to defined position....

There are a metric buttload of 48-60 MHz ARM-based MCU's out there, orders of magnitude more than there are multi-GHz ARMs. There are probably 3 or 4 of them in your phone complementing the multi-GHz main CPU, there are probably 50 of them in your car. This is a market that RISC-V is primed to take over today, while it matures and reaches into the high-end over the next 10 years. Despite these chips being vastly cheaper than the latest Qualcomm chip, they are likely a larger source of revenue to ARM, a revenue stream that's under attack.