Cursor has launched Origin, a GitHub-style code hosting platform built directly into its AI coding environment. The company is initially positioning Origin as a low-risk layer on top of GitHub, keeping GitHub as the "source of truth," but the launch landed just as a major GitHub outage highlighted growing concerns about reliability in the age of AI-generated code. VentureBeat reports: Cursor began rolling out Origin, its own code hosting platform, to paid users on Monday morning. Roughly three and a half hours later, GitHub's status page lit up with what became a six-hour-and-forty-two-minute global degradation -- error rates near 20% across pull requests, issues and the API, and near 50% on archive and raw file downloads, according to GitHub's incident log. Enterprise single sign-on went down with it: SAML, OIDC, SCIM provisioning and Team Sync all failed. So did Copilot. The developer internet did what the developer internet does. "You can now host your repos in Cursor Origin and deploy to Vercel via Cursor Origin which is itself hosted on Vercel," Vercel chief executive Guillermo Rauch posted on X. "And unlike GitHub, it's online [smile emoji]" Asked why he was smiling, Rauch replied: "trying to make light of the situation. We ourselves are stuck because of github rn!" Matt Palmer, who works at Cursor, quote-tweeted his own company's launch with the day's best line: "We were going to ship this earlier, but GitHub was down." A GitHub outage, in other words, delayed the launch of a GitHub competitor. Product launches get locked weeks in advance, and no evidence suggests Cursor timed this one. But the coincidence did the company an enormous favor, because it dramatized the argument Origin exists to make. For eighteen years, choosing where to host your team's source code has been the least interesting decision an engineering organization makes. Cursor is betting that AI agents have made it interesting again -- and for technical decision makers, that is the real news here. Not a new product, but a new procurement question with a governance problem attached.

Read more of this story at Slashdot.

"GitHub and the Python Package Index (PyPI) have introduced new policies meant to boost supply chain security," reports SecurityWeek, "by preventing the fast propagation of poisoned package versions and the poisoning of old and long-stable releases." To prevent the fast delivery of malicious code through the immediate fetching of brand-new releases, GitHub has introduced a Dependabot cooldown, where the automation tool waits for at least three days after a release has been published before opening a pull request. "Waiting a few days before adopting a new release gives maintainers, security researchers, and automated scanners time to spot a malicious version and get it pulled before it ever reaches your pull requests," GitHub explains. The three-day cooldown only applies to non-security version bumps, and the behavior can be modified through the configuration option in the dependabot.yml. "Three days as the default balances two goals: it pushes you past the window where most of these attacks live, and it doesn't hold your dependencies back longer than necessary," GitHub notes. And the Python Package Index (PyPI) "now rejects new files being uploaded to releases that are older than 14 days," according to a recernt blog post from the Python Software Foundation's security developer-in-residence Seth Larson: This restriction was put in place to prevent old and long-stable releases from being poisoned in case publishing tokens or workflows of PyPI projects were compromised... The discussion of this behavior began during PEP 740 (Digital Attestations) back in January 2024. The discussion was restarted in March 2026 after the popular packages LiteLLM and Telnyx were compromised. These packages were compromised due to a "mutable reference" in these projects' usage of the Trivy GitHub Action... To quantify how disruptive this change would be to existing workflows, the PyPI database was queried for projects that have published new files to old releases... [O]nly 56 projects of 15,000 had published a [Python] 3.14-compatible wheel more than 14 days after a release was available. This topic was brought to the Packaging Summit at PyCon US 2026 by PyPI Safety & Security Engineer, Mike Fiedler. The rough consensus of the discussion was that the summit attendees thought it was "acceptable to require users to bump to the next version" to support new Python versions. With the data and consensus in hand, Seth moved forward with a patch to reject new files on old releases which was merged July 8th, 2026.

Read more of this story at Slashdot.

Longtime Slashdot reader AmiMoJo shares a report from Hackaday: Community-led open source project hosting site Codeberg has formally announced that projects whose code is largely or fully machine-generated through LLMs and other 'AI' tools will no longer be welcome. This follows on the heels of a similar ban on cryptocurrency-related projects. The community vote was on two issues, the first being the notion that scraping of project code for the use in LLMs should be forbidden, which was a motion that easily passed. The second motion was on disallowing projects whose code was substantially generated by LLMs like Claude, OpenAI Codex, and similar. This motion passed with 358 in favor versus 144 against. In the earlier linked blog post the reasoning behind especially this second issue is expanded upon, covering not only "license whitewashing," but also the direct and indirect hardware costs, with the expanding 'AI' datacenter hyperscaling having massively increased hardware costs for Codeberg over the past years, as the costs have been largely externalized. Also covered is the aspect of these LLM-based tools destroying the OSS community, which is something that is backed up by recent studies.

Read more of this story at Slashdot.

ZDNet reports on June's Open Source Summit India 2026 in Mumbai, where Linux stable kernel maintainer Greg Kroah-Hartman gave a talk titled "Rust and Linux: How the Rust Language is Going to Help Linux Succeed." Kroah-Hartman said in his keynote that "the [Linux] kernel is moving toward Rust. Git is moving toward Rust. Lots of projects are starting to move toward Rust." He didn't always feel that way. Kroah-Hartman added, "A number of years ago, when a friend of mine said, 'Ah, you got to try this new language. It's called Rust.' I was like, 'What? No, C is great.' His friend continued, "'No, no, no! It makes programming fun again.' I'm like, 'Nah, programming is fun in C.' He was right. I should have done it then. Rust is actually fun. It makes programming fun. It takes a lot of stuff away from having to worry about the compiler, which can fix a lot of your problems for you, and it makes code a little bit better." So, Kroah-Hartman has moved from being a Rust skeptic to one of its strongest champions inside the kernel. He now regards Rust as a permanent part of Linux, not an experiment. His case is straightforward: Rust's ownership and type system can eliminate most of the "stupid little tiny things" that dominate kernel Common Vulnerabilities and Exposures (CVEs), while making life easier for overworked maintainers. "Rust," in short, "makes my life so much easier...." In India, he said Linux sees "about 13 CVEs a day" and has been running at "almost nine changes an hour" for a decade or more. Most of those vulnerabilities, he argued, are not exotic attacks but simple C mistakes — unchecked pointers, forgotten unlocks, and sloppy cleanup paths: "This is what we're fixing 13 times a day. Small, trivial, little bugs like this all the time.... I've seen every CVE the kernel has done in the past 25 years. I think 80% would be gone, just because they would be caught by Rust." The remaining 20% are the logic bugs he'd prefer to focus on...." Moreover, Rust is becoming the default for new work in key subsystems. "New drivers for some subsystems are only going to be accepted in Rust...." he said. Binder, the Android IPC mechanism at the heart of billions of devices, now has parallel C and Rust implementations in the kernel. The C version "will go away soon," leaving the Rust version "as the bedrock of all Android devices going forward."

Read more of this story at Slashdot.

"Git and email are the two really only tools I use," Linus Torvalds said at Open Source Summit India 2026. But ZDNet reports that he also shared his thoughts on Rust, C, and patch-checking tools: "I use Google as a way to look things up." He added, "I'm unusual; most of the other maintainers end up using many more tools, and I think a lot of them are starting to use AI tools for patch checking," while he "works at a higher level. I work with people, not tools." When asked about Rust both in Git and the kernel, he pushed back against hype: "I'm not sure Rust is going to take over the world. I still think Rust is very interesting, [but] I still find C to be a much simpler tool." Torvalds continued, "I'm much more excited about all the tools we have for verification of C," including "automated patch verification tools" and "automated email checking tools for patches like Sashiko." Summing up, Torvalds told the Mumbai audience: "I'm more of a hack-and-slash kind of person, and I still like the raw and simple power of C, and I don't think that's going to change." Torvalds also warned against overestimating Rust's benefits: "Rust fixes a few easy bugs that you can make in C, but it does not fix the logic errors, right? It does not think for you, and when you write incorrect code, the language does not matter. The end result will be incorrect." On mixed C/Rust code bases, he pointed out that guarantees are limited: "The guarantees that Rust give you only apply in the Rust-only parts of your code base, and wherever you interact with C code, all bets are off," with most Rust code in Linux talking to "core kernel C code" that is "much better quality... because that code has been tested in every single environment." At the same time, Torvalds pointed out, "some of our big and more high-profile bugs in the kernel lately have been logic errors" rather than the kind of memory errors Rust prevents. "It was just bad programming, which sadly happens even in carefully maintained subsystems and important kernels that are supposed to be very secure."

Read more of this story at Slashdot.

It was more than two years ago that TypeScript's creator Anders Hejlsberg announced plans to rewrite its compiler in Go. This week Microsoft announced its first Go-based release candidate for TypeScript 7.0, reports InfoWorld: TypeScript 7.0 is often about 10 times faster than TypeScript 6.0, Microsoft said, thanks to native code speed and shared memory parallelism... Unlike TypeScript 6.0, TypeScript 7.0 performs many steps in parallel, including parsing, type checking, and emitting, Microsoft said. Some of these steps, such as parsing and emitting, can mostly be done independently across files. For that reason, parallelization automatically scales well with larger codebases with relatively little overhead. However, not every step in a TypeScript build is easily parallelizable, Microsoft said. Microsoft plans to release TypeScript 7.0 within the next month, the article points out, but developers can try the new compiler by installing it from the typescript package on npm: npm install -D typescript@rc

Read more of this story at Slashdot.