None of the middlemen are in a position to do that. It's all done by the manufacturer to name-brand specs. All the OEM does is add 25% to the production runs and sell the excess to the dropshippers. Changing the internals in any way would involve setting up a different production line, and that's too expensive compared to increasing capacity on an existing line. The economics are what made it appealing to buy grey-market electronics from Asia.

Other consumer goods, though, the economics are different. True cheap knock-offs are feasible, and you have to watch out for them. With the plethora of brands schlepping them, you need to be careful not to buy too much until you've actually seen the product. OTOH, if you do find a good one, the weird name doesn't have to be a negative. Just pay attention and be prepared to dump an order in the trash if it's not up to par (and don't buy from that brand again).

That's what most of those brands seem to be: dropshippers carrying OEM versions of products made for larger and more well-known brands. I'm used to dealing with that, techies have after all been getting OEM products from China et. al. since forever since they're often exactly the same thing as the name brands just without the branding on the case. The explosion of different "brands" on Amazon just highlights the same problem we had back then: distinguishing the reliable ones (who sold the OEM version of the name-brand product) from the unreliable (who sold completely different and usually inferior items with visually-identical cases).

This was already decided during the original trial. Two things will prevent Xinuos from succeeding:

1. SCO never had a license to the code they claim to own. They had a license to distribute it, but Novell owned the copyrights (such as they were).

2. The code SCO claimed was copied from Project Monterey wasn't in fact copied from there. It was original code IBM wrote and contributed to Monterey (while retaining the copyrights) and then subsequently contributed to Linux (which they had every right to do because the license granted to Monterey wasn't exclusive).

The only reason the lawsuit ended with a settlement was that SCO had lost on every argument and gone bankrupt, so there was no money to pay any judgement against them. I suspect some of the terms of that settlement are going to come back to bite Xinuos, because SCO had managed what everyone had considered impossible: they'd not only angered IBM enough they were out for blood, they'd managed to get IBM's law firm (Cravath, Swaine and Moore, who are a big name) personally angry at them too. I'm fairly sure there's terms in that settlement expressly to make sure that dead horse stays dead and buried. Given that Xinuos isn't bankrupt, and some of the figures behind SCO and the original lawsuit were involved with them last I heard, I expect IBM's attorneys to make great white sharks look cute and cuddly by comparison.

Asking for it in a situation where a user would expect to have to enter it, so they won't find the request unusual or suspicious.

It's not anywhere near one step away. Designing the peptides and getting one or more candidates is the easy part. The next steps are the hard ones, the ones that make pharmaceutical chemists and drug researchers cry:

• Phase I trials to see if it even works as claimed. Expect a 95+% failure rate here. Note that this is where you're going to see the best results for your drug candidate, things never improve from here. The best you can hope for is that they don't get any worse. So if you don't get strong results here you're probably wasting your money.
• Phase II trials to determine the best dosage and pharmacokinetics. Again expect a 95+% failure rate here, and results showing less effectiveness than shown in Phase I.
• Phase III trials to determine behavior in a large sample representative of the target population. Expect a failure rate upwards of 99% here, and a major drop-off in effectiveness. This is where toxicity and serious negative side effects show up, and those can kill your trial dead even if your candidate is working.

Getting through this process will take multiple tries and years of work, assuming you succeed at all. There's a reason they say that the clinic (clinical trials) is where drug candidates go to die.

That's why everything running in the cloud runs in containers on a cluster (Kubernetes or similar). If a physical server dies, the cluster control software just drops that server from the cluster. Load management then automatically moves the containers to the remaining servers in the pool. When enough servers are dead they send a tech and a truckload of replacements out. Same for storage: everything's on RAID arrays and as physical SSDs die the array drops that drive and keeps on going with no data loss. Once enough drives in the bay are dead they send someone to swap them out and the RAID controller takes care of initializing them and restoring data from the existing drives as required. It's not uncommon for 30% of the capacity to be out-of-service before replacements are ordered.

They still have to catch up to IBM's old mainframes though. Those you could go in during peak business hours and start pulling and replacing CPUs and memory modules and I/O controllers while everything was live and not disrupt anything.

The language part, true. The problem is dependencies. Any time you upgrade, especially if you're jumping a large number of versions, you're going to have packages your code uses needing upgrades too. Those package upgrades will usually require code changes to accommodate. Some of those changes will require refactoring to handle structural changes needed for things to work right. That is usually where you end up down a rabbit-hole.

I'd prioritize updating Java 8 applications to Java 11 first. Those are going to be the hardest to bring up-to-date with Java 25 (latest LTS), bringing them up to Java 11 buys the most time. Then upgrade to Java 25 starting with Java 17 applications, then Java 21, then Java 11.

Remember that Java 25 will end support in 2033, so plan on starting your upgrade from Java 25 to the next LTS version basically as soon as your last upgrades to Java 25 are done.

Yes. The construction jobs are very short-term, and once built the data centers bring huge costs (financial and otherwise) while contributing only a handful of permanent jobs. Remember, these are lights-out hands-off facilities. They'll employ a handful of security guards and maintenance workers, the rest will all be handled remotely from Malaysia or the like.

True up to a point, and governments are past that point. They can in fact tell companies what formats the government will accept and generate and companies can't afford to just ignore that. And that's actually the first step towards sovereignty: dictate formats that aren't controlled by hostile entities. So, start by declaring the ODF formats the official government standard formats. You'll accept documents in other formats, but you can't guarantee they'll be correctly rendered on your end and you won't put any effort into trying to clean up Word and other non-standard format documents. If they're bad or unreadable or whatever, they'll be rejected and it's on the sender to fix the problem. When you send documents you'll only send them in ODF format, no others, and it's on the receiver to be able to read them.

Internally you standardize on something like LibreOffice that natively handles ODF formats. Anyone else can use anything they want as long as it can handle ODF. Word, BTW, actually does a decent job of handling ODF. Inertia may be a thing, but remember that governments have a lot more mass behind them than private companies. If the government insists and won't budge, any company that needs to do business with the government will slowly come around.

So now NHS has nearly half a million headaches. I'm not sure this is an improvement.

Please, no. Often when writing code I need the API reference and only the API reference. I know what I want to do and how to do it, I just need a quick check of the exact order of arguments or exact symbol names. I don't need to try to sift that out of commentary. Likewise when I'm learning how to use the library I'm more interested in the overall view. I don't need to know the exact names of the options for a call, only what the options are for. I expect the code in the user's guide to be accurate, but I don't want the same things out of it that I want out of the API reference.

Except for the bit where it does that caching for a loop where each lookup only occurs once. Because everybody caches lookups, so that must be the right thing to do (it's the most likely thing to happen) in a case where the cache is never used. Riiiiight...

Something critical to note: intent is the most important thing to document when it comes to software. You can see what it does by reading the code, that's straightforward. What I need to know most, both when writing software and maintaining it later, is why it's doing that. What's it supposed to be doing? Why is it doing it in that way? What were the alternatives and why weren't they chosen? How is it supposed to be used by code that calls it? An LLM can't generate any of that just from the code.

This is why traditionally software libraries have had two separate pieces of documentation: an API reference that details every call and it's arguments and results, and a user's guide that lays out how and why to use the library.

This has been typical behavior for large companies when dealing with vulnerability reports for decades. Report one, they treat you as the problem. They'll try to ignore it, consider it "not exploitable", delay and deflect as long as they can get away with it, anything but address the vulnerability. And they'll never tell anyone the vulnerability exists. This only changes when they have no choice but to admit to the problem and fix it, usually when the vulnerability is being publicly exploited. They push "responsible disclosure" because it includes the reporter not making the vulnerability public until the company has a fix, which allows them to stall disclosure as long as they want.

It used to be enough to just include a reasonable deadline when reporting it, after which the reporter would make it public if the company hadn't taken some action on it. Then companies started threatening and then taking legal action against the reporter as soon as they reported the problem, playing the deadline up as "blackmail".

So, what do you do when faced with this? The only reasonable response is to skip the company entirely and make the details public immediately. You're going to be facing retaliation from the company either way, this way the public isn't vulnerable for an extended time. And yes you include details on how to exploit the vulnerability, ideally via working code, so researchers other than the company can confirm it's a real vulnerability that's actually exploitable without having to take your word for it. No, that doesn't give the bad guys anything because remember the working assumption for vulnerabilities: if a good guy has found it, the bad guys already know about it and are using it. Remember that when the company whines.