Incumbent US-focused auto makers/sellers, whether HQ'd in the US or elsewhere, should be worried about their own collective abandonment of the market for entry-level cars and small cars in general. The idea that young person can jump directly from a bicycle or driving the family junker to buying a $60,000 SUV with no entry point in between is clearly not sustainable, but that's where the current crop of automakers is headed. So yes, if they continue down that path they should be concerned about new competitors who have figured out how to make affordable and regulatory-compliant small cars.

An irregularly shaped chunk of solid Inconel? Sure to tumble as it passes through the atmosphere? I don't think anyone who worked in high temperature industrial process was surprised by this; not sure what NASA was thinking.

And yet the SmartCar (the original one, not the SmartForTwo) was certified in the EU and uncertifiable in the US. We can argue all day as to whose safety and registration regulations are stronger or in some sense better (neither of which was part of my OP), but the fact is they are different. And the PRC EV manufactures have so far not see a positive return in meeting the US/Canada standards and entering the market.

So far the EV autos designed in the PRC have not attempted to meet US/Canada safety and regulatory certification standards. BYD has an engineering and manufacturing center in the US for their EV municipal vehicles so they could certify a car if they thought they had a market for it, but so far that doesn't seem to be the case. Perhaps the US EV makers could concentrate on making their products more price competitive and improving sales and service so they don't have to resort to a trade war to win the market?

That's a symptom, not a cause. EVs are all newer and built with current technology; there are still many ICE vehicles in production based on 2005 designs, technology, and parts. As those age out of the production system - as they are doing now - they are being replaced by new designs (whether ICE, hybrid, or EV) that use extremely expensive and non-repairable modern technology and parts. Have a fender-bender in one of those, EV or ICE, and you will be hit with a $5000 repair bill. The days of "beat to fit; paint to match" are over.

We have created a virtual reality remote control surgeon based on Arthur C Clarke's 1971 story "A Meeting with Medusa, or What Can Go Wrong Using Virtual Reality Remote Control For Precision Operations".

Apparently Apple does not allow 3D porn in these devices. Looks like a classic rerun of Sony Betamax vs JVC VHS format wars. Sony prohibited porn and JVC was not too strict and that tipped the balance. (Well, I did not check snopes, because I would rather live with this belief than knowing the truth)

Why should anyone waste their time

For the "time" part of that question I'd posit that in most cases it wouldn't take any additional time.

I don't particularly want to get bogged down in PHP 7.4, it was just a random example, but a git blame in the problematic code probably shows the code has been there untouched for a long time and it would be almost zero extra effort to include PHP 7.4.* in the CVE listing.

And I am not proposing it forever, just for a defined period or once some threshold of CVEs have been issued after a piece of software goes EOL.

For the "why", it's the same reason why CVEs exist at all, to provide information to help people make informed decisions and reduces the chances of ending up here (which I stumbled into just now)

Outside the issue of "people" misunderstanding CVEs, several downstream tools make use of CVEs to monitor software and currently some are blind to issues in EOL software (again, not to pick on Ubuntu or PHP specifically, but it says PHP 7.4 is "Not vulnerable". which is very different to it being vulnerable but unsupported.)

Having automated tools report more effectively will save people "time" in the long run.

Security is about defence in depth and better information at the start of the CVE issuance chain will have all sort of positive effects down the chain

The revolutionary new product from Apple iGrain is the recommended way to dry wet iPhones. It retails at 14.99$ a pound. Use of any other grain to dry wet phones voids the warranty. It has special sensors to detect non Apple approved grains being used to dry the phone.

Chrome should encrypt the save state and it can be decrypted only by chrome...

I see, MS can always launch chrome and scrape the URL from the screen ... yeah, I see chrome cant protect itself from this ... MS owns the OS it can override all permissions and stuff.

They buy discover, charge it to their discover card, and the clerk will ask sweetly, "do you want to get 50$ in cash too?"

Someone is paying a lot of money to pump these "EV sales are crashing; EVs are FAIL" stories throughout multiple media channels the last six weeks. Reality is that EV sales growth is flattening out a bit from astronomical to just high, and absolute EV sales continue to climb. But when e.g. Norway has had 40%+ EV marketshare for new car sales for 5 years sales increases are eventually going to flatten out. Same thing will take longer in the US but is happening to a certain extent in Southern California, which is a large part of the overall vehicle market in the US.

No CVEs will be assigned for any issue found in a version of the kernel that is not currently being actively supported by the Stable/LTS kernel team.

This is one part of the way CVE's are issued (not specifically for the Linux kernel) that I don't like because I think it leads to people not being aware of vulnerabilities.

An example from non-kernel software, if you try and find vulnerabilities in PHP 7.4.33 you won't find any, not because there aren't any, but because it is end of life and no longer supported.
From then on you just get things like CVE-2023-3824

In PHP version 8.0.* before 8.0.30, 8.1.* before 8.1.22, and 8.2.* before 8.2.8, when loading phar file, while reading PHAR directory entries, insufficient length checking may lead to a stack buffer overflow, leading potentially to memory corruption or RCE.

which an unknowing reader (and many automated security checking tools) may interpret as not effecting PHP 7.4.33.

I think it would be much better if there were some post end-of-life period for which CVEs are still created (either a fixed time period, or until a certain number of CVEs had been issued) so that the final version of end-of-life software doesn't seem magically immune to issues. If nothing else a few more red flags being thrown in security tools might help some people resource upgrades, a big red "vulnerability" often seems to be easier to motivate management with than "end of life"....

It does not have to before. But if they trace the bomb threat to a device that has ProtonMail, once court orders it, all Meta data on that phone should be disclosed.

It's not some random political act. A hoax bomb threat. ProtonMail should comply, if it can't it should be banned.