Kevin Barry, founder and sole developer of Nova Launcher, has left parent company Branch Metrics after being told to stop work on both the launcher and an open-source release. While the app remains on Google Play, the launcher's website currently shows a 404 error. The Verge reports: Mobile analytics company Branch Metrics acquired Nova in 2022. The company's CEO at the time, co-founder Alex Austin, said on Reddit that if Barry were to leave Branch, "it's contracted that the code will be open-sourced and put in the hands of the community." Austin left Branch in 2023, and now with Barry officially gone from the company, too, it's unclear if the launcher will now actually be open-sourced.

"I think the newer leadership since Alex Austin left has put a different focus on the company and Nova simply isn't part of that focus in any way at all," Cliff Wade, Nova's former customer relations lead who left as part of the 2024 layoffs, tells The Verge. "It's just some app that they own but no longer feel they need or want." Wade also said that "I don't believe Branch will do the right thing any time soon with regards to open-sourcing Nova. I think they simply just don't care and don't want to invest time, unless of course, they get enough pressure from the community and individuals who care."

Users have started a change.org petition to ask for the project to be open-sourced, and Wade says it's a "great start" to apply that pressure. Wade said he hasn't personally seen Barry's contract, so couldn't corroborate the claim of a contractual obligation to open-source Nova. Still, he said that the community "deserves" for the launcher to be open-sourced. "Branch just simply needs to do the right thing here and honor what they as a company have stated as well as what then CEO Alex Austin has stated numerous times prior to him leaving Branch."

Slashdot reader Charlotte Web shared this report from the Register: Among the software developers who use Microsoft's GitHub, the most popular community discussion in the past 12 months has been a request for a way to block Copilot, the company's AI service, from generating issues and pull requests in code repositories. The second most popular discussion — where popularity is measured in upvotes — is a bug report that seeks a fix for the inability of users to disable Copilot code reviews. Both of these questions, the first opened in May and the second opened a month ago, remain unanswered, despite an abundance of comments critical of generative AI and Copilot...

The author of the first, developer Andi McClure, published a similar request to Microsoft's Visual Studio Code repository in January, objecting to the reappearance of a Copilot icon in VS Code after she had uninstalled the Copilot extension... "I've been for a while now filing issues in the GitHub Community feedback area when Copilot intrudes on my GitHub usage," McClure told The Register in an email. "I deeply resent that on top of Copilot seemingly training itself on my GitHub-posted code in violation of my licenses, GitHub wants me to look at (effectively) ads for this project I will never touch. If something's bothering me, I don't see a reason to stay quiet about it. I think part of how we get pushed into things we collectively don't want is because we stay quiet about it."

It's not just the burden of responding to AI slop, an ongoing issue for Curl maintainer Daniel Stenberg. It's the permissionless copying and regurgitation of speculation as fact, mitigated only by small print disclaimers that generative AI may produce inaccurate results. It's also GitHub's disavowal of liability if Copilot code suggestions happen to have reproduced source code that requires attribution. It's what the Servo project characterizes in its ban on AI code contributions as the lack of code correctness guarantees, copyright issues, and ethical concerns. Similar objections have been used to justify AI code bans in GNOME's Loupe project, FreeBSD, Gentoo, NetBSD, and QEMU... Calls to shun Microsoft and GitHub go back a long way in the open source community, but moved beyond simmering dissatisfaction in 2022 when the Software Freedom Conservancy (SFC) urged free software supporters to give up GitHub, a position SFC policy fellow Bradley M. Kuhn recently reiterated.
McClure says In the last six months their posts have drawn more community support — and tells the Register there's been a second change in how people see GitHub within the last month. After GitHub moved from a distinct subsidiary to part of Microsoft's CoreAI group, "it seems to have galvanized the open source community from just complaining about Copilot to now actively moving away from GitHub."

In July 791 professional coders were surveyed by Fastly about their use of AI coding tools, reports InfoWorld. The results?

"About a third of senior developers (10+ years of experience) say over half their shipped code is AI-generated," Fastly writes, "nearly two and a half times the rate reported by junior developers (0-2 years of experience), at 13%." "AI will bench test code and find errors much faster than a human, repairing them seamlessly. This has been the case many times," one senior developer said...

Senior developers were also more likely to say they invest time fixing AI-generated code. Just under 30% of seniors reported editing AI output enough to offset most of the time savings, compared to 17% of juniors. Even so, 59% of seniors say AI tools help them ship faster overall, compared to 49% of juniors. Just over 50% of junior developers say AI makes them moderately faster. By contrast, only 39% of more senior developers say the same.

But senior devs are more likely to report significant speed gains: 26% say AI makes them a lot faster, double the 13% of junior devs who agree. One reason for this gap may be that senior developers are simply better equipped to catch and correct AI's mistakes... Nearly 1 in 3 developers (28%) say they frequently have to fix or edit AI-generated code enough that it offsets most of the time savings. Only 14% say they rarely need to make changes. And yet, over half of developers still feel faster with AI tools like Copilot, Gemini, or Claude.

Fastly's survey isn't alone in calling AI productivity gains into question. A recent randomized controlled trial (RCT) of experienced open-source developers found something even more striking: when developers used AI tools, they took 19% longer to complete their tasks. This disconnect may come down to psychology. AI coding often feels smooth... but the early speed gains are often followed by cycles of editing, testing, and reworking that eat into any gains. This pattern is echoed both in conversations we've had with Fastly developers and in many of the comments we received in our survey...

Yet, AI still seems to improve developer job satisfaction. Nearly 80% of developers say AI tools make coding more enjoyable... Enjoyment doesn't equal efficiency, but in a profession wrestling with burnout and backlogs, that morale boost might still count for something.
Fastly quotes one developer who said their AI tool "saves time by using boilerplate code, but it also needs manual fixes for inefficiencies, which keep productivity in check."

The study also found the practice of green coding "goes up sharply with experience. Just over 56% of junior developers say they actively consider energy use in their work, while nearly 80% among mid- and senior-level engineers consider this when coding."

Announced this week at RustConf 2025 in Seattle, the new Rust Innovation Lab will offer open source projects "the opportunity to receive fiscal sponsorship from the Rust Foundation, including governance, legal, networking, marketing, and administrative support."

And their first project will be the TLS library Rustls (for cryptographic security), which they say "demonstrates Rust's ability to deliver both security and performance in one of the most sensitive areas of modern software infrastructure." Choosing Rustls "underscores the lab's focus on infrastructure-critical tools, where reliability is paramount," argues explains WebProNews. But "Looking ahead, the foundation plans to expand the lab's portfolio, inviting applications from promising Rust initiatives. This could catalyze innovations in areas like embedded systems and blockchain, where Rust's efficiency shines."

Their article notes that the Rust Foundation "sees the lab as a way to accelerate innovation while mitigating the operational burdens that often hinder open-source development." [T]he Foundation aims to provide a stable, neutral environment for select Rust endeavors, complete with governance oversight, legal and administrative backing, and fiscal sponsorship... At its core, the Rust Innovation Lab addresses a growing need within the developer community for structured support amid Rust's rising adoption in sectors like systems programming and web infrastructure. By offering a "home" for projects that might otherwise struggle with sustainability, the lab ensures continuity and scalability. This comes at a time when Rust's memory safety features are drawing attention from major tech firms, including those in cloud computing and cybersecurity, as a counter to vulnerabilities plaguing languages like C++...

Industry observers note that such fiscal sponsorship could prove transformative, enabling projects to secure funding from diverse sources while maintaining independence. The Rust Foundation's involvement ensures compliance with best practices, potentially attracting more corporate backers wary of fragmented open-source efforts... By providing a neutral venue, the foundation aims to prevent the pitfalls seen in other ecosystems, such as project abandonment due to maintainer burnout or legal entanglements... For industry insiders, the Rust Innovation Lab represents a strategic evolution, potentially accelerating Rust's integration into mission-critical systems.

The latest status report from the FreeBSD Project says no thanks to code generated by LLM-based assistants. From a report: The FreeBSD Project's Status Report for the second quarter of 2025 contains updates from various sub-teams that are working on improving the FreeBSD OS, including separate sub-projects such as enabling FreeBSD apps to run on Linux, Chinese translation efforts, support for Solaris-style Extended Attributes, and for Apple's legacy HFS+ file system.

The thing that stood out to us, though, was that the core team is working on what it terms a "Policy on generative AI created code and documentation." The relevant paragraph says: "Core is investigating setting up a policy for LLM/AI usage (including but not limited to generating code). The result will be added to the Contributors Guide in the doc repository. AI can be useful for translations (which seems faster than doing the work manually), explaining long/obscure documents, tracking down bugs, or helping to understand large code bases. We currently tend to not use it to generate code because of license concerns. The discussion continues at the core session at BSDCan 2025 developer summit, and core is still collecting feedback and working on the policy."

Taylor Otwell, inventor and maintainer of popular PHP framework Laravel, is warning against overly complex code and the risks of bypassing the framework. From a report: Developers are sometimes drawn to building "cathedrals of complexity that aren't so easy to change," he said, speaking in a podcast for maintainable.fm, a series produced by Ruby on Rails consultancy Planet Argon.

Software, he said, should be "simple and disposable and easy to change." Some problems are genuinely complex, but in general, if a developer finds a "clever solution" which goes beyond the standard documented way in a framework such as Laravel or Ruby on Rails, "that would be like a smell."

A code smell -- for the uninitiated in the The Reg readership -- is a term developers use for code that works but may cause problems at a later date. Otwell described himself as a "pretty average programmer" but reckons many others are the same, solving basic problems as quickly and efficiently as they can.

"I'm still teaching at Princeton," 83-year-old Brian Kernighan recently told an audience at New Jersey's InfoAge Science and History Museums.

And last month the video was uploaded to YouTube, a new article points out, "showing that his talk ended with a unique question-and-answer session that turned almost historic..." "Do you think there's any sort of merit to Rust replacing C?" one audience member asked... "Or is this just a huge hype bubble that's waiting to die down...?"

'"I have written only one Rust program, so you should take all of this with a giant grain of salt," he said. "And I found it a — pain... I just couldn't grok the mechanisms that were required to do memory safety, in a program where memory wasn't even an issue!" Speaking of Rust, Kernighan said "The support mechanism that went with it — this notion of crates and barrels and things like that — was just incomprehensibly big and slow. And the compiler was slow, the code that came out was slow..."

All in all, Kernighan had had a bad experience. "When I tried to figure out what was going on, the language had changed since the last time somebody had posted a description! And so it took days to write a program which in other languages would take maybe five minutes..." It was his one and only experience with the language, so Kernighan acknowledged that when it comes to Rust "I'm probably unduly cynical. "But I'm — I don't think it's gonna replace C right away, anyway."
Kernighan was also asked about NixOS and HolyC — but his formative experiences remain rooted in Bell Labs starts in the 1970s, where he remembers it was "great fun to hang out with these people."

And he acknowledged that the descendants of Unix now power nearly every cellphone. "I find it intriguing... And I also find it kind of irritating that underneath there is a system that I could do things with — but I can't get at it!"


Kernighan answered questions from Slashdot readers in 2009 and again in 2015...

"From a side project in Amsterdam to powering AI at the world's biggest companies — this is the story of Python," says the description of a new 84-minute documentary.

Long-time Slashdot reader destinyland writes: It traces Python all the way back to its origins in Amsterdam back in 1991. (Although the first time Guido van Rossum showed his new language to a co-worker, they'd typed one line of code just to prove they could crash Python's first interpreter.) The language slowly spread after van Rossum released it on Usenet — split across 21 separate posts — and Robin Friedrich, a NASA aerospace engineer, remembers using Python to build flight simulations for the Space Shuttle. (Friedrich says in the documentary he also attended Guido's first in-person U.S. workshop in 1994, and "I still have the t-shirt...")

Dropbox's CEO/founder Drew Houston describes what it was like being one of the first companies to use Python to build a company reaching millions of users. (Another success story was YouTube, which was built by a small team using Python before being acquired by Google). Anaconda co-founder Travis Oliphant remembers Python's popularity increasing even more thanks to the data science/macine learning community. But the documentary also includes the controversial move to Python 3 (which broke compatability with earlier versions). Though ironically, one of the people slogging through a massive code migration ended up being van Rossum himself at his new job at Dropbox. The documentary also includes van Rossum's resignation as "Benevolent Dictator for Life" after approving the walrus operator. (In van Rossum's words, he essentially "rage-quit over this issue.")

But the focus is on Python's community. At one point, various interviewees even take turns reciting passages from the "Zen of Python" — which to this day is still hidden in Python as an import-able library as a kind of Easter Egg.
"It was a massive undertaking", the documentary's director explains in a new interview, describing a full year of interviews. (The article features screenshots from the documentary — including a young Guido van Rossum and the original 1991 email that announced Python to the world.) [Director Bechtle] is part of a group that's filmed documentaries on everything from Kubernetes and Prometheus to Angular, Node.js, and Ruby on Rails... Originally part of the job platform Honeypot, the documentary-makers relaunched in April as Cult.Repo, promising they were "100% independent and more committed than ever to telling the human stories behind technology."
Honeypot's founder Emma Tracey bought back its 272,000-subscriber YouTube channel from Honeypot's new owners, New Work SE, and Cult.Repo now bills itself as "The home of Open Source documentaries."

Over in a thread at Python.org, language creator Guido van Rossum has identified the Python community members in the film's Monty Python-esque poster art. And core developer Hugo van Kemenade notes there's also a video from EuroPython with a 55-minute Q&A about the documentary.

An anonymous reader quotes a report from Ars Technica: Earlier this month, EA announced that players in its Battlefield 6 open beta on PC would have to enable Secure Boot in their Windows OS and BIOS settings. That decision proved controversial among players who weren't able to get the finicky low-level security setting working on their machines and others who were unwilling to allow EA's anti-cheat tools to once again have kernel-level access to their systems. Now, Battlefield 6 technical director Christian Buhl is defending that requirement as something of a necessary evil to combat cheaters, even as he apologizes to any potential players that it has kept away.

"The fact is I wish we didn't have to do things like Secure Boot," Buhl said in an interview with Eurogamer. "It does prevent some players from playing the game. Some people's PCs can't handle it and they can't play: that really sucks. I wish everyone could play the game with low friction and not have to do these sorts of things." Throughout the interview, Buhl admits that even requiring Secure Boot won't completely eradicate cheating in Battlefield 6 long term. Even so, he offered that the Javelin anti-cheat tools enabled by Secure Boot's low-level system access were "some of the strongest tools in our toolbox to stop cheating. Again, nothing makes cheating impossible, but enabling Secure Boot and having kernel-level access makes it so much harder to cheat and so much easier for us to find and stop cheating." [...]

Despite all these justifications for the Secure Boot requirement on EA's part, it hasn't been hard to find people complaining about what they see as an onerous barrier to playing an online shooter. A quick Reddit search turns up dozens of posts complaining about the difficulty of getting Secure Boot on certain PC configurations or expressing discomfort about installing what they consider a "malware rootkit" on their machine. "I want to play this beta but A) I'm worried about bricking my PC. B) I'm worried about giving EA complete access to my machine," one representative Redditor wrote.

An anonymous reader quotes a report from CBS News: They look, move and even smell like the kind of furry Everglades marsh rabbit a Burmese python would love to eat. But these bunnies are robots meant to lure the giant invasive snakes out of their hiding spots. It's the latest effort by the South Florida Water Management District to eliminate as many pythons as possible from the Everglades, where they are decimating native species with their voracious appetites. In Everglades National Park, officials say the snakes have eliminated 95% of small mammals as well as thousands of birds. "Removing them is fairly simple. It's detection. We're having a really hard time finding them," said Mike Kirkland, lead invasive animal biologist for the water district. "They're so well camouflaged in the field."

The water district and University of Florida researchers deployed 120 robot rabbits this summer as an experiment. Previously, there was an effort to use live rabbits as snake lures but that became too expensive and time-consuming, Kirkland said. The robots are simple toy rabbits, but retrofitted to emit heat, a smell and to make natural movements to appear like any other regular rabbit. "They look like a real rabbit," Kirkland said. They are solar powered and can be switched on and off remotely. They are placed in small pens monitored by a video camera that sends out a signal when a python is nearby. "Then I can deploy one of our many contractors to go out and remove the python," Kirkland said. The total cost per robot rabbit is about $4,000, financed by the water district, he added.

A widely used Node.js utility called fast-glob, relied on by thousands of projectsâ"including over 30 U.S. Department of Defense systems -- is maintained solely by a Russian developer linked to Yandex. While there's no evidence of malicious activity, cybersecurity experts warn that the lack of oversight in such critical open-source projects leaves them vulnerable to potential exploitation by state-backed actors. The Register reports: US cybersecurity firm Hunted Labs reported the revelations on Wednesday. The utility in question is fast-glob, which is used to find files and folders that match specific patterns. Its maintainer goes by the handle "mrmlnc", and the Github profile associated with that handle identifies its owner as a Yandex developer named Denis Malinochkin living in a suburb of Moscow. A website associated with that handle also identifies its owner as the same person, as Hunted Labs pointed out.

Hunted Labs told us that it didn't speak to Malinochkin prior to publication of its report today, and that it found no ties between him and any threat actor. According to Hunted Labs, fast-glob is downloaded more than 79 million times a week and is currently used by more than 5,000 public projects in addition to the DoD systems and Node.js container images that include it. That's not to mention private projects that might use it, meaning that the actual number of at-risk projects could be far greater.

While fast-glob has no known CVEs, the utility has deep access to systems that use it, potentially giving Russia a number of attack vectors to exploit. Fast-glob could attack filesystems directly to expose and steal info, launch a DoS or glob-injection attack, include a kill switch to stop downstream software from functioning properly, or inject additional malware, a list Hunted Labs said is hardly exhaustive. [...] Hunted Labs cofounder Haden Smith told The Register that the ties are cause for concern. "Every piece of code written by Russians isn't automatically suspect, but popular packages with no external oversight are ripe for the taking by state or state-backed actors looking to further their aims," Smith told us in an email. "As a whole, the open source community should be paying more attention to this risk and mitigating it." [...]

Hunted Labs said that the simplest solution for the thousands of projects using fast-glob would be for Malinochkin to add additional maintainers and enhance project oversight, as the only other alternative would be for anyone using it to find a suitable replacement. "Open source software doesn't need a CVE to be dangerous," Hunted Labs said of the matter. "It only needs access, obscurity, and complacency," something we've noted before is an ongoing problem for open source projects. This serves as another powerful reminder that knowing who writes your code is just as critical as understanding what the code does," Hunted Labs concluded.

More than 30,000 Python developers from around the world answered questions for the Python Software Foundation's annual survey — and PSF Fellow Michael Kennedy tells the Python community what they've learned in a new blog post. Some highlights: Most still use older Python versions despite benefits of newer releases... Many of us (15%) are running on the very latest released version of Python, but more likely than not, we're using a version a year old or older (83%). [Although less than 1% are using "Python 3.5 or lower".] The survey also indicates that many of us are using Docker and containers to execute our code, which makes this 83% or higher number even more surprising... You simply choose a newer runtime, and your code runs faster. CPython has been extremely good at backward compatibility. There's rarely significant effort involved in upgrading... [He calculates some cloud users are paying up to $420,000 and $5.6M more in compute costs.] If your company realizes you are burning an extra $0.4M-$5M a year because you haven't gotten around to spending the day it takes to upgrade, that'll be a tough conversation...

Rust is how we speed up Python now... The Python Language Summit of 2025 revealed that "Somewhere between one-quarter and one-third of all native code being uploaded to PyPI for new projects uses Rust", indicating that "people are choosing to start new projects using Rust". Looking into the survey results, we see that Rust usage grew from 27% to 33% for binary extensions to Python packages... [The blog post later advises Python developers to learn to read basic Rust, "not to replace Python, but to complement it," since Rust "is becoming increasingly important in the most significant portions of the Python ecosystem."]

PostgreSQL is the king of Python databases, and only it's growing, going from 43% to 49%. That's +14% year over year, which is remarkable for a 28-year-old open-source project... [E]very single database in the top six grew in usage year over year. This is likely another indicator that web development itself is growing again, as discussed above...

[N]early half of the respondents (49%) plan to try AI coding agents in the coming year. Program managers at major tech companies have stated that they almost cannot hire developers who don't embrace agentic AI. The productive delta between those using it and those who avoid it is simply too great (estimated at about 30% greater productivity with AI).
It's their eighth annual survey (conducted in collaboration with JetBrains last October and November). But even though Python is 34 years old, it's still evolving. "In just the past few months, we have seen two new high-performance typing tools released," notes the blog post. (The ty and Pyrefly typecheckers — both written in Rust.) And Python 3.14 will be the first version of Python to completely support free-threaded Python... Just last week, the steering council and core developers officially accepted this as a permanent part of the language and runtime... Developers and data scientists will have to think more carefully about threaded code with locks, race conditions, and the performance benefits that come with it. Package maintainers, especially those with native code extensions, may have to rewrite some of their code to support free-threaded Python so they themselves do not enter race conditions and deadlocks.

There is a massive upside to this as well. I'm currently writing this on the cheapest Apple Mac Mini M4. This computer comes with 10 CPU cores. That means until this change manifests in Python, the maximum performance I can get out of a single Python process is 10% of what my machine is actually capable of. Once free-threaded Python is fully part of the ecosystem, I should get much closer to maximum capacity with a standard Python program using threading and the async and await keywords.
Some other notable findings from the survey:

• Data science is now over half of all Python. This year, 51% of all surveyed Python developers are involved in data exploration and processing, with pandas and NumPy being the tools most commonly used for this.

• Exactly 50% of respondents have less than two years of professional coding experience! And 39% have less than two years of experience with Python (even in hobbyist or educational settings)...

• "The survey tells us that one-third of devs contributed to open source. This manifests primarily as code and documentation/tutorial additions."

Davis Lu, a former Eaton Corporation developer, has been sentenced to four years in prison for sabotaging his ex-employer's Windows network with malware and a custom kill switch that locked out thousands of employees once his account was disabled. The attack caused significant operational disruption and financial losses, with Lu also attempting to cover his tracks by deleting data and researching privilege escalation techniques. BleepingComputer reports: After a corporate restructuring and subsequent demotion in 2018, the DOJ says that Lu retaliated by embedding malicious code throughout the company's Windows production environment. The malicious code included an infinite Java thread loop designed to overwhelm servers and crash production systems. Lu also created a kill switch named "IsDLEnabledinAD" ("Is Davis Lu enabled in Active Directory") that would automatically lock all users out of their accounts if his account was disabled in Active Directory. When his employment was terminated on September 9, 2019, and his account disabled, the kill switch activated, causing thousands of users to be locked out of their systems.

"The defendant breached his employer's trust by using his access and technical knowledge to sabotage company networks, wreaking havoc and causing hundreds of thousands of dollars in losses for a U.S. company," said Acting Assistant Attorney General Matthew R. Galeotti. When he was instructed to return his laptop, Lu reportedly deleted encrypted data from his device. Investigators later discovered search queries on the device researching how to elevate privileges, hide processes, and quickly delete files. Lu was found guilty earlier this year of intentionally causing damage to protected computers. After his four-year sentence, Lu will also serve three years of supervised release following his prison term.

Last month, Python "reached the highest ranking a programming language ever had in the TIOBE index," according to TIOBE CEO Paul Jansen.

"We thought Python couldn't grow any further, but AI code assistants let Python take yet another step forward." According to recent studies of Stanford University (Yegor Denisov-Blanch), AI code assistants such as Microsoft Copilot, Cursor or Google Gemini Code Assist are 20% more effective if used for popular programming languages. The reason for this is obvious: there is more code for these languages available to train the underlying models. This trend is visible in the TIOBE index as well, where we see a consolidation of languages at the top. Why would you start to learn a new obscure language for which no AI assistance is available? This is the modern way of saying that you don't want to learn a new language that is hardly documented and/or has too few libraries that can help you.
TIOBE's "Programming Community Index" attempts to calculate the popularity of languages using the number of skilled engineers, courses, and third-party vendors. It nows gives Python a 26.14% rating, which TechRepublic notes "is well ahead of the next two programming languages on this month's leaderboard: C++ is at 9.18% and C is 9.03%." But the first top six languages haven't changed since last year...

1. Python
2. C++
3. C
4. Java
5. C#
6. JavaScript

Since August of 2024 SQL has dropped from its #7 rank down to #12 (meaning Visual Basic and Go each rise up one rank from their position a year ago, into the #7 and #8 positions).

In the last year Perl has risen from the #25 position to #9, beating out Delphi/Oracle Pascal at #10, and Fortran at #11 (last year's #10). TIOBE CEO Jansen "told TechRepublic in an email that many people were asking why Perl was becoming more popular, but he didn't have a definitive answer. He said he double-checked the underlying data and found the increase to be accurate, though the reason for the shift remains unclear."

DeepSeek's development of its next-gen R2 AI model was severely delayed after months of failed training attempts on Huawei's Ascend chips, which suffered from unstable hardware, slow interconnects, and immature software. The Register reports: Following the industry rattling launch of DeepSeek R1 earlier this year, the Chinese AI darling faced pressure from government authorities to train the model's successor on Huawei's homegrown silicon, three unnamed sources have told the Financial Times. But after months of work and the help of an entire team of Huawei engineers, unstable chips, glacial interconnects, and immature software proved insurmountable for DeepSeek, which was apparently unable to complete a single successful training run. The failure, along with challenges with data labeling, ultimately delayed the release of DeepSeek R2 as the company started anew, using Nvidia's H20 GPUs instead. The company has reportedly relegated Huawei's Ascend accelerators to inference duty.