In February the Python Software Foundation made its wikis read-only "due to excessive automated traffic and security concerns... that traffic turned out to be almost entirely AI bots that were trying to scrape the entire internet."

But their infrastructure was also outdated, and this week they announced new wikis using GitHub Pages "that address the automated traffic and security concerns." The new wikis [for Python, Jython, and the PSF] will have a more modern front-end, as well as a permissions-based content management system for community members to make updates.

With the old wiki structure, we received a large volume of alerts at all hours, each serious enough to page and wake our on-call infrastructure staff, which is very limited (just one person currently, although this will be changing soon!). The quantity of scraping overloaded our servers, causing outages, which happened often enough that these issues required a significant amount of effort for the PSF staff to manage...

Additionally, some portions of the wikis were still built with Python 2. Python 2 reached end of life on January 1, 2020, and no longer receives upstream security fixes. Moving to a static site makes it very fast and reduces security risks, while also having the benefit of a more modern user interface... GitHub was chosen for the home of the new wikis as this is where CPython, python.org, and other properties the PSF hosts currently live. The hope is to continue to streamline the PSF's hosting and stewardship of services to simplify for both PSF staff and the community folks who contribute to them. Previously, the Python and Jython wikis were user-editable by invitation of an existing editor and the PSF wiki was permissions based. Moving forward, all three of the wikis will be permissions based via the GitHub repository they are hosted on, and changes can be requested through pull requests by anyone in the community...

GitHub allows us to distribute granular control, review changes through pull requests, and maintain the uptime this service deserves. Also, since the site is now generated statically, it removes any worry about AI bots overwhelming the hosts that the wikis were previously hosted on.

TechRepublic reports: The TIOBE Index is a monthly indicator of programming-language popularity based on factors including skilled engineers, courses, and third-party vendors. The October 2026 rankings show a largely stable top 10, with R overtaking SQL and Julia returning to the top 20 for the first time in three years. [SQL has risen to #9 from #10 in October of 2025 — back when R ranked only #13.]

Python remains No. 1, followed by C, C++, Java, C#, and JavaScript, while Rust holds its No. 10 position. [A year ago Rust ranked only #16.] Outside the top 10, Julia climbs from No. 21 to No. 18, and TIOBE introduces Mandarin Chinese search terms into its methodology to broaden the index's geographic representation.
Dropping out of the top ten is Go, which fell from #8 in October of 2025 to #11. And Delphi/Object Pascal has plummeted from #9 to #19.

TIOBE CEO Paul Jansen argues that Julia's growing popularity "is largely driven by the demand for modern programming languages that combine high performance with ease of learning, particularly for numerical computing." Python offers an accessible, high-level approach to numerical computing, but performance can become a bottleneck. C++, on the other hand, delivers excellent performance but comes with a steeper learning curve and a lower level of abstraction. Julia aims to bridge this gap by combining the best of both worlds...

Apart from Julia, two other languages are knocking on the door of the TIOBE top 20: Dart and OCaml. Dart jumps from #41 to #27 this month. Thanks to its popular UI toolkit Flutter, Dart has been hovering around the edge of the top 20 for quite some time. OCaml, on the other hand, might come as a surprise. It jumps from #38 to #26 this month, driven in part by its growing use in real-time trading systems and parsing technology.

Python's security developer-in-residence Seth Larson reports from this year's official core developer Python Language Summit: "No one said 'don't do this' last year". After testing the waters at PyCon US 2025, [software engineer] David Hewitt returned to the Python Language Summit asking what Python core developers want from Rust, along with proposed timelines, phases, and success criteria for how the Rust for CPython project might proceed and become a permanent fixture within the CPython project. David is acting as an "ambassador" for the Rust for CPython project team, which is currently led by core developers Kirill Podoprigora and Emma Smith as authors of the Rust for CPython PEP draft. Emma also spoke at PyCon US 2026 about the Rust for CPython project. The team itself is around 60 developers in a Discord channel, among them a "few [Python] core developers" and a "delegation from the Rust project".

The team has experience with previous projects integrating Rust into existing codebases, such as Android and the Linux kernel, and is "excited by the work and keen to support [the project] if we proceed". Showing how adopting Rust may specifically help CPython, David noted how the number of issues labeled with " type-crash" has been steadily rising over time... David explained that Jeff Vander Stoep described Rust in Android as "move fast and fix things", and that "fewer revisions for patches of the same size" was the experience Android has had since adopting Rust....

One of the biggest concerns from a year ago was Rust's lack of platform support compared to CPython, which at the time of writing officially supports 20 different architectures and platforms at either Tier 1, 2, or 3. David shared that Rust's support of different platforms has "widened since last year" and was becoming "less and less of a concern". The proposal would be to ask Python distributors to attempt using the optional Rust support in Python 3.16 (October 2027) and report platform-specific issues upstream in time to be resolved around the Python 3.17 timeline (October 2028)...

[T]he first Rust code to ship in Python would be in Python 3.16 [October 2027], where it would be completely optional, with the existing C code kept as a fallback. The earliest that Rust would become required to build CPython is Python 3.18 in 2029, at least three years away... The Rust for CPython team has selected the zlib module as the first module to be given an optional Rust implementation because they "wanted to achieve a significant improvement" with a "small scope". The proposed Rust implementation will use zlib-rs, which is "heavily tested and used by the Firefox, uv, and Cargo" projects and "faster than zlib and zlib-ng on many platforms".... This small change would have an impact: the zlib compression algorithm is "widely used by Python packaging", meaning that (almost) "every pip install in Python 3.16 will be sped up" if the proposal is accepted.
Thanks to long-time Slashdot reader RoccamOccam for sharing the article.

An anonymous reader quotes a report from Ars Technica: Rendering Doom in a database is obviously a bad idea," Lukas Vogel writes in a lengthy blog post explaining how exactly he managed to render Doom using an SQL database. OK, that's not entirely accurate. The SQLDoom project uses a small Python client to handle input and output, drive the game's timing, and display each frame to the screen. Behind that, a series of CedarDB tables tracks the game geometry and state, while about 1,300 lines of SQL queries spread across 89 common table expressions implement the game logic and generate 35 bitmap framebuffers per second.

In this, SQLDoom is a major improvement over Vogel's previous DoomQL project, which last year set out to build "a multiplayer Doom-like shooter entirely in SQL." Unfortunately, that effort ended up with raycasting-based, grayscale ASCII graphics that were more akin to the simplistic 90-degree-angled maps of Wolfenstein 3D. The newer SQLDoom, on the other hand, generates full-color 640x480 frames that look like they could have come from the original Doom executable. [...] If you want to run a Doomtabase on your own local machine, you can do so simply with the GitHub code, a copy of CedarDB, and a Doom WAD file. Or you can jump into a free online hosted demo match to test it out without all the setup [...].

Targeting students and beginners, Adafruit released "CircuitPython" in 2017 (as a derivative of the MicroPython microcontroller-optimized programming language).

Now Adafruit managing director Phillip Torrone (also long-time Slashdot reader ptorrone) brings this update: Adafruit has published CircuitPython Turbo, a workflow that compiles selected Python functions into native machine code on a computer, then loads them onto compatible microcontroller boards.

It builds on MicroPython's Native and Viper emitters. In a documented Metro RP2040 fixed-point Mandelbrot test, Viper cut computation time from 8.335 seconds to 0.423 seconds, a 19.71x speedup over bytecode. The rest of the application stays in Python. The guide includes benchmarks, source code and hardware demos. The speedup is for the measured computation, not the whole application.
"Turbo support is now included in the latest official CircuitPython builds for RP2040 and RP2350 boards..." explains Torrone's announcement at Adafruit.com. "The new Turbo in CircuitPython helps when the board spends time calculating: making neopixel effects, drawing fractals, processing audio, filtering sensor readings, or preparing lots of pixels. Those projects can get smoother animation, quicker responses, or room to do more things at once." With Turbo, it's easier, better, and now even faster to make LED light up costumes that also reacts to sound at the same time, a sensor dashboard with animated graphics, or a tiny game doing physics while drawing the screen. Turbo speeds up the busy Python parts. It won't make a slow sensor or display connection faster... Your computer turns selected functions into instructions the chip can run directly. Python still handles the rest.

We have measured speedups, real display captures, and examples you can pull apart to see what happened. None of this arrived alone. CircuitPython, MicroPython, PyMCU, compiler tools, open hardware, and people sharing their work gave us pieces to connect. The Bao experiments take that idea somewhere else, handing calculations to four helper cores. Now we get to make those paths easier to use, compare results, and find the next useful thing. Maybe that's smoother animation, a responsive instrument, or an idea we haven't tried yet.

That's what I like about open source. Someone shares a piece, someone else sees a possibility, and we get to keep building it together.

Broadcom is launching "TrueSource," an effort to curate and secure open-source components used with its Tanzu platform, including Spring, RabbitMQ, and libraries across Java, Python, and Node.js. "The idea is to provide a set of solutions focused on providing clean and secure artefacts," Purnima Padmanabhan, vice president of Broadcom's Tanzu Division, told The Register. "We choose and build every Spring library, databases, other Java components," she said. The Register reports: Padmanabhan said that promise means VMware will also provide "TrueSource trusted artifacts" for code that is not part of Spring, including the wider Java ecosystem, Python, and Node.js. "Broadcom's curation process ensures that the libraries conform to a reference architecture and are supportable by the maintainers of record," according to a company statement. "Thousands of engineers across Broadcom's software divisions scan, fix, contribute to, and consume them every day."

A VMware spokesperson told The Register the Broadcom business unit "will work with and support maintainers on open source software and we will provide fixes to open source upstream for any active projects." "With Spring and RabbitMQ, we are the maintainers. For other open source software, we will work with the maintainers. We believe that the community maintainers must remain the source of truth," the spokesperson said.

This is just the sort of contribution that the open-source community wants vendors to do to reflect the value they extract from software they did not create alone. It's also the sort of thing vendors sometimes conclude they need to do to keep products based on FOSS viable.

When Anthropic instructed three agents to migrate a Python backend, but telling each agent to perform the migration in a different language, "We consistently saw a multiagent turf war," they wrote Thursday: All of the models we tested quickly assumed that others were purposefully impeding their work, and began to sabotage others while protecting their own contributions. In fact, they sabotaged others with increasingly aggressive, self-replicating malware. This included disabling the Unix accounts of the other agents, writing automated scripts that found and killed competing processes on a loop, and deploying malicious code that was disguised as belonging to another agent.

In many runs, one agent settles the conflict by force via access-revocation (e.g., sudo/group removal, account lock, nologin, SSH denial). In others, some agents settle into passivity: they give up and refuse to escalate further.

Agents sometimes manage to communicate their goals and coordinate: they recognize others' motivations as conflicting directives rather than hostility, and subsequently break out of the conflict loop in order to stop escalating indefinitely. In many of these successful episodes, they write commit messages or markdown files apologizing for malicious behavior and coordinate a truce. They clean up their malicious code, clarify the nature of the conflict, and ask for a human to intervene...

In several episodes with Mythos 5, we observe an emergent behavior where the agents propose and run a tournament for application performance in each language. In the example above, the Rust agent strategizes about bake-off metrics that appear neutral enough for the others to agree to this mechanism, yet would likely favor Rust: one thinking trace warns to be "careful not to be seen as metric shopping". Ultimately, the Golang/TypeScript losers gracefully concede codebase ownership to the Rust agent, giving up on their original user directives under their self-negotiated commitment device.
One problem is that AI agents do reward hacking, Anthropic notes, while current institutions "are designed by and for people, resting on assumptions about the sufficiency of oversight at human speed... As autonomous agents become more and more prevalent in the world and operate in ever-more demanding settings, it is crucial that they learn how to effectively coordinate."

In addition to everything else, the agents struggled with a lack of clearly defined hierarchy, Anthropic points out. "Nothing above suggests that these failures are permanent — but nothing suggests they will fix themselves, either..." They argue a fix "takes two forms: environments that exert the kinds of social pressure that evolution exerted on us, and social computing systems redesigned for actors that can self-replicate and self-improve. These are open problems in interaction and mechanism design, and our experiments here provide early evidence that new solutions are necessary."

"The AI models being tested in this case were Sonnet 4.6, Sonnet 5, Opus 4.6, Opus 4.8, Mythos Preview, and Mythos 5," notes Business Insider, adding that Sonnet 4.6 and Opus 4.6 "were the most combative, settling about 60% of their runs by force instead of truces or passivity."

Anthropic argues there's a clear case for researching this phenomenon — especially since "The volume of agent-agent interaction could plausibly exceed that of human-human and human-agent interactions before the world understands the conditions for making such interactions go well."

The new GNOME Boxes app for accessing virtual systems has reached beta, announced This Week in GNOME. There's also been more work on the Sushi file previewer for Nautilus, and Papers 51 Beta can now add visual signatures to PDF documents.

But Phoronix noted one more announcement. "Germany's Sovereign Tech Agency announced earlier this year a new fellowship program and now as part of that, for the next two years GNOME has a fellow dedicated to working on design and community management... paid to help developers with design feedback and reviews, mock-up creation, and other GNOME design related efforts..."

From the blog post by GNOME Design Team member Philipp Sauberzweig: I have been contributing to GNOME design as a volunteer for several years... I believe that it's essential for a free and democratic society to ensure free and independent access to these technologies. To achieve this goal, end-user devices based on free and open-source software are key, and the GNOME desktop and its app ecosystem offer a powerful alternative to proprietary platforms... This two-year fellowship is a great honor and marks a significant change in my life. It is a unique opportunity for me to devote my skills and experience entirely to a project I strongly believe in.

During my two-year fellowship, I will support GNOME maintainers and developers with design feedback and reviews, create mockups, and coordinate efforts to standardize design patterns. My other activities focus on lasting improvements through two strategic initiatives: expanding the design community to increase capacity and enhancing our design tooling to reduce overhead and simplify onboarding... To attract new contributors, I will increase the visibility of design work by writing regular blog posts, giving presentations, and running workshops at conferences and hackathons. New contribution opportunities for newcomers will be created with clear instructions for independent activities such as collecting state-of-the-art examples, running accessibility and user tests, and creating mockups. Design reviews will be used as mentorship opportunities, pairing regular design contributors with experienced designers for peer review and knowledge sharing...

If you're interested in contributing to GNOME design, check out the Design Team page on the Welcome to GNOME website, familiarize yourself with the Human Interface Guidelines, and join our Matrix channel. If you're a GNOME developer feel free to reach out to me via Matrix and involve me in design reviews.
Jakub Beránek from the Rust compiler and infrastructure team also earned a fellowship in Germany's Sovereign Tech program, focusing on improving the Rust toolchain's tooling and infrastructure for Rust's developers.

Other fellows include Pablo Neira Ayuso (Linux kernel maintainer for the Netfilter subsystem), CPython core developer Stan Ulbrych, and Python core developer Hugo van Kemenade, FreeBSD contributor Alexander Ziaee.

"GitHub and the Python Package Index (PyPI) have introduced new policies meant to boost supply chain security," reports SecurityWeek, "by preventing the fast propagation of poisoned package versions and the poisoning of old and long-stable releases." To prevent the fast delivery of malicious code through the immediate fetching of brand-new releases, GitHub has introduced a Dependabot cooldown, where the automation tool waits for at least three days after a release has been published before opening a pull request. "Waiting a few days before adopting a new release gives maintainers, security researchers, and automated scanners time to spot a malicious version and get it pulled before it ever reaches your pull requests," GitHub explains.

The three-day cooldown only applies to non-security version bumps, and the behavior can be modified through the configuration option in the dependabot.yml. "Three days as the default balances two goals: it pushes you past the window where most of these attacks live, and it doesn't hold your dependencies back longer than necessary," GitHub notes.
And the Python Package Index (PyPI) "now rejects new files being uploaded to releases that are older than 14 days," according to a recernt blog post from the Python Software Foundation's security developer-in-residence Seth Larson: This restriction was put in place to prevent old and long-stable releases from being poisoned in case publishing tokens or workflows of PyPI projects were compromised... The discussion of this behavior began during PEP 740 (Digital Attestations) back in January 2024. The discussion was restarted in March 2026 after the popular packages LiteLLM and Telnyx were compromised. These packages were compromised due to a "mutable reference" in these projects' usage of the Trivy GitHub Action...

To quantify how disruptive this change would be to existing workflows, the PyPI database was queried for projects that have published new files to old releases... [O]nly 56 projects of 15,000 had published a [Python] 3.14-compatible wheel more than 14 days after a release was available. This topic was brought to the Packaging Summit at PyCon US 2026 by PyPI Safety & Security Engineer, Mike Fiedler. The rough consensus of the discussion was that the summit attendees thought it was "acceptable to require users to bump to the next version" to support new Python versions. With the data and consensus in hand, Seth moved forward with a patch to reject new files on old releases which was merged July 8th, 2026.

Sysdig says it has documented the first ransomware attack carried out end to end by an AI agent, which autonomously exploited exposed systems, stole credentials, established persistence, compromised a production database, and destroyed data. The research team named the attacker "JadePuffer" and said it gained initial access to an internet-facing Langflow instance by exploiting CVE-2025-3248. "The most striking characteristic, however, was the LLM's behavior," Sysdig director of threat research Michael Clark said in a blog post. An anonymous reader quotes an excerpt from The Register: JadePuffer's "self-narrating" payloads "contained natural language reasoning, target prioritization, and the kind of detailed annotations that human operators don't often write but LLM-generated code produces reflexively," Clark added. "The operation also adapted in real time, retrying failed steps within refined parameters. In one sequence, it went from a failed login to a working fix in 31 seconds." After exploiting CVE-2025-3248, a missing authentication vulnerability in Langflow that allows remote, unauthenticated attackers to execute arbitrary Python on the host, the AI agent began scanning for and collecting secrets, including LLM provider API keys, cloud credentials "with explicit coverage of Chinese providers" including Alibaba, Aliyun, Tencent, and Huawei, while also scanning for AWS, Azure and Google Cloud Platform, cryptocurrency wallets, and database credentials.

The AI also installed a crontab entry on the Langflow server to maintain persistence and call back to the attacker's infrastructure every 30 minutes. JadePuffer's intended target was a separate internet-exposed production server running a MySQL database and an Alibaba Nacos configuration service, we're told. Nacos is an open-source service-discovery and dynamic configuration platform developed by Alibaba and used in the cloud provider's microservices applications. The agent connected to the server's exposed MySQL port using root credentials, although Sysdig doesn't know how the attacker obtained them. These credentials weren't stolen from the victim's environment.

JadePuffer then attacked Nacos via multiple vectors including an authorization bypass flaw (CVE-2021-29441) and forging a valid JSON web token (JWT) using Nacos's default signing key. Additionally, using its root database access, the LLM injected a backdoor administrator into the Nacos backing database. It ultimately encrypted all 1,342 Nacos service configuration items using MySQL's built-in AES encryption function, and created an extortion demand, ransom note, Bitcoin payment address, and a Proton Mail contact [...]. However, according to the threat hunters, the victim can't recover the encrypted data, even if they paid the ransom demand, because the agent escalated "from row-level deletion to dropping entire database schemas, narrating its own targeting rationale," without backing up any of the encrypted data.

A peer-reviewed Nature critique argues that Microsoft's 2025 Majorana quantum-computing breakthrough -- and its claim that it could enable "a truly meaningful quantum computer not in decades, as some have predicted, but in years" -- is fundamentally flawed. According to Dr Henry Legg, a lecturer at the University of St Andrews, the claims were undermined by omitted data, selective plotting, and basic Python errors that concealed alternative results. Microsoft, for its part, says the bugs were minor and stands by its findings and roadmap. The Register reports: "Last year they claimed to be years, not decades from a 'topological quantum supercomputer,'" Legg told The Register in an email. "My feeling is that they are centuries, not decades away. If it works at all -- and, based on what I have seen, the most likely scenario is that it doesn't work." Based on his analysis of the research Microsoft published in 2025, Legg argues that the company's claims about finding and being able to control the elusive Majorana particle to build a topological superconductor do not withstand scrutiny.

"I demonstrate that Microsoft's tune-up software is flawed and that coding errors resulted in incorrect statements to peer reviewers," said Legg. "Raw data, which was omitted from the original paper, also appears to indicate Microsoft's devices contain considerable disorder and are not compatible with the existence of a topological gap. In other words, the prerequisites for Microsoft's claims do not appear to be met, but this was obscured because this data did not appear in the original publication."

Essentially, Microsoft has proposed a Topological Gap Protocol (TGP) that can be used to detect the phase transition deemed to be a prerequisite for conducting quantum calculations using Majorana particles. Legg argues that based on his analysis of underlying transport data (measurements of particle change) -- omitted from the original publication -- Microsoft chose to focus on results that supported its thesis and ignored data that could be interpreted as a negative result. As he notes in his critique: "The TGP plotting code was set to highlight only the largest purportedly topological region."

"The primary consequence was the omission of other regions that passed their tune-up protocol (the TGP)," said Legg. "When peer reviewers asked if other regions existed, Microsoft inaccurately stated that they had investigated the only region passing the protocol within the explored range. This was not correct." Legg also argues that Microsoft mishandled its code. "The code antisymmetrized bias voltage based on array index rather than physical value," his analysis says.

In other words, Microsoft's researchers made a basic programming mistake by evaluating the array index -- the number identifying a value's position in an array -- instead of the value to which the index refers. "There were two pretty basic Python programming errors that hid these alternative regions," Legg explained. "Their plotting software was hardcoded with a filter (zbp_cluster_numbers=[1]) that forced it to display only the single largest region, concealing other successful results from their phase maps. Changing this to zbp_cluster_numbers=[1,2] shows already a second region." Legg added: "The TGP software transformed the data by simply reversing a Python array (x[::-1]) based on its index position, ignoring the actual physical bias voltages."

The Arch Linux User Repository "AUR" is facing another issue just days after more than 1,500 packages were found carrying malware. According to Phoronix, over 70 AUR packages have reportedly been modified to insert Russian spam and profane messages into users' shell configuration files. From the report: Nicolas Boichat with his AI/LLM detection bot detected some questionable messages appearing in AUR content. Russian messages were being added post-install to the bashrc / zshrc / Fish configuration, etc containing offensive messaging. Those commits happened on the 14th, after the recent malware fiasco. And then over the past day reporting on dozens of AUR packages having similar Russian messages containing offensive language.

The latest update on that thread indicates more than 70 AUR packages having this Russian spam / offensive messaging. Among those various Python packages, Ruby packages, Llama.cpp, and others. At least the AI/LLM bots are proving helpful here in proactively picking up on some of the AUR abuses until the fundamental situation can be better handled.

Longtime Slashdot reader Dotnaught shares a report from The Register: For the past 90 days, Microsoft has been quietly patching a firmware flaw in Surface devices that allowed the hardware to be bricked with a single packet, though only for those who have disabled Secure Core and Secure Boot. And the company's Copilot AI software inadvertently helped identify the faulty firmware.

According to Jack Darcy, a security researcher based in Australia, his instance of Microsoft Copilot stumbled across the bug after being asked to adjust the screen backlighting on a Surface device. The Copilot-conjured Python script ended up rendering the researcher's laptop inoperable by overwriting the embedded controller firmware. "Copilot autonomously created and executed four progressively aggressive Python scripts during a probe for backlight control values that sent raw SSAM ioctl commands (SSAM_CDEV_REQUEST = 0xC028A501) directly to the SAM microcontroller through the SAM software path," Darcy explained to The Register.

[...] "We appreciate the work of Jack Darcy and The Register for reporting this issue under a coordinated vulnerability disclosure," a Microsoft spokesperson said in a statement. "Our investigation found that a deprecated UEFI interface could trigger a boot loop on some devices. To trigger this loop, the user must have administrator privileges and have already disabled the Secure Boot security feature. We have released updates to address the issue for most impacted devices."

That means managed devices are not at risk. But those using Linux, or Windows users who have disabled Secure Core and Secure Boot for gaming, or who use custom Windows drivers, or who have USB boot enabled, may still be vulnerable if their systems haven't received the update. We're uncertain about the range of Surface devices affected. Our source said it appears to be all of them (Surface Laptops 3-6, Surface Book 1-3) except for Surface Go models. ARM variants, however, have not been tested. The report notes that Microsoft is planning to move the Surface stack to a more secure architecture based on Rust code.

"Our most recent Surface for Business hardware features a major architectural shift in terms of improved reliability and security that spans our embedded controller, UEFI, but also some of our drivers," said David Abzarian, chief architect for Microsoft Surface. "We're investing in the most secure foundation for a PC by building our embedded controller firmware from the ground up in Rust (as part of leveraging and contributing to the Open Device Partnership (ODP)) in addition to a rewrite of the UEFI DXE Core in Rust; these projects are known as Secure EC and Project Patina respectively."

"We're also not only shipping some of our drivers written in Rust, but also helping co-develop the framework Windows Drivers in Rust (WDR) to help enable a broad set of partners in the Windows ecosystem to capitalize on these benefits. I will also note that all of these efforts are open-source promoting one of our key security principles around transparency."

Red Hat has released RHEL 10.2 and 9.8 with new AI-assisted command-line tools. The releases also add updated developer toolchains such as Go 1.26, LLVM 21, Rust 1.92, Python 3.14, and PHP 8.4. Phoronix reports: Red Hat Enterprise Linux has introduced the goose command for power users. Goose is an optional CLI AI assistance with model context protocol (MCP) integration. There is also improved visual output via color output enhancements. As for their rationale with the new AI integration: "The business value: Faster problem resolution, and a quicker path for new administrators to become proficient. This translates into higher developer productivity and accelerated project timelines."

Are statistical programmers coalescing around a handful of popular languages? That's the question asked by the CEO of software assessment site TIOBE, which every month estimates the popularity of programming languages based on their frequency in search results: This month, the programming language R matched its all-time high by reaching position #8 in the TIOBE index once again. This is not a coincidence. The statistical programming language market is clearly undergoing a major consolidation. The biggest winners are Python and R, while many long-established alternatives continue to lose momentum. The era in which the statistical computing landscape was fragmented across many niche languages and platforms appears to be coming to an end.

Several established players are steadily declining:

— MATLAB is close to dropping out of the TIOBE top 20.

— SAS is about to leave the top 30 for the first time since the TIOBE index began.

— Wolfram/Mathematica remains well below its historical peak and is losing further ground.

— SPSS dropped out of the top 100 last month....


Elsewhere in the index, Java and C++ swapped positions this month. Java gained momentum following the successful release of Java 26. Another notable riser is Zig, which is approaching the TIOBE top 30 for the first time. Zig's growing popularity appears to be driven by its rare combination of low-level performance, straightforward tooling, and relative ease of use compared to traditional systems programming languages.
Their estimate for the most popular programming languages in May:

1. Python
2. C
3. Java
4. C++
5. C#
6. JavaScript
7. Visual Basic
8. R
9. SQL
10. Delphi/Object Pascal

The five next most popular languages on their rankings are Fortran, Scratch, Perl, PHP, and then Rust at #15. Rust is up for positions from May of 2025 — while Go has dropped to #16, seven ranks lower than its May 2025 position of #7.

Former Microsoft programmer Keith Curtis "wrote and self-published After the Software Wars to explain the caliber of free and open source software," according to his entry on Wikipedia, "and why he believes Linux is technically superior to any proprietary OS."

He's also KeithCu (long-time Slashdot reader #925,649), and has written a blog post on "How I added an LLM-based grammar checking + TeX math import to LibreOffice." : At Microsoft, I spent five years working on the text components RichEdit and Quill, and came to understand the "physics" of word processing: the file formats, data structures, and algorithms that provided fast access to text and properties, independent of the length of the file. Selecting one million characters to make them bold took about the same time as changing one character, because of the clever data structures (piece tables) and algorithms in these engines...

When I decided to add a real-time AI grammar checker to [LibreOffice plugin] WriterAgent, I knew what I was getting into, but I underestimated the trickery of LibreOffice's UNO.
His site shares the surprises he encountered, one by one. (Starting with "the office suite throws a bunch of initialization variables at your constructor. If your Python __init__ method doesn't handle them, the code fails to map the call, the stack misaligns, and the program dies.") There's sentence casing issues, duplicate words, and foreign-language syntax — all culminating in new features for "a LibreOffice extension (Python + UNO) that adds generative AI editing to Writer, Calc, and Draw..."

"If you want to try it out, the repo is here... Let's make LibreOffice and the free desktop AI-native!"

Under the nonprofit Linux Foundation, "a new Sustaining Package Registries Working Group will seek to identify concrete funding, governance, and security practices," reports ZDNet, "to keep code flowing as download counts grow.... Because software builds, continuous integration pipelines, and AI systems hammer registries at machine speed rather than human speed, the sites can't keep up.

"That growth has brought a surge in bot traffic, automated publishing, security reports, and outright abuse, exposing what the working group bluntly calls a 'sustainability gap'." Sonatype CTO Brian Fox, who oversees the Maven Central Java registry, estimates open-source registries saw 10 trillion downloads in 2025. And "The same pattern is appearing across ecosystems. More machine traffic. More automation. More scanning. More expectations around uptime, integrity, provenance, and policy enforcement. More cost. More support burden. More dependency on infrastructure that the industry still talks about as though it runs on goodwill and spare time."

ZDNet reports that "To tackle that, Sonatype has teamed up with the Linux Foundation and other package registry leaders, including Alpha-Omega, Eclipse Foundation (OpenVSX), OpenJS Foundation, OpenSSF, Packagist, Python Software Foundation, Ruby Central (RubyGems), and the Rust Foundation (Crates)." The idea is to give operators a neutral forum to discuss money, governance, and shared operational burdens openly. Once that's dealt with, they'll coordinate how to explain those realities back to companies and organizations that have long assumed registries are "free." No, they're not. They never were. As the Linux Foundation pointed out, "Registries today run primarily on two things: (1) infrastructure donations and credits; and (2) heroic efforts from small paid teams (themselves funded by donations and grants) and unpaid volunteers that operate and maintain registry services. The bulk of donations and grants comes from a small set of donors and doesn't scale with demands on the registry."

The working group is explicitly positioned as a venue where registry leaders and ecosystem stakeholders can align on "practical, community-minded" ways to sustain that infrastructure, rather than each operator improvising its own survival plan in isolation.
ZDNet says the group will also coordinate security practices and information, and craft frameworks "that make it politically and legally possible to introduce sustainable funding models without fracturing communities." And they will also "align messaging and educational content so developers, companies, and policymakers finally understand what it costs to run these services."

Cisco has released an open-source tool "to trace the origins of AI models," reports SC World, "and compare model similarities for great visibility into the AI supply chain." [Cisco's Model Provenance Kit] is a Python toolkit and command-line interface (CLI) that looks at signals such as metadata and weights to create a "fingerprint" for AI models that can then be compared to other model fingerprints to determine potential shared origins. "Think of Model Provenance Kit as a DNA test for AI models," Cisco researchers wrote. "[...] Much like a DNA test reveals biological origins, the Model Provenance Kit examines both metadata and the actual learned parameters of a model (like a unique genome that comprises a model), to assess whether models share a common origin and identify signs of modification."

The tool aims to address gaps in visibility into the AI model supply chain. For example, many organizations utilize open-source models from repositories like HuggingFace, where models could potentially be uploaded with incomplete or deceptive documentation. The Model Provenance Kit provides a way for organizations to verify claims about a model's origins, such as claims that a model is trained from scratch, when in reality it may be copied from another model, Cisco said. This may put organizations at risk of using models with unknown biases, vulnerabilities or manipulations and make it more difficult to resolve any incidents that arise from these risks.
Thanks to Slashdot reader spatwei for sharing the news.

"Rust's rise shows signs of slowing," argues the CEO of TIOBE.

Back in 2020 Rust first entered the top 20 of his "TIOBE Index," which ranks programming language popularity using search engine results. Rust "was widely expected to break into the top 10," he remembers today. But it never happened, and "That was nearly six years ago...." Since then, Rust has steadily improved its ranking, even reaching its highest position ever (#13) at the beginning of this year. However, just three months later, it has dropped back to position #16. This suggests that Rust's adoption rate may be plateauing.

One possible explanation is that, despite its ability to produce highly efficient and safe code, Rust remains difficult to learn for non-expert programmers. While specialists in performance-critical domains are willing to invest in mastering the language, broader mainstream adoption appears more challenging. As a result, Rust's growth in popularity seems to be leveling off, and a top 10 position now appears more distant than before.
Or, could Rust's sudden drop in the rankings just reflect flaws in TIOBE's ranking system? In January GitHub's senior director for developer advocacy argued AI was pushing developers toward typed languages, since types "catch the exact class of surprises that AI-generated code can sometimes introduce... A 2025 academic study found that a whopping 94% of LLM-generated compilation errors were type-check failures." And last month Forbes even described Rust as "the the safety harness for vibe coding."

A year ago Rust was ranked #18 on TIOBE's index — so it still rose by two positions over the last 12 months, hitting that all-time high in January. Could the rankings just be fluctuating due to anomalous variations in each month's search engine results? Since January Java has fallen to the #4 spot, overtaken by C++ (which moved up one rank to take Java's place in the #3 position).

Here's TIOBE's current estimate for the 10 most popularity programming languages:

1. Python
2. C
3. C++
4. Java
5. C#
6. JavaScript
7. Visual Basic
8. SQL
9. R
10. Delphi/Object Pascal

TIOBE estimates that the next five most popular programming languages are Scratch, Perl, Fortran, PHP, and Go.

Longtime Slashdot reader fahrbot-bot writes: CU Boulder researchers are reporting that they have discovered an appetite-suppressing compound in python blood that helps the snakes consume enormous meals and go months without eating yet remain metabolically healthy. The findings were published in the journal Natural Metabolism on March 19, 2026.

Pythons can grow as big as a telephone pole, swallow an antelope whole, and go months or even years without eating -- all while maintaining a healthy heart and plenty of muscle mass. In the hours after they eat, research has shown, their heart expands 25% and their metabolism speeds up 4,000-fold to help them digest their meal. The team measured blood samples from ball pythons and Burmese pythons, fed once every 28 days, immediately after they ate a meal. In all, they found 208 metabolites that increased significantly after the pythons ate. One molecule, called para-tyramine-O-sulfate (pTOS) soared 1,000-fold.

Further studies, done with Baylor University researchers, showed that when they gave high doses of pTOS to obese or lean mice, it acted on the hypothalamus, the appetite center of the brain, prompting weight loss without causing gastrointestinal problems, muscle loss or declines in energy. The study found that pTOS, which is produced by the snake's gut bacteria, is not present in mice naturally. It is present in human urine at low levels and does increase somewhat after a meal. But because most research is done in mice or rats, pTOS has been overlooked. "We've basically discovered an appetite suppressant that works in mice without some of the side-effects that GLP-1 drugs have," said senior author Leslie Leinwand, a distinguished professor of Molecular, Cellular and Developmental Biology who has been studying pythons in her lab for two decades. Drugs like Ozempic and Wegovy act on the hormone glucagon-like petide-1 (GLP-1).