An anonymous reader shares a report: It's too soon to be talking about the Curse of OpenAI, but we're going to anyway. Since September 10, when Oracle announced a $300 billion deal with the chatbot maker, its stock has shed $315 billion in market value.

OK, yes, it's a gross simplification to just look at market cap. But equivalents to Oracle shares are little changed over the same period (Nasdaq Composite, Microsoft, Dow Jones US Software Index), so the $15 billion loss figure [figure updated with stock price] is not entirely wrong. Oracle's "astonishing quarter" really has cost it nearly as much as one General Motors, or two Kraft Heinz.

Linux kernel maintainers "are grappling with how to integrate AI-generated contributions without compromising the project's integrity," reports WebProNews: The latest push comes from a proposal by Sasha Levin, a prominent kernel developer at NVIDIA, who has outlined guidelines for tool-generated submissions. Posted to the kernel mailing list, these guidelines aim to standardize how AI-assisted patches are handled. According to Phoronix, the v3 iteration of the proposal [posted by Intel engineer Dave Hansen] emphasizes transparency and accountability, requiring developers to disclose AI involvement in their contributions. This move reflects broader industry concerns about the quality and copyright implications of machine-generated code.

Linus Torvalds, the creator of Linux, has weighed in on the debate, advocating for treating AI tools no differently than traditional coding aids. As reported by heise online, Torvalds sees no need for special copyright treatment for AI contributions, stating that they should be viewed as extensions of the developer's work. This perspective aligns with the kernel's pragmatic approach to innovation. The proposal, initially put forward by Levin in July 2025, includes a 'Co-developed-by' tag for AI-assisted patches, ensuring credit and traceability. OSTechNix details how tools like GitHub Copilot and Claude are specifically addressed, with configurations to guide their use in kernel development... ZDNET warns that without official policy, AI could 'creep' into the kernel and cause chaos...

The New Stack provides insight into how AI is already assisting kernel maintainers with mundane tasks. According to The New Stack, large language models (LLMs) are being used like 'novice interns' for drudgery work, freeing up experienced developers for complex problems... The Linux kernel's approach could set precedents for other open-source projects. With AI integration accelerating, projects like those in the Linux Foundation are watching closely... Recent kernel releases, such as 6.17.7, include performance improvements that indirectly support AI applications, as noted in Linux Compatible.

Android's security team published a blog post this week about their experience using Rust. Its title? "Move fast and fix things." Last year, we wrote about why a memory safety strategy that focuses on vulnerability prevention in new code quickly yields durable and compounding gains. This year we look at how this approach isn't just fixing things, but helping us move faster.

The 2025 data continues to validate the approach, with memory safety vulnerabilities falling below 20% of total vulnerabilities for the first time. We adopted Rust for its security and are seeing a 1000x reduction in memory safety vulnerability density compared to Android's C and C++ code. But the biggest surprise was Rust's impact on software delivery. With Rust changes having a 4x lower rollback rate and spending 25% less time in code review, the safer path is now also the faster one... Data shows that Rust code requires fewer revisions. This trend has been consistent since 2023. Rust changes of a similar size need about 20% fewer revisions than their C++ counterparts... In a self-reported survey from 2022, Google software engineers reported that Rust is both easier to review and more likely to be correct. The hard data on rollback rates and review times validates those impressions.

Historically, security improvements often came at a cost. More security meant more process, slower performance, or delayed features, forcing trade-offs between security and other product goals. The shift to Rust is different: we are significantly improving security and key development efficiency and product stability metrics.

With Rust support now mature for building Android system services and libraries, we are focused on bringing its security and productivity advantages elsewhere. Android's 6.12 Linux kernel is our first kernel with Rust support enabled and our first production Rust driver. More exciting projects are underway, such as our ongoing collaboration with Arm and Collabora on a Rust-based kernel-mode GPU driver. [They've also been deploying Rust in firmware for years, and Rust "is ensuring memory safety from the ground up in several security-critical Google applications," including Chromium's parsers for PNG, JSON, and web fonts.]
2025 was the first year more lines of Rust code were added to Android than lines of C++ code...

An anonymous reader shared this report from The Register: Yet another supply chain attack has hit the npm registry in what Amazon describes as "one of the largest package flooding incidents in open source registry history" — but with a twist. Instead of injecting credential-stealing code or ransomware into the packages, this one is a token farming campaign.

Amazon Inspector security researchers, using a new detection rule and AI assistance, originally spotted the suspicious npm packages in late October, and, by November 7, the team had flagged thousands. By November 12, they had uncovered more than 150,000 malicious packages across "multiple" developer accounts. These were all linked to a coordinated tea.xyz token farming campaign, we're told. This is a decentralized protocol designed to reward open-source developers for their contributions using the TEA token, a utility asset used within the tea ecosystem for incentives, staking, and governance.

Unlike the spate of package poisoning incidents over recent months, this one didn't inject traditional malware into the open source code. Instead, the miscreants created a self-replicating attack, infecting the packages with code to automatically generate and publish, thus earning cryptocurrency rewards on the backs of legitimate open source developers. The code also included tea.yaml files that linked these packages to attacker-controlled blockchain wallet addresses.
At the moment, Tea tokens have no value, points out CSO Online. "But it is suspected that the threat actors are positioning themselves to receive real cryptocurrency tokens when the Tea Protocol launches its Mainnet, where Tea tokens will have actual monetary value and can be traded..." In an interview on Friday, an executive at software supply chain management provider Sonatype, which wrote about the campaign in April 2024, told CSO that number has now grown to 153,000. "It's unfortunate that the worm isn't under control yet," said Sonatype CTO Brian Fox. And while this payload merely steals tokens, other threat actors are paying attention, he predicted. "I'm sure somebody out there in the world is looking at this massively replicating worm and wondering if they can ride that, not just to get the Tea tokens but to put some actual malware in there, because if it's replicating that fast, why wouldn't you?"

When Sonatype wrote about the campaign just over a year ago, it found a mere 15,000 packages that appeared to come from a single person. With the swollen numbers reported this week, Amazon researchers wrote that it's "one of the largest package flooding incidents in open source registry history, and represents a defining moment in supply chain security...." For now, says Sonatype's Fox, the scheme wastes the time of npm administrators, who are trying to expel over 100,000 packages. But Fox and Amazon point out the scheme could inspire others to take advantage of other reward-based systems for financial gain, or to deliver malware.
After deplooying a new detection rule "paired with AI", Amazon's security researchers' write, "within days, the system began flagging packages linked to the tea.xyz protocol... By November 7, the researchers flagged thousands of packages and began investigating what appeared to be a coordinated campaign. The next day, after validating the evaluation results and analyzing the patterns, they reached out to OpenSSF to share their findings and coordinate a response.
Their blog post thanks the Open Source Security Foundation (OpenSSF) for rapid collaboration, while calling the incident "a defining moment in supply chain security..."

It's been trying to measure the popularity of programming languages since 2000 using metrics like the number of engineers, courses, and third-party vendors. And "The November 2025 TIOBE Index brings another twist below Python's familiar lead," writes TechRepublic. "C solidifies its position as runner-up, C++ and Java lose some ground, and C# moves sharply upward, narrowing the gap with Java to less than a percentage point..."

TIO CEO Paul Jansen said this month that "Instead of Python, programming language C# is now the fastest rising language," How did C# achieve this? Java and C# are battling for a long time in the same areas. Right now it seems like C# has removed every reason why not to use C# instead of Java: it is cross platform nowadays, it is open source and it contains all new language features a developer wants. While the financial world is still dominated by Java, all other terrains show equal shares between Java and C#. Besides this, Microsoft is going strong and C# is still their most backed programming language.

Interesting note: C# has never been higher than Java in the TIOBE index. Currently the difference between the two rivals is less than 1%. There are exciting times ahead of us. Is C# going to surpass Java for the first time in the TIOBE index history?
"The fact that C# has been in the news for the successive betas and pre-release candidates prior to the release of C# 14 may have bumped up its percentage share in the last few months," notes a post on the site i-Programmer. But they also point out that by TIOBE's reckoning, Java — having been overtaken by Python in 2021 — "has been in decline ever since."

TechRepublic summarizes the rest of the Top Ten: JavaScript stays in sixth place at 3.42%, and Visual Basic edges up to seventh with 3.31%. Delphi/Object Pascal nudges upward to eighth at 2.06%, while Perl returns to the top 10 in ninth at 1.84% after a sharp year-over-year climb. SQL rounds out the list at tenth with 1.80%, maintaining a foothold that shows the enduring centrality of relational databases. Go, which held eighth place in October, slips out of the top 10 entirely.
Here's how TIOBE's methodology ranks programming language popularity in November:

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

Russia's first AI humanoid robot, Aldol, fell just seconds after its debut at a technology event in Moscow on Tuesday. "The robot was being led on stage to the soundtrack from the film 'Rocky,' before it suddenly lost its balance and fell," reports the BBC. "Assistants could then be seen scrambling to cover it with a cloth -- which ended up tangling in the process." Developers of Aldol blamed poor lighting and calibration issues for the collapse, saying the robot's stereo cameras are sensitive to light and the hall was dark.

Dave Knott writes: Microsoft has released Visual Studio 2026, the first major version of their flagship compiler in almost four years. Release notes are available here. The compiler has also been updated, including improved (but not yet 100%) C++23 core language and standard library implementations.

Linux kernel developers are moving toward enabling Microsoft C Extensions (-fms-extensions) by default in Linux 6.19, with Linus Torvalds signaling no objection. While some dislike relying on Microsoft-style behavior, the patches in kbuild-next suggest the project is ready to "bite the bullet" and adopt the extensions system-wide. Phoronix reports: Rasmus Villemoes argued with Kbuild: enable -fms-extensions that would allow for "prettier code" and others have noted in the past the potential for saving stack space and all around being beneficial in being able to leverage the Microsoft C behavior: "Once in a while, it turns out that enabling -fms-extensions could allow some slightly prettier code. But every time it has come up, the code that had to be used instead has been deemed 'not too awful' and not worth introducing another compiler flag for. That's probably true for each individual case, but then it's somewhat of a chicken/egg situation. If we just 'bite the bullet' as Linus says and enable it once and for all, it is available whenever a use case turns up, and no individual case has to justify it..."

The second patch is kbuild: Add '-fms-extensions' to areas with dedicated CFLAGS to ensure -fms-extensions is passed for the CPU architectures that rely on their own CFLAGS being set rather than the main KBUILD_CFLAGS. Linus Torvalds chimed in on the prior mailing list discussion and doesn't appear to be against enabling -fms-extensions beginning with the Linux 6.19 kernel.

New submitter benramsey writes: The PHP Foundation has launched a search for its next executive director.

The Executive Director serves as the operational leader of the PHP Foundation, defining its strategic vision and translating it into reality while managing day-to-day operations and serving as the primary bridge between the Board, staff, community, and sponsors.

While the programming language PHP is over 30 years old, the PHP Foundation was only created in 2021. The Executive Director will be responsible for maturing the foundation's internal structure and will play a crucial role in ensuring the foundation can effectively support this vital ecosystem.

Interested parties are encouraged to submit a cover letter describing their interest and relevant experience, resume or CV, and a brief vision statement detailing the applicant's understanding of the position, key opportunities and challenges they see for the foundation, and their approach to the role.

The Rust Foundation has a responsibility to "shed light on the impact of supporting the often unseen work" that keeps the Rust Project running. So this week they announced a new initiative "to provide consistent, transparent, and long term support for the developers who make the Rust programming language possible."

It's the Rust Foundation Maintainers Fund, "an initiative we'll shape in close collaboration with the Rust Project Leadership Council and Project Directors to ensure funding decisions are made openly and with accountability." In the months ahead, we'll define the fund's structure, secure contributions, and work with the Rust Project and community to bring it to life. This work will build on lessons from earlier iterations of our grants and fellowships to create a lasting framework for supporting Rust's maintainers... Over the past several months, through ongoing board discussions and input from the Leadership Council, this initiative has taken shape as a way to help maintainers continue their vital development and review work, and plan for the future...

This initiative reflects our commitment to Rust being shaped by its people, guided by open collaboration, and backed by a global network of contributors and partners. The Rust Foundation Maintainers Fund will operate within the governance framework shared between the Rust Project and the Rust Foundation, ensuring alignment and oversight at every level... The Rust Foundation's approach to this initiative will be guided by our structure: as a 501( C)(6) nonprofit, we operate under a mandate for transparency and accountability to the Rust Project, language community, and our members. That means we must develop this fund in coordination with the Rust Project's priorities, ensuring shared governance and long-term viability...

Our goal is simple: to help the people building Rust continue their essential work with the support they deserve. That means creating the conditions for long term maintainer roles and ensuring continuity for those whose efforts keep the language stable and evolving. Through the Rust Foundation Maintainers Fund, we aim to address these needs directly.
"The more companies using Rust can contribute to the Rust Foundation Maintainers Fund, the more we can keep the language and tooling evolving for the benefit of everyone," says Rust Foundation project director Carol Nichols.

After the Python Software Foundation rejected a $1.5 million grant because it restricted DEI activity, "a flood of new donations followed," according to a new report. By Friday they'd raised over $157,000, including 295 new Supporting Members paying an annual $99 membership fee, says PSF executive director Deb Nicholson.

"It doesn't quite bridge the gap of $1.5 million, but it's incredibly impactful for us, both financially and in terms of feeling this strong groundswell of support from the community." Could that same security project still happen if new funding materializes? The PSF hasn't entirely given up. "The PSF is always looking for new opportunities to fund work benefiting the Python community," Nicholson told me in an email last week, adding pointedly that "we have received some helpful suggestions in response to our announcement that we will be pursuing." And even as things stand, the PSF sees itself as "always developing or implementing the latest technologies for protecting PyPI project maintainers and users from current threats," and it plans to continue with that commitment.
The Python Software Foundation was "astounded and deeply appreciative at the outpouring of solidarity in both words and actions," their executive director wrote in a new blog post this week, saying the show of support "reminds us of the community's strength."

But that post also acknowledges the reality that the Python Software Foundation's yearly revenue and assets (including contributions from major donors) "have declined, and costs have increased,..." Historically, PyCon US has been a source of revenue for the PSF, enabling us to fund programs like our currently paused Grants Program... Unfortunately, PyCon US has run at a loss for three years — and not from a lack of effort from our staff and volunteers! Everyone has been working very hard to find areas where we can trim costs, but even with those efforts, inflation continues to surge, and changing U.S. and economic conditions have reduced our attendance... Because we have so few expense categories (the vast majority of our spending goes to running PyCon US, the Grants Program, and our small 13-member staff), we have limited "levers to pull" when it comes to budgeting and long-term sustainability...
While Python usage continues to surge, "corporate investment back into the language and the community has declined overall. The PSF has longstanding sponsors and partners that we are ever grateful for, but signing on new corporate sponsors has slowed." (They're asking employees at Python-using companies to encourage sponsorships.) We have been seeking out alternate revenue channels to diversify our income, with some success and some challenges. PyPI Organizations offers paid features to companies (PyPI features are always free to community groups) and has begun bringing in monthly income. We've also been seeking out grant opportunities where we find good fits with our mission.... We currently have more than six months of runway (as opposed to our preferred 12 months+ of runway), so the PSF is not at immediate risk of having to make more dramatic changes, but we are on track to face difficult decisions if the situation doesn't shift in the next year.

Based on all of this, the PSF has been making changes and working on multiple fronts to combat losses and work to ensure financial sustainability, in order to continue protecting and serving the community in the long term. Some of these changes and efforts include:

— Pursuing new sponsors, specifically in the AI industry and the security sector
— Increasing sponsorship package pricing to match inflation
— Making adjustments to reduce PyCon US expenses
— Pursuing funding opportunities in the US and Europe
— Working with other organizations to raise awareness
— Strategic planning, to ensure we are maximizing our impact for the community while cultivating mission-aligned revenue channels

The PSF's end-of-year fundraiser effort is usually run by staff based on their capacity, but this year we have assembled a fundraising team that includes Board members to put some more "oomph" behind the campaign. We'll be doing our regular fundraising activities; we'll also be creating a unique webpage, piloting temporary and VERY visible pop-ups to python.org and PyPI.org, and telling more stories from our Grants Program recipients...

Keep your eyes on the PSF Blog, the PSF category on Discuss, and our social media accounts for updates and information as we kick off the fundraiser this month. Your boosts of our posts and your personal shares of "why I support the PSF" stories will make all the difference in our end-of-year fundraiser. If this post has you all fired up to personally support the future of Python and the PSF right now, we always welcome new PSF Supporting Members and donations.

A maintainer of Debian's Advanced Package Tool (APT) "has announced plans to introduce hard Rust dependencies into APT starting May 2026," reports the blog It's FOSS. The integration targets critical areas like parsing .deb, .ar, and tar files plus HTTP signature verification using Sequoia. [APT maintainer Julian Andres Klode] said these components "would strongly benefit from memory safe languages and a stronger approach to unit testing."

He also gave a firm message to maintainers of Debian ports: "If you maintain a port without a working Rust toolchain, please ensure it has one within the next 6 months, or sunset the port."

The reasoning is straightforward. Debian wants to move forward with modern tools rather than being held back by legacy architecture... Debian ports running on CPU architectures without Rust compiler support have six months to add proper toolchains. If they can't meet this deadline, those ports will need to be discontinued. As a result, some obscure or legacy platforms may lose official support. For most users on mainstream architectures like x86_64 and ARM, nothing changes. Your APT will simply become more secure and reliable under the hood.
It's FOSS argues that "If done right, this could significantly strengthen APT's security and code quality."

And the blog Linuxiac also supports the move. "By embedding Rust into APT, the distro joins a growing number of major open-source projects, such as the Linux kernel, Firefox, and systemd, that are gradually adopting Rust. And if I had to guess, I'd say this is just one of the first steps toward even deeper Rust integration in this legendary distribution, which is a good thing."

BrianFagioli writes: Google has released Magika 1.0, a stable version of its AI-based file type detection tool, and rebuilt the entire engine in Rust for speed and memory safety. The system now recognizes more than 200 file types, up from about 100, and is better at distinguishing look-alike formats such as JSON vs JSONL, TSV vs CSV, C vs C++, and JavaScript vs TypeScript. The team used a 3TB training dataset and even relied on Gemini to generate synthetic samples for rare file types, allowing Magika to handle formats that don't have large, publicly available corpora. The tool supports Python and TypeScript integrations and offers a native Rust command-line client.

Under the hood, Magika uses ONNX Runtime for inference and Tokio for parallel processing, allowing it to scan around 1,000 files per second on a modern laptop core and scale further with more CPU cores. Google says this makes Magika suitable for security workflows, automated analysis pipelines, and general developer tooling. Installation is a single curl or PowerShell command, and the project remains fully open source. The project is available on GitHub and documentation can be found here.

A new survey of over 300 US and UK gaming executives found that 72% view Steam as a monopoly. "Furthermore, 88% said that at least three-quarters of their revenue came from Steam, while 37% reported that the platform accounted for 90% of their total revenue," adds Techspot. From the report: Atomik Research conducted the recent survey on behalf of Rokky, a company that helps game publishers minimize the impact of grey market key resellers on prices. In addition to opinions on Steam, developers also answered questions about the PC market's biggest challenges.

The increasing popularity of free-to-play games such as Fortnite, DOTA 2, Counter-Strike 2, Call of Duty: Warzone, and Roblox topped the list of concerns for 40% of respondents. Approximately a third mentioned market saturation and discoverability, echoing data that suggests there aren't enough players for the thousands of new titles released on Steam each year. A similar portion of survey respondents also expressed concerns regarding subscription services.

"AI isn't just a tool anymore; it's an integral part of the development experience," argues GitHub's blog. So "Agents shouldn't be bolted on. They should work the way you already work..."

So this week GitHub announced "Agent HQ," which CNBC describes as a "mission control" interface "that will allow software developers to manage coding agents from multiple vendors on a single platform." Developers have a range of new capabilities at their fingertips because of these agents, but it can require a lot of effort to keep track of them all individually, said GitHub COO Kyle Daigle. Developers will now be able to manage agents from GitHub, OpenAI, Google, Anthropic, xAI and Cognition in one place with Agent HQ. "We want to bring a little bit of order to the chaos of innovation," Daigle told CNBC in an interview. "With so many different agents, there's so many different ways of kicking off these asynchronous tasks, and so our big opportunity here is to bring this all together." Agent HQ users will be able to access a command center where they can assign, steer and monitor the work of multiple agents...

The third-party agents will begin rolling out to GitHub Copilot subscribers in the coming months, but Copilot Pro+ users will be able to access OpenAI Codex in VS Code Insiders this week, the company said.
"We're into this wave two era," GitHub's COO Mario Rodriguez told VentureBeat, an era that's "going to be multimodal, it's going to be agentic and it's going to have these new experiences that will feel AI native...."

Or, as VentureBeat sees it, GitHub "is positioning itself as the essential orchestration layer beneath them all..." Just as the company transformed Git, pull requests and CI/CD into collaborative workflows, it's now trying to do the same with a fragmented AI coding landscape...

The technical architecture addresses a critical enterprise concern: Security. Unlike standalone agent implementations where users must grant broad repository access, GitHub's Agent HQ implements granular controls at the platform level... Agents operating through Agent HQ can only commit to designated branches. They run within sandboxed GitHub Actions environments with firewall protections. They operate under strict identity controls. [GitHub COO] Rodriguez explained that even if an agent goes rogue, the firewall prevents it from accessing external networks or exfiltrating data unless those protections are explicitly disabled.

Beyond managing third-party agents, GitHub is introducing two technical capabilities that set Agent HQ apart from alternative approaches like Cursor's standalone editor or Anthropic's Claude integration. Custom agents via AGENTS.md files: Enterprises can now create source-controlled configuration files that define specific rules, tools and guardrails for how Copilot behaves. For example, a company could specify "prefer this logger" or "use table-driven tests for all handlers." This permanently encodes organizational standards without requiring developers to re-prompt every time... Native Model Context Protocol (MCP) support: VS Code now includes a GitHub MCP Registry. Developers can discover, install and enable MCP servers with a single click. They can then create custom agents that combine these tools with specific system prompts. This positions GitHub as the integration point between the emerging MCP ecosystem and actual developer workflows. MCP, introduced by Anthropic but rapidly gaining industry support, is becoming a de facto standard for agent-to-tool communication. By supporting the full specification, GitHub can orchestrate agents that need access to external services without each agent implementing its own integration logic.

GitHub is also shipping new capabilities within VS Code itself. Plan Mode allows developers to collaborate with Copilot on building step-by-step project approaches. The AI asks clarifying questions before any code is written. Once approved, the plan can be executed either locally in VS Code or by cloud-based agents. The feature addresses a common failure mode in AI coding: Beginning implementation before requirements are fully understood. By forcing an explicit planning phase, GitHub aims to reduce wasted effort and improve output quality.

More significantly, GitHub's code review feature is becoming agentic. The new implementation will use GitHub's CodeQL engine, which previously largely focused on security vulnerabilities to identify bugs and maintainability issues. The code review agent will automatically scan agent-generated pull requests before human review. This creates a two-stage quality gate.
"Don't let this little bit of news float past you like all those self-satisfied marketing pitches we semi-hear and ignore," writes ZDNet: If it works and remains reliable, this is actually a very big deal... Tech companies, especially the giant ones, often like to talk "open" but then do their level best to engineer lock-in to their solution and their solution alone. Sure, most of them offer some sort of export tool, but the barrier to moving from one tool to another is often huge... [T]he idea that you can continue to use your favorite agent or agents in GitHub, fully integrated into the GitHub tool path, is powerful. It means there's a chance developers might not have to suffer the walled garden effect that so many companies have strived for to lock in their customers.