The Army's new truck is built on a Chevy Colorado. (https://www.gmdefensellc.com/site/us/en/gm-defense/home/integrated-vehicles/infantry-squad-vehicle.html ) Will GM have to give the Army all the part specifications for Colorado parts? Will Palantir have to give up detailed data on how its software works?

The Government has always been able to require data hand-over as part of meeting a solicitation/Request for Proposal. See https://www.dau.edu/acquipedia... Now in many cases I saw, the PM decided to not spend the $ for this, either because s/he didn't think it was necessary or because the bill would have been too high. It used to really piss me off when the government would pay for a lot of new software but not own that software. The argument was "let the contractor commercialize that and that should reduce the government's maintenance costs." But requirements, operating environment, and lifetimes for software used in military applications are significantly different than those in commercial practice. The related problem came when the contractor would do some R&D, and then carve out the core of the system as "company proprietary." (Imagine Linux if the kernel wasn't open source....)

But to pretend this is a Sudden New Revelation is to ignore what have been acquisition practices for much longer than the now 40 years I was working in that business.

That makes sense, it's what the article should have said.

I tried to figure that out from what I could see of the Bloomburg article, but wasn't sure if this was registrations in US Patent Office, worldwide, China, etc.

both directions. You'll be better for it.

I would have thought there are advantages to keeping the Linux kernel as a 'strictly conforming application' using only the standard C language features.

On this Veterans Day/Armistice Day, it's worth repeating the apocryphal story about the French admiral complaining at a NATO meeting, "Why do we all have to speak English here?" The Dutch admiral responded, "It's because the British, Americans, and Canadians made sure we are not all speaking German."

Are usually full of shit. Whether it's Gurman or Kuo, or less well known Apple 'prognosticators', their track record is poor. Apple is very (notoriously) secretive, and to think that product release plans would be leaked is very unlikely.

But if you believe what you read on the Internet, I'm sure you live an "adventurous" life...

I've been reading "Enshittification" and Doctorow clearly calls for much more aggressive anti-monopoly regulation and enforcement. What he's calling for, as I understand it (I haven't finished the book) would be a significant change to US understanding of 'illegal monopoly'. But Europe operates under different rules, as EU actions against Apple and Google have shown. One could well argue that Spotify should be qualified as a 'gatekeeper' kind of company, but I am certainly not a EU lawyer. A ruling that says "engagement engineering" is illegal would be difficult to enforce, but presumably not impossible.

It's a worldwide phenomenon. Will the EU produce a response applied to not just US companies, but Big Tech from the EU? I don't think anyone is expecting significant legal action within the US.

You can do software engineering in any language, even C or Visual Basic. But it's easier with languages that provide more precision in specification and in behavior. Once you get used to it, strong typing, particularly for scalars (integer types) is your friend. It can catch at compile-time subtle bugs that can be hard to find. Similarly, languages that make it easy to define chunks of code with well defined interfaces/APIs (and that do information hiding on details) is a huge advantage in large (as in 'many developers') and long-lived (as in 'many maintainers') systems. In large systems, code is read -much more frequently- than it is written. And that a good API specification should help the user/reader understand what happens when things go right, and what happens when things go wrong. Even in Ada, there are a few things in the language specification that are 'undefined', which means "we have no clue what a program that makes this mistake will do."

Then clearly you've not worked in a safety-critical regime, where specifications are required to fully cover behavior sufficient to generate test cases that cover 100% of the requirements, and by extension 100% of the code branches.

But even in "regular" development, the API specifications I wrote, implemented and tested were all expected to be sufficient to be useful for test and verification.

Frankly, if you haven't seen this level of specification, I really question if you've been doing "software engineering", or just hacking.

Seems to me from reading the article this -should have been caught- by testing against the specification.

"date -r reports current date instead of date specified by reference file." This should have ben tested, it's not a particularly complex test case.

and moves your money from a savings account to a Ponzi scheme stock?

I know of cases here in NH were financial advisors were sued and even prosecuted for misleading/undisclosed risky investments.

"Sources familiar with the situation" make shit up all the time. Apple production numbers and expectations are tightly held, but people still believe "media influencers" who look around and say "Huh, we can collect clicks by generating some FUD around Apple." In this case, we see is one "media influencer" citing another "media influencer" using their "proprietary algorithms" (usually involving rectal sampling.)

When you're in a yearly production cycle, there's ALWAYS production cuts after the product release, you produce leading up to release, and then move production to The Next Thing.

Uh, yeah. That's exactly what I thought when I saw this.

All Social Media is full of 'influencers' who don't know what the fuck they're talking about. The potential benefit of a (wrong) AI answer is that you -might- be able to query the AI to find out how why it said that. Of course, the LLM is likely to say "That's the most common content from Social Media."