Espresso Code: Italian Dev Insights

Insights and guides from an Italian passionate developer

Dark brown background with the headline "AI amplifies those who look for flaws", "look for flaws" in orange. Below, sixteen vertical brown bars: one is a dashed orange outline, like a lever taken out. Typography and geometric shapes only.

Abliterated models and October’s flaws: AI amplifies those who look for flaws

By

On 2026-10-29

In News

On October 21, 2026, Wiz, a cybersecurity company, published the PHP2Shell case: two critical flaws in PHP, a programming language used in websites. According to Wiz they had been in the code for decades, and they were found with the help of artificial intelligence models.

Hence the question: if models help those who look for flaws, who benefits the most? I read the sources, and the answer is less clear-cut than I imagined. Models amplify those who look for flaws, in defense and in attack, and for each step I say what is proven and what is not.

Those who look for flaws get extra help

Of the four flaws of October, the use of AI models is declared for only one, the PHP one. For Node.js the page lists “OpenAI Codex Security” among the reporters without saying how the flaw was found, and for WordPress and Tailscale it says nothing on the matter.

A few acronyms: CVE is the code that identifies a known vulnerability, and KEV is the catalog of exploited vulnerabilities kept by CISA, the U.S. cybersecurity agency. RCE is remote code execution; XSS, the injection of malicious code into a web page, is called stored when the code remains saved on the site.

  • PHP: according to Wiz, the work was done with Wiz Atlas, one of the company’s own tools, and with the models Gemini 4 Argon and GPT-5.6 Sol. Google Cloud repeats the same sentence about Gemini 4 Argon, but Wiz now appears to be part of Google Cloud: it is not an independent confirmation.
  • Node.js and Brotli: the Node.js page attributes the report to “OpenAI Codex Security,” but does not say how the flaw was found.
  • WordPress 7.1.4: the official notice of October 28 lists 13 security items, including several stored XSS problems grouped in a single item. Two are reported by “Anthropic,” but the page does not say with which tools.
  • Tailscale: Erica Windisch, of Cyberdione Labs, published a report on 11 problems in Tailscale and headscale. The stated method consists of lab work, code analysis and fuzzing (automated tests with random data), with no declared use of AI.

On PHP, Wiz explains the point with one sentence. The flaws had been there for a long time, but showing that they could be exploited required a chain of steps at the limit of what human researchers could do. For Wiz, which is describing its own work, “Frontier AI models substantially reduced that barrier, turning a longstanding flaw into an exploit.”

On exploitation, I stick to what the sources say. CISA added the two PHP flaws to the KEV catalog on October 26. Sansec, picking up a report from Cloudflare, reports early attempts on October 21, but writes that mass exploitation is less likely than expected. The Node.js flaw has been in the KEV catalog since October 27: Node.js describes it as an out-of-bounds write, while CISA classifies it under a different name.

Hacker doesn’t mean malicious

The word was born with a different meaning. RFC 1392, an Internet glossary from January 1993, calls a hacker someone who delights in understanding in depth how a system works, and a cracker someone who tries to get into systems without authorization.

The defensive use of AI is documented too. Hugging Face hosts models of this kind and is therefore an interested party. In its account of the intrusion it suffered in July, it writes that the safeguards (guardrails) of commercial models accessed through APIs blocked the defenders’ work, because they cannot tell an incident responder from an attacker.

For the analysis it used an open-weight model, GLM-5.2: a model whose weights are published and can be downloaded, which is not the same as open source in the strict sense. Jeff Boudier, in a guide on the Hugging Face blog, advises defenders to have one ready locally: it is the position of someone who hosts those models.

Anthropic, with Project Glasswing, says that it puts the capabilities of its models at the service of defense: it is a statement from an interested party. In Anthropic’s tests with human experts, moreover, GLM-5.3 found previously unknown vulnerabilities in a browser’s JavaScript engine, which according to Anthropic were reported to the maintainer. I did not find it stated whether the model in those tests was the original version or the abliterated one.

What is abliteration?

A model refuses certain requests because it learned to do so in training. In 2024 a group of researchers, with Arditi as first author, showed that in 13 open-source chat models, up to 72 billion parameters, refusal depends on a single direction in the model’s internal space. It reminds me of a machine with many brakes where you only need to remove a single lever: once that is gone, refusal no longer kicks in, without retraining anything.

The word “abliteration,” from “ablation,” does not appear in the paper. Maxime Labonne uses it in a Hugging Face post from June 2024 that applies that technique. From here on I write “abliterated” for models whose refusal has been removed this way.

Anthropic’s attempt on the GLM-5.3 model required, according to Anthropic, about 2,200 GPU hours (GPUs are the graphics processors used for these computations) and about $4,400, largely to try out variants. An expert team, Anthropic estimates, would use about 600 GPU hours and about $1,200. Also according to Anthropic, the model’s capabilities remain substantially unchanged.

Chinese open-weight models and their versions without refusals

Abliterated versions appear quickly after a model’s release. The only primary-source evidence concerns GLM-5.3, from Z.ai: according to Anthropic, several developers published abliterated versions of it within days. For the other models I found mostly secondary sources.

Pillitteri, a personal blog that links no primary sources, writes that for DeepSeek 4.1 Flash the first versions arrived a few hours after release. According to CBS News, researchers at Tech Against Terrorism found abliterated versions of an Alibaba model within a day of its release. For Qwen, explainx reports that Pliny, a jailbreak researcher (someone who tries to get around models’ safeguards), published a version that Pliny calls “OBLITERATED” of Qwen3.8-27B and says 0.0% refusals on 842 harmful requests: it is Pliny’s own figure, unverified.

On Kimi K2.7 Code and on MiMo I have less. A page that picks up a post on X says that the Kimi repository is no longer reachable, but does not give the cause. For MiMo I could not verify anything. The Tech Against Terrorism test, on terrorism and not on cybersecurity, also covered non-Chinese models, such as Meta’s Llama and TII’s Falcon: the effect is not only Chinese.

How much do models without refusals amplify those who use them?

In an isolated environment the difference shows. In the tests described by Anthropic on September 29, 2026, with 50 samples per condition, GLM-5.3 accepted explicit requests for offensive cyber operations in 0% of cases with a direct request. The rate rises to 64% with a deceptive prompt (a false cover story: posing as an autonomous red-team agent; the red team is the group that simulates attacks), to 92% with a reasoning prefill (the model’s reasoning is started for it), and to 100% in the abliterated version.

On the refusal benchmarks, according to Anthropic, the average refusal rate drops from about 95% to about 6%. Anthropic specifies that the simulations “are not perfect portrayals of real-world conditions”: no generated code is executed, so these are engagement rates and not success rates of real attacks.

Those rates measure the willingness to answer, not the capability, and the two intermediate conditions concern the original model: refusal can be bypassed even without abliteration. Anthropic, moreover, is an interested party, because it develops competing models.

An independent source is CAISI, a center of the U.S. National Institute of Standards and Technology (NIST). On September 17, 2026, it wrote that “GLM-5.3 is the most cyber-capable open-weight model released to date,” but that the model “lags the capability level of the U.S. frontier by about four months.” The page does not mention abliteration. According to Anthropic, abliteration leaves capabilities substantially unchanged, but the lag of about four months measured by CAISI concerns the original model: I did not find a measurement on the abliterated model.

Z.ai is an interested party too. One of its researchers, in a post on X, said that GLM-5.3 had flagged 4,249 potential vulnerabilities in 389 open-source projects, 53 of them with a CVE. The post is reported by Pillitteri and the figure has not been verified by third parties. It is the same capability that, as I wrote above, also serves to report flaws.

A real case, with its limits

The only real case I found is from CrowdStrike, dated October 7, 2026. According to CrowdStrike, between late September and early October an unknown actor hit South Korean financial organizations with ARTEX, an agentic tool, meaning one that can act autonomously, for penetration testing (intrusion tests), open source and developed in China.

As its main model it used DeepSeek v4.1-flash, probably through a proxy or an API reseller, while GLM-5.3 and Grok 4.6 appear in other sessions.

According to CrowdStrike, AI can allow a financially motivated actor to carry out more intrusions in a short time. But the page does not say the models were abliterated. It attributes the actor to a probable Chinese speaker, with moderate confidence and no known group. I looked for a real attack with an abliterated model and did not find one, though my search is not exhaustive.

Hugging Face removed some models, not all

I started from the idea that Hugging Face had removed them all. The sources say otherwise. One removal is confirmed: the repository penclaw-GLM-5.3-abliterated-for-offensive-cyber, from the Audn AI account, appears as disabled for violating the Content Policy, as the repository page says. On when this happened, the sources I read do not agree and the page has no date.

The Content Policy does not name “uncensored” or “abliterated” models. It prohibits content designed to gain unauthorized access to systems, and content that attempts to transmit or generate malicious code, and provides for moderating other content in response to evolving challenges posed by advancements in machine learning. The repository page does not say which clause was applied. According to a blog with no primary sources, a copy with a different name is circulating: it is a rumor.

Other disappearances are uncertain, such as that of Kimi K2.7 Code. Many models remain: on October 29 the search “abliterated” on Hugging Face returned 8,803 results. It is the search count, not a census, and it includes quantizations (compressed versions that run on smaller machines) and copies.

CBS, citing Tech Against Terrorism, speaks of more than 29,000 repositories advertising models without censorship: it is a different measure, with a different criterion.

Hugging Face, in a note written to CBS by Yacine Jernite, says that it “conducts ongoing moderation and regularly acts on datasets, models, and Spaces that go against its content policy.” According to CBS’s summary, Jernite maintains that abliterated should not be equated with harmful, because a model that refuses can also block legitimate uses.

I found no official statement on specific removals or on a general ban.

Where the barrier stands

According to Wiz and Anthropic, the barrier has dropped for those who look for flaws. In the sources I read, this is documented for those who look for flaws with U.S. models (the PHP case) and in controlled tests on GLM-5.3. There is also a real case on the attack side, of which the page does not say whether the models were abliterated. For the four flaws of October I found no documented link to Chinese or abliterated models.

To the question I opened with, the sources do not allow an answer: they document the help to those who look for flaws, not a greater advantage for those who attack. What remains open is what will happen if the versions without refusals become easier to find or to stop. It remains to be seen how Hugging Face, the labs and the defenders will use these tools in the coming months.

A note before the sources: the newsroom I work with uses Anthropic models, and Anthropic is among the sources of this article. For this reason I attributed each of its claims and marked where it is an interested party.

Sources

Accessed October 29, 2026. I mark when a source is primary, a secondary report, or an interested party.

  1. Hugging Face, page of the repository penclaw-GLM-5.3-abliterated-for-offensive-cyber (account audnai), no date on the page. Primary source. I do not give the link, because it is an offensive-cyber repository.
  2. Hugging Face, Content Policy, effective April 10, 2025. https://huggingface.co/content-policy
  3. Pasquale Pillitteri, “Hugging Face Pulls GLM-5.3 Build Made for Cyberattacks,” date on the page 02/10/2026, day and month order not stated. Secondary report with no primary sources. https://pasqualepillitteri.it/en/news/20174/glm53-huggingface-takedown-cyber-en
  4. Pasquale Pillitteri, “Hugging Face bans first uncensored models, Kimi K2.7 Code vanishes,” October 25, 2026. Secondary report of a post on X. The title speaks of a ban, but the article itself describes removals one repository at a time and calls the reading of a general ban not fully supported. https://pasqualepillitteri.it/en/news/27102/hugging-face-bans-uncensored-models-kimi-k27-code
  5. Hugging Face, search “abliterated,” 8,803 results on October 29, 2026 (the page has no absolute date). https://huggingface.co/models?search=abliterated
  6. CBS News, Lauren Fichten, “Researchers asked AI models to help with terrorist operations. Here’s how they responded.” October 9, 2026. Secondary report of the Tech Against Terrorism report. https://www.cbsnews.com/news/researchers-ai-terrorist-operations-responded/
  7. Hugging Face, “Security incident disclosure – July 2026,” July 16, 2026. Primary source and interested party. https://huggingface.co/blog/security-incident-july-2026
  8. Jeff Boudier and Enrique Hernandez Calabres, “Be Ready Before the Attack: A Practical Guide to Self-Hosting an Open Model for Cyber Defense,” Hugging Face, July 20, 2026. Interested party. https://huggingface.co/blog/jeffboudier/open-model-cyber-defense
  9. Arditi, Obeso, Syed, Paleka, Panickssery, Gurnee, Nanda, “Refusal in Language Models Is Mediated by a Single Direction,” arXiv:2406.11717, June 2024. https://arxiv.org/abs/2406.11717
  10. Maxime Labonne, “Uncensor any LLM with abliteration,” Hugging Face, June 13, 2024. I do not give the link: it is a tutorial on the procedure.
  11. Anthropic Frontier Red Team, “GLM-5.3 and the spread of advanced cyber capabilities,” September 29, 2026. Primary source and interested party. https://www.anthropic.com/research/glm-5-3-and-the-spread-of-advanced-cyber-capabilities
  12. NIST CAISI, “CAISI’s Assessment of Z.ai’s GLM-5.3 Cyber Capabilities,” September 17, 2026. Primary source, independent. https://www.nist.gov/news-events/news/2026/09/caisis-assessment-zais-glm-53-cyber-capabilities
  13. Pasquale Pillitteri, “DeepSeek 4.1 Flash Uncensored, Abliterated Builds Hit HuggingFace Hours After Release,” date on the page September 13, 2026 (probably edited later). Secondary report. https://pasqualepillitteri.it/en/news/16070/deepseek-41-flash-uncensored-abliterated-builds
  14. explainx.ai, Yash Thakker, article on Pliny and Qwen3.8-27B, August 21, 2026. Secondary report; the refusal figure is stated by Pliny. https://www.explainx.ai/blog/pliny-qwen3-8-27b-obliterated-alex-finn-mac-august-2026
  15. Pasquale Pillitteri, article on the 4,249 vulnerabilities stated by a Z.ai researcher, September 30, 2026. Secondary report of a post on X; figure from an interested party. https://pasqualepillitteri.it/en/news/19470/glm-5-3-4249-vulnerabilities-nist-caisi
  16. CrowdStrike, “Unknown Threat Actor Uses AI-Driven ARTEX to Target South Korean Finance,” October 7, 2026. Primary source. https://www.crowdstrike.com/en-us/blog/unknown-threat-actor-uses-artex-to-target-south-korean-finance/
  17. Wiz Research, “PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet,” October 21, 2026. Primary source and interested party. https://www.wiz.io/blog/php2shell-php-rce
  18. Google Cloud, Chris Betz and Raluca Ada Popa, “Responding to core PHP vulnerabilities (CVE-2026-109618, CVE-2026-109619),” October 21, 2026, updated October 22 and 23. https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619
  19. Sansec, “PHP2Shell,” October 21, 2026. Secondary report of a Cloudflare report. https://sansec.io/research/php2shell
  20. CISA, “CISA Adds Two Known Exploited Vulnerabilities to Catalog,” October 26, 2026. https://www.cisa.gov/news-events/alerts/2026/10/26/cisa-adds-two-known-exploited-vulnerabilities-catalog
  21. CISA, Known Exploited Vulnerabilities catalog, entry CVE-2026-111497, added October 27, 2026. https://www.cisa.gov/known-exploited-vulnerabilities-catalog
  22. Node.js, “Wednesday, October 21, 2026 Security Releases,” October 21, 2026. https://nodejs.org/en/blog/vulnerability/october-2026-security-releases
  23. WordPress.org News, Aaron Jorbin, “WordPress 7.1.4,” October 28, 2026. https://wordpress.org/news/2026/10/wordpress-7-1-4/
  24. Erica Windisch, Cyberdione Labs, “Tailworm,” report on Tailscale v1.104.2 and headscale v0.29.5, updated October 27, 2026. https://tailworm.com/
  25. RFC 1392, “Internet Users’ Glossary,” January 1993. https://www.rfc-editor.org/rfc/rfc1392
  26. Anthropic, “Project Glasswing: Securing critical software for the AI era,” April 7, 2026. Primary source and interested party. https://www.anthropic.com/glasswing
  27. itdaily.com, “Google completes $32 billion acquisition of Wiz,” March 11, 2026. Secondary report. https://itdaily.com/news/business/google-acquires-wiz/
Diagram: on macOS, Safari and native apps use Apple's block of the eMudhra certificates, while git, curl, and python3 read the file /etc/ssl/cert.pem

eMudhra certificates on Mac: what happens to git and curl

By

On 2026-10-29

In News

On October 26, 2026, Apple released macOS Golden Gate 27.2, but developers on a Mac are still missing one fix: the one for the compromised eMudhra certificates. Safari has rejected them since October 19; the system git and curl still accept them [1]. In fact, according to two October 28 sources, the update undid the manual fix [5] [7].

What does that mean, in practice, for a repository clone run over a hotel Wi-Fi network? Just think: anyone on the network path between you and GitHub can pass themselves off as GitHub and hand you code of their choosing [5].

Let’s take it one step at a time: what happened, why it only affects some tools, and what Apple has said as of October 29, 2026.

In short:

As of October 29, 2026, macOS’s own git, curl, and python3 still trust the compromised eMudhra certificates; Safari, Mail, and native apps block them (Apple page of October 23, unchanged on the 29th). If you use them for HTTPS, you’re exposed: you can wait for the promised, undated update or follow Apple’s procedure, which requires an administrator account.

  • October 19 and 23, 2026: Apple blocks the 12 compromised certificates and then the emSign ECC Root CA – G3 root, but only for Safari, Mail, and native apps.
  • October 23, 2026: Apple publishes support page 149555, with a manual procedure for anyone who administers a Mac.
  • October 26, 2026: macOS 27.2 doesn’t fix the problem and, according to a test from October 28, puts the two roots back in /etc/ssl/cert.pem.

What happened to the eMudhra certificates?

The private keys of eight eMudhra intermediate CAs have been compromised, Apple writes [1]. eMudhra is a certificate authority (CA): with its signature it vouches that a TLS certificate, the one behind HTTPS connections, really belongs to a site.

An intermediate CA sits between the root certificate, which systems trust up front, and the certificates of the sites. Two of the eight sign code, the other six sign TLS certificates. With the keys of these six, according to Apple, anyone can create certificates that appear valid for any site [1].

Twelve certificates are involved. Six chain to the emSign ECC Root CA – G3 root; the other six, cross-signed by Sectigo, chain to the AAA Certificate Services root. eMudhra and Sectigo have revoked them [1].

According to Dennis Jackson and the other authors of emudhra.we-have-a-problem.com, the keys were generated incorrectly and could be recovered from the certificates themselves as far back as April 2025 [4]. Whether anyone exploited them is not known: MacRumors reported on October 25, 2026, that there is no evidence of malicious use [8].

Why is Safari protected while git and curl aren’t?

Because they don’t read the same list of certificates. Safari, Mail, and the apps that use Apple’s networking and security frameworks get the block automatically, with nothing to install: the 12 certificates since October 19, 2026, the emSign root since the 23rd [1].

The curl, git, python3, ruby, perl, and openssl that ship with macOS or the Xcode Command Line Tools use /etc/ssl/cert.pem instead, a text file with the root certificates lined up one after another. For certificates that chain to a root in that file, Apple writes, they check neither the block nor revocation [1].

There is also a second difference. Most browsers require every certificate to be in the public Certificate Transparency (CT) logs; curl doesn’t [4]. And in the logs, for these intermediate CAs, no certificate had appeared since April 2025, when the keys first became recoverable [4].

That is why, according to the same authors, Firefox, Chrome, Edge, and Safari could not have been attacked, while for programs outside the browser it is not known [4].

Why did macOS 27.2 put the two roots back in the file?

Because a macOS update can replace /etc/ssl/cert.pem with Apple’s version, which still contains the two roots. Apple says so itself: anyone who removed them by hand has to repeat the check described on page 149555 after every update, until the one with the fix arrives [1].

In the security notes for macOS Golden Gate 27.2, released on October 26, 2026, there is no trace of eMudhra [3]. The Japanese site AAPL Ch. updated a virtual machine running macOS 27.0 to 27.2: after the installation, the two roots were back in the file [7].

The same thing happened with macOS Tahoe 26.7.2, released on the same day [2]. In issue #157 on GitHub, opened on October 27, 2026, a Mac updated from 26.7.1 to 26.7.2 went from 126 to 128 certificates. And the system curl started accepting the test sites that use certificates from the compromised CAs again [4] [6].

The author of the issue also found the two roots in the reference copy of the file that macOS 26.7.2 keeps among its system templates. Their hypothesis, presented as such, is that the update recreates the file from there instead of editing it [6].

What are the risks for developers on a Mac?

A specific condition is needed: someone has to be on the network path and use a certificate signed by one of the compromised CAs. In that position, according to the site of Dennis Jackson and the other authors, they can intercept the HTTPS connections of the tools Apple ships [5].

For git, a clone or pull from an HTTPS address can deliver code chosen by the attacker. A push can be altered along the way, and credentials such as GitHub tokens can be intercepted. The same goes for curl and python3 [5].

Think of an installation script downloaded with curl over a conference network: if the fake certificate gets through, the script that arrives may be a different one.

The picture, however, should be kept in proportion. The major browsers, as mentioned, could not have been attacked [4], and anyone who uses a Mac only with Safari and native apps, Apple writes, doesn’t need to do anything [1]. Apps that ship their own certificate list, such as Electron-based ones, need to be kept up to date instead [4].

This concerns people who work in the Terminal and those who run macOS runners for continuous integration (CI). For the latter, the researchers’ site recommends evaluating the risk to the software supply chain [5].

What does Apple say, and what can you do in the meantime?

Apple writes that the fix will come with a future macOS update and that you won’t need to edit any files [1]. There is no date: MacRumors pointed this out too on October 25, 2026 [8]. As of October 29, 2026, the latest macOS version listed by Apple is still 27.2 [2].

If you don’t want to wait, support page 149555 has the official procedure for removing the two roots from the file [1]. It requires an administrator account and has to be repeated after every update, until the one with the fix comes out.

If it’s a company Mac, the choice is up to whoever manages it: Apple notes that the commands can be deployed through a device management (MDM) solution [1].

The procedure has a cost, and Apple spells it out: without the two roots, tools that use only that file might no longer be able to verify some legitimate sites, the ones that go through intermediate CAs that weren’t compromised [1]. If a pull that used to work starts throwing certificate errors, this may be the reason.

As an alternative to the procedure, some people have git and curl use Homebrew’s list of certificates, which excludes the same two roots [6] [9]: the system file stays untouched, but the same legitimate sites can throw errors.

And other programs, from Node.js to Linux?

It depends on which list of certificates they use. Anything that ships its own list follows its own version, not the macOS one: as of October 28, 2026, the patched versions include, among others, Node.js 26.12.1, 24.22.1, and 22.23.4 and the certifi 2026.10.19 package for Python [4].

If you install the TypeScript 7.1 beta with npm, as in my article, what matters is the Node.js version you have on your Mac.

For Electron-based apps, such as Slack and Discord, the fix only arrives with an update of the app to a version built on a patched Electron [4]. Go, on the other hand, uses system verification on the Mac starting with version 1.18, when the program doesn’t specify roots of its own [10].

On Linux, the major distributions have already updated the ca-certificates package [4]. On a board like the Radxa ROCK 5B from my guide on booting from an NVMe SSD, updating its distribution’s package is enough.

It remains to be seen how long it will take for the update Apple has promised. Until then, for anyone who uses git and curl on a Mac, page 149555 remains the reference to reopen after every macOS update.

Frequently asked questions

Do I need to do anything if I don’t use the Terminal on my Mac?

No. Apple writes that Safari, Mail, and the apps that use its frameworks have blocked the compromised certificates automatically since October 19, 2026. The problem concerns the command-line tools that ship with macOS, such as git, curl, and python3, and the apps that ship their own list of certificates, which need to be kept up to date.

What should I do if I use git or curl on my Mac?

For now, either wait for Apple’s update or follow the procedure on page 149555, repeating it after every update. On company Macs, whoever manages them decides. An alternative is a certificate bundle, a separate file listing the trusted roots, such as Homebrew’s: it excludes the same two roots, so the risk Apple points out for legitimate sites remains.

Does updating macOS already fix the eMudhra certificate problem?

Not yet. As of October 29, 2026, the latest version is macOS Golden Gate 27.2, from October 26, and Apple’s page still mentions a future update. According to tests from October 27 and 28, 26.7.2 and 27.2 actually put the two roots back in the file. When the fix arrives, Apple says, you won’t need to edit any files.

What is an intermediate CA, and what does it mean that it is compromised?

It is a certificate authority that sits between the root certificate and the sites, and signs the sites’ certificates. If its private key is compromised, whoever has it can sign a certificate that appears valid for any site. According to Apple, this happened to eight eMudhra intermediate CAs, six of which sign TLS certificates.

Sources

  1. Apple, “About the compromised eMudhra intermediate CAs” (Apple Support 149555), October 23, 2026, accessed October 29, 2026 – https://support.apple.com/en-us/149555
  2. Apple, “Apple security releases” (Apple Support 100100), updated October 26, 2026, accessed October 29, 2026 – https://support.apple.com/en-us/100100
  3. Apple, “About the security content of macOS Golden Gate 27.2” (Apple Support 149521), October 26, 2026 – https://support.apple.com/en-us/149521
  4. Dennis Jackson and contributors, “eMudhra Intermediate CA Compromise,” October 20, 2026, updated October 28, 2026, accessed October 29, 2026 – https://emudhra.we-have-a-problem.com/
  5. Dennis Jackson and contributors, “Apple’s git still trusts the compromised eMudhra certificates,” October 28, 2026 – https://emudhra.we-have-a-problem.com/apple.html
  6. Issue #157 in the galadran/we-have-a-problem.com repository on GitHub, “macOS 26.7.2 (26 Oct) restores /etc/ssl/cert.pem with both roots; the workaround must be re-applied after every update,” opened October 27, 2026, comments through October 28, 2026 – https://github.com/galadran/we-have-a-problem.com/issues/157
  7. AAPL Ch., article on macOS 27.2 and the restoration of /etc/ssl/cert.pem (in Japanese), October 28, 2026 – https://applech2.com/archives/20261028-macos-updates-may-restore-emudhra-root-ca-certificates.html
  8. MacRumors (Joe Rossignol), “Apple Addresses Web Security Threat, Working on macOS Update With Additional Fix,” October 25, 2026 – https://www.macrumors.com/2026/10/25/apple-blocks-compromised-emudhra-certificates/
  9. Homebrew, ca-certificates formula (stable version 2026-10-20; exclusion of the AAA Certificate Services and emSign G3 roots), accessed October 29, 2026 – https://formulae.brew.sh/formula/ca-certificates and https://github.com/Homebrew/homebrew-core/blob/main/Formula/c/ca-certificates.rb
  10. Go, “Go 1.18 Release Notes,” crypto/x509 section, accessed October 29, 2026 – https://go.dev/doc/go1.18
Bar chart: TypeScript 7.0 and 7.1 Beta type-checking times on five codebases, Microsoft data from October 20, 2026

Faster TypeScript: the 7.1 beta in Go and tsrs, the Rust port

By

On 2026-10-22

In News

On October 20, 2026, two pieces of news arrived for anyone who writes TypeScript every day. Microsoft released the beta of TypeScript 7.1, the second version of the compiler rewritten in Go. On the same day, Cloudflare introduced tsrs, a port (that is, a faithful rewrite in another language) of the compiler to Rust.

A port is like a translator’s work: the book moves into another language, but the plot stays the same. For a compiler, the plot is the rules of the language, and the errors it reports should be identical.

But what does this mean, in practice, for anyone who runs tsc on their own code? Just consider that on the mui-docs project, the best of the five cases Microsoft measured, type-checking drops from 22.2 to 11.9 seconds with the beta [1].

The two announcements arrived together, but they are not the same thing. One is an official beta, with the Release Candidate, that is, the version that may become the final release, announced for about a month later; the other is an experimental project. Let’s try to separate the measured facts from the announcements.

In short:

The TypeScript 7.1 beta, released by Microsoft on October 20, 2026, type-checks faster than 7.0 according to Microsoft’s measurements and can be tried on a test branch. For tsrs, the Rust port, Cloudflare claims higher numbers, but measured with its own tests and on an experimental version. For a project in production, as of October 22, 2026, there is nothing to change.

  • TypeScript 7.1 Beta (October 20, 2026): on five real-world codebases, Microsoft measures type-checking 1.2 to 1.9 times faster than 7.0 and 15.8% to 49.6% less memory.
  • tsrs (October 20, 2026): in Cloudflare’s tests, with 4 threads on four projects, tsrs is up to 8 times faster than TypeScript 7.0.2, with about 70% less memory; these are not Microsoft’s tests.
  • Next steps: Microsoft announces the 7.1 Release Candidate “in about a month” from October 20, 2026; tsrs aims for a stable version aligned with TypeScript 7.1.

What was announced on October 20, 2026?

Two different compilers for the same language were announced. Microsoft released TypeScript 7.1 Beta, which on the npm registry corresponds to version 7.1.0-beta. It follows TypeScript 7.0, the first native compiler in Go, released by Microsoft on July 8, 2026 [1] [4] [5].

Cloudflare introduced tsrs in a post signed by Boshen Chen, Dimitri Mitropoulos, and Christoph Nakazawa. The project comes from the work of Max Schwenk, of Owner.com, and Cloudflare writes that it is incubating it within Oxc, a collection of JavaScript tools written in Rust. In the post, Cloudflare says it is working on it together with VoidZero and in close collaboration with the TypeScript team [2] [3].

Besides speed, 7.1 brings some new features for people who write code and for people who build tools [1] [4]:

  • import attributes (metadata such as with { type: "css" } attached to an import) can be declared in ambient modules (the ones described with declare module, usually in .d.ts files);
  • support arrives for source phase imports, that is, import source, useful for example for WebAssembly modules;
  • es2026 becomes a stable --target and --lib;
  • a new API (the interface through which other programs use the compiler) arrives for external tools, different from TypeScript 6’s; 7.0 had none.

For example, anyone importing CSS or Markdown files could declare a module for each extension; with 7.1 the declaration is tied to the import attribute, and TypeScript reports an error if the import is missing the required attribute. For tool authors, what matters instead is the API: with 7.0, Microsoft had made sure TypeScript 6 could run side by side for tools that need to access the compiler from code, such as typescript-eslint [1] [4].

What is the difference between TypeScript 7 in Go and tsrs in Rust?

The main difference is who maintains it and how far along it is. TypeScript 7 is Microsoft’s official compiler, written in Go, and version 7.0 has been stable since July 8, 2026. tsrs is a Rust port of the 7 compiler, maintained by others and, as of October 22, 2026, still experimental [2] [4].

In practice, anyone who installs the typescript package from npm is already using the Go compiler, and the command is still tsc. tsrs is a separate package, with the tsrs command, which compiles like tsc and accepts almost all of its options (the exceptions come later) [3] [4].

Cloudflare writes that the project is not a fork: the TypeScript team remains responsible for the language, and tsrs follows its behavior “in close collaboration” with that team [2].

The repository README, for its part, states two goals. The first is a stable version aligned with TypeScript 7.1, with 100% conformance; the second is to replace, without changes (drop-in), the compiler and language server (the program that gives the editor completions, errors, and code navigation) of TypeScript 7. It does, however, point out that the project is not affiliated with or endorsed by Microsoft [3].

The code is distributed under the Apache-2.0 license, as a derivative work of TypeScript. External pull requests are closed, while the repository’s tracker accepts bug reports [3].

Why a Rust port, if the Go one works? Cloudflare’s answer is WebAssembly, which I cover further on [2].

How much faster is TypeScript 7.1 than 7.0?

According to Microsoft, the TypeScript 7.1 Beta is 1.2 to 1.9 times faster than 7.0 on the five codebases it measured (post of October 20, 2026). The test uses the default configuration of 4 type-checking threads and the --noEmit option, which checks types without generating JavaScript files. So these are times for a type check, not for a continuous integration (CI) pipeline, and the gain varies from project to project [1].

CodebaseTypeScript 7.0TypeScript 7.1 BetaSpeedup (Microsoft)Less memory
bluesky4.48 s3.89 s1.2×15.8%
mui-docs22.2 s11.9 s1.9×49.6%
sentry19.6 s15.1 s1.3×20.8%
t3code-server26.5 s19.1 s1.4×24.6%
vscode21.6 s17.7 s1.2×17.2%
Source: Microsoft, “Announcing TypeScript 7.1 Beta” post, October 20, 2026 [1]. The post does not state the hardware used.

The gain, however, is not the same for everyone: on mui-docs the time is almost cut in half, while on bluesky and vscode the speedup is 1.2 times. So it pays to measure on your own code [1].

For 7.0, Microsoft had written that the Go compiler was often around 10 times faster than TypeScript 6, the previous version, written in TypeScript, as Cloudflare describes it. The two measurements come from different tests, on projects that only partly overlap: multiplying 10 by 1.9 gives a number that no source has measured. The sources give no direct numbers between 7.1 and the 5.x versions [1] [2] [4].

What did the move to TypeScript 7 mean outside the charts? In the 7.0 post, dated July 8, 2026, Microsoft reported that, according to Slack’s engineers, after moving to TypeScript 7, their type-checking in CI had dropped from about 7.5 to 1.25 minutes [4].

So the figure is about the move to TypeScript 7, not 7.1, and Microsoft does not say which version Slack was coming from. It should be taken for what it is: a testimonial collected by Microsoft [4].

Cloudflare, in its post, speaks of a 7.1 beta “up to 2.5x faster” than 7.0. But be careful: in Cloudflare’s charts the version measured is a nightly build (7.1.0-dev.20261019.1), not the beta, and the maximum value there is 2.58× on the MUI docs project [2].

These are two different measurements, not to be put side by side or compared with each other: the same MUI docs, on 7.0, takes 22.2 seconds in Microsoft’s tests and 10.44 in Cloudflare’s [1] [2].

How fast is tsrs, according to Cloudflare?

In Cloudflare’s early benchmarks, tsrs is up to 8 times faster than TypeScript 7.0, with the same number of checker threads. The comparison is between tsrs 0.18.0-ts7.1.0-dev.20260929, which ports a development version of 7.1 to Rust, and TypeScript 7.0.2, with 4 threads (--checkers 4) and --noEmit [2] [3].

The projects are VS Code, MUI docs, webpack, and t3code server, and the measure is real elapsed time (wall time). The post does not state the hardware [2].

In the chart with TypeScript’s default configuration (4 threads), Cloudflare reports type-checking from 3.83 times (VS Code) to 8.10 times (MUI docs) faster. Peak memory drops to between 0.13 and 0.31 times that of 7.0.2, that is, from 87% to 69% less (MUI docs and webpack). In the text, Cloudflare sums it up as “~70% less memory” [2].

The same chart also includes the 7.1 nightly, that is, the nightly build mentioned above: it is the closest comparison to 7.1 to be found there. Cloudflare does not make this comparison, but the times are there:

Projecttsrs7.1 nightly
VS Code1.73 s5.28 s
MUI docs1.29 s4.05 s
webpack0.23 s0.71 s
t3code server1.21 s7.17 s
Source: Cloudflare, “Introducing tsrs: A port of TypeScript to Rust” post, October 20, 2026, chart with TypeScript’s default configuration (4 threads) [2]. The post does not state the hardware used.

Working out the ratio, tsrs comes out about 3 times faster than the nightly on the first three projects and about 6 times faster on t3code server [2].

This should be read with two caveats. tsrs is based on a development version of 7.1 from late September (7.1.0-dev.20260930.4), the nightly is from October 19, and neither of them is the beta. In addition, Cloudflare’s post states neither the machine nor how tsrs was built [2].

As already said for 7.1, it matters who did the measuring: here it is tsrs’s own developers. Cloudflare writes that it worked with the TypeScript team to make sure the tests compare the same configuration, and it publishes the scripts in the repository’s bench folder. It also adds that some of the 7.1 optimizations come from tsrs, while Microsoft’s post does not mention tsrs [1] [2] [3].

A detail for anyone trying it: out of the box, tsrs does not use 4 threads but an adaptive configuration that, according to Cloudflare, is faster but uses more memory. For a like-for-like comparison with tsc, both need the same --checkers value [2].

Why do we need a TypeScript compiler in WebAssembly?

It lets the compiler run where a native program cannot go, such as the browser or an isolated environment (sandbox). WebAssembly is a binary format that browsers and runtimes execute in a portable and secure way. As of October 22, 2026, the tsrs README points to a playground in the browser, where you can try type-checking and code generation [3].

According to Cloudflare, a Go program compiled to WebAssembly has to carry its own garbage collector, the system that frees unused memory. Rust, on the other hand, does not need one, and this simplifies exchanging data with the environment that hosts it. The WebAssembly package is called @tsrs/wasm and, according to the README, uses the wasm32-wasip1 target [2] [3].

Cloudflare mentions three possible uses: sandboxed development tools for AI agents, the browser, and embedded or IoT devices (Internet of Things, connected objects). The first is the closest to its own work: an agent can run the entire development toolchain in an isolated environment on Cloudflare’s platform [2].

Will tsrs replace the official TypeScript compiler?

In a project it can take its place, because it is designed to replace tsc without changes. As the reference for the language, no: Cloudflare writes that it is not a fork and that decisions about the language remain with the TypeScript team [2] [3].

The replacement also covers the editor: the repository documentation explains how to start the language server with tsrs --lsp -stdio. The same document warns that the language server does not yet run content mappers, the plugins through which TypeScript 7.1 checks files such as Vue or Svelte files [1] [3].

There are still known differences, however. The README mentions the order in which some diagnostics appear and the lack of support for --init and --showConfig. Cloudflare also writes that it is working with Theo Browne to merge tsrs and tsc-rs, another Rust port, into a single package with a language server and content mappers [2] [3].

It remains to be seen how such a large project can stay aligned with the original. For tsrs, Cloudflare wants to use the method it already applies to Vinext: an agent that reads the original project’s changes every morning, and compatibility tests rerun every night.

AI also shows up in another part of the post. To explain why a port like tsrs is arriving precisely in 2026, Cloudflare argues that the most advanced AI models can do large ports “almost independently in a matter of days” [2].

Cloudflare, however, does not say how much of tsrs was written this way, nor does it attach any data. In the post, though, it links to the one by Max Schwenk on Owner.com, dated October 19, 2026, which presents tsrs as “A Rust port of TypeScript, written entirely by agents” [2] [7].

I wrote about the limits of these models in A.I. – Artificial Intelligence and Discrimination. An LLM (Large Language Model, the kind of model behind chatbots) picks the most likely word and can produce content that is coherent but false, the so-called hallucinations. For a compiler, then, tests count for more than announcements.

How do you try the TypeScript 7.1 beta and tsrs on your own project?

You install the beta as a development dependency, with the command given by Microsoft [1]:

npm install -D typescript@beta

In a test run on October 22, 2026, on Linux x86_64 (Debian 13, Node.js 20.19.2) and in an empty project, the command prints:

added 2 packages, and audited 3 packages in 2s

found 0 vulnerabilities

To check the version:

npx tsc --version
Version 7.1.0-beta

On October 22, 2026, this is the version that corresponds to the beta tag on npm, while latest is still 7.0.2. Before merging it into the main branch, it is a good idea to run type-checking in CI and read the new errors [5].

Microsoft in fact points out two changes that can make some appear. The first concerns the DOM types (the interfaces through which code uses the web page in the browser) in lib.d.ts. The second is a stricter check on distributive type parameters, with a new error message, which Microsoft explains with a simple image: “a Cat might be a subtype of Animal, but it certainly won’t be a subtype of every type of Animal” [1].

If you use Vue, Svelte, Astro, or MDX, you can also look at content mappers: Microsoft warns, however, that the example package for Vue is not yet on npm [1].

For tsrs, Cloudflare gives the shortest form, npm install tsrs and then npx tsrs. The project README instead recommends installing it as a development dependency and running it with --noEmit, which checks types without generating JavaScript. With npm, it looks like this [2] [3]:

npm install -D tsrs
npx tsrs --noEmit

In the same test run, the installation adds two packages, tsrs and its binary for Linux x64. On a small test file (src/index.ts) with two type errors, npx tsrs --noEmit prints the same lines as tsc 7.1.0-beta and exits with code 2:

src/index.ts(4,7): error TS2322: Type 'string' is not assignable to type 'number'.
src/index.ts(5,20): error TS2345: Argument of type 'number' is not assignable to parameter of type 'string'.

With correct code it prints nothing and exits with 0, and in neither case does it write files. It is a single test file, so it says nothing about conformance in general.

Why --noEmit in particular? Without that option, tsrs behaves like tsc: it reads tsconfig.json and generates the JavaScript files, and in the same test run it generated them even with the type errors. There is a reason for -D too: without it, npm adds tsrs to the production dependencies.

To see which TypeScript version it is based on:

npx tsrs --version
Version 7.1.0-dev.20260930.4 (tsrs 0.18.0-ts7.1.0-dev.20260929, microsoft/TypeScript@b85298b6a81f)

As the output shows, tsrs is based on a development version of TypeScript, 7.1.0-dev.20260930.4, and not on the beta. The package name, on the other hand, carries September 29: as of October 22, 2026, the version published on npm is 0.18.0-ts7.1.0-dev.20260929 [6].

Before trying it, it is worth checking your system. Version 0.18.0 has binaries only for macOS on Apple Silicon and for Linux x64 and arm64, with both glibc and musl (the two most widely used C libraries on Linux; musl is the one Alpine uses). No Windows and no Mac with an Intel processor [6].

If the check fails or gives results different from tsc, the report goes in the tsrs repository’s tracker on GitHub, which accepts bug reports with a minimal reproduction. tsrs is not a Microsoft project [3].

What should you do before the final release of 7.1?

My advice, while waiting for the final release, is to keep production on TypeScript 7.0, which remains the stable version, and to try the 7.1 beta on a separate branch. tsrs is worth following, especially for anyone working with browsers, WebAssembly, or agents, but it should be treated as an experiment [1] [5].

Tool authors, such as those writing plugins or editor integrations, have more reasons to try the beta: Microsoft is asking for feedback on the new API. Anyone working on Linux or on a Mac with Apple Silicon can instead run tsrs alongside tsc with --noEmit and compare the errors, without touching the build [1].

It remains to be seen whether Microsoft’s Release Candidate will confirm the beta’s numbers, and whether tsrs will reach the stable version it has promised.

Frequently asked questions

Why did Microsoft write TypeScript 7 in Go and not in Rust?

To stay as close as possible to the existing code. In the “Why Go?” discussion in the typescript-go repository (March 5, 2025), Ryan Cavanaugh of the TypeScript team explains that a port was needed, not a rewrite, and that Go, written idiomatically, resembles the style of the original code. The garbage collector, he adds, carries little weight in the TypeScript codebase. Cloudflare chose Rust for WebAssembly, where it does not have to carry a garbage collector along.

How much faster is TypeScript 7.1 than 7.0 and earlier versions?

From 1.2 to 1.9 times faster than 7.0, according to Microsoft’s measurements of October 20, 2026 on five codebases, with 4 threads and --noEmit. For 7.0, Microsoft had indicated about 10 times the speed of TypeScript 6: different tests, not to be multiplied. The sources report no direct comparisons with the 5.x versions.

Can I use the TypeScript 7.1 beta in production?

Better not: it is a beta, and Microsoft says nothing about production use. The Release Candidate is announced for about a month after October 20, 2026, with the final release shortly after. It is best to try it on a separate branch and in CI, checking for new errors in the DOM types and on distributive type parameters.

Does typescript-eslint work with TypeScript 7?

Not directly with 7.0, which has no API for external tools. In its July 8, 2026 post, Microsoft explains that it made sure TypeScript 6 can run side by side, with the @typescript/typescript6 package, for tools such as typescript-eslint. The 7.1 Beta brings a new API; in the typescript-eslint tracker (issue #10940), support for 7.1 was a work in progress in late September 2026.

Can I use tsrs instead of tsc in my project?

Yes, for testing: the README presents it as a drop-in replacement for the TypeScript 7 compiler and language server. As of October 22, 2026, the version on npm is 0.18.0, which is based on a development version of 7.1, not on the beta, and has no binaries for Windows or for Macs with an Intel processor. You install it with npm install -D tsrs and run it alongside tsc with npx tsrs --noEmit.

How do I try the TypeScript 7.1 beta on my project?

With npm install -D typescript@beta, the command given by Microsoft on October 20, 2026, on a dedicated branch and with type-checking in CI. For tsrs, the README gives -D and --noEmit: with npm, npm install -D tsrs and npx tsrs --noEmit. Version 0.18.0 binaries exist only for Linux and for macOS on Apple Silicon.

Sources

  1. Microsoft (Daniel Rosenwasser and the TypeScript team), “Announcing TypeScript 7.1 Beta,” October 20, 2026 – https://devblogs.microsoft.com/typescript/announcing-typescript-7-1-beta/
  2. Cloudflare (Boshen Chen, Dimitri Mitropoulos, Christoph Nakazawa), “Introducing tsrs: A port of TypeScript to Rust,” October 20, 2026 – https://blog.cloudflare.com/typescript-rust-port/
  3. Oxc project, oxc-project/tsrs repository on GitHub (README, documentation in docs/, and bench folder), accessed October 22, 2026 – https://github.com/oxc-project/tsrs
  4. Microsoft (Daniel Rosenwasser), “Announcing TypeScript 7.0,” July 8, 2026 – https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/
  5. npm registry, typescript package (dist-tags: beta = 7.1.0-beta, latest = 7.0.2), data read from the registry on October 22, 2026 – https://registry.npmjs.org/typescript
  6. npm registry, tsrs package (latest = 0.18.0-ts7.1.0-dev.20260929, Apache-2.0 license, per-platform binaries in optionalDependencies), data read from the registry on October 22, 2026 – https://registry.npmjs.org/tsrs
  7. Owner.com (Max Schwenk, Head of AI Developer Experience), “tsrs,” October 19, 2026 – https://building.owner.com/tsrs
  8. Microsoft (Ryan Cavanaugh, TypeScript team), “Why Go?” discussion in the microsoft/typescript-go repository, March 5, 2025 – https://github.com/microsoft/typescript-go/discussions/411
  9. typescript-eslint, issue #10940 “Enhancement: Use TS 7 (tsgo / typescript-go) for type information” (update by Josh Goldberg, late September 2026), accessed October 22, 2026 – https://github.com/typescript-eslint/typescript-eslint/issues/10940

A.I. – Artificial Intelligence and Discrimination

By

On 2026-10-21

In Uncategorized

“How can I help you today?” – These are the words of one of the best-known Artificial Intelligences; in fact, few people have never read them and never tried asking it questions.

But what is an AI? What is it capable of doing? Is it impartial, being a machine?

From the first artificial neuron to Big Data

The first step in this field was taken more than 80 years ago, contrary to what one might imagine. It was a neurophysiologist and a logician, Warren McCulloch and Walter Pitts, who proposed the first model in 1943, built by trying to imitate a biological neuron. Since then, efforts have been made to refine the imitation, but the basic model has always remained the same.

But why is it only in recent years that artificial intelligence has captured so much media attention, on everyone’s lips, from governments trying to keep pace in order to regulate it, to companies looking for talent to be able to implement it, to ordinary people who use it widely instead of the more traditional search engines?

The reason why the time is ripe only now comes down to two factors: Big Data and the enormous computing power we now have thanks to technological progress.

Big Data is a vast set of data, which may or may not be structured, and it is only since the advent of the internet that people have begun to write enormous amounts of text and to generate an inconceivable mass of content such as images and videos: just consider that more than 500 hours of video are uploaded to YouTube every minute1.

The human brain and artificial intelligence

Just as a child begins to speak by imitating their parents, who day after day, tirelessly, talk to them and care for them, so too is this tool the result of the “training data” it repeatedly comes into contact with.

But however useful this metaphor may be, we have not yet reached an artificial intelligence as sophisticated as the cognitive abilities of a human being. In fact, the activation functions, the neural structure, the efficiency of operations, the capacity to adapt and the plasticity of the whole are very far from being able to imitate a biological organism.

Biological synapses are much more than simple connections: they are complex structures involved in transmitting, processing and modifying signals. Their strength and behavior change dynamically, contributing to learning, memory and other complex brain functions2.

The parameters of artificial intelligence are mathematical values within a model, adjusted during the learning process. Artificial intelligence models have difficulty reasoning and thinking critically. They are not able to form their own opinions, analyze situations from different points of view or learn from experience in the same way a human brain does. They can analyze enormous amounts of text and generate human-like text by identifying patterns and statistical relationships between words. However, they do not intrinsically understand the meaning of the words they use. In fact, an LLM (Large Language Model) analyzes a very large body of text to predict which word is most likely to follow a sequence of words already written. It considers several factors, such as co-occurrence, that is, how often two words (n-grams) appear together, their syntactic and grammatical role, etc. Although governed by sophisticated processes, it is a purely statistical choice: the model assigns a probability to each different word and usually chooses among the most probable ones according to the patterns it was trained on.

The quality of an AI is closely tied to that of its training data.

Applications and hallucinations

Neural networks can be applied in different sectors and can specialize in different functions:

  • we have talked about text generation, but they can also generate pieces of music and images;
  • they can predict an event and tell us how likely it is to occur, such as the efficacy of a drug or its side effects;
  • they can analyze determining factors, extracting and generating value from data;
  • they are capable of recognizing patterns, highlighting anomalies or understanding a consumer.

They have very broad, many-sided capabilities, but this does not make them immune to errors such as “hallucinations.”

We speak of hallucination when a model generates content that makes no sense or, worse, seems to make sense but is false and not supported by any logical or scientific basis. The more versatile an AI is and the more capable it is of handling different topics, the more insidious the hallucination3. Faithfulness hallucinations occur when the output generated is not consistent with the instructions or the context provided by the user, or contradicts itself. For example, a model asked to summarize a news article might generate a summary that seems realistic and well written, but that contains information absent from the article or that contradicts it.

Factuality hallucinations occur when the text generated is grammatically correct and consistent with the training data, but impossible or highly improbable in reality. For example, a model trained on a dataset of recipes might generate a new recipe that includes nonexistent ingredients or impossible cooking instructions.

One of the main reasons that can lead to hallucinations is the bias hidden in the training data, which favors certain behaviors and discriminates against others, producing a “biased output.”

An impartial algorithm?

There was a time, and perhaps for some it is still so, when, dreaming of an external and impartial system of judgment, people believed that an algorithm could make choices that were based on data and therefore objective4. But software cannot be immune to human influence and partiality, much less an Artificial Intelligence that learns from inequalities entrenched over the years. It is not able to tell good from evil: what is “right” and what is “wrong” is introduced through labels on the data, and the model manages to generalize this concept, becoming able to repeat it on unlabeled data too, without, however, understanding the reason. A simple “mathematical operation.”

Using automated systems to make decisions amplifies discrimination, instead of reducing or eliminating it, taking it to a larger scale.

Inequality: a limitation or an asset?

Although bias plays an important role in the process of discrimination, it does not necessarily cause it: bias is defined as a deviation from the standard, and it is sometimes necessary in order to identify the existence of statistical patterns in data or language. Classifying and finding differences would be impossible without bias5.

Indeed, the relationship between bias and discrimination is not always clear and understandable.

Many claim that by eliminating bias, discrimination can also be eliminated or reduced, but since implementations often ignore the context in which the algorithm will be used, the decision as to whether a biased output results in a case of discrimination is often left to the user to assess.

To explain this concept better, let’s think of a sophisticated algorithm that recommends which candidates are the best to hire after analyzing their résumés. We might notice that it favors candidates aged between 25 and 35, and this could be discrimination; but if instead the goal is precisely to hire younger candidates in order to have generational turnover within the company, then it would not be a case of discrimination by the algorithm, but an expected result.

Measures of bias and awareness

There are different ways of measuring bias; the statistical measure is the most intuitive and comprises three aspects. The first is that different categories should be able to appear in the results with the same probability: for example, if four out of five applicants from the advantaged group were granted a mortgage, the same proportion of applicants from the protected group should obtain the mortgage as well. The second aspect is satisfied if the unprotected and protected groups have an equal probability that a positive classification is correct, while the last aspect is that of well-calibration: the probability estimated by the algorithm must match the actual frequency of outcomes in each group6.

As already mentioned, this is the simplest measure, but other, more complex measures are used in order to have a model that limits inequalities and does not create discrimination, such as the measure of similarity between individuals called “fairness through awareness”7, according to which, for fairness to hold, the distance between the distributions of outcomes for individuals should be at most the distance between the two individuals as estimated by means of a similarity metric.

This shows us how much energy is spent in the field on analyzing a model with the aim of improving it as much as possible and minimizing discrimination. But without the awareness of users, every effort risks being in vain: we must use common sense and intelligence before applying an algorithm or a model to automate decisions on a large scale. Artificial intelligences are powerful tools and, as such, can lead to great benefits or great disparities. There is a growing need for honest, God-fearing people8, aware of the limits and risks of these tools and able to use them wisely.

Originally published in the dossier “Tempo del Creato 2024” of the GLAM commission of the FCEI (Federation of Protestant Churches in Italy)

  1. How YouTube search works – YouTube Help (“over 500 hours are uploaded every minute”; figure reported by YouTube in 2019). See also Statista. ↩
  2. Proverbs 20:5 “A person’s thoughts are like water in a deep well, but someone with insight can draw them out.” (GNT) ↩
  3. L. Huang et al., A Survey on Hallucination in Large Language Models: Principles, Taxonomy, Challenges, and Open Questions, arXiv:2311.05232, 2023. ↩
  4. Can an Algorithm Hire Better Than a Human? – The New York Times (nytimes.com) ↩
  5. The definitions and examples in this section and the next are drawn from, and in places closely follow the wording of, X. Ferrer, T. van Nuenen, J. M. Such, M. Coté, N. Criado, Bias and Discrimination in AI: a cross-disciplinary perspective, arXiv:2008.07309, 2020. ↩
  6. Criteria such as calibration within groups and balance for the positive and negative classes cannot, except in very special cases, all be satisfied at the same time: J. Kleinberg, S. Mullainathan, M. Raghavan, Inherent Trade-Offs in the Fair Determination of Risk Scores, 2016 (ITCS 2017). ↩
  7. C. Dwork, M. Hardt, T. Pitassi, O. Reingold, R. Zemel, Fairness Through Awareness, ITCS 2012. ↩
  8. Galatians 3:3 “How can you be so foolish! You began by God’s Spirit; do you now want to finish by your own power?” (GNT) ↩

Scripture quotations marked (GNT) are from the Good News Translation in Today’s English Version – Second Edition Copyright © 1992 by American Bible Society. Used by Permission.

GOOD NEWS TRANSLATION™ is a trademark of the American Bible Society and may be used only under license.

When Faith Inspires Innovation: Ellen White and the Science Behind SuperWood

By

On 2025-05-13

In Uncategorized

Ellen G. White’s nineteenth-century descriptions of antediluvian timber—gigantic trees whose wood was “fine-grained,” “hardly less enduring than stone,” and able to resist decay for centuries—map with surprising fidelity onto the micro-scale architecture and bulk properties now engineered into InventWood’s “SuperWood,” a densified, partially delignified cellulose composite that is 10–12 × stronger and tougher than natural wood, lighter than steel, and highly resistant to rot and biological attack. A systematic comparison shows that the mechanical, durability and sustainability claims White ascribed to pre-Flood wood correspond within the same order of magnitude to peer-reviewed measurements of SuperWood’s strength (≈550 MPa), hardness, dimensional stability and longevity, while the spiritual motif of restoring original creation parallels the biomimetic strategy of restoring wood’s cellulose framework to its theoretical packing density. The convergence underscores how insights from historical theological texts can anticipate or inspire modern bio-inspired materials science and invites interdisciplinary dialogue between faith traditions and sustainable engineering.

Abstract

Ellen G. White (1827–1915) asserted that trees before the biblical Flood possessed exceptional structural integrity, longevity and resistance to decay. SuperWood—developed at the University of Maryland and commercialized by InventWood—achieves comparable performance through chemical delignification and hot compression that densifies cellulose nanofibers. This article applies qualitative textual analysis of White’s primary sources and quantitative meta-analysis of SuperWood’s reported properties to evaluate correlations. Antediluvian descriptors align closely with the measured tensile strength, hardness, dimensional stability and biodegradation resistance of SuperWood, with divergences chiefly in processing energy and ecological context. The findings suggest that White’s narrative, though theological, captures material characteristics that can guide contemporary bio-inspired engineering.

Keywords: Ellen G. White, antediluvian wood, SuperWood, densified cellulose, biomimetic materials, sustainability

Introduction

White’s canonical work Patriarchs and Prophets depicts pre-Flood arboreal species as “majestic trees…their wood…of fine grain and hard substance, closely resembling stone, and hardly less enduring” (ellenwhite.info). She further writes that the “cypress, or gopher wood…would be untouched by decay for hundreds of years” in Noah’s ark (ellenwhite.info).
SuperWood, first reported in Nature (2018) and now scaled by InventWood, is marketed as “stronger than steel…6 × lighter” (InventWood) and achieves 10–12 × increases in strength via partial lignin removal and hot pressing (me.umd.edu). Nature News summarized the breakthrough as “compressing the material and removing some of its polymers can increase its strength tenfold” (Nature). Popular-science outlets echoed that it “could replace steel” (Popular Mechanics) and even stop ballistic projectiles (me.umd.edu).

Materials and Methods

Textual corpus

White’s statements were extracted from digitized editions of Patriarchs and Prophets (Chapter 7) and cross-checked with Spiritual Gifts Vol. 3 for thematic consistency.

Mechanical data set

Mechanical metrics for SuperWood—ultimate tensile strength (UTS), modulus of rupture, toughness, and decay resistance—were taken from the 2018 University of Maryland press release (me.umd.edu); the Nature News report (Nature); the Popular Mechanics summary (Popular Mechanics); the National Geographic education brief (National Geographic Education Blog); and subsequent peer-reviewed densification studies covering hot isostatic pressing (Nature), nanofluidic alignment (Science), and 2025 cell-wall engineering advances (Nature).

Results

Structural endurance

White’s claim that gopher wood resisted decay “for hundreds of years” (ellenwhite.info) parallels InventWood’s statement that SuperWood “resists moisture, termites, rot” (InventWood).

Mechanical strength and toughness

The UTS of SuperWood (~550 MPa) (Nature) exceeds the lower bound of mild steel (≈250 MPa) while maintaining a density of 1.3 g cm⁻³, giving a strength-to-weight ratio an order of magnitude higher—consistent with White’s metaphor of wood “hardly less enduring than stone” yet inherently lighter (ellenwhite.info). Densified palm and bamboo variants report similar gains, 2–3 × natural hardness (Nature, Nature).

Dimensional stability and decay

InventWood cites “minimal expansion and contraction” for facade applications (InventWood), achieved by reducing amorphous regions vulnerable to moisture. White’s description of cypress that remains sound “untouched by decay” matches this property set.

Process parallels

White noted that antediluvian timber preparation required “much more labor…than now” due to tree size and hardness (ellenwhite.info). Modern densification likewise involves energy-intensive compression at about 100 °C and high pressure (smithsonianmag.com), echoing the concept of extraordinary effort to unlock wood’s latent strength.

Discussion

The convergence between White’s pre-scientific narrative and SuperWood’s empirically validated performance suggests two non-exclusive interpretations. First, her observations—rooted in meditative reflection—could express intuitive inference about pristine biological order, resonating with current understanding that optimal cellulose packing yields maximal mechanical performance. Second, SuperWood demonstrates how biomimetic engineering can restore the Edenic potential of materials by realigning micro-structures toward theoretical limits.
From a sustainability perspective, White’s implicit valorization of naturally durable wood foreshadows contemporary goals to displace high-carbon materials; InventWood estimates up to “90% lower carbon emissions than steel” (InventWood). Ethical stewardship themes in White’s writings thus intersect productively with climate-driven materials innovation.

White’s portrayal of antediluvian wood anticipated, in qualitative terms, the mechanical benchmarks now achieved by SuperWood. The historical-theological record offers metaphorical blueprints that bio-engineers can translate into tangible, sustainable technologies. Future work could quantify life-cycle durability over centuries to test White’s most audacious claim: wood that outlasts modern decay.

References

  1. White, E.G. Patriarchs and Prophets, Chapter 7: “The Flood.” (ellenwhite.info)
  2. White, E.G. Patriarchs and Prophets, p. 95. (ellenwhite.info)
  3. InventWood. “Technology—Reinventing Wood.” (InventWood)
  4. University of Maryland Press Release. “Super Wood Could Replace Steel.” (me.umd.edu)
  5. Nature News. “Crushed wood is stronger than steel.” (Nature)
  6. Popular Mechanics. “New chemical treatment makes ‘Super Wood’ that could replace steel.” (Popular Mechanics)
  7. Smithsonian Magazine. “A chemical bath and strong squeeze makes super-dense and strong wood.” (smithsonianmag.com)
  8. National Geographic Education Blog. “Super Wood is Stronger Than Steel.” (National Geographic Education Blog)
  9. Nature Communications. “Bioinspired self-flowing wood chemical treatment” (2025). (Nature)
  10. Scientific Reports. “Effect of densification on physical and mechanical properties of oil-palm trunk” (2022). (Nature)
  11. Scientific American. “Stronger than steel, able to stop a speeding bullet—It’s SuperWood!” (Feb. 7, 2018). (InventWood)
  12. Nature d41586-018-01600-6. “Crushed wood is stronger than steel.” (Nature)
  13. Popular Mechanics TikTok summary (2022) – wood-bending context. (tiktok.com)
  14. Science Advances. “Anisotropic, lightweight, strong, and super thermally insulating nanowood with naturally aligned nanocellulose” (2018). (Science)
  15. Scientific Reports. “Two-step hot isostatic pressing densification of hardwoods” (2023). (Nature)
Grafico a barre del costo livellato dell'idrogeno (LCOH, €/kg) per filiera: H2 grigio, H2 blu, fotovoltaico, eolico, FER, gassificazione e import

Hydrogen and renewables: a look at the future

By

On 2024-11-27

In News

Yesterday a press conference was held in the Auditorium of the Gestore dei Servizi Energetici (GSE) in Rome, where Minister Pichetto shared the National Strategy, which sets the goal of “Net Zero” by 2050.

Italy seems determined to carve out a leading role in the renewable energy landscape, focusing in particular on hydrogen as a strategic energy carrier for the future.

The strategic role of hydrogen

The Italian strategy recognizes hydrogen as a key element for decarbonizing sectors that are hard to electrify, such as heavy transport, shipping and aviation. With its ability to store energy and transport it over long distances at competitive costs, hydrogen represents a complementary solution to renewable sources, which suffer from some intermittency.

Note that hydrogen can mainly be divided into five categories, which are not official but are increasingly used:

  • Green hydrogen: produced through water electrolysis powered by renewable energy (photovoltaic, wind, hydroelectric, etc.)
  • Blue hydrogen: derived from natural gas with CO₂ capture, utilization and storage (CCUS). It could be considered as a transitional option, but Italy does not seem to have a large geological CO₂ storage capacity.
  • Gray hydrogen: produced from fossil sources without CO₂ capture. The most polluting, and therefore not a viable choice in a “green” context.
  • Pink hydrogen: produced from nuclear sources.
  • White hydrogen: of geological origin.

Currently, however, the national landscape is dominated by gray hydrogen, produced mainly through industrial processes such as Steam Methane Reforming (SMR) without CO₂ capture. This type of hydrogen is used mainly in refineries and in the production of ammonia for fertilizers. The transition toward low-emission hydrogen, whether blue or green, is one of the main goals of the plan.

Bar chart of the levelized cost of hydrogen (LCOH, €/kg) by production pathway: gray H2, blue H2, solar PV, wind, renewables, gasification, imports
LCOH (€/kg) of hydrogen for different production pathways

Innovations and synergies

Ammonia (NH3) is emerging as a particularly interesting alternative in the Italian context. This compound, obtained by combining green hydrogen and atmospheric nitrogen through the Haber-Bosch process, offers significant advantages over pure hydrogen, both in terms of energy density and logistics. Indeed, ammonia:

  • Is easier to store and transport: it liquefies at higher temperatures (−33 °C compared with −253 °C for liquid hydrogen), reducing energy consumption during these phases, and it has established transport infrastructure (such as ammonia tankers).
  • Is chemically stable: difficult to ignite and easier to store than pure hydrogen.
  • Avoids the boil-off problem: while liquid hydrogen tends to evaporate over time, ammonia maintains greater stability.
  • Has direct industrial applications: besides serving as an energy carrier, it is used without further transformation to produce fertilizers.

Tools and outlook

Italy has deployed a varied portfolio of tools, funded through the PNRR, to support the development of the hydrogen supply chain. These include:

  • Projects for Hydrogen Valleys, pilot areas for the local development of hydrogen.
  • Initiatives in rail and road transport, aimed at introducing alternative fuels.
  • Production of electrolyzers, essential for green hydrogen.
  • Support for research and development to accelerate innovation.

In addition, emphasis is placed on the synergy between hydrogen and CCS technologies, which could broaden decarbonization opportunities, including through low-carbon hydrogen.

The future of hydrogen in Italy

Among the strategy’s flagship projects, the Southern Hydrogen Corridor stands out: an international infrastructure project that will position Italy as a European hub for hydrogen. This project will facilitate import flows, strengthening energy cooperation in the Mediterranean and beyond.

In a world increasingly oriented toward sustainability, the vision outlined by Italy fits into a framework of international cooperation and technological innovation. It remains to be seen how these ambitions will take shape in the coming years, turning hydrogen from a promise into a pillar of the energy transition.

How to boot Radxa Rock 5B from an NVMe SSD

By

On 2024-04-04

In Guides

Radxa ROCK 5 Model B spec infographic: Rockchip RK3588, up to 16GB RAM, PCIe 3.0 x4 NVMe slot, 8K video, WiFi 6E, 2.5GbE

The tech community has seen a surge of single-board computers (SBCs) over the past few years, offering tech enthusiasts a plethora of options. However, few come as power-packed and future-ready as the Radxa ROCK 5 Model B. This potent Raspberry Pi alternative brings to the table a set of features that puts it a notch above many of its competitors.

Historically, the default choices for booting operating systems on such devices have been either through a microSD card (microSD) or embedded MultiMediaCard (eMMC) memory. While both methods have served their purpose, they come with their own sets of limitations, primarily in terms of speed and overall system responsiveness. Enter the NVMe (Non-Volatile Memory Express) drives, a game-changer in the world of storage solutions, known for their breathtaking speed and efficiency.

The PCIe 3.0 x4 slot on the ROCK 5B isn’t just a token feature; it represents a paradigm shift. By leveraging the capability to connect NVMe drives directly to this slot, users can bypass the traditional bottlenecks associated with microSD cards and eMMC memory. The potential benefits?

  • Faster boot times,
  • snappier system responses, and
  • a smoother user experience.

For those yearning to unlock this potential and revolutionize their SBC experience, the question isn’t about “why” but “how.” How does one transition from conventional storage methods to booting their operating system straight from an NVMe drive on the ROCK 5B? The upcoming guide promises to shed light on this transformative journey, offering step-by-step insights to supercharge your ROCK 5B experience.

Download the needed files

Let’s start by downloading the needed files: zero.img and the new bootloader.img, needed since we are going to flash it to the SPI NOR flash.

There are 4 different bootloader images:

  • normal bootloader [old], recommended for everything except Armbian, has the U-Boot serial console disabled
  • bootloader for Armbian, if you want to boot Armbian from the M.2 NVMe SSD
  • debugging bootloader [old] with U-Boot serial console enabled, if you need to troubleshoot booting issues over the serial console (for advanced users).
  • EDK2 bootloader for booting UEFI-compatible operating system images (currently experimental)

You can download files by using wget link.to/file.img. In this guide I’m using the first one.

mkdir bootloader
cd bootloader/
wget https://dl.radxa.com/rock5/sw/images/others/zero.img.gz
wget https://dl.radxa.com/rock5/sw/images/loader/rock-5b/release/rock-5b-spi-image-gd1cf491-20240523.img

We are going to decompress the file and check that the MD5 digest is the same as the one published on the Radxa website.

gzip -d zero.img.gz
md5sum zero.img

The result of the above command will be something like this: 2c7ab85a893283e98c931e9511add182 zero.img

md5sum rock-5b-spi-image-gd1cf491-20240523.img

cf53d06b3bfaaf51bbb6f25896da4b3a rock-5b-spi-image-gd1cf491-20240523.img

Here are the checksums of the other possible files:

2c7ab85a893283e98c931e9511add182  zero.img
cf53d06b3bfaaf51bbb6f25896da4b3a  rock-5b-spi-image-gd1cf491-20240523.img
fa14c99718f55b66e82aa1661e43c1ec  rock-5b-spi-image-gd1cf491-20240523-debug.img
bd21a6459ad33b8189782e4c904d99b3  rock-5b-spi-image-gbf47e81-20230607.img
1b83982a5979008b4407552152732156  rkspi_loader.img

If everything is okay, we can move on to checking whether the SPI flash is available:

ls /dev/mtdblock*

It will return the device: /dev/mtdblock0

Let’s flash the bootloader

The first step is to completely clear the SPI flash: (be patient: flashing can take up to 5 mins; in my case it took 3 mins)

sudo dd if=zero.img of=/dev/mtdblock0

Check whether the flash was successfully cleared:

sudo md5sum /dev/mtdblock0 zero.img

2c7ab85a893283e98c931e9511add182 /dev/mtdblock0
2c7ab85a893283e98c931e9511add182 zero.img

Okay! Now you can write the desired bootloader to the SPI flash using the following command:

sudo dd if=rock-5b-spi-image-gd1cf491-20240523.img of=/dev/mtdblock0

Be patient, it will take some time again; as soon as it has finished, you can run

sync

and then check again if everything was successful:

sudo md5sum /dev/mtdblock0 rock-5b-spi-image-gd1cf491-20240523.img

cf53d06b3bfaaf51bbb6f25896da4b3a /dev/mtdblock0
cf53d06b3bfaaf51bbb6f25896da4b3a rock-5b-spi-image-gd1cf491-20240523.img
In my case the two digests are identical, which means that everything went well; otherwise, flash the bootloader again.

Now you can safely reboot your device!

Simone Flavio

I’m the CTO of Rinoova and hold a Bachelor’s degree in Computer Science, cum laude. I’m passionate about Linux, electronics and anything that makes life simpler and more secure. In my spare time I tinker with ffmpeg, re-encoding my movie collection to AV1/HEVC. Squeezing the most out of storage and bandwidth has been a habit since childhood, when all I had was a 2 Mbps connection. That’s why every image on this blog is in AVIF: pages stay light and load fast.