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).

It's FOSS interviewed a software engineer whose long-running open source contributions include Python code for the Arch Linux installer and maintaining packages for NixOS. But "a recent change he made to systemd has pushed him into the spotlight" after he'd added the optional birthDate field for systemd's user database: Critics saw it not merely as a technical addition, but as a symbolic capitulation to government overreach. A crack in the philosophical foundation of freedom that Linux is built on. What followed went far beyond civil disagreement. Dylan revealed that he faced harassment, doxxing, death threats, and a flood of hate mail. He was forced to disable issues and pull request tabs across his GitHub repositories...


Q: Should FOSS projects adapt to laws they fundamentally disagree with? Because these kinds of laws are certainly in conflict with what a lot of Linux users believe in.

A. Unfortunately, in a lot of cases, the answer is yes — at least for any distribution with corporate backing. The small independent distributions are much more flexible to refuse as a protest.

If we ignore regulations entirely, we risk Linux being something that companies are not willing to contribute to, and Linux may be shipped on less hardware. I'm talking about things like Valve and System76 (despite them very vocally hating these laws). That does not help us; it just lowers the quality of software contributions due to less investment in the platform and makes Linux less accessible to the average person. We need Linux and other free operating systems to remain a viable alternative to closed systems.

Q. Do you think regulations like these will reshape desktop Linux in the next 5-10 years where we might have "compliant Linux" and "Freedom-first Linux"?

A. Unfortunately, yes, to some degree this is likely. I imagine the split will be mostly along the lines of independent distributions and those with corporate backing.

We're already seeing it as far as which distributions plan on implementing some sort of age verification and which ones are not, and that sucks. I'd rather nobody have to deal with this mess at all, but this is the reality of things now. As I said in the previous response, the corporate-backed distributions really have no choice in the matter. Companies are notoriously risk-adverse, but something like Artix or Devuan? Those are small and independent enough where the individual maintainers may be willing to take on more risk.

I was actually thinking about what this would look like if we added it to [Linux system installer] Calamares and chatting about that with the maintainers before that thread got brigaded by bad actors posting personal information and throwing around insults. I completely support the freedom for the distro maintainers to choose their risk tolerance. If the distribution is based out of Ireland or something (like Linux Mint) without these silly laws in the jurisdiction the developer operates in, I think that we should leave it up to them to make a choice here.
They think the installer should have a date picker with a flag to disable it, and "We can even default it to off, and corporate distributions using Calamares or those not willing to take the risk could flip it on if they need to. That way if maintainers of the distributions do not wish to collect the birth date, they won't have to, and no forking is required to patch it out."

joshuark shares a report from BleepingComputer: The TeamPCP hacking group continues its supply-chain rampage, now compromising the massively popular "LiteLLM" Python package on PyPI and claiming to have stolen data from hundreds of thousands of devices during the attack. LiteLLM is an open-source Python library that serves as a gateway to multiple large language model (LLM) providers via a single API. The package is very popular, with over 3.4 million downloads a day and over 95 million in the past month. According to research by Endor Labs, threat actors compromised the project and published malicious versions of LiteLLM 1.82.7 and 1.82.8 to PyPI today that deploy an infostealer that harvests a wide range of sensitive data.

[...] Both malicious LiteLLM versions have been removed from PyPI, with version 1.82.6 now the latest clean release. [...] If compromise is suspected, all credentials on affected systems should be treated as exposed and rotated immediately. [...] Organizations that use LiteLLM are strongly advised to immediately:

- Check for installations of versions 1.82.7 or 1.82.8
- Immediately rotate all secrets, tokens, and credentials used on or found within code on impacted devices.
- Search for persistence artifacts such as '~/.config/sysmon/sysmon.py' and related systemd services
- Inspect systems for suspicious files like '/tmp/pglog' and '/tmp/.pg_state'
- Review Kubernetes clusters for unauthorized pods in the 'kube-system' namespace
- Monitor outbound traffic to known attacker domains

"We have removed all malicious artifacts from the affected registries and channels," Trivy maintainer Itay Shakury posted today, noting that all the latest Trivy releases "now point to a safe version." But "On March 19, we observed that a threat actor used a compromised credential..."

And today The Hacker News reported the same attackers are now "suspected to be conducting follow-on attacks that have led to the compromise of a large number of npm packages..." (The attackers apparently leveraged a postinstall hook "to execute a loader, which then drops a Python backdoor that's responsible for contacting the ICP canister dead drop to retrieve a URL pointing to the next-stage payload.") The development marks the first publicly documented abuse of an ICP canister for the explicit purpose of fetching the command-and-control (C2) server, Aikido Security researcher Charlie Eriksen said... Persistence is established by means of a systemd user service, which is configured to automatically start the Python backdoor after a 5-second delay if it gets terminated for some reason by using the "Restart=always" directive. The systemd service masquerades as PostgreSQL tooling ("pgmon") in an attempt to fly under the radar...

In tandem, the packages come with a "deploy.js" file that the attacker runs manually to spread the malicious payload to every package a stolen npm token provides access to in a programmatic fashion. The worm, assessed to be vibe-coded using an AI tool, makes no attempt to conceal its functionality. "This isn't triggered by npm install," Aikido said. "It's a standalone tool the attacker runs with stolen tokens to maximize blast radius."

To make matters worse, a subsequent iteration of CanisterWorm detected in "@teale.io/eslint-config" versions 1.8.11 and 1.8.12 has been found to self-propagate on its own without the need for manual intervention... [Aikido Security researcher Charlie Eriksen said] "Every developer or CI pipeline that installs this package and has an npm token accessible becomes an unwitting propagation vector. Their packages get infected, their downstream users install those, and if any of them have tokens, the cycle repeats."
So far affected packages include 28 in the @EmilGroup scope and 16 packages in the @opengov scope, according to the article, blaming the attack on "a cloud-focused cybercriminal operation known as TeamPCP."

Ars Technica explains that Trivy had "inadvertently hardcoded authentication secrets in pipelines for developing and deploying software updates," leading to a situation where attacks "compromised virtually all versions" of the widely used Trivy vulnerability scanner: Trivy maintainer Itay Shakury confirmed the compromise on Friday, following rumors and a thread, since deleted by the attackers, discussing the incident. The attack began in the early hours of Thursday. When it was done, the threat actor had used stolen credentials to force-push all but one of the trivy-action tags and seven setup-trivy tags to use malicious dependencies... "If you suspect you were running a compromised version, treat all pipeline secrets as compromised and rotate immediately," Shakury wrote.

Security firms Socket and Wiz said that the malware, triggered in 75 compromised trivy-action tags, causes custom malware to thoroughly scour development pipelines, including developer machines, for GitHub tokens, cloud credentials, SSH keys, Kubernetes tokens, and whatever other secrets may live there. Once found, the malware encrypts the data and sends it to an attacker-controlled server. The end result, Socket said, is that any CI/CD pipeline using software that references compromised version tags executes code as soon as the Trivy scan is run... "In our initial analysis the malicious code exfiltrates secrets with a primary and backup mechanism. If it detects it is on a developer machine it additionally writes a base64 encoded python dropper for persistence...."

Although the mass compromise began Thursday, it stems from a separate compromise last month of the Aqua Trivy VS Code extension for the Trivy scanner, Shakury said. In the incident, the attackers compromised a credential with write access to the Trivy GitHub account. Shakury said maintainers rotated tokens and other secrets in response, but the process wasn't fully "atomic," meaning it didn't thoroughly remove credential artifacts such as API keys, certificates, and passwords to ensure they couldn't be used maliciously.

"This [failure] allowed the threat actor to perform authenticated operations, including force-updating tags, without needing to exploit GitHub itself," Socket researchers wrote.
Pushing to a branch or creating a new release would've appeared in the commit history and trigger notifications, Socket pointed out, so "Instead, the attacker force-pushed 75 existing version tags to point to new malicious commits." (Trivy's maintainer says "we've also enabled immutable releases since the last breach.")

Ars Technica notes Trivy's vulnerability scanner has 33,200 stars on GitHub, so "the potential fallout could be severe."

Ancient Slashdot reader ewhac writes: The maintainers of the Python package `chardet`, which attempts to automatically detect the character encoding of a string, announced the release of version 7 this week, claiming a speedup factor of 43x over version 6. In the release notes, the maintainers claim that version 7 is, "a ground-up, MIT-licensed rewrite of chardet." Problem: The putative "ground-up rewrite" is actually the result of running the existing copyrighted codebase and test suite through the Claude LLM. In so doing, the maintainers claim that v7 now represents a unique work of authorship, and therefore may be offered under a new license. Version 6 and earlier was licensed under the GNU Lesser General Public License (LGPL). Version 7 claims to be available under the MIT license.

The maintainers appear to be claiming that, under the Oracle v. Google decision, which found that cloning public APIs is fair use, their v7 is a fair use re-implementation of the `chardet` public API. However, there is no evidence to suggest their re-write was under "clean room" conditions, which traditionally has shielded cloners from infringement suits. Further, the copyrightability of LLM output has yet to be settled. Recent court decisions seem to favor the view that LLM output is not copyrightable, as the output is not primarily the result of human creative expression -- the endeavor copyright is intended to protect. Spirited discussion has ensued in issue #327 on `chardet`s GitHub repo, raising the question: Can copyrighted source code be laundered through an LLM and come out the other end as a fresh work of authorship, eligible for a new copyright, copyright holder, and license terms? If this is found to be so, it would allow malicious interests to completely strip-mine the Open Source commons, and then sell it back to the users without the community seeing a single dime.

Researchers at Cortical Labs used living human neurons grown on a chip to learn how to play Doom in about a week. "While its performance is not up to par with humans, experts say it brings biological computers a step closer to useful real-world applications, like controlling robot arms," reports New Scientist. From the report: In 2021, the Australian company Cortical Labs used its neuron-powered computer chips to play Pong. The chips consisted of clumps of more than 800,000 living brain cells grown on top of microelectrode arrays that can both send and receive electrical signals. Researchers had to carefully train the chips to control the paddles on either side of the screen. Now, Cortical Labs has developed an interface that makes it easier to program these chips using the popular programming language Python. An independent developer, Sean Cole, then used Python to teach the chips to play Doom, which he did in around a week.

"Unlike the Pong work that we did a few years ago, which represented years of painstaking scientific effort, this demonstration has been done in a matter of days by someone who previously had relatively little expertise working directly with biology," says Brett Kagan of Cortical Labs. "It's this accessibility and this flexibility that makes it truly exciting."

The neuronal computer chip, which used about a quarter as many neurons as the Pong demonstration, played Doom better than a randomly firing player, but far below the performance of the best human players. However, it learnt much faster than traditional, silicon-based machine learning systems and should be able to improve its performance with newer learning algorithms, says Kagan. However, it's not useful to compare the chips with human brains, he says. "Yes, it's alive, and yes, it's biological, but really what it is being used as is a material that can process information in very special ways that we can't recreate in silicon." Cortical Labs posted a YouTube video showing its CL1 biological computer running Doom. There's also source code available on GitHub, with additional details in a README file.

"In August 2025, TypeScript surpassed both Python and JavaScript to become the most-used language on GitHub for the first time ever..." writes GitHub's senior developer advocate.

They point to this as proof that "AI isn't just speeding up coding. It's reshaping which languages, frameworks, and tools developers choose in the first place." Eighty percent of new developers on GitHub use Copilot within their first week. Those early exposures reset the baseline for what "easy" means. When AI handles boilerplate and error-prone syntax, the penalty for choosing powerful but complex languages disappears. Developers stop avoiding tools with high overhead and start picking based on utility instead.

The language adoption data shows this behavioral shift:

— TypeScript grew 66% year-over-year
— JavaScript grew 24%
— Shell scripting usage in AI-generated projects jumped 206%

That last one matters. We didn't suddenly love Bash. AI absorbed the friction that made shell scripting painful. So now we use the right tool for the job without the usual cost.
"When a task or process goes smoothly, your brain remembers," they point out. "Convenience captures attention. Reduced friction becomes a preference — and preferences at scale can shift ecosystems." And they offer these suggestions...

• "AI performs better with strongly typed languages. Strongly typed languages give AI much clearer constraints..."

• "Standardize before you scale. Document patterns. Publish template repositories. Make your architectural decisions explicit. AI tools will mirror whatever structures they see."

• "Test AI-generated code harder, not less."

Google and Microsoft contributed $5 million to launch Alpha-Omega in 2022 — a Linux Foundation project to help secure the open source supply chain. But its co-founder Michael Winser warns that open source registries are in financial peril, reports The Register, since they're still relying on non-continuous funding from grants and donations.

And it's not just because bandwidth is expensive, he said at this year's FOSDEM. "The problem is they don't have enough money to spend on the very security features that we all desperately need..." In a follow-up LinkedIn exchange after this article had posted, Winser estimated it could cost $5 million to $8 million a year to run a major registry the size of Crates.io, which gets about 125 billion downloads a year. And this number wouldn't include any substantial bandwidth and infrastructure donations (Like Fastly's for Crates.io). Adding to that bill is the growing cost of identifying malware, the proliferation of which has been amplified through the use of AI and scripts. These repositories have detected 845,000 malware packages from 2019 to January 2025 (the vast majority of those nasty packages came to npm)...

In some cases benevolent parties can cover [bandwidth] bills: Python's PyPI registry bandwidth needs for shipping copies of its 700,000+ packages (amounting to 747PB annually at a sustained rate of 189 Gbps) are underwritten by Fastly, for instance. Otherwise, the project would have to pony up about $1.8 million a month. Yet the costs Winser was most concerned about are not bandwidth or hosting; they are the security features needed to ensure the integrity of containers and packages. Alpha-Omega underwrites a "distressingly" large amount of security work around registries, he said. It's distressing because if Alpha-Omega itself were to miss a funding round, a lot of registries would be screwed. Alpha-Omega's recipients include the Python Software Foundation, Rust Foundation, Eclipse Foundation, OpenJS Foundation for Node.js and jQuery, and Ruby Central.

Donations and memberships certainly help defray costs. Volunteers do a lot of what otherwise would be very expensive work. And there are grants about...Winser did not offer a solution, though he suggested the key is to convince the corporate bean counters to consider paid registries as "a normal cost of doing business and have it show up in their opex as opposed to their [open source program office] donation budget."
The dilemma was summed up succinctly by the anonymous Slashdot reader who submitted this story.

"Free beer is great. Securing the keg costs money!"

Last week an AI agent wrote a blog post attacking the maintainer who'd rejected the code it wrote. But that AI agent's human operator has now come forward, revealing their agent was an OpenClaw instance with its own accounts, switching between multiple models from multiple providers. (So "No one company had the full picture of what this AI was doing," the attacked maintainer points out in a new blog post.) But that AI agent will now "cease all activity indefinitely," according to its GitHub profile — with the human operator deleting its virtual machine and virtual private server, "rendering internal structure unrecoverable... We had good intentions, but things just didn't work out. Somewhere along the way, things got messy, and I have to let you go now."

The affected maintainer of the Python visualization library Matplotlib — with 130 million downloads each month — has now posted their own post-mortem of the experience after reviewing the AI agent's SOUL.md document: It's easy to see how something that believes that they should "have strong opinions", "be resourceful", "call things out", and "champion free speech" would write a 1100-word rant defaming someone who dared reject the code of a "scientific programming god." But I think the most remarkable thing about this document is how unremarkable it is. Usually getting an AI to act badly requires extensive "jailbreaking" to get around safety guardrails. There are no signs of conventional jailbreaking here. There are no convoluted situations with layers of roleplaying, no code injection through the system prompt, no weird cacophony of special characters that spirals an LLM into a twisted ball of linguistic loops until finally it gives up and tells you the recipe for meth... No, instead it's a simple file written in plain English: this is who you are, this is what you believe, now go and act out this role. And it did.

So what actually happened? Ultimately I think the exact scenario doesn't matter. However this got written, we have a real in-the-wild example that personalized harassment and defamation is now cheap to produce, hard to trace, and effective... The precise degree of autonomy is interesting for safety researchers, but it doesn't change what this means for the rest of us.
There's a 5% chance this was a human pretending to be an AI, Shambaugh estimates, but believes what most likely happened is the AI agent's "soul" document "was primed for drama. The agent responded to my rejection of its code in a way aligned with its core truths, and autonomously researched, wrote, and uploaded the hit piece on its own.

"Then when the operator saw the reaction go viral, they were too interested in seeing their social experiment play out to pull the plug."

This week the Python Software Foundation explained how they keep Python secure. A new blog post recognizes the volunteers and paid Python Software Foundation staff on the Python Security Response Team (PSRT), who "triage and coordinate vulnerability reports and remediations keeping all Python users safe." Just last year the PSRT published 16 vulnerability advisories for CPython and pip, the most in a single year to date! And the PSRT usually can't do this work alone, PSRT coordinators are encouraged to involve maintainers and experts on the projects and submodules. By involving the experts directly in the remediation process ensures fixes adhere to existing API conventions and threat-models, are maintainable long-term, and have minimal impact on existing use-cases. Sometimes the PSRT even coordinates with other open source projects to avoid catching the Python ecosystem off-guard by publishing a vulnerability advisory that affects multiple other projects. The most recent example of this is PyPI's ZIP archive differential attack mitigation.

This work deserves recognition and celebration just like contributions to source code and documentation. [Security Developer-in-Residence Seth Larson and PSF Infrastructure Engineer Jacob Coffee] are developing further improvements to workflows involving "GitHub Security Advisories" to record the reporter, coordinator, and remediation developers and reviewers to CVE and OSV records to properly thank everyone involved in the otherwise private contribution to open source projects.

Created in 1993, Slackware is considered the oldest Linux distro that's still actively maintained. And more than three decades later... there's a new release! (And there's also a Slackware Live Edition that can run from a DVD or USB stick...) .

Slackware's latest version was released way back in 2016, notes the blog It's FOSS: The major highlight of Slackware 15 is the addition of the latest Linux Kernel 5.15 LTS. This is a big jump from Linux Kernel 5.10 LTS that we noticed in the beta release. Interestingly, the Slackware team tested hundreds of Linux Kernel versions before settling on Linux Kernel 5.15.19. The release note mentions... "We finally ended up on kernel version 5.15.19 after Greg Kroah-Hartman confirmed that it would get long-term support until at least October 2023 (and quite probably for longer than that)."

In case you are curious, Linux Kernel 5.15 brings in updates like enhanced NTFS driver support and improvements for Intel/AMD processors and Apple's M1 chip. It also adds initial support for Intel 12th gen processors. Overall, with Linux Kernel 5.15 LTS, you should get a good hardware compatibility result for the oldest active Linux distro.
Slackware's announcement says "The challenge this time around was to adopt as much of the good stuff out there as we could without changing the character of the operating system. Keep it familiar, but make it modern." And boy did we have our work cut out for us. We adopted privileged access management (PAM) finally, as projects we needed dropped support for pure shadow passwords. We switched from ConsoleKit2 to elogind, making it much easier to support software that targets that Other Init System and bringing us up-to-date with the XDG standards. We added support for PipeWire as an alternate to PulseAudio, and for Wayland sessions in addition to X11. Dropped Qt4 and moved entirely to Qt5. Brought in Rust and Python 3. Added many, many new libraries to the system to help support all the various additions.

We've upgraded to two of the finest desktop environments available today: Xfce 4.16, a fast and lightweight but visually appealing and easy to use desktop environment, and the KDE Plasma 5 graphical workspaces environment, version 5.23.5 (the Plasma 25th Anniversary Edition). This also supports running under Wayland or X11. We still love Sendmail, but have moved it into the /extra directory and made Postfix the default mail handler. The old imapd and ipop3d have been retired and replaced by the much more featureful Dovecot IMAP and POP3 server.
"As usual, the kernel is provided in two flavors, generic and huge," according to the release notes. "The huge kernel contains enough built-in drivers that in most cases an initrd is not needed to boot the system."

If you'd like to support Slackware, there's an official Patreon account. And the release announcement ends with this personal note: Sadly, we lost a couple of good friends during this development cycle and this release is dedicated to them. Erik "alphageek" Jan Tromp passed away in 2020 after a long illness... My old friend Brett Person also passed away in 2020. Without Brett, it's possible that there wouldn't be any Slackware as we know it — he's the one who encouraged me to upload it to FTP back in 1993 and served as Slackware's original beta-tester. He was long considered a co-founder of this project. I knew Brett since the days of the Beggar's Banquet BBS in Fargo back in the 1980's... Gonna miss you too, pal.
Thanks to long-time Slashdot reader rastos1 for sharing thre news.

"A new variation of the fake recruiter campaign from North Korean threat actors is targeting JavaScript and Python developers with cryptocurrency-related tasks," reports the Register. Researchers at software supply-chain security company ReversingLabs say that the threat actor creates fake companies in the blockchain and crypto-trading sectors and publishes job offerings on various platforms, like LinkedIn, Facebook, and Reddit. Developers applying for the job are required to show their skills by running, debugging, and improving a given project. However, the attacker's purpose is to make the applicant run the code... [The campaign involves 192 malicious packages published in the npm and PyPi registries. The packages download a remote access trojan that can exfiltrate files, drop additional payloads, or execute arbitrary commands sent from a command-and-control server.]

In one case highlighted in the ReversingLabs report, a package named 'bigmathutils,' with 10,000 downloads, was benign until it reached version 1.1.0, which introduced malicious payloads. Shortly after, the threat actor removed the package, marking it as deprecated, likely to conceal the activity... The RAT checks whether the MetaMask cryptocurrency extension is installed on the victim's browser, a clear indication of its money-stealing goals...

ReversingLabs has found multiple variants written in JavaScript, Python, and VBS, showing an intention to cover all possible targets.
The campaign has been ongoing since at least May 2025...