Posts by Sproggit

Microsoft warns customers AI will mean busier Patch Tuesdays

Re: I wonder...

Hard to predict the actual outcome to the question you ask, but your question talks to a deeper point.

If you're using AI as a coding co-worker, or even if you're using it to help review and polish code you've drafted, then you're aware that AI can be used to find code vulnerabilities.

In other words, if you're using AI to write code *BUT THEN NOT IMMEDIATELY TESTING YOUR OUTPUT WITH THE BEST AVAILABLE AI TOOLS FROM OTHER AI PROVIDERS* then the problem isn't the AI, it's you.

Your post hints at a second, deeper [more interesting] question, though: starting at first principles, is it easier to write defect free code, or to find defects in code. If the answer is the former, then once properly written, code should be secure and not contain vulnerabilities. If the answer is the latter, then God help us all, because it suggests that the deck is now implicitly stacked against the developer.

The truth is inevitably going to be somewhere between the two - at the end of the day the quality of an AI model can only ever be the product of two input parameters: the innate sophistication of the vanilla code; and the quality of the data on which it is trained.

In the case of writing robust, secure code [and/or finding defects in code], I suspect that the innate quality of the model is already pretty good... and that now the differences in results come down to the way the models are trained. For example, if we train a model using human-written code that contains defects, we should expect the model to write code with defects... Garbage in, garbage out.

But it would be interesting to see if e.g. Anthropic and OpenAI would be willing to enter in to a coding exercise. Give the two models a coding objective... Let the models finish producing their output, then ask each model to find defects in the work of the other model.

Kind of like the answer to the old physics question, "What happens when an irresistable force meets an immovable object? Answer: you get a lot of very interesting side effects..."

WTAF

From the article:-

“We continue to evolve our internal systems and practices so that vulnerability discovery is not treated as a separate activity, but as part of how we build, review and improve Windows before new features or updates are released,” he wrote.

Where has this idiot been for the last few years? Under a rock? In a cave? On the moon?

Cinnamon 6.8 will support Wayland – if you want it

The point you raise here is critical.

Wayland was first developed in 2008 by Kristian Høgsberg, who was working at Red Hat.

That's *eighteen* years ago.

My sense is that if there is functionality in X that is not yet in Wayland, it's never going to happen.

Irish datacenters now guzzle 23% of the country's electricity

Generators or Battery Systems?

The article notes that, "server farm operators seeking a grid connection of more than 10 MW must also now provide generators or battery systems capable of providing the same power." It goes on to say, of the server farm operators, "They will be required to feed power back to the national grid, if and when required, a system already pioneered by Microsoft and Digital Realty."

There's an obvious problem with this.

Give or take a bit, a 400 watt solar panel is approximately 1 metre wide and 2 metres long - so 2 square metres. It would take 25,000 such panels - working at optimum efficiency - to generate 10MW of power... That ignores losses and it ignores the fact that Ireland is sufficiently far north of the equator that panels start to lose serious amounts of efficiency thanks to the shallower angle by which the suns rays reach them - and the amount of atmosphere the sunlight has to pass through. But hey, let's stick with a perfect panel at 400 watts. So we'll need 25,000 of them to provide 10MW during daylight hours. And for the sake of this thought process, let's round up their dimensions to 2 x 1 metres.

That would require at least 320 x 320 metres of land area to build out... which is likely to be quite a bit bigger than the roof dimensions of an average bit barn. Note that you'd only need 160x320 metres if you wanted to host your panels edge-to-edge with no gaps... but note that if you did this, you'd either have to lay the panels completely flat [which reduces their efficiency, thanks to Ireland's latitude, or you have to leave spaces between rows of panels to ensure that the shadow of one row doesn't fall on the panels in the next.

Let's imagine that you can do all this. Well done you.

But now you're going to be generating peak power between say 09:00 and 15:00 on sunny, summer days. Does that line up with grid demands? Seems a bit optimistic.

So now you're going to look at alternatives, maybe to meet your 10MW quota, maybe because you need to provide the capacity at other times. How are you going to do that, exactly?

Diesel generators? Gas turbine generators? What is that going to do to the environmental impact of your bit-barn? It seems likely that forcing owners to consider fossil-fuel-based generation to meet your requirement for 10MW on demand, companies are going to be adding to pollution and environmental damage.

And that's before we get to water requirements for cooling... before we get to the land footprint... before we get to the inevitable tax breaks demanded, even though a bit-barn isn't really likely to support much more than a couple of security guards and a cleaner or two.

Maybe there are other factors at play here... but on the face of it this looks like something that is simply going to hurt the people of Ireland and benefit big multi-nationals. Hmm... that concept of screwing over local people for the benefit of big multi-nationals... where I have seen that before?

Britain's cloud habit has become a billion-pound risk

Re: Clouds are temporary

"This is not an abstract threat; the magnetic field of earth is due a pole-swap and this is happening as we speak. We don't really know how long it will take, but we do know that whilst it is happening power grids will be very unstable."

This article in Discovery Magazine from

https://www.discovermagazine.com/earth-s-magnetic-field-flipped-43-million-years-ago-was-there-an-impact-on-life-48915

suggests that this event occurs roughly every 300,000 years and takes around 10,000 years to complete... even though researchers found that one event, around 43,000,000 years ago, lasted up to 80,000 years.

For anyone reading this and wondering, "How on earth do we know that the poles have reversed, and how could we possibly know how long it takes?" the answer comes from the geologic record. Molten rock contains particles and atoms of e.g. iron - metals that exhibit magnetic properties. As the molten rock is thrown up from the core to either the surface [or to the bottom of ocean trenches where plates are separating] the molten rock cools and solidifies. However, this solidification happens at a rate slow enough to allow the iron in the molten rock to align itself with the active magnetic field.

Mineralogists have conducted multiple experiments to extract rock cores from ocean trenches and elsewhere and examined the "magnetic orientation" of the contents, which is how we know that the poles have reversed.

Also, because molten rock also carbon and other radioactive isotopes, these decay [like uranium to lead, potassium to argon] while trapped inside the minerals that have crystalized/solidified out from magma.

Taken together, we can establish the age of a rock and the magnetic alignment of the planetary magnetic field that was present when the rock was formed and the time the reversal takes to complete. We also know that the magnetic field is typically reduced - significantly reduced - during the reversal.

To be fair... the interval between "pole flips" can be variable and, as noted, can last between 10,000-80,000 years.

And whilst I'd agree that during this time things like the electrical grid [anything not RFI-hardened] will be impacted... I'd respectfully suggest that we should be much, much, MUCH more concerned with the potential for the cancer risk this will cause. The Earth's magnetic field is what allows life to exist on this planet. The sun throws of a constant blast of extremely high energy particles that are blocked by our Magnetic Field - witness the "Northern Lights" - so that if anything were to happen that would reduce the effective protection we get at the Earth's surface, this would cause all animals - including humans - to develop cancers at a much, much higher rate. It would also break down the DNA in plants and crops.

In a really extreme environment, potentially the only lifeforms that might survive such an event would be those in the oceans.

So yeah, clouds might be temporary... and a magnetic pole swap might play merry hell with the electrical grid. But if that happens any time soon, the electrical grid will be the least of our worries.

MPs tell NHS to start packing Palantir's bags ahead of 2027 contract break

Let's See The Plans

I understand why it would be a good thing to get a company like Palantir out of the UK's health service - and get their grubby mitts off UK patient record data - but I'm not sure that it is time to celebrate yet.

This is the UK government after all. A government that is never going to win any awards for competence or their stances on anti-corruption or anti-nepotism.

So I think we might want to wait until we see the actual plans and actual evidence of Palantir being pushed out. After all, it wouldn't be the first time that a contractor had secreted some weasel-wording in a contract that would make it much more expensive [if not impossible] for the UK government to get out of the thing.

[For example, the contract that Gordon Brown signed for the two Queen Elizabeth class aircraft carriers, written such that when Cameron won office and tried to cancel the second carrier, the contractor pointed to a clause that required the government to pay for both even if only one was to be commissioned...]

https://www.bbc.co.uk/news/uk-scotland-11577395

https://www.telegraph.co.uk/news/uknews/defence/8111117/Cancelling-aircraft-carriers-would-have-cost-taxpayers-690-million.html

Microsoft shifts to annual exchange rate price revision for cloudy products

Self-Limiting...

Microsoft is a global corporation which absolutely conducts business in all of the major currencies in use in the world today - certainly all of the currencies used by say the G20 nations, plus a few more.

So Microsoft's bank will offer them a multi-currency account services and the company will either directly [on payroll] or indirectly [through a paid-for service provided by their bank] have access to money managers who move funds between currencies when the exchange rates make those actions lucrative.

Which begs the question: why would Microsoft even bother to do this? Why not simply price global cloud products in all the major currencies and let the customer pick the currency they want? Especially when Microsoft are one of these multi-national corporations that use cross-jurisdiction licensing deals between wholly-owned subsidiaries to wriggle out of paying corporation tax...

There's something a bit off about this...

Microsoft Global Device Identifier fingers Scattered Spider suspect

Aaaand it's systemd for the win. Again.

via a Google search:-

The file /etc/machine-id is used by Systemd distributions (like Ubuntu, Debian, Arch, and Fedora) to uniquely identify an operating system instance.

It is referenced by:

DHCP clients to request consistent IP addresses.

D-Bus for intra-system communication.

Systemd-journald to collate logs and track where logs should be written.

So we have yet more functionality [in this case 3 separate elements] where the systemd developers have:-

1. Added functionality to systemd that didn't need to be there in the first place.

2. Significantly eroded the security of hosts running systemd as a result.

And according to the same search that surfaced the above, simply removing the file will potentially break the machine concerned:-

"Yes, completely removing /etc/machine-id on an active Linux installation will break your system. While it won't destroy the kernel, it disrupts core system functions like networking (DHCP) and logging (Systemd Journal) because system services expect this file to act as a unique, stable local identifier."

1. For DHCP clients, why could the software not simply use the MAC address of the network device concerned?

2. For D-BUS, whilst I'd accept that intra-system communication is necessary, there is no ####ing need to combine the unique ID used for DBUS with the one used for DHCP...

3. For system-journald... what were they thinking? Were they trying to solve a problem that might not exist [i.e. that a sysadmin might want to collate logs from lots of devices and might want a unique ID? See previous comment about NIC MAC address. Or use the IP address. Or, when a sysadmin needs that functionality, let them pick the unique ID for themselves.

The more I learn about systemd, the more convinced I am that the community would be better off replacing it. That and the fact that I am starting to suspect that a Three-Letter-Agency had a hand in it's "scope creep".

UK guts planning red tape so datacenters can bypass the neighbors faster

Planning - Corruption on Steriods

It doesn't matter where you live, planning always seems to be one of the most corrupt practices undertaken by government.

How about wealthy local builders giving bunces to officials, either to get planning permission rammed through, or to prevent someone from getting permission in order to force a sale [to a builder], there are just so many cases of corrupt practice that it's amazing any pretense of transparency is maintained.

But how about this as an example... Imagine the boundary line between two UK "Local Councils", each of which have their own Planning Department. Now imagine that, by mutual agreement, that line was also the centre of a "green belt" initiative, from the councils, to ensure that new developments didn't spoil local countryside.

Finally, picture the scene in a Planning meeting - I happened to be attending with the specific intent of objecting to the application in this instance - only to hear a local Conservative Councilor, who stood up and made the argument that he "suspected" that the neighbouring local authority had secret plans to grant planning permission on *their* half of the greenbelt land. His argument was that if the neighbouring authority did this - and thereby secured more Council Tax/NNDR income - that his local council would be disadvantaged. His proposal? Write to the neighbouring authority and remind them of their obligations?

Not a bit of it - he wanted to give building permits for the greenbelt land that his council *did* control - and do so before the neighbouring authority could act. His argument was that if the local council built on the greenbelt first, then the neighbouring council would be forced to leave their half of the greenbelt un-touched, touting his genius proposal as a net win.

The fact that he was in cahoots with the builder that had just bought a significant parcel of the green-belt land had nothing to do with it. That fact that the council *knew* he had done so, because they had processed the change in ownership via e.g. their local NNDR and Land Charges Teams was conveniently overlooked.

The problem is that much of what happens in these sorts of cases goes under the RADAR, happens out of sight of the general public, then goes through "on the nod". If fellow councilor Fred stands up and says he knows about this application and it's from a "good fellow", that is too often the end of sensible inquiry. And as for consultation ... We live in the modern digital age, where local councils expect to have our email addresses or our mobile phone numbers, but when it comes to giving us notice of planning applications, they still insist on putting A5-sized paper notices on lamp-posts. [ And of course, any enterprising applicant familiar with that practice is out the following day, cutting the notices down].

My gut sense is that corruption in local councils is like a GCSE Test... If you pass that [are sufficiently corrupt] then you get to stand for County Councils [A-Level corruption]... and if you pass that, you can do a Degree Course in Corruption at Westminster as an MP.

Sigh...

Zombie ‘who owns Unix?’ lawsuit comes alive again

The original complaint

Actually, if you read TSG's original complaint (courtesy of the WayBack Machine):-

https://web.archive.org/web/20170704181155/http://www.groklaw.net/article.php?story=20040704170212250

you'll find their characterization of Project Monterey, a joint initiative between IBM and The SCO Group to develop a 64-bit version of a UNIX-based operating system for "Intel-based processing platforms." Here's the actual text of the complaint:-

" Project Monterey

50. As SCO was poised and ready to expand its market and market share for UnixWare targeted to high-performance enterprise customers, IBM approached SCO to jointly develop a new 64-bit UNIX-based operating system for Intel-based processing platforms. This joint development effort was widely known as Project Monterey.

51. Prior to this time, IBM had not developed any expertise to run UNIX on an Intel chip and instead was confined to its Power PC chip.

52. In furtherance of Project Monterey, SCO expended substantial amounts of money and dedicated a significant portion of SCO’s development team to completion of the project.

53.Specifically, plaintiff and plaintiff’s predecessor provided IBM engineers with valuable information and trade secrets with respect to architecture, schematics, and design of UnixWare and the UNIX Software Code for Intel-based processors.

54. By about May 2001, all technical aspects of Project Monterey had been substantially completed. The only remaining tasks of Project Monterey involved marketing and branding tasks to be performed substantially by IBM.

55. On or about May 2001, IBM notified plaintiff that it refused to proceed with Project Monterey, and that IBM considered Project Monterey to be “dead.” In fact, in violation of its obligations to SCO, IBM chose to use and appropriate for its own business the proprietary information obtained from SCO."

The context here is critical in a technology sense, perhaps less so in a legal sense.

There are a couple of critical issues with the text of that initial complaint. The first is that "The SCO Group" - the party bringing the complaint - continue to refer to "OldSCO" and "The SCO Group" interchangeably, using "SCO" as the label, in a largely successful attempt to bamboozle the Court in to thinking that TSG had a bigger role in this story than was actually the case.

The second is an attempt to convince a (non-technical) Court Judge that somehow there is arcane magic involved in getting a 64-bit version of a "UNIX-based operating system" to run on an Intel-based platform. Here's why that is utter tosh:-

1. IBM invented the "PC platform" and arguably had more and better knowledge of getting code to run on it with the exception of maybe Microsoft and Intel. Certainly they had a much better understanding of the platform than any version of SCO - ***it was their frikkin' platform***...

2. Absent all the other factors required, the steps needed to get a 64-bit version of a UNIX-like operating system running on a 64-bit PC platform would be something approximately like this:-

2.1. Start with 64-bit hardware running a 32-bit operating system. Ideally that would be 32-bit UNIX, but it didn't have to be. [ This was readily available - i.e. Xenix, etc.].

2.2. Write a C compiler that produces 64-bit code, taking advantage of new instructions and new address space. [ This has been done many, many times as basic C compilers [such as gcc] get ported to new hardware platforms...]

2.3. One-at-a-time, write the 64-bit code files needed to get a bootable kernel for the target platform.

2.4. Copy the kernel files to a target/destination boot disk, including a utility to lay down a 64-bit boot sector.

2.5. Once you have enough of the basic files needed to create a bootable kernel and shell, boot your hardware with the new image...

2.6. The first thing you do once you have a running image is write a 64-bit C compiler for the new platform, along with it's tools...

2.7. Port the 64-bit compiler to the new prototype OS...

2.8. Start taking your 32-bit source code, one application at a time, and recompiling it using the new 64-bit compiler to build out a fully-featured OS...

2.9. Package up your 64-bit files with a 64-bit installer...

2.10. Perform an all 64-bit test install to make sure everything works.

At this point, you have "enough" of a 64-bit platform that you can start porting code in earnest. As the complaint from TSG notes, you can start with library files and build out from there.

But for SCO to try and claim that they had unique knowledge and expertise and it would have been impossible for IBM to create a 64-bit version of UNIX able to run on the Intel platform is just such utter, utter tosh it's difficult to know what they could possibly have been thinking.

Interestingly, you will see if you search Groklaw that IBM only really objected to TSG's egregious motion practice, they did not waste their time trying to promote their possible defenses ahead of the trial. So we don't actually know how much fun IBM would have had in cutting this nonsense to pieces...

I offer all of this as interesting context, because though you might not have realised it, the very heart of TSG's complaint against IBM was that only they, not IBM, had the skills and experience needed to "port" a UNIX variant from 32-bit to 64-bit.

Curiously, for all you nerds out there... the first 64-bit [stable] Linux kernel was the 1.2.x, series [for the DEC Alpha [on which PowerPC was based], which released in 1995 - 8 full years before the TSG lawsuit against IBM dropped. Which, if any evidence were needed of the falsity of TSG's complaint, might be a pretty big clue.

Re: The Novell Angle

Hmm...

I vaguely recall that the reason this was not immediately cut-and-dried [it got clarified by the Tenth Circuit on Appeal] was that the deal with Novell was split in to two parts.

The first part was the "APA" - the Asset Purchase Agreement - and this document explicitly *excluded* the copyrights that TSG would have needed to bring their case. However, there were multiple amendments to the APA, the 2nd of which had something to do with the clarification of Santa Cruz's rights to the code.

IIRC, in filings, TSG tried to argue that the 2nd Amendment had a different meaning to the one that Novell were trying to attach [note - Novell were in the room when the 2nd Amendment was reached, TSG were not...] and this formed the basis of their complaint/escalation.

This is why my admittedly not-very-clear previous post said that Novell were not able to immediately put their hands on a single document the unequivocally established the facts. Well, that and history - had that been true, the *years* of litigation would not have been necessary.

Irrespective... I hope this latest attempt will end in Rule 11 sanctions for the plaintiff's counsel.

(Under the Federal Rules of Civil Procedure, a party's counsel are required to sign each submission to the Court as being good faith and factual. A counsel filing a bad-faith, frivolous, harassing or factually unsupported claim can be guilty of breaching Rule 11 and the Court can impose sanctions including monetary penalties.)

Re: The Novell Angle

I was another of the many denizens who hung out at Groklaw on a practically daily basis, and, like you, transcribed documents and did research.

It was such a shame when the Lavabit issue came along and proved to be the "last straw" that prompted PJ to close down the project... though I'd corresponded with her privately through much of the saga and I'm aware that a fair bit went on behind the scenes and that she became concerned for her personal safety, so I wasn't surprised when it happened.

I doubt that Pamela would want to return to her keyboard now... but given the amount of time that has passed, it's quite possible that the community will be able to help if this case actually moves forward.

If only it were that simple...

The SCO Group and their counsel, BSF, largely refused to disclose any of the infringing code *in the actual, original court case*, but that didn't prevent them from using every last device the law offered to prolong their case in an attempt to extort IBM.

The two most likely causes of infringement that the Zombie could bring in this case would be either copyright or patent infringement.

The problem for IBM is that, in particular with the case of source code [but also books and documents] the law recognizes that "derivative works" can infringe an original copyright.

So to translate: if there were lines of code in the 2006 Linux kernel that infringed a TSG copyright, and if those lines of code were iterated and rewritten over the intervening 20 years, it would still be legally possible for the 2026 Linux kernel to infringe, *provided* the Zombie could show - kernel version by kernel version - how their original code transformed down through the versions and how it still existed in the kernel today.

I would agree with anyone whose response is that this seems like a bit of a tall order, but, I think, the news might be better for IBM this time around.

Here, IBM can use the intervening 20 years as another fact in their favor - and they could go to a Judge and say, "Look, in order for us to be able to respond, the plaintiff is going to need to show us the file, lines and origin of any and all infringing material."

If I had one concern about the way that the otherwise superb Judge Kimball handled the original case, it was that he afforded TSG too much latitude to make their case. For example, having filed suit, they then attempted to place such a huge discovery burden on IBM - by demanding full access to IBM's own AIX source code for example - that IBM were forced to go back to court and say, "Yoiur Honor, the plaintiff is asking for discovery of *our* source code to prove their case... but they have been telling the press and the world that they have the evidence in the source code they control and the Linux kernel. So they don't actually need access to our AIX5L code to use as evidence..."

I think that what Judge Kimball was doing was trying to make the case appeal-proof... so it will be interesting to see how a Court views this today.

The Novell Angle

Unfortunately, the original Groklaw web site has been lost and is now some weird crypto/gambling site [*don't* go there...]... but the Novell dimension to the story went [approximately] like this...

The ownership of the original Unix SVR4 code bounced around between different companies, but ended up with Novell, who branded it Unixware, in partnership with AT&T whose Unix System Laboratories developed the original code. The code then went through a succession of companies - the Santa Cruz Operation (SCO, aka OldSCO), Caldera Systems, Caldera International and "The SCO Group" (TSG, *not* SCO/OldSCO).

However, the documentation that came to light through the original court case, when Novell entered the litigation in response to TSG making materially false claims before the court [and with a helpful nudge from IBM ;o) ] (and at which point TSG promptly turned around and sued them as well) Novell showed that what they had sold and what TSG came to inherit was a "non-exclusive right to take forward and develop", not outright ownership of the code. One of the critical dimensions of the evidence in support of the Novell/IBM position was that TSG became Novell's agents - they were charged with obtaining all the licensing fees from existing customers and then remitting 90% of those fees back to Novell, while keeping 10% as an agent's fee.

The problem that IBM/Novell had was that Novell were unable to put their hands on a single, definitive document that set out the terms of the sale. They did have some very strong evidence in their favour - minutes of a Novell Board Meeting around the time of the sale that set out exactly this position. Eventually, on August 10, 2007, the United States District Court in Utah issued a ruling that Novell had retained ownership of the System V UNIX copyrights and that SCO was in breach of its covenants to provide Novell with the previously agreed royalties to the Unix technology Novell had originally sold to SCO.

Meanwhile, on the other side of the court, TSG received a cash injection of some $50 million from Microsoft - a "licensing fee" - who clearly saw TSG's move as being a way to cripple Linux... which was of course an existential threat to Windows. (In case you're wondering, that "licensing deal" was the origin of WSL - Windows Services for Linux - because Microsoft had to be able to show their shareholders that the $50MM they spent actually had a benefit for Microsoft...).

The main reason that the case dragged on for as long as it did was that TSG simply refused to clearly set out which lines of code in the Linux kernel were infringing. At one point lawyers for IBM - from Cravath, Swaine and Moore (CSM, aka "The Nazgul") argued in court that what TSG were doing was basically throwing IBM a document the size of the Nieman-Marcus catalog (a *huge* home shopping business in the US) and saying, "The infringing code is in there - you find it!" [The document being all the source code for the kernel].

IBM maintained that in order for them to be able to bring a defense to court, TSG would have to identify :-

Each file in Linux containing infringing code

The line or lines of code so infringing

Evidence that the code was introduced to the Linux source by an IBM employee...

Very early on, TSG tried to give some "examples" of infringement - not in front of the court, but in shareholder calls. The Groklaw community got hold of the examples and very quickly proved that the source had not been IBM but in fact other vectors, at which point TSG changed tactic and refused to disclose more.

This went on for literally months and months, but gradually, TSG's business model faltered and they ran out of cash. They attempted to successively narrow the case against IBM, until they went one step too far and all that was left in their case could be presided over by a judge in a bench trial. This was a critical error, because TSG's entire strategy was to rely on their counsel - Boies, Schiller & Flexner, led by the famous David Boies - in front of a jury...

On the eve of the trial, TSG declared bankruptcy, thinking they would be able to use Chapter 11 to regroup and change their tactics... but they ended up in front of a Bankruptcy judge who I have to say didn't seem all that trustworthy. He quickly decided that what TSG needed was a Trustee... and, well, the Trustee really needed to have some legal experience, like, say another judge. At that point, don't you know it, "presto", a Trustee [and retired judge] was appointed... and that worthy proceeded to burn through all of TSG's remaining cash on what seemed like idiotic fees to his company, rather than paying out TSG's creditors.

The really terrible part about this stage of the story was that TSG had a bunch of creditors like a Mom+Pop pizzeria in the town where they were based, who were owed hundreds or thousands of dollars on account and who never saw a dime.

So when this trail went cold, TSG had failed to prove anything in court... They had been given more than ample opportunity to do so - and when they had gone public with examples, those code snippets were quickly shown to be entirely innocent and either not submitted by IBM and/or to have come from other sources. All the court rulings had gone against them...

We can only hope that this dies a similarly ignominious death...

MFA-optional banks leave safe doors (and accounts) wide open for thieves to pillage

I Know This Is Pedantry, But...

... what is being described in this article doesn't strictly meet the definition of MFA.

To clarify, MFA - Multi-Factor Authentication - means that in order to prove your identity the the bank's infrastructure, you would have to provide at least two of the following things:-

1. Something you Know [like a Password or Pin]

2. Something you Have [like a Physical Device - such as a token that generates OTPs]

3. Something you Are [i.e. is derived from your physical being, such as a retina pattern.

When we see discussions of "MFA" that include e.g. a Password, but then combined with a PIN or value sent to an email address, this IS NOT MFA... It's two instances of Single-Factor Authentication [something you know]. That's "better than nothing", but as this article then goes on to explain, it's far too easy for an attacker to compromise an email address. It's also far too easy for them to write an inbox-filter that pushes emails from a legitimate bank email address to a waste bin [or somewhere else].

Another dimension to the challenge here is that because mobile phones can receive both emails and SMS messages, it means that the handsets themselves represent a significant single point of failure in the authentication process.

Finally, it's worth noting that there are viable solutions to this - such as returning to the original type of physical RSA tokens. Even better, technology has reached the point where a physical token generator could be embedded in something with the dimensions of your credit or ATM card, if - *if* - the banks wanted to.

There's a reason that they don't - and it's cost. Basically, the calculus that the bank performs is to look at the cost of rolling out something like a credit-card-based token-generation MFA solution and compares that cost with the amount of actual card fraud they have to pay for. Note that this is not the same as the total amount of account or card fraud - because of course banks are getting better and better at side-stepping liability for breaches - using, can you believe it, their terrible history at preventing card fraud as illustrative of why customers should be more cautious.

The key point to remember here is that there are viable, reliable, effective solutions available today. The fact that they haven't been implemented it is simply because regulators are happy to turn a blind eye and not force the banks to eat in to their outrageous profits* in order to tighten up on security.

* JPMorgan net profit for 2025 - NET profit - was $57 billion. That's over a billion a week, in *profit*.

Citigroup net profit for 2025 was $14,3 billion.

HSBC net profit for 2025 was $23.1 billion.

So that's just shy of $100 billion in net profits from just 3 banks... yet they can't afford secure remote authentication for their clients? Pull the other one, cough, cough, it's got bells on...

Confidential computing's trust mechanism is broken. The fix may not exist

"If you want to make an apple pie from scratch..."

"..., you must first make the universe."

(Richard Feynman, Messenger Lectures on Physics, Cornell University, 1964).

The only way to achieve the levels of trust claimed by confidential computing would be to have an unbroken chain all the way back to the design of the hardware on which the TEE was running. Since the design and implementation of TEE's from e.g. AMD and Intel are proprietary, it is possible that the only way that this can be made to work would be for the EU to build their own IT industry from scratch - CPUs, GPU's RAM, chipsets, adapters (network and serial, etc.) - then to maintain the integrity of those manufacturers with adequate security provisions.

We would need to be able to:-

- Subject (all - there is no point doing this with "just" the CPU...) the component designs to independent review to ensure that they were vulnerability-free...

- Verify that the fabrication process (lithography, packaging, etc.) could not be used to implement bypasses or modifications to chip architecture...

- Mandate some kind of component isolation at the physical level, so that signal traffic between components could be independently monitored for spurious content [a bit like having a packet sniffer on a network segment to look for suspicious traffic, except working on the electrical connections between major components on circuit boards)...

- Independently review the design of e.g. the motherboard implementations...

- Design and implement the chain-of-trust mechanisms needed so that an end-to-end verification can be performed - by which I mean, that software running on "my" client over here can reach across a network and drill down to the hardware that is running "your" client and provably establish that your hardware meets minimum requirements...

None of this would be remotely easy... but theoretically, at least, it should all be possible [if the requestor would be willing to throw the needed billions of (Euros, Pounds, Swiss Francs, Whatever) at the problem...

But I wonder if even this would be enough.

We are being told that quantum computing and something like (Peter) Shor's algorithm will be able to break conventional encryption schemes. Yes, organization's like NIST have proposed post-quantum encryption schemes... but the specifics of the solution are less relevant here than the fact that they imply a requirement to make fundamental changes to the assertion/validation mechanisms. The fact that it is therefore necessary to allow for modifications for that code means that the entire platform has a threat vector with the potential to undermine all of the safeguards I set out above.

So I see two pretty deep and interconnected challenges.

First, how do you establish a "ground truth" solution that is viable end-to-end? The answer is that you are going to have to achieve a minimum level of assurance over every single component connecting your endpoints - hardware and software. Depending on your use case, that might defeat the purpose of the exercise.

Second, how do you maintain the integrity/security of your solution over time, given the threat environment [nation state actors, increasingly capable AI models with too much time on their hands, etc.]? The answer is that your solution is going to need not just a degree of "agility", but a degree of "trusted agility", which is like a second order of trust that needs to be folded in.

I say "second order of trust" because reliable encryption schemes are algorithms; encryption algorithms are extremely complex things; and to achieve a degree of independence, those algorithms are going to need to be implemented in different programming languages on different platforms... so now you are also going to need to validate those implementations.

The problem kinda reminds me of that old truism: "Two people can keep a secret if one of them is dead..."

I do think it's possible to get there. I'm not yet convinced that the decision makers in the EU fully grasp *what it would take* to get there...

Lessons from the VMwars – nothing virtual about the Broadcom vs Tesco slugfest

What About A Zero-Day?

The point that Rupert makes in his article has been the initial driver of several of the largest and/or most well-known technology companies, to the point where Microsoft became infamous for their mantra of "Embrace, Extend, Extinguish" - basically a strategy to co-opt any emerging Standard, then add proprietary extensions - which makes it much, much harder to port a solution built on the platform to a competitor.

Virtualization offerings have run the gamut from programming languages (JAVA [write once, test *everywhere*) to infrastructure (Docker, Kubernetes), to operating systems (zOS L-PARs).

Yet curiously, the most portable programming language available today [according to a Google search] remains ANSI COBOL. [In fairness to COBOL's developers, it isn't just the ANSI specification that makes that possible, but the rigid and mandatory "Environment Division" which means that the code has no choice but to run in an abstracted environment...

What interests me, though, is not the VMWare side of this story, but Tesco's technology environment. They spend an estimated $2 billion a year on technology and ICT... which is not a small amount of money. With that sort of value in the mix, it would be unthinkable for the company to not have a well-defined technology architecture and a well-defined technology strategy. Yet what we're learning from this article is that Tesco also, apparently, have at least one single-point-of-failure in that mix, with an abstraction layer that Broadcom hope and believe is too difficult/expensive/time-consuming to ditch.

*If* that were true - and even though Tesco are fighting back, it's clear they need time to exit the technology - whatever they have in their architecture and strategy for technology, it clearly doesn't include as much abstraction or alternate solutions as they would like.

I make this point not to be critical of Tesco [it's far too easy for us to armchair-quarterback what they're doing when we don't have a clear picture of their internal environment] but to make the observation that the difficulty they now find themselves in is exactly the same kind of stress test that an extremely dangerous Zero-Day would pose. What if, instead of this being a contract dispute with Broadcom, Rupert's article had been a story discussing how Broadcom had just discovered a completely inescapable and hugely dangerous zero day, one that could allow anyone able to send a network packet to a VMWare network interface to either bring down the entire VM environment [all hosted virtual machines] and/or take over that VMWare instance with admin privileges? What if that same vulnerability was so instrumental to VMWare's architecture that it couldn't easily or quickly be mitigated by Broadcom.

In short, Tesco [and all other VMWare users] would be in serious trouble.

The only viable option they might have would be to migrate off the VMWare platform. In Tesco's case, that looks to be "easier said than done"...

I do not underestimate the incredible effort involved, but I reckon the best way to prepare for that sort of eventuality is to enforce a modular architecture on your environment. In other words, two different types of [e.g. blade] servers, with the same basic performance profile [in terms of CPU and RAM, for example]. Two different operating systems; two different SQL databases, but both of which fully implement ANSI SQL. Code written in two different ANSI-compliant programming languages... The use of load balancers and aggregators to enable applications to scale horizontally [instead of using monolithic instances]. Clear - and ruthlessly enforced - separation between e.g. data and business logic layers...

The same sort of safeguards that a company like Tesco should have in place to safeguard against zero day threats would have helped them here... Because they would have had two "Standard Builds" for their servers, one of which used VMWare as its abstraction layer and one of which used "something else".

If you're reading this and thinking, "Too hard, unrealistic", I understand where you're coming from. But I've worked for an organization that adopted this strategy and lived by it. Applications were horizontally scaled; every single server got rebooted at least once weekly; at reboot time, servers could be [and were] re-initialized to different configurations, just to prove that the resiliency still worked.

Don't get me wrong... it was hard to get the initial setup. Harder to get the developers, in particular, to get on board with it.

But if you can get over the initial setup hurdle, then not only is your environment resilient against a vendor trying to strong-arm you with a lock-in play, but you've also got the agility you need to help you avoid the worst impact from e.g. a zero-day or similarly bad vulnerability issue.

It's often said that the military of a nation tends to prepare for the last major war they fought. I think there's a corollary in technology - companies tend to prepare for the last major technology outage/issue they had.

Only problem is, in this game, past *isn't* prologue.

Are you able to provide a link to the filings please?

Thanks in advance...

NASA unsure Boeing Starliner will ever be certified for human flight

Re: Vostok 1

"Modern corporations do (the more, the better) so reusable with fast turnarounds and low cost labour are the new metrics.

Safety is a loss leader in their eyes. Manned crews will have to die before things change for the better. "

This isn't just wrong, it's not rational.

Do you honestly think that NASA would give contracts to SpaceX to fly astronauts to the ISS if their capsule "occasionally" failed and killed everyone on board? What do you think would happen to the share valuation of a "modern corporation" if it's premier product killed people in such a spectacular way? [ And I think it's important that we differentiate between a loss-of-life metric, and a negative-publicity metric. The former is critical to us as compassionate human beings; the latter, like it or loathe it, is what matters to the stock market].

My point - which you seemed to have missed - was nothing to do with "disposable rockets, using massive amounts of fuel" to *get to* LEO, but the materials science and flight profile required to safely *return* a manned capsule, from LEO to the earth's surface. The thermodynamic science and materials engineering required to get a human-occupied capsule down from the several hundred kilometres of altitude of the ISS, back to the surface, decelerating from approximately 8km/s - 28,800km/h - hasn't changed since mankind first achieved it in the 1960s, at a time when the design work would have been performed using slide rules, paper and pencils. The approach taken by both Boeing and SpaceX is to use an ablative heat shield - a sacrificial thermal protection system.

In manned space flight, we've seen three distinct generations of approach. The earliest solutions - in the Apollo era - used Avcoat - a fiberglass honeycomb structure packed with an epoxy-phenolic resin. Effective, but heavy [higher launch energy/costs] and required labor-intensive manufacture. The next approach can be found in the Space Shuttle, which set full reusability as a goal and switched to Li-900 Silica thermal tiles and Reinforced Carbon-Carbon (RCC).

Now we're seeing a modern resurgence of ablation-based solutions, but with drastically upgraded materials science. These modern materials are lighter, more durable and better suited to the environments in which they have to work. They include PICA (Phenolic Impregnated Carbon Ablater), PICA-X (used by SpaceX on Dragon), Conformal PICA (C-PICA) and even 3D-woven materials such as NASA's 3D Mat.

The issues reported with Boeing weren't driven by a need to immediately relaunch their capsule, but from getting it to work reliably in a single demonstration. This is where the approach from Boeing differed from the one taken by SpaceX.

SpaceX likely found and fixed a load of issues with Dragon Cargo... iterating their design to be better and better with each launch. As a result, by the time that Dragon was used for crew, it's design and operation were thoroughly understood and substantially tweaked by SpaceX. Boeing aimed for a get-it-right-at-the-first-attempt approach. They gave themselves no opportunity to tweak their design.

SpaceX put astronauts in a flight-proven vehicle that was well-understood by themselves and NASA. Boeing put astronauts in an un-tested [through re-entry] vehicle.

The difference is more philosophical than anything and has nothing to do with "low cost labor".

Re: Vostok 1

That's fair - thanks - have a "thumb up".

On the other hand, NASA paid Boeing an initial $4.2 billion to develop the capsule, plus additional sums for follow-on missions, leaving estimates in the region of $4.5-$5,1 billion...

Meanwhile NASA paid SpaceX $2.6 billion to develop the Dragon Capsule. Which, of course, is actually flying.

So while you're right that their award to Boeing was fixed-price, it really does look like there was a generous helping of fat in there, too...

Vostok 1

On April 12th, 1961, Yuri Gagarin made a successful return to Earth after becoming the first human to reach outer space.

Like both the Boeing and SpaceX capsules, Vostok 1 protected it's passenger by means of an ablative heat shield.

In other words, mankind has known "how to do this" for getting on *seventy years*.

Now, it's quite possible that the design brief for NASA included more extensive features than Vostok 1 had to meet... but at the same time those nearly seven decades have seen staggering examples in materials science, design, manufacturing and relevant technologies. It's possible that those design differences were so significant that it would take hundreds of thousands of person-hours of Boeing effort to perfect a modern replacement...

But you have to wonder why it would cost Boeing so much money - and require so much time - to "re-invent" this particular wheel.

The US has successfully flown four different crew capsules:-

Mercury - 1961-1963

Gemini - 1965-1966

Apollo - 1968-1975

Crew Dragon - 2020-

Yet despite all this experience, Boeing still aren't flight certified.

I can't help but conclude that Boeing tried to run another project based on pork-barrel economics and miscalculated, badly.

T-Mobile appears to be quitting VMware – and fighting a very familiar battle for support rights on the way out

Three Possible Explanations...

I could think of three reasons that Broadcom might have been interested in a purchase of VMWare...

First - Monetization

It would not have been the first time that Broadcom bought a tech company that already had a loyal customer base, then reducing the product portfolio of the acquired company to a few high-priced packages and then increasing software subscription prices. See e.g. here:-

https://www.macquariecloudservices.com/blog/broadcom-acquisition-of-vmware-and-its-impact/

Second - Diversification

It would allow Broadcom to expand outwards from being solely reliant upon hardware [chip] sales - for which there is very little on-going maintenance and thus for which the market and income can be more volatile/less predictable. See e.g. here:-

https://www.channelinsider.com/infrastructure/virtualization/broadcom-vmware-acquisition-changes-explained/

Third - an Integration Wedge

If we consider that Broadcom might have been looking to expand their footprint in the corporate data center then maybe it's possible that Broadcom thought that owning both physical chips and the virtual machines that run directly on them would enable the development of highly integrated all-in-one systems. Of course, the chips that Broadcom fabricate are not as powerful as e.g. AMD or Intel, so perhaps their plans included some kind of enhancement or extension to the virtualisation concept to improve clustering of the underlying hardware?

Based on their track record alone, my gut tells me that the most likely driver would have been the first - monetization - a drive to acquire a readily-available and mature income stream. See also here:-

https://www.channelinsider.com/infrastructure/virtualization/broadcom-vmware-acquisition-changes-explained/

Then they got greedy.

Claude Code users complain their chat records are being mysteriously wiped out

Re: Wrong tool for the job

Yup - it's the poor worker who blames the tools...

Re: I may be missing something

On your second point, Credentials...

I'm using Claude in CoWork mode at the moment, on a PHP/MariaDB project for which, at the moment, I'm the only developer. It took me minutes to get Claude set up with a read-only account to just the MariaDB database I'm using for my Dev environment... It took even less time to add a single line to my workstation's "/etc/fstab" file and set permissions to give Claude the ability to edit my *Dev* environment source code directly... [ I tend to break down my sessions and take interim backups, just in case].

I didn't need any special configuration work to enable it, but in CoWork mode Claude has access to my git repository so that it's able to commit successfully completed units of work [it uses my credentials via the command line].

I have two separate backup mechanisms for the Claude environment itself; first, I've soft-linked the Claude folders out to a location on my NAS that is enrolled in an overnight-scheduled 31-generation backup cycle and which pushes the backups to a second NAS in another building [my garage]; and second, I have an alias in my .bashrc config file that triggers a simple BASH script that performs an rsync of my local ~/Claude folder to the same remote NAS but a different location, so that I can perform intraday backups at any point in time.

I didn't set out with the above as a fully-formed plan in my head [and I'm still mostly a beginner with Claude and Linux in general], but within a couple of weeks of use I'd quickly identified vulnerabilities in my approach - then got Claude to recommend sensible solutions to close the gaps.

I do not for one minute believe that what I've done is special or impressive, but offer it instead as an illustration of where you can get with nothing more than basic common sense.

Oh, speaking of which, the very last thing I do with every Claude conversation, just before I quit the client, is to copy-and-paste the entire chat in to my local Xed editor and then save the transcript as an .md Markdown file, which makes it platform-and-editor independent, but which allows me to retain some useful formatting. Those transcripts go in a dedicated folder subordinate to my project root and are enrolled in the 31-generation automated backup.

Perfect? Not even close.

Adequate? So far.

Useful? Hell yes.

I can't help but feel that if the people raising these concerns are professional developers (I have a hunch maybe not, as I suspect most of those will be on Claude Enterprise, where I suspect the organisation can perform site-wide backups), then I only hope I won't be buying anything that runs any of their code.

Boffins peg narcissistic leadership as the real driver behind 'return to office' demands

Self-Selecting Incompetence

I've spent the last 28 years working for [different] global organizations. In total, I've probably worked in the same country as my Manager for 6 of those 28 years and the same building as my Manager for 2.

In particular, I have spent some of that time in working conditions where the companies concerned actively didn't want people to work in the office. The most obvious was during the global Covid crisis, where numerous countries had "stay at home" orders in place... but I've also experienced the same thing when real estate work or changes like mergers meant that an employer simply didn't have enough desks to go round.

I tend to like having metrics to understand the nature and volume of work my Teams do [with the caveat that I will never ask a subordinate to track that sort of stuff by hand - as I tell my fellow managers, "If it's important enough for us to use to govern the business, it's important enough for us to automate..." [which tends to kill off a lot of objection]. I have had multiple [angry] debates during year-end performance reviews where a more senior manager has told me that I can't award a top performance review to anyone in my Team this year because they all spent "X" weeks working from home and therefore it was implicit that performance must have dipped. Fortunately, I have always had cold, hard metrics to back up my assertions.

On one occasion we had such a desk shortage in our UK office that staff were asked to WFH 5 days per week. Two of my subordinates approached me in that time with special requests: one asked if they could relocate to Scotland to live near an aging parent; the other asked if they could relocate to Thailand. I put safeguards in place - clearly documented annual objectives, rigorous peer reviews [covering responsiveness, helpfulness, availability, etc.] and agreed. That year, the colleague who relocated to Thailand was peer-voted a "Team Superstar" and the colleague who worked in Scotland was awarded a patent by USPTO.

I've made the observation [here, at El Reg] multiple times before, but it bears repeating: any manager who tells you that "remote working doesn't work" is in fact declaring themselves to be unfit to manage people. If more senior managers were to ruthlessly enforce that principle and "manage out" any middle manager who pushed back, they would see productivity and job satisfaction improve across the board.

None of which is to say that there won't of course be employees who will try to "swing the lead" ... but that's why you need clear objectives, good [automated] metrics and a quality manager.

I'm not sure why I make this connection, but I tend to frame "you can't be productive when working remotely" in the same bucket [of bull####] as "closing tax loopholes and taxing multi-millionaires won't work" - it's a useful fiction those individuals try and tell themselves, almost as though they believe that if they repeat the lie often enough, it will suddenly become true.

Large Hadron Collider goes offline to make room for its enhanced successor

Re: Chance of humanity ending

This is an apples-to-pears comparison, but for context - and courtesy of Wikipedia - the US Department of Defense apparently used 30 Terawatts as far back as 2006:-

https://en.wikipedia.org/wiki/Energy_usage_of_the_United_States_military

The DoD also uses over 4.6 billion [US] gallons of fuel per year, or approximately 12.6 million US gallons *per day*.

Asked to predict which of these two entities (US DoD or CERN) is more likely to bring about the end of the world thanks to a calamitous miscalculation, um....

Re: Most-Important Tidbit

My vote would go to an upgrade to Linac4 - the Linear Accelerator that generates the negative hydrogen ions and injects them in to the PSB (Proton Synchotrom Booster), before they get to the PS (Proton Synchrotron) and SPS (Super Proton Synchrotron).

My proposal for Linac4 would be to give it decals so that it looked like the manual ball release for a very large pinball machine.

Obviously I'd also need to ask for additional budget for the PA system so that I could play "Pinball Wizard" by The Who each time a new set of samples were energized for testing...

HS2's latest reset ditches autonomous train tech to get project back on track

Re: HS 2 late

It was neither.

It was a project to transfer an obscene amount of money to Tory donors and friends of George Osborne, using a massive rail project as the cut-out.

The "current" part of the project, "Phase 1" is supposed to deliver 140 miles (224 km) of track for an estimated £102.7 billion [in 2025 £].

So that works out at just short of £460 million per *kilometre* of track laid.

Or, put another way, not far off **half a million quid per metre of track**.

Making this the most expensive rail project, anywhere in the world, by the inevitable country mile.

It isn't the cost of laying the actual track that has made this so expensive, mind... Nor is it the heavier civil engineering [cuttings, tunnels, etc.]... It is the cost of the compulsory purchase orders for the land for the selected route.

Please refer back to previous reference to "donors and friends" for context.

UK firm bombarded debt-ridden people with 5.5M texts

KRA Consultancy Ltd

This is just a guess on my part - but please see below for substantiation - that "KRA Consulting" looked very much like a 2-person operation run jointly by Khuram Ahmad and (Mrs) Bushra Yaqub. Their registered office appears to be a 1-bedroom or 2-bedroom terraced property in the Sparkhill area of Birmingham. The published accounts I was able to find - dated October 2024 - show the company to be a "micro business" with a turnover that, on the face of it, does not seem to make enough revenue to support the salary of even one person, let alone two.

There are many possible explanations for this:-

- With only 2 years of detail at Companies House, it's possible that the business was already in the process of winding up [though the prosecution suggests otherwise]

- The business model involved victims contacting the company and then being talked in to making partial payments to "stave off" a worse fate... and some of those payments may not be recorded via Companies House...

- The business was basically just a hybrid spam/textortion scheme looking to dupe people in to paying "something" and running along, scratching a very low income in the form of a part-time hobby for the two directors.

However, if the published accounts at Companies House are accurate, then a fine of £300,000 is either going to hopefully cripple these two directors financially, and/or serve as a useful warning to others.

The only concern is the unknown question - how much were they really making from this scheme. If it was just the couple of thousand pounds a year their filed accounts suggest, then a £300k fine will wipe them out. But if they directed a small number of payments to their "official" accounts and a larger number to an "unofficial" account - say an *overseas* account then [depending on how smart they are] they might still come out of this "ahead".

A quick check of Companies House shows that KRA Consultancy Limited - still active - lists 2 Officers and a single Resignation. The active Officers are Bushra Yaqub and Khuram Rezvan Ahmad.

A set of micro-accounts are also listed - dated 31st October 2024... which lists an average number of employees as being 3 people in 2023 and 2 in 2024.

The 2024 "numbers" are listed as:-

Fixed Assets: £384

Current Assets: £4,380

Creditors: amounts falling due within one year (£4,091)

Net Current Assets: £289

Total Net Assets: £673

Often when you read a set of accounts there will be a preliminary statement indicating that "all numbers are thousands", so that e.g. £384 as shown above would be £384,000. However, in this case that doesn't appear to be the case - it looks like three hundred and eighty four actual pounds.

The accounts were signed and submitted by "Mrs B. Yaqub, Director".

It's looking like a hot, messy summer for security teams as AI finds countless previously hidden vulns

Re: Patterns in the Noise

"For a more complex example, I've had LLMs suggesting Javascript-isms for C++ projects."

This sounds like a much more interesting example than just "complex". Can you give some context here please?

Which model made that suggestion? Which version? How recently did this happen? Did you get any response when you raised that as an issue with the authors?

I'm happy to accept that LLMs are not expert at everything, but the general consensus *seems* to be that they have become extremely good working with e.g. software, scripting languages and technology [product] configurations, in large part because the people developing the models have plentiful examples of that material to hand. So it would be really helpful to get a clear idea of how you hit this problem.

Thanks in advance.

Re: Here's a stupid question

It is highly unlikely, for perhaps a couple of reasons...

First, we should note that quite a significant amount of open source code is written by professional developers. Large companies such as IBM, JPMorganChase, Amazon and others employ developers to create, support and maintain open source projects. These companies not only have pockets deep enough to hire extremely competent developers, but they have budgets to enable them to use a wide range of quality management tools.

Just a qualification on the above: when you have an extremely talented developer, keeping them working in your organization isn't simply a question of paying them enough money, but of giving them work that they enjoy. We can think of well-known Open Source luminaries - Linus worked for Transmeta, Greg Kroah-Hartmen used to work for Novell in SuSE Labs; Jono Bacon worked for Canonical (Ubuntu) before setting up his own business... I can only speak from my own personal experience, but where we have colleagues who have worked or still work, all or part time on Open Source projects, the company has enabled this working practice because the software project concerned has been critically important to the business. Sometimes there's altruism involved, but it's just as often a case of the fact that the company sponsoring the developer(s) would like to see particular functionality included, so provides employment to the project developer(s) in order to get it done.

Second - and perhaps more importantly - is the fact that even if it were true that paying twice as much for a developer got you one with twice the abilities, the narrow statement simply *does not scale*. If $50,000 a year gets me a competent developer, paying $200,000 a year won't get me a coding super-being and paying $500,000 certainly won't get me some Godlike developer. I might be able to find someone with a bit more relevant experience, but ultimately it's a "law of diminishing returns" situation.

Third - and this may not have been true when comparing with AI until quite recently - has been what I'll have to describe as the "mental capacity" of the developer. As a rule I like to write small, modular pieces of code - I think the longest single program file I've written myself is likely to be in the 3,000-5,000 lines range [mainframe COBOL]... When I write PHP code, I like to keep scripts down to a few hundred lines max. I do this because of the amount of ability/effort it takes to maintain and extend a codebase in a time-effective way. There is a practical limit to the amount of deep understanding that a human developer can hold in their head that enables them to understand the code they are working on. As they hit that limit, it becomes necessary to spend more time cross-checking in order to write reliable code. An LLM optimized for coding doesn't have the same limitations. It *does* have limits - for example system RAM - but it can tokenize up code and hold an entire codebase in memory far more easily than a human can.

Fourth and last, there's the obvious point that AI/LLM development is simply the "the computerization" of a process previously done manually. There are sound reasons that we employ computers to replace humans. They are more consistently reliable. But they are much, much faster. If you've ever worked with e.g. Claude Opus in "Cowork Mode" on a development project, I think you would be surprised at the speed with which it can modify code, smoke test it, then offer it back to you for "UAT". We're talking seconds. Not even the best developers are that good.

So my sense is that yes, there will be a small but measurable improvement if you were to hire in the very best experts you could find... but also that those improvements will hit limits much, much sooner.

Patterns in the Noise

The fact that in many/most cases, the vulnerabilities now being found by AI coding agents have been present in code for long periods of time should be an opportunity that we seize and try to learn from. For example, some of the questions that I'd like to ask the Athena Community outlined in the article to which we're responding are:-

1. Programming Languages

Are you finding the distribution of vulnerabilities between programming languages to be regular or irregular, using a vulnerability-density scale - e.g. vulnerabilities per MLOC (millions of lines of code)? In other words, are these hard-to-find vulnerabilities distributed evenly across all languages, or concentrated in a smaller sub-set? This would tell me if any languages out there are more or less likely to contain vulnerabilities than others. In turn, that should be something that all developers/organizations treat as a critical factor when it comes to selecting their technology architecture. And maybe it's an opportunity to give some honest feedback to the language maintainers/platforms concerned...

2. Programming Operations

When you look at the purpose of the underlying code that contains the vulnerability, are you able to classify or categorize the code purpose down to defined activities that might be "more vulnerable than other code"? For example, are the defects showing up in: input validation; session management; authentication and authorization actions; data layer interactions? Which surface contains the vulnerability? (User-facing code; inter-function code; calling down to service code)?

3. Anticipated Detection Mechanism

Hopefully most code written today is subject to at least some kind of testing or review... which in turn suggests that the vulnerabilities being found were missed by traditional mechanisms - whether that was peer review, source code analysis, binary testing, or something else. If possible, it would be helpful to look at the vulnerabilities and try and figure out how the underlying code was originally tested, because that would tell us whether the issue was simply "not enough proper testing done" or whether it was, "our testing methodology and/or tooling was insufficient" - and from that it should be possible to start turning a lens in the direction of the more traditional [and less expensive] methods of preventing bugs from occurring.

4. Genuine Bug or Obfuscated "Back Door"

This is likely going to be the hardest question to answer with confidence, but as a cybersecurity professional, I'm particularly interested in getting insight if it is possible to distinguish between, "OK, that's just a coding error" or "No, this has been carefully written to be vulnerable but to not fail with common use-cases"... It's one of the hardest things that a SOC has to do - determine motive. But if it was possible to learn something from the nature of the vulnerabilities, then there is an entire "higher level" of learning that might be possible.

A while back the YT channel, "Veritasium" produced a video discussing the way a malicious actor very nearly managed to push a major vulnerability in to most current Linux distributions by poisoning a test file for a compression algorithm... It occurs to me that a deeper analysis across all vulnerabilities might throw up possible patterns. If it were possible to automate analysis of things like patch submission histories on Git repos, this work might even be used to find connections between different vulnerabilities in different projects, which in turn could tell us a lot about the malicious actors who we know try to secrete vulnerabilities in to open source projects. That, in turn, might help us protect all open source projects from similar attacks going forward.

As with almost all technology issues, there are wheels within wheels here - we can take the information from Athena and fix the bugs, pat everyone on the back and move on... or we could take the information from Athena and mine it, learn from it, try to prevent the introduction of future bugs by introducing or enhancing preventative controls to cut off the vectors by which the issues were introduced in the first place.

We can't stop with fixing these vulnerabilities.

We have to fix the tools and practices [and, if necessary, languages] that made them possible in the first place.

Like many large organizations, my employer has very robust Incident and Problem Management functions. (Incident manages this issue when it is present in our technology environment; Problem conducts the forensic triage after-the-fact and aims to learn lessons and put in place corrections to eliminate repeat incidents).

It would be really, really nice if the Athena community could try and apply those Problem Management disciplines to this exercise at a sort-of meta level; to look horizontally across all the low-level noise that is being surfaced from the application of these tools and to try and drive more permanent change.

I'm not sure if it really was Einstein, but he's often attributed as the source of one definition of insanity: repeating the same experiment over and over and expecting different results. In this context, the "experiment" that we are repeating is the act of writing software. The AI models are now telling us - loud and clear - that our existing processes for developing code are unreliable. If we want to get a different result when we run the experiment, we're going to need to embrace some [possibly difficult] change.

Google wants AI regulation, but on its own terms

Re: Classic

I don't think the established players are looking to regulation to lock out competition, since of course they would also be bound by it.

Cartel markets seem to be using patents and other forms of intellectual property law for that.

In this case I think what they are aiming for is a sort of "Keyser Soze" form of Regulatory Capture - basically trying to influence the federal government on what elements of AI need to be regulated and what form that regulation should take.

We can expect their proposals to have the appearance of something useful whilst allowing them to continue doing pretty much whatever the #### they want. It will be all show - all bark and no bite - and it will be narrowly tailored in the same way that US financial regulation is narrowly tailored, which will make it possible [perhaps even easy] for the industry to work around the laws.

Everyone hates frontier AI labs, says Palantir boss

Re: You Can Smell The Fear...

Respectfully have to disagree.

Microsoft Windows, IBM z/OS and Apple MacOS are all proprietary operating systems, but:-

They all provide hardware abstraction mechanisms

They all provide pre-emptive multi-tasking capabilities

They all provide memory management functions

We could go on...

The fact that Palantir's code is proprietary doesn't make it special or unique... The mathematics on which it is based - stochastic modelling, gaussian distributions, descriptive statistics (mean, median, mode, variance and standard deviation), or possibly even hypothesis testing like Grubb's test or Z-tests - are not unique to Palantir's code. Nor is the concept of collecting data from lots of potentially disparate sources and reviewing/monitoring it - just like e.g. Instana and Turbonomic from IBM, Datadog, Dynatrace, LogicMonitor and others...

Even the Secret Service won't use company-issued phones

Re: A Bit OT

Here's the thing: President Trump has already been given the OK by his own Justice Department (I know, what a surprise, right?). See here:-

https://edition.cnn.com/2025/05/14/politics/bondi-justice-department-trump-qatar-747

https://www.yahoo.com/news/pam-bondi-round-constitution-trump-184210851.html?guccounter=1

President Trump has already said that he intends to keep the aircraft when he steps down from serving as the 47th President and that he intends to add the aircraft to his "Presidential Museum". In so doing he used the example of President Regan, who had a Boeing 707 that served him during his two terms and which was retired from service in 2001. The aircraft was permanently installed at the Ronald Reagan Presidential Library and Museum in Simi Valley, California.

Of course, the key difference here is that Reagan's 707 had been formally retired and was at end-of-life... while the 747-800 gifted by Qatar was originally manufactured in 2012, but which was effectively given a complete overhaul over the last year and is essentially a "re-manufactured" aircraft. I can't say for sure that all the timed-life components will have been replaced, but it's reasonable to assume that most of them have.

Which doesn't mean, of course, that President Trump intends to keep using it... just that should he wish to do so, he'll effectively being inheriting a 2-year-old aircraft where he was the only previous user...

A Bit OT

So yes, this is a bit off-topic, but... I notice that the article included a shot of several Secret Service personnel with Air Force One in the background.

Not sure if anyone caught it, but a "new" Air Force One - the $400 million 747-8 gifted to the President by Qatar - was rolled out on Friday.

There are pictures of the new aircraft here:-

https://www.yahoo.com/news/politics/articles/air-force-one-qatar-destined-140904834.html?_guc_consent_skip=1782543665

and here:-

https://edition.cnn.com/2026/06/24/us/trump-air-force-one-design

And if you're looking at those images and thinking, "Hang on, I thought that Air Force One was always painted 'Robin's Egg Blue'?" then you would be right, since that is the color scheme that has been in use since the livery was established by President Kennedy in the 1960s.

But.

It costs *at least* $150,000-$300,000 for the most basic paint job for a 747... For more detailed work, such as for Air Force One - the cost can easily run in to millions of dollars.

Wild guess: President Trump expects that this new color scheme will be unique to his aircraft and his presidency. Having been told that the 2 new 747s ordered to replace the existing, original Air Force One will be delayed beyond the day he leaves office, it's just possible that President Trump has decided to have this Qatari-sourced plane painted in the color scheme he wanted, since he's already declared that it was a gift to him personally and that he will add it to his Presidential Museum when he retires. Cough.

Handy way to get your bung of an aircraft refurbished and painted at no cost, eh?

Apple, Tree...

Just a bit of speculation on my part, but I wonder how much of this has actually been driven by Secret Service personnel and how much has been driven by their protectees?

President Trump famously won't use email, doesn't like to put anything in writing, prefers to do everything in person when he can and by phone call when he can't meet face to face. I'm far from the first person to note this, but President Trump operates using the exact same techniques adopted by the New York mafia when they didn't want NYPD to know what they were "getting up to". So I have to wonder if the push-back against GFE has come directly from agents involved or if it is part of a broader resistance to leaving an audit trail? Cough.

A bit off topic - but I think also worth mentioning in this context - does anyone remember the LIBOR scandal from around 2012-2014? For those who don't, LIBOR was the "London Inter-Bank Overnight Rate" and that was the interest charged by one bank lending to another bank so that the borrowing institution could meet it's BASEL-II (now BASEL-III) liquidity obligations - introduced after previous financial meltdowns. What happened was that a small group of traders figured out a way to literally rig the LIBOR market - to set the interest rate and make more money for their (lending) banks.

What was quickly forgotten - or not even reported - in the wake of the LIBOR scandal was the way the scheme was implemented... It was done using SMS messaging, private email accounts and uncontrolled Internet Relay Chat (IRC) channels. Traders used these unofficial and un-monitored communications channels to defraud other banks. If you're interested, here's a BBC article that includes some of those exchanges:-

https://www.bbc.co.uk/news/business-21358362

Point being that in the wake of the LIBOR scandal, financial regulators the world over immediately notified banks that such practices would be prohibited. All access to webmail and external IRC was banned. Anyone in a "market sensitive" role who had a need for a phone was issued with a corporate mobile... and anyone who *didn't* need a corporate mobile often lost the ability to make or receive external calls and to send or receive external emails.

What interests me is not the obvious case of a government basically declaring, "Do what I say, not what I do..." and ordering companies to adopt security practices far more strict than the *Secret Service*... but the fact that there isn't already clear, unambiguous and tight regulation in place to prohibit this.

Donald Trump - often rightly - gets a lot of criticism for his disregard for protocol and his bull-in-a-china-shop approach to doing and getting what he wants... but my sense is that when we look back on this period fifteen or twenty years from now - assuming we're able to do so - we'll see the issue more as a failure to act when it was clear that action was necessary. The first Trump administration clearly became vulnerable to hostile nation state actors - the multiple Chinese nationals caught, tried and convicted of trying to enter Mar-A-Lago during the four years that Donald Trump was out of office, for example...

https://www.justice.gov/usao-sdfl/pr/chinese-national-sentenced-prison-entering-restricted-grounds-mar-lago-and-lying-us

It just seems surprising that, given this backdrop, that members of the Secret Service haven't been told that a failure to use GFE at all times is not just a sackable offense, it's a *prosecutable* offense, on the grounds that it places their protectees at risk. It's amazing that on-duty Secret Service staff aren't subject to much more strict operational rules. Not, I would like to make clear, to suggest that such rules aren't in place (I don't know if they are or not, but it seems unlikely that guidelines would not exist), but that they aren't being rigorously followed.

And it's worth noting how President Trump has singled out certain Secret Service personnel - Anthony Ornato, Robert Engel and Sean Curran, for example - have been brought more closely in to the President's orbit. It certainly seems like the Secret Service are adopting the same sort of practices as their principle charge...

US auto regulators want to kill robotaxi brake pedals

Document Now Published

I just checked - 09:15 Eastern - and the file is now available on the web site. Direct link here:-

https://www.regulations.gov/search?filter=NHTSA-2026-0728

It looks like - as with so many other things - the agency got out over their skis.

Trump-shuttered climate change site back online in nonprofit hands

Re: Life after Trump

At this point, I'd settle for, "Let there be life after Trump" and consider that a narrow escape.

The fact that this wasn't intended to be hyperbolic makes it so - and all the more worrying for it.

AI coding agents could soon cost more than the developers using them

Respectfully, I think your claim "You can't run Claude, whether Mythos, Fable, Opus, or Sonnet in your own facility; Anthropic doesn't let you", is, I believe inaccurate - please see below for examples of AI providers that *do* allow you to run their models on client-owned hardware - and note that Anthropic is among them. The reason I'm pretty confident of that is that until January this year, I worked for just such a company - a US-based global financial services provider - which ran both Anthropic *and* OpenAI models on-premises.

However, I think there may need to be some caveat here. It's possible that we may be talking past each other. There are many industries using AI today - cancer and general drug research for example - where a vanilla/generic model may simply not be appropriate for a company to use. What they want instead is the ability to take a generic model and then tune it with their own closed and open training data sets, to effectively "teach it" the foundational knowledge they want it to have in order for it to support their business needs. That simply isn't something that the main cloud-based solution providers can presently scale to.

It's possible to run something like GLM-5.2 (79.65 coding average; 73.33 Agentic Coding Average)... 1-million token context window; 753B total parameters and comes via an Enterprise-friendly MIT license.... Or you could go with DeepSeek V4-Pro...

[Source: Google Search]

Several major AI companies now allow enterprise clients to run their models fully on their own infrastructure or on-premise hardware. This approach enables strict data sovereignty, regulatory compliance, and total cost control.Leading providers offering this capability include:

Cohere: Designed specifically for businesses, Cohere allows enterprise clients to set up secure servers and run models themselves. Data does not leave your infrastructure.

Mistral AI: Known for its open-weights philosophy, Mistral enables organizations to download powerful models and run them on private systems.

Anthropic: While maintaining its cloud-hosted options, Anthropic allows enterprises operating under strict data residency requirements to host models on their own private servers.

IBM: IBM's Watsonx enterprise AI platform allows companies to train, fine-tune, and run proprietary machine learning models entirely behind their own firewalls.

Inflection AI: Their enterprise offerings let customers fully own custom intelligence configurations with the ability to run directly on-premise.

Databricks: By providing platforms like the Databricks MosaicML platform, companies can train, deploy, and operate custom models within their own VPC (Virtual Private Cloud).

Citations:-

https://northflank.com/blog/top-ai-companies

https://www.eqs-news.com/news/corporate/giotto-ai-launches-portable-ai-for-enterprises-advanced-reasoning-from-cloud-to-workstation/a6faba46-aed6-4b7e-8b05-3166e37e10b2_en

https://www.stackai.com/blog/top-ai-enterprise-companies

https://aimagazine.com/news/why-enterprises-are-moving-critical-ai-workloads-on-premise

https://trustco.co.uk/guide-to-on-premises-artificial-intelligence/

https://www.youtube.com/watch?v=TMOrs464Bd8&vl=en&t=9

https://www.truefoundry.com/blog/on-premises-generative-ai

https://www.edureka.co/blog/generative-ai-companies/

https://intuitionlabs.ai/articles/cohere-enterprise-ai-llm-profile

https://www.eesel.ai/blog/cohere-ai

https://windowsforum.com/threads/coheres-north-the-new-rival-in-enterprise-ai-for-windows-users.349246/

https://worqlo.com/blog/on-premise-ai-vs-cloud-ai-how-to-choose-the-right-deployment-model/

https://www.fortanix.com/blog/how-can-enterprises-deploy-proprietary-ai-model-on-premises

Never Let Facts Get In The Way Of A Good Story

Just pause and think about this for a moment...

Google search offers the following outline costs for US-based developers:-

Average/Median Base Pay = $90,000-$120,000

Experienced/Senior = $124,000-$151,000+

Going back to the claims of the article, it suggests that "AI coding agents could soon cost more than the developers using them..."

OK.

As a rule-of-thumb, the on-costs for an employee - things like the employer contributions to their 401K, their healthcare/medical insurance and all the other benefits they might get [like subsidized meals, the cost of maintaining the building for them to work in - average out as being equal to their salary. So in other words, the fully realized cost of an Average/Median developer is $180,000-$240,000.

Now the article wants you to believe that the cost of AI coding agents will soon exceed that value and claim the following:

" 'Developer teams face an emerging problem of escalating costs, said Nitish Tyagi, senior principal analyst at Gartner. AI coding bills were leaping from $20 or $100 to $2,000 to $5,000 per developer per month, while in extreme cases, the bill might hit $20,000 in token charges.' "

But hang on a moment...

If you are a development shop and you are genuinely spending even *close* to $20,000 per month for AI coding support for one of your developers, then your CIO should have already anticipated this and should have built out your own on-premises AI / compute farm to support your in-house development team. For example,

JPMorgan spends $2 billion per year running AI models [specifically in support of development] out of a broader annual tech budget of $20 billion [so, 10%]...

The Ford Motor Company made an initial billion-dollar investment to in-house "Argo AI" and a further $2 billion into a new energy division for data centers...

GlaxoSmithKliine has committed a multi-billion-dollar investment towards AI and advanced digital technologies...

If you're reading this and think that companies like the above - just a quick sample spanning diverse sectors - will collectively invest billions of dollars in to AI without having the presence of mind to insulate themselves from this sort of thing - or without having direct evidence of real, tangible benefits - then respectfully I think you are mistaken.

We live in an age of the "litigant investor" - people are willing to hold shares in companies that are run responsibly and well - and making feckless bets with unproven technology is not a good career move.

There is another side to this coin, of course... Because AI companies are still very much in startup mode, their products are evolving almost daily and it is next to impossible to predict how expensive a model will be to run until it is deployed in production. Which means that setting prices in advance is incredibly difficult. Which is why the big AI companies are moving towards a token-based model. That's understandable. Where the space for abuse exists is the opacity of these charging models... We simply have no way of knowing how these companies compute token consumption.

And as I said in a previous post, more than 20 years ago I worked with (Honeywell Bull) systems that had forensically precise costing models built in to the operating system - every job that ran was recorded in terms of the cost to execute down to IIRC one thousandsth of a CPU-second. In other words, there are no real excuses for AI companies to be so opaque with their charging... So there has to be another reason...

This storm-in-a-teacup being whipped up by Gartner may be a reaction to a lot of noise as the AI companies jockey and prepare themselves for IPO. They need to be able to show potential investors that their models are profitable, so they are jacking up the prices to inflate margins and attempt to put some black in the ledger ahead of IPO season.

Once all the companies have been *through* IPO and need to actually make money long term, the chances are that this will settle down... because it is better to have 1,000,000 customers making you $100 a month in profit than 1,000 customers making you $50,000 a month in profit.

We have to bear in mind that OpenAI and Anthropic are still relatively young and part of a relatively young industry. Even the most experienced directors and C-Suite executives in these companies still don't fully understand the markets they are trying to serve.

It's going to be bumpy over the next few years, for sure.

And it's worth remembering that AI will never replace a good developer... but it can act as a powerful force-multiplier for a good developer.

Gartner's view is too narrow and almost specious in its arguments. And it conveniently ignores the inevitability of what it takes to run a successful IPO these days. This doesn't excuse the likes of OpenAI and Anthropic playing fast-and-loose with pricing models [and I've certainly seen Anthropic doing that], but the facts simply don't support the conclusions of Gartner's piece.

Nothing to see here. Move along. Move along.

Windows 11 turns five, leaving some important lessons for Microsoft

The "Last Version of Windows"

If you think back to Windows 10, back in 2015, Microsoft announced that it would be "The Last Version of Windows"... and stated that the OS would instead be delivered as a service, receiving continuous feature and security updates, rather than being replaced by future, stand-alone versions.

Even Auntie heard about it:

https://www.bbc.co.uk/news/technology-32658340

I've long wondered about the run-up to the decision to release Windows 11...

In the years previously, Microsoft had got a "cozy thing going on" with Intel and the games ecosystem so that if you wanted to play the latest triple-A game on your PC, then you would need to have the latest version of DirectX... [a *very* thin API shim]... which in turn meant that you would have to have the latest graphics driver for your GPU, which, sadly, meant that you would probably also need to buy a new GPU... and if you didn't need a new GPU, then you'd probably need a new PC with more RAM because the latest version of Windows just demanded more resources.

That nice little ever-decreasing-circle of lies worked for a while... but when governments started muttering "antitrust" and looking at the practice as being a conspiratorial racket, the worldview changed.

It never made sense that Microsoft would back-track and issue Windows 11 so quickly after making such a clearly committed statement.

I mean, we all *know* that Microsoft were lying through their teeth when they said that the latest version of DirectX requires a different OS... Maybe it was the case that GPUs - and gaming hardware in general - just got so expensive that the market for PC gaming dried up... at which point they realised that people with a computer that did what they wanted "today" would not feel obliged to pay for upgrades.

My sense was the whole upgrade cycle was a scam from start to finish.

And don't get me started on the obscene amount of spyware now embedded as standard...

UK school’s network left wide open for invasion, student found

Wasn't it Ferris Bueller's Day Off?

Ferris hacked the school computer to change the number of days he had been sick that semester, even while the baffled Mr Rooney looked on, perplexed.

Nation-state actors cracked critical Australian infrastructure to ‘cripple it at a time of their choosing’

Re: Good on them

If it was remotely possible, coming up with a play that would have allowed them to preferably arrest her, or possibly embarrass her publicly, that would have been the perfect response.

Of course we don't know the specifics - and it may well be that ASIO looked at all the opportunities and this was their best option.

And we also have to think about the fact that ASIO also have a duty to educate and warn other potential targets in Australia. It seems to me that these hostile outreach activities are a cheap and easy way to cripple a nation from within... so by going public and showing that there were only positive outcomes for the target, ASIO may be trying to encourage other people to step forward.

In particular, this story shows that the target provided and was paid for work by a hostile foreign agent... and there may be other Australian citizens who find themselves in a similar situation and who are reluctant to come forward because they fear they will be charged.

If this is ASIO's way of saying, "Look, the problem is much bigger - we're not going to condemn you for a previous error in judgement, *if* you come clean now..." then it might be effective.

I guess that's the challenge with spy agencies, eh? You never really know what they're thinking...

Micron locks in historically high memory prices for five years

Is This A Prediction?

Obviously I have no internal knowledge of the thinking behind Micron's decision, but there's something a bit fishy here.

If Micron believed that the demand for RAM would continue to rise over the next five years, they would be mad to agree to a price cap - in effect limiting their profits. In the event that things turned south [and depending on local laws] they might have some shareholder lawsuits on their hands.

Which suggests that they might have a different outlook.

There are a couple of possible explanations, but surely the most likely is that Micron suspect that the AI bubble will burst within the next 5 years and that this will result in a glut of RAM chips on the market. So by signing these agreements, they are in fact locking in their customers to what may become artificially *high* prices for another five years.

And of course Micron are in a position to know more about the marketplace than most, because they are the same company that walked away from retail sales in order to exclusively serve the biggest customer clients... They will be monitoring RAM sales to the bigger AI startup companies, so if they see a softening in demand, now would be the perfect time for them to strike deals that "lock in" the obscene profits they have been making.

It probably isn't a coincidence that this week's market sell-offs have been driven by investor jitters over whether the AI revolution will return profits or whether the valuations of the key stocks are over-priced.

Mythos discovers 'Squidbleed,' a memory leak that's gone undetected since Clinton era

Re: More marketing

Maybe the fact that no humans reported this bug for 29 years indicates something slightly different?

I accept that implicit in the point you're making is the fact that this is more PR supporting Mythos and Anthropic... but to try and be balanced about this... Can you imagine how many millions of person-hours are spent each year by companies forced to recover from software errors? Can you imagine the costs to industry writ large?

That isn't to say, by the way, that we should push every piece of source code through Mythos just to ensure that it is bug free... but I think the evidence emerging suggests that the most common software in use today - things like operating systems, the BIOS on motherboards, firmware in devices like hard drives and SSDs... the most commonly used applications and middleware... these are valid candidates for more rigorous testing.

And I appreciate that these are not "high volume" examples (the opposite, in fact), but among the more embarrassing losses due to software errors, we could include:-

The Mars Climate Orbiter (1999)

Phobos 1 (1998)

Lunar Trailblazer (2025)

Mariner 1 (1962)

Hakuto-R Mission 1 (2023)

and

Mars Global Surveyor (2006)

There are a whole class of use cases where we deploy software in mission-critical or very-difficult-to-update scenarios.

On the mission-critical side of things, what about avionics, aerospace, RADAR and software running across the aviation industry;

trains, railways, underground systems, signalling and junction control software;

electricity generation, distribution and management;

etc.

The obvious question/challenge to this is: "Yes, but what about the cost?" I think the answer is implementation specific, but could be something along the lines of:-

"Assume that a malicious attacker had access to AI to attempt to break or meddle with the software in question. What would a typical failure mode look like in terms of impact and cost-to-recover? If the cost-to-scan is less than the cost of a common-or-garden AI-backed attack, it's probably worth your time and resource to perform a scan..."

Bold move, Cotton: Trump administration tells US techies it expects American quantum computer by 2028

Reality Has Nothing To Do With It

There are at least a couple of high-probability contenders to explain this announcement.

The first one is that President Trump is by now famous for being vulnerable to the "Last Person Who Speaks" - someone gets to buttonhole him on the way out a meeting room, throws in some fawning compliments and makes a bold pitch... and we've all seen how the President can fixate on something when he wants to. The United States lost thirteen sons and daughters because Netanyahu and the Israeli government seized the moment when the President was riding high after the Venezuela operation to sell him on the idea of a war with Iran. Look where the world is now.

The second is that President Trump now has sufficient operating capital, from various other "investment schemes" and "business opportunities" [things like the $TRUMP meme coin, for example] to be able to benefit from strategic investments. We've already seen in his own financial disclosures that the President has invested in companies that he then supports with contracts or similar sponsorship. Of course, that is tip-of-the-iceberg stuff - one of the massive differences between this Administration and the 2016 Administration is that this time around his family members are ostensibly not involved, or working behind the scenes. Which is not to suggest that they did this to avoid controversy:-

https://www.economist.com/europe/2026/06/16/albanias-flamingo-protests-target-donald-trumps-son-in-law

My sense is that out of the range of possible explanations is that the President and or his family might be considering a sizeable financial investment in one or more companies that are about to be the recipient of major federal funding initiatives, intended to yield the outcome of a viable Quantum Computer. A bit like the way that pouring money in to NASA starts a cascade effect because all of the cost-plus contracts with the major players like Boeing then in turn create opportunities for Boeing's suppliers. Very much copying the model that Japan pioneered after World War II.

It's much, much harder to bring forward evidence to support this hunch - which is why I'm being circumspect and careful to suggest that it is, in fact, a hunch. But if there were something I could point to, then it would be the almost complete lack of interest that the President has shown in ANY domestic issue where he is not personally invested.

Farmers driven to bankruptcy because of the soaring price of fertilizer, thanks to the Iran conflict? Nope.

Companies failing because of tariffs? Nope.

Victims of fraud and financial crime? Nope. [He has not only pardoned a number of criminals convicted of financial crimes, he has also waived court demands for restitution to victims.

As a tekkie I genuinely hope that this cross-government initiative yields real results.

As a tax payer I'm quite a bit more suspicious.

EU won't force publishers to grant dead video games an afterlife

Re: Physical Comparisons

I think the answer might be "Yes, but..." ... in that BMW, Tesla, Mercedes-Benz, Toyota and Subaru have all implemented "Software Tiers". When the owner of a bought-from-new car trades it in part-exchange for another new vehicle, dealers of the above brands are able to disable functionality "in software", thus forcing the buyer of a used vehicle to pay extra for functionality already installed...

So... to answer your question, I think that companies like those above will continue to maintain the technology for as long as they are able to use it to extort even more money from buyers of used vehicles.

The other thing I think is important to point out is that vehicles that have this sort of functionality are also appearing with "wrap-around dashboards" and huge OLED screens instead of conventional dials... and I would just observe that these are all designed and built as bespoke items for specific models, which means that once production has ceased, there will be a limited window in which spares will be available before entire vehicles will have to be scrapped.

Which of course is going to ensure that the companies retain healthy profit margins for as long as privately-owned personal transport is a thing.

Peter Mandelson invited UK PM to meet Palantir's Thiel

Just on your first item - devolution...

At the time he was in office [and clearly thinking about his next gig] he made a big show of giving press conferences and speaking French, of the use of a podium and of conducting himself more like a President than a Prime Minister. Lots of the insider Mainstream Media spoke or wrote about Blair favoring a "Presidential Model" of democracy... Of course, what he was really doing was auditioning for the job of EU President, which he didn't get.

One of the things the EU has promoted as Brussels has become ever more powerful is the undermining of national governments. It historically provided significant financial support to Scottish infrastructure, university and community projects through European Structural and Investment funds. Similarly, Wales has received billions of pounds from the same EU funds - more than £5 billion since 2020.

This isn't altruism.

The net effect of Blair pushing devolution and the EU providing large amounts of financial support to Scotland and Wales reduces the authority, scope and effectiveness of Westminster. And of course a powerful Westminster is the last thing that Brussels would want if their goal was harmonization of the EU as an integrated political whole.

In other words, the EU has always been in a power struggle with national governments... and Blair made it easier by triggering devolution. He did it not because it was in the UK's best interests, but because it was in his.

That man is so low he could put on a tall silk hat and walk under a duck.

Anthropic's Mythos mess just keeps getting more complicated

Remember nVidia and AMD...

Back in August last year, nVidia struck a deal with the US Government that allowed them to export their H20 chips to China in return for 15% of the company's Chinese sales revenue.

Similarly, AMD got the same export approvals in return for 15% of the revenue from their sales of the MI308 Chip. See here:-

https://www.theguardian.com/technology/2025/aug/10/nvidia-amd-china-chip-sale-revenues

I appreciate that the above examples are *hardware*, while the Anthropic situation involves *software*, but to my way of thinking, that makes the difference in outcome all the more astounding. Software can be stolen. There is circumstantial evidence to suggest that these AI companies are not as serious about security as they could be - and we know from evidence that China, North Korea and Russia have dedicated vast resources to stealing secrets from the US and other western nations - everything from compromising RSA's root keys in order to be able to hack Lockheed Martin to stealing the operating principles of a wave-based power generator from a Scottish engineering company.

Yet here we see the US government refusing to give Anthropic an "export license" for their software - for the whole world, not just China/Russia/North Korea - citing national security.

That's just utter garbage.

The Trump administration was happy to give China the cutting edge hardware needed to run AI models [which, arguably, they would have found much more difficult to develop themselves], yet is blocking Anthropic from exporting. Just Anthropic, mind, not OpenAI or xAI...

Nice little AI business you got here. It would be a shame if something were to happen to it.