I liked it better when the Ukrainians referred to the Russian invaders as Orcs...

The more interesting observation is that the part containing those 2 switches has been replaced twice since the advisory was issued. So presumably the questionable switches in the advisory were not used in the much newer replacement part.

I don't know what those parts are made of, but if they're metal, they might well survive. We'll have to wait for the final accident report to see what they learn about that aircraft's switches.

See https://ad.easa.europa.eu/blob... That's an old advisory (December 2018) that applies across a variety of Boeing aircraft. It should have been the case that all operators did and documented the required inspections.

Model 717-200 airplanes; Model 737-700, -700C, -800, and -900ER
series airplanes; Model 737-8 and -9 airplanes; Model 747-400, -400D, -400F, -8, and -8F series
airplanes; Model 757-200, -200CB, -200PF, and -300 series airplanes; Model 767-200, -300, -
300F, -400ER, and -2C series airplanes; Model 787-8, -9, and -10 airplanes; Model MD-11 and
MD-11F airplanes; and Model MD-90-30 airplanes of the potential for disengagement of the fuel
control switch locking feature.

1) Inspect the locking feature of the fuel control switch to ensure its engagement. While the
airplane is on the ground, check whether the fuel control switch can be moved between the
two positions without lifting up the switch. If the switch can be moved without lifting it up,
the locking feature has been disengaged and the switch should be replaced at the earliest
opportunity.
2) For Boeing Model 737-700, -700C, -800, and -900ER series airplanes and Boeing Model 737-
8 and -9 airplanes delivered with a fuel control switch having P/N 766AT613-3D: Replace the
fuel control switch with a switch having P/N 766AT614-3D, which includes an improved
locking feature.

It's my understanding that part of the cockpit was recovered pretty much intact, so I'm sure there'll be forensic investigation into those switches.

(It was at -1 when I responded...)

Parent post deserves more respect, it's insightful.

But as long as there are no legal consequences for software that has faults, whether security faults or functional faults, this approach of "throw shit out there, and disclaim responsibility for it" will continue.

https://science.slashdot.org/s... It's clearly a problem that current LLMs can't distinguish between relevant content and 'poison'. But we're told "Trust AI, it will save the world."

"Now you tell me!"

This from "The Register" piece:
The infamous Heartbleed flaw in the OpenSSL cryptographic library was the result of a memory safety error (an out-of-bounds read) in C code. And there are many other examples, including the mid-June Google Cloud outage, which Google's incident report attributes to a lack of proper error handling for a null pointer.

Within a few years, the tech industry began answering the call for memory-safe languages. In 2022, Microsoft executives began calling for new applications to be written in memory-safe languages like Rust.

General purpose memory safe languages have been around for a long time, for example Ada (1983) or Eiffel (1986). They just haven't been very popular, because they tend to require programmers to think harder. But software development is an industry that has a very short memory, and generally doesn't show much interest in techniques that produce better, as opposed to faster, software development. I guess it only counts if Microsoft or Google recognizes a technology as legitimate.

It's my contention that as a company, they're a bunch of assholes. Whether or not they make money or lose money is irrelevant to my assessment of the company's morals.

They have a long track record of treating everyone, employees, customers, etc. as "fodder" for their algorithmic profiting.

I'd rather walk miles than call Uber.

So you understand the situation to be the target company is using VMWare products it has under an existing perpetual license agreement, but that refused to change the terms of that agreement or to sign any new agreements? I could see that as a legal foundation for the audits to "ensure only the existing licensed products are being used." (But I'd sure ask, "Where was corporate legal when that contract was first signed?" Agreeing to an unconstrained right for some outside company to enter your company and "audit" it strikes me as Not A Good Thing. Now if there are some constraints on the audit on the pre-existing contracts, that would be interesting to know. And it wouldn't surprise me for the two companies to engage in substantial legal negotiations and possibly litigation to constrain an "audit.")

Does VMWare have a contract clause that permits them to 'audit' a former customer? Under what country's laws would this be conducted? NL or US?
IANAL, but it's not clear at all to me that a company with whom you no longer have a contract has any legal right to conduct a clearly forensic audit. And of course, as others here have pointed out, this is an action that inflicts financial damage on the former customer to support such an audit. I'm sure the target company's legal counsel is working overtime preparing a response to this.

But of course, it's easy to pound on Apple and Google. Shutting down the wider surveillance economy would gore a lot more oxen... THOSE do much more damage to actual end users than the Apple/Google duopoly. Apple & Google arguably hurt the big players like Epic, but as far as I'm personally concerned, that's A Feature.

A good place to start when there's a problem with your bank: https://www.helpwithmybank.gov...

Credit Unions are supervised by a different agency: https://ncua.gov/consumers

It actually was a bit of a search to find "SMNP", so my original post was both a commentary on how our eyes tend to see what we expect, and to provide the acronym expansion for the lazy among us...