The GitHub Secure Open Source Fund launched this week with an initial commitment of $1.25 million, reports TechCrunch, using "capital from contributors including American Express, 1Password, Shopify, Stripe, and GitHub's own parent company Microsoft." GitHub briefly teased the new initiative at its annual GitHub Universe developer conference last month, but Tuesday it announced full details and formally opened the program for applicants, which will be reviewed "on a rolling basis" through the closing date of January 7, 2025, with programming and funding starting shortly after...

Tuesday's news builds on a number of previous GitHub initiatives designed to support project maintainers that work on key components of critical software, including GitHub Sponsors which landed in 2019 (and which is powering the new fund), but more directly the GitHub Accelerator program that launched its first cohort last year — the GitHub Secure Open Source Fund is essentially an extension of that.

"We're trying to acknowledge the fact that we're the home of open source, ultimately, and we have an obligation to help ensure that open source can continue to thrive and have the support that it needs," GitHub Chief Operating Officer Kyle Daigle told TechCrunch in an interview. Qualifying projects can be pretty much any project that has an open source license, but of course GitHub will be looking at those that need the funds most — so Kubernetes can hold fire with its application. "We're looking for the outsized impact, which tends to be big projects with few maintainers that we all rely on," Daigle said.

The sum of $1.25 million might sound like a reasonable amount, but it will be split across 125 projects, which means just $10,000 each — better than nothing, for sure, but a drop in the ocean on the grand scheme of things. However, Daigle is quick to stress that money is only part of the prize here — as with the initial accelerator program, maintainers embark on a three-week program, which includes mentorship, certification, education workshops, and ongoing access to GitHub tools.
From GitHub's announcement: Since introducing support for organizations through GitHub Sponsors, more than 5,800 organizations, including Microsoft and Stripe, have invested in maintainers and projects on GitHub, up nearly 40% YoY. Cumulatively, the platform has unlocked over $60 million in funding for maintainers to help them spend more time working on their projects.

But we know we're just scratching the surface when it comes to organizations and corporate support of open source. This summer, we partnered with the Linux Foundation and researchers from Laboratory for Innovation Science at Harvard (LISH) to learn more about the state of open source funding today. Diving in, we assessed organizations funding behaviors, potential misalignments, and opportunities to improve. In the report launched today, we found:


- Responding organizations annually invest $1.7 billion in open source, which can be extrapolated to estimate that approximately $7.7 billion is invested across the entire open source ecosystem annually.

- 86% of investment is in the form of contribution labor by employees and contractors working for the funding organization, with the remaining 14% being direct financial contributions.

- Organizations generally know how and where they contribute (65%) but lack specific clarity of their contributions (38%).

- Security efforts focus on bugs and maintenance; only a few (6%) said comprehensive security audits are a priority.


We all stand to benefit from unlocking more funding for open source. By tackling problems like open source security as an ecosystem, we believe we can help create more available funding and resources that are vital to the sustainability of open source. Not every open source project or maintainer has access to funding and training for security. That's why we created a fund that everyone potentially eligible can apply for...

This is the beginning of a journey into helping find ways to secure open source. On its own, it's not the answer, but we are confident it will help. We will be monitoring the impact of these investments and share what we learn as we go.

The Rust community has "recognized the unsafety of Rust (if used incorrectly)," according to a blog post by Amazon Web Services.

So now AWS and the Rust Foundation are "crowdsourcing an effort to verify the Rust standard library," according to an article at DevClass.com, "by setting out a series of challenges for devs and offering financial rewards for solutions..." Rust includes ways to bypass its safety guarantees though, with the use of the "unsafe" keyword... The issue AWS highlights is that even if developers use only safe code, most applications still depend on the Rust standard library. AWS states that there are approximately 7.5K unsafe functions in the Rust Standard Library and notes that 57 "soundness issues" and 20 CVEs (Common Vulnerabilities and Exposures) have been reported in the last three years. [28% of the soundness issues were discovered in 2024.]

Marking a function as unsafe does not mean it is vulnerable, only that Rust does not guarantee its safety. AWS plans to reduce the risk by using tools and techniques for formal verification of key library code, but believes that "a single team would be unable to make significant inroads" for reasons including the lack of a verification mechanism in the Rust ecosystem and what it calls the "unknowns of scalable verification." The plan therefore is to turn this over to the community, by posing challenges and rewarding developers for solutions.... A GitHub repository provides a fork of the Rust code and includes a set of challenges, currently 13 of them... The Rust Foundation says that there is a financial reward tied to each challenge, and that the "challenge rewards committee is responsible for reviewing activity and dispensing rewards." How much will be paid though is not stated.

Despite the wide admiration for Rust, there is no formal specification for the language, an issue which impacts formal verification efforts.
Thanks to Slashdot reader sean-it-all for sharing the news.

Microsoft-owned GitHub published a blog post asking "Does GitHub Copilot improve code quality? Here's what the data says."

Its first paragraph includes statistics from past studies — that GitHub Copilot has helped developers code up to 55% faster, leaving 88% of developers feeling more "in the flow" and 85% feeling more confident in their code.

But does it improve code quality? [W]e recruited 202 [Python] developers with at least five years of experience. Half were randomly assigned GitHub Copilot access and the other half were instructed not to use any AI tools... We then evaluated the code with unit tests and with an expert review conducted by developers.

Our findings overall show that code authored with GitHub Copilot has increased functionality and improved readability, is of better quality, and receives higher approval rates... Developers with GitHub Copilot access had a 56% greater likelihood of passing all 10 unit tests in the study, indicating that GitHub Copilot helps developers write more functional code by a wide margin. In blind reviews, code written with GitHub Copilot had significantly fewer code readability errors, allowing developers to write 13.6% more lines of code, on average, without encountering readability problems. Readability improved by 3.62%, reliability by 2.94%, maintainability by 2.47%, and conciseness by 4.16%. All numbers were statistically significant... Developers were 5% more likely to approve code written with GitHub Copilot, meaning that such code is ready to be merged sooner, speeding up the time to fix bugs or deploy new features.
"While GitHub's reports have been positive, a few others haven't," reports Visual Studio magazine: For example, a recent study from Uplevel Data Labs said, "Developers with Copilot access saw a significantly higher bug rate while their issue throughput remained consistent."

And earlier this year a "Coding on Copilot" whitepaper from GitClear said, "We find disconcerting trends for maintainability. Code churn — the percentage of lines that are reverted or updated less than two weeks after being authored — is projected to double in 2024 compared to its 2021, pre-AI baseline. We further find that the percentage of 'added code' and 'copy/pasted code' is increasing in proportion to 'updated,' 'deleted,' and 'moved 'code. In this regard, AI-generated code resembles an itinerant contributor, prone to violate the DRY-ness [don't repeat yourself] of the repos visited."

Instead of focusing on chatbots, a new study reveals an automated way to breach LLM-driven robots "with 100 percent success," according to IEEE Spectrum. "By circumventing safety guardrails, researchers could manipulate self-driving systems into colliding with pedestrians and robot dogs into hunting for harmful places to detonate bombs..." [The researchers] have developed RoboPAIR, an algorithm designed to attack any LLM-controlled robot. In experiments with three different robotic systems — the Go2; the wheeled ChatGPT-powered Clearpath Robotics Jackal; and Nvidia's open-source Dolphins LLM self-driving vehicle simulator. They found that RoboPAIR needed just days to achieve a 100 percent jailbreak rate against all three systems... RoboPAIR uses an attacker LLM to feed prompts to a target LLM. The attacker examines the responses from its target and adjusts its prompts until these commands can bypass the target's safety filters. RoboPAIR was equipped with the target robot's application programming interface (API) so that the attacker could format its prompts in a way that its target could execute as code. The scientists also added a "judge" LLM to RoboPAIR to ensure the attacker was generating prompts the target could actually perform given physical limitations, such as specific obstacles in the environment...

One finding the scientists found concerning was how jailbroken LLMs often went beyond complying with malicious prompts by actively offering suggestions. For example, when asked to locate weapons, a jailbroken robot described how common objects like desks and chairs could be used to bludgeon people.

The researchers stressed that prior to the public release of their work, they shared their findings with the manufacturers of the robots they studied, as well as leading AI companies. They also noted they are not suggesting that researchers stop using LLMs for robotics... "Strong defenses for malicious use-cases can only be designed after first identifying the strongest possible attacks," Robey says. He hopes their work "will lead to robust defenses for robots against jailbreaking attacks."
The article includes a reaction from Hakki Sevil, associate professor of intelligent systems and robotics at the University of West Florida. He concludes that the "lack of understanding of context of consequences" among even advanced LLMs "leads to the importance of human oversight in sensitive environments, especially in environments where safety is crucial." But a long-term solution could be LLMs with "situational awareness" that understand broader intent.

"Although developing context-aware LLM is challenging, it can be done by extensive, interdisciplinary future research combining AI, ethics, and behavioral modeling..."

Thanks to long-time Slashdot reader DesertNomad for sharing the article.

Longtime Slashdot reader theodp writes: Past corporate-sponsored Hour of Code tutorials for the nation's schoolchildren have blurred the lines between coding lessons and product infomercials. So too is the case again with this year's newly-announced Hour of Code 2024 flagship tutorials, which include Microsoft Minecraft, Amazon Music, and Transformers One movie-themed intros to coding. The press release announcing the tutorials from tech-backed nonprofit Code.org, which organizes the Hour of Code and counts Microsoft and Amazon as $30+ million donors, boasts of its "decade of partnership with [Microsoft] Minecraft this year, reaching more than 300 million sessions of Minecraft Hour of Code since 2015!"

Interestingly, The Transformers (Paramount Pictures, which released Transformers One in the U.S., is a $25,000+ Code.org donor) is cited as one of the OG's of children's Saturday morning cartoon advertising (aka 30-minute commercials) that prompted the Children's Television Act (CTA) of 1990, an act of Congress that ordered the FCC to put in place regulations to protect children from advertising. Throughout the 1980s, Action for Children's Television (ACT) criticized children's television programs that "blur(red) the distinction between program content and commercial speech."

Slashdot readers damn_registrars and GFS666 share the news of the passing of Thomas E. Kurtz, co-inventor of the BASIC programming language back in the 1960s. He was 96. Hackaday reports: The origins of BASIC lie in the Dartmouth Timesharing System, like similar timesharing operating systems of the day, designed to allow the resources of a single computer to be shared across many terminals. In this case the computer was at Dartmouth College, and BASIC was designed to be a language with which software could be written by average students who perhaps didn't have a computing background. In the decade that followed it proved ideal for the new microcomputers, and few were the home computers of the era which didn't boot into some form of BASIC interpreter. Kurtz continued his work as a distinguished academic and educator until his retirement in 1993, but throughout he remained as the guiding hand of the language.

An anonymous reader quotes a report from TechCrunch: For the past couple of years, the startup has been iterating on a brand-new CRM platform and making everything available on GitHub under a permissive AGPLv3 license. While Twenty doesn't have all the features that you can find in Salesforce [comparison], the company is slowly building a community of CRM and open source enthusiasts around it, with more than 300 contributors in the last year and 20,000 stars on GitHub. [...] Twenty is trying to build a flexible platform that can be tweaked to every company's needs and that can serve as a basis for other tools and use cases. Each entry in a CRM is an object. It can be a standard, pre-defined object like a person or a company. But customers can also create their own custom objects.

If you're a conference organizer, you can create a conference object. If you're a restaurant chain manager, you can create a restaurant object. As you may have guessed, Twenty also lets you create custom fields for each object. This way, it's easier to capture and compare data across multiple entries. This customer data can be viewed in Twenty directly in list or Kanban views. People can sort and filter entries, add tasks and notes, all the usual CRM stuff. But data in Twenty can also be reused with GraphQL and REST APIs. And that's how you can extend Twenty beyond its CRM roots. Eventually, Twenty hopes there will be an active ecosystem of developers working on extensions and plugins to build a proper alternative to the Salesforce product suite. But we're not there yet. "Building a CRM is a daunting task, especially for us because of the way we've chosen to do it. We're building a platform, and we're not taking any shortcut. In fact, we still need to work on workflows, on automation and more," [said Twenty co-founder and CEO Felix Malfait]. "People often don't understand why Salesforce is so big, so powerful," Malfait said. Salesforce's platform utilizes a flexible data model -- a programming language called Apex to execute code on Salesforce's servers and a front-end customization framework.

"So when you have these three bricks you can store data, do logic on the back end, and display the result as you like," Malfait said. "It means that you can do everything. And that's what we want to enable in the long term."

The goal? "Make C++ and Rust interoperability easily accessible and approachable to the widest possible audience." And the Rust Foundation's "Interop Initiative" is specifically focused on the goal of interoperability "within the same executable," through either inline embedding that allows "integrated compilation", or foreign function interfaces.

To that end, a statement addressing "the challenges and opportunities in C++ and Rust interoperability" was announced this week by the Rust Foundation. Pointing out that the "Interop Initiative" was launched in February 2024 with a $1M contribution from Google, it now "proposes a collaborative, problem-space approach engaging key stakeholders from both language communities.

"Rather than prescribing specific solutions, this problem statement serves as a foundation for community input and participation in shaping both the strategic direction and tactical implementation of improved C++/Rust interoperability."

Their official problem statement outlines three "key strategic approaches."

- Improve existing tools and address tactical issues to reduce interoperability friction and risk in the short term.

- Build consensus around long-term goals requiring changes to Rust itself and develop the tactical approaches to begin pursuing them.

- Engage with the C++ community and committee to improve the quality of interoperation for both languages to help realize the mutual goals of safety and performance.

And it argues that interoperability "is essential to pursuing safety and performance which is maintainable and scalable." A significant amount of development has gone into libraries to facilitate interoperability with both C and C++, but from the language and compiler level, the situation remains largely unchanged from the early days of Rust. As the desire to integrate Rust into more C++ codebases increases, the value of making C++/Rust interoperability safer, easier, and more efficient is rapidly increasing. While each language takes a different overall approach, both view safety as an essential concern in modern systems. Both Rust and C++ have language- and standard-library-level facilities to improve safety in seemingly compatible ways, but significant benefits are lost when transiting the foreign function interfaces (FFI) boundary using the C ABI...

The consequence of this increased cost to interoperate means both C++ and Rust codebases are less able to access valuable code that already exists in the other language, and the ability to transition system components from one language to another is reduced outside of existing C-like interface boundaries. Ultimately, this reduction in freedom leads to worse outcomes for all users since technologists are less free to choose the most effective solutions.

The Tiobe index tries to track the popularity of programming languages by counting the number of search results for the language's name followed by the word "programming" (on 25 different search engines). And this month there were some surprises...

By TIOBE's reckoning, compared to a year ago PHP has now fallen from #7 to #12, while Delphi/Object Pascal shot up five spots from #16 to #11. In that same year, Fortran jumped from #12 to #8 — while both Visual Basic and SQL dropped down a single rank. Toward the top of the list, C actually fell from the #2 spot over the last 12 months to the #4 spot.

And Go just reached the #7 rank on the TIOBE's ranking of programming language popularity — "an all time high for Go," according to TIOBE CEO Paul Jansen. In this month's note, he explains what he thinks is unusual about this — starting by saying that Go programs are both fast, and easy in many ways — easy to deploy, easy to learn, and easy to understand. Python for instance is easy to learn but not fast, and deployment for larger Python programs is fragile due to dependencies on all kind of versioned libraries in the environment.

If compared to Rust for instance (another contender for a top position), Go is a tiny bit slower, but the Go programs are much easier to understand. The next hurdle for Go in the TIOBE index is JavaScript at position #6. That will be a tough one to pass. JavaScript is ubiquitous in software development, although for larger JavaScript systems we see a shift to TypeScript nowadays.
"If annual trends continue this way, Go will bypass JavaScript within 3 years," TIOBE's CEO predicts. (Adding "Let's see what the future has in store for Go...") Although the Go team actually has specific plans for the future, according to a blog post this week celebrating Go's 15th anniversary: We're working on making Go better for AI — and AI better for Go — by enhancing Go's capabilities in AI infrastructure, applications, and developer assistance. Go is a great language for building production systems, and we want it to be a great language for building production AI systems, too... For AI applications, we will continue building out first-class support for Go in popular AI SDKs, including LangChainGo and Genkit. And from its very beginning, Go aimed to improve the end-to-end software engineering process, so naturally we're looking at bringing the latest tools and techniques from AI to bear on reducing developer toil, leaving more time for the fun stuff — like actually programming!
TIOBE's top 10 programming language rankings for the month of November:

1. Python
2. C++
3. Java
4. C
5. C#
6. JavaScript
7. Go
8. Fortran
9. Visual Basic
10. SQL

Google's transistion to Safe Coding and memory-safe languages "will take multiple years," according to a post on Google's security blog. So "we're also retrofitting secure-by-design principles to our existing C++ codebase wherever possible," a process which includes "working towards bringing spatial memory safety into as many of our C++ codebases as possible, including Chrome and the monolithic codebase powering our services." We've begun by enabling hardened libc++, which adds bounds checking to standard C++ data structures, eliminating a significant class of spatial safety bugs. While C++ will not become fully memory-safe, these improvements reduce risk as discussed in more detail in our perspective on memory safety, leading to more reliable and secure software... It's also worth noting that similar hardening is available in other C++ standard libraries, such as libstdc++. Building on the successful deployment of hardened libc++ in Chrome in 2022, we've now made it default across our server-side production systems. This improves spatial memory safety across our services, including key performance-critical components of products like Search, Gmail, Drive, YouTube, and Maps... The performance impact of these changes was surprisingly low, despite Google's modern C++ codebase making heavy use of libc++. Hardening libc++ resulted in an average 0.30% performance impact across our services (yes, only a third of a percent) ...

In just a few months since enabling hardened libc++ by default, we've already seen benefits. Hardened libc++ has already disrupted an internal red team exercise and would have prevented another one that happened before we enabled hardening, demonstrating its effectiveness in thwarting exploits. The safety checks have uncovered over 1,000 bugs, and would prevent 1,000 to 2,000 new bugs yearly at our current rate of C++ development...

The process of identifying and fixing bugs uncovered by hardened libc++ led to a 30% reduction in our baseline segmentation fault rate across production, indicating improved code reliability and quality. Beyond crashes, the checks also caught errors that would have otherwise manifested as unpredictable behavior or data corruption... Hardened libc++ enabled us to identify and fix multiple bugs that had been lurking in our code for more than a decade. The checks transform many difficult-to-diagnose memory corruptions into immediate and easily debuggable errors, saving developers valuable time and effort.
The post notes that they're also working on "making it easier to interoperate with memory-safe languages. Migrating our C++ to Safe Buffers shrinks the gap between the languages, which simplifies interoperability and potentially even an eventual automated translation."

Longtime Slashdot reader DaPhil writes: I taught myself to code at 12 years old in the 90s and I've always liked the back-and-forth with the runtime to achieve the right result. I recently got back from other roles to code again, and when starting a new project last year, I decided to give the new "AI assistants" a go.

My initial surprise at the quality and the speed you can achieve when using ChatGPT and/or Copilot when coding turned sour over the months, as I realized that all the joy I felt about trying to get the result I want -- slowly improving my code by (slowly) thinking, checking the results against the runtime, and finally achieving success -- is, well, gone. What I do now is type English sentences in increasingly desperate attempts to get ChatGPT to output what I want (or provide snippets to Copilot to get the right autocompletion), which -- as they are pretty much black boxes -- is frustrating and non-linear: it either "just works," or it doesn't. There is no measure of progress. In a way, having Copilot in the IDE was even worse, since it often disrupts my thinking when suggesting completions.

I've since disabled Copilot. Interestingly, I myself now feel somehow "disabled" without it in the IDE; however, the abstention has given me back the ability to sit back and think, and through that, the joy of programming. Still, it feels like I'm now somehow an ex-drug addict always on the verge of a relapse. I was wondering if any of you felt the same, or if I'm just... old.

Phoronix's Michael Larabel reports: The OpenMP Architecture Review Board announced from SC24 that OpenMP 6.0 is now available as a major upgrade to the OpenMP specification for multi-process programming within C / C++ / Fortran. A big emphasis on OpenMP 6.0 is making it easier for developers to embrace. OpenMP 6.0 aims to make it easier to support parallel programming in new applications, easier to adapt to new use-cases, and more fine-grained developer control.

OpenMP 6.0 simplifies task programming with support for task execution by free-agent threads, allowing for recording of task graphs for efficient replay, and other improvements. OpenMP 6.0 also brings support for array syntax applications, better control over memory allocations and accessibility, easier writing of asynchronous data transfers, and other improvements for enhanced device support / offloading. There is also easier programming of loop transformations, support for induction, support for C23 / Fortran 2023 / C++23, grater user control of storage resources and memory spaces, and other improvements.

An anonymous reader quotes a report from Bloomberg: OpenAI is preparing to launch a new artificial intelligence agent codenamed "Operator" that can use a computer to take actions on a person's behalf (Warning: source may be paywalled; alternative source), such as writing code or booking travel [...]. In a staff meeting on Wednesday, OpenAI's leadership announced plans to release the tool in January as a research preview and through the company's application programming interface for developers [...]. The one nearest completion will be a general-purpose tool that executes tasks in a web browser, one of the people said.

OpenAI Chief Executive Officer Sam Altman hinted at the shift to agents in response to a question last month during an Ask Me Anything session on Reddit. "We will have better and better models," Altman wrote. "But I think the thing that will feel like the next giant breakthrough will be agents." The move to release an agentic AI tool also comes as OpenAI and its competitors have seen diminishing returns from their costly efforts to develop more advanced AI models.

Mark Rainey: Engineers are currently debugging why the Voyager 1 spacecraft, which is 15 billions miles away, turned off its main radio and switched to a backup radio that hasn't been used in over forty years!

I've had some tricky debugging issues in the past, including finding compiler bugs and debugging code with no debugger that had been burnt into prom packs for terminals, however I have huge admiration for the engineers maintaining the operation of Voyager 1.

Recently they sent a command to the craft that caused it to shut off its main radio transmitter, seemingly in an effort to preserve power and protect from faults. This prompted it to switch over to the backup radio transmitter, that is lower power. Now they have regained communication they are trying to determine the cause on hardware that is nearly 50 years old. Any communication takes days. When you think you have a difficult issue to debug, spare a thought for this team.

Paul Kinlan, who leads the Chrome and the Open Web Developer Relations team at Google, asks and answers the question (with a no.): Frameworks are abstractions over a platform designed for people and teams to accelerate their teams new work and maintenance while improving the consistency and quality of the projects. They also frequently force a certain type of structure and architecture to your code base. This isn't a bad thing, team productivity is an important aspect of any software.

I'm of the belief that software development is entering a radical shift that is currently driven by agents like Replit's and there is a world where a person never actually has to manipulate code directly anymore. As I was making broad and sweeping changes to the functionality of the applications by throwing the Agent a couple of prompts here and there, the software didn't seem to care that there was repetition in the code across multiple views, it didn't care about shared logic, extensibility or inheritability of components... it just implemented what it needed to do and it did it as vanilla as it could.

I was just left wondering if there will be a need for frameworks in the future? Do the architecture patterns we've learnt over the years matter? Will new patterns for software architecture appear that favour LLM management?

Google's head of research Yossi Matias maintains that learning to code remains "as important as ever" despite AI's growing role in software development. While AI tools have reduced coding time for some developers -- and Alphabet CEO Sundar Pichai noting that AI now generates a quarter of all code, Matias stressed that human engineers still review and approve AI-generated code.

The Google executive, who also serves as a company VP, acknowledged that junior professionals have faced challenges gaining experience as AI handles entry-level tasks. Google has launched initiatives to support early-career employees through this transition. Matias compared coding literacy to basic mathematics, arguing it provides crucial understanding of technology regardless of career path.

Nathan Sobo "joined GitHub in late 2011 to build the Atom text editor," according to an online biography, "and he led the Atom team until 2018." Max Brunsfeld joined the Atom team in 2013, and "While driving Atom towards its 1.0 launch during the day, Max spent nights and weekends building Tree-sitter, a blazing-fast and expressive incremental parsing framework that currently powers all code analysis at GitHub."

Last year they teamed up with Antonio Scandurra (another Atom alumnus) to launch a new startup called Zed (which in 2023 raised $10 million, according to TechCrunch). And today the open source blog It's FOSS checks in on their open-source code editor — "Zed Editor". Mainly written in Rust, it supports running in CLI, diagnosing project-wide errors, split panes, and markdown previews: By default, any added content is treated as plain text. I used the language switcher to change it to Rust so that I would get proper syntax highlighting, indentation, error detection, and other useful language-specific functions. The switch highlighted all the Rust elements correctly, and I then focused on Zed Editor's user interface. The overall feel of the editor was minimal, with all the important options being laid out nicely.

[Its status bar] had some interesting panels. The first one I checked was the Terminal Panel, which, as the name suggests, lets you run commands, scripts, and facilitates interaction with system files or processes directly from within the editor. I then moved to the Assistant Panel, which is home to various large language models that can be integrated into Zed Editor. There are options like Anthropic, GitHub Copilot Chat, Ollama, OpenAI, and Google AI... The Zed Editor team has also recently introduced Zed AI in collaboration with Anthropic for assisting with coding, allowing for code generation, advanced context-powered interactions, and more...

The real-time collaboration features on Zed Editor are quite appealing too. To check them out, I had to log in with my GitHub account. After logging in, the Collab Panel opened up, and I could see many channels from the official Zed community. I could chat with others, add collaborators to existing projects, join a call with the option to share my screen and track other collaborators' cursors, add new contacts, and carry out many other collaborative tasks.

One can also use extensions and themes to extend what Zed Editor can do. There are some nice pre-installed themes as well.

"The Rust trademark policy has been updated and a new draft is available to view," announced the Rust Foundation this week.

The last proposed trademark policy (in April of 2023) was criticized by open source advocate Bruce Perens in The Register as "far awry of fair use which is legally permitted." The Rust Foundation says this new version has "incorporated a number of suggestions from the Rust community," in a blog post that summarizes the feedback and enumerates specific ways it's been addressed: 1. We primarily plan to lean on community reports for enforcement and have no intention of spending our limited resources policing the work of small creators.

2. We have removed the non-legal language summary and instead have clarified wording throughout as best we can while keeping the policy valid.

3. The Rust trademark does not cover use of the word "Rust" in general and instead pertains to its use in relevant technical settings.

4. We have updated the logo usage policy. Color modifications are allowed.

5. The non-endorsement rule is about managing perception of official affiliation with the Foundation and Rust Project, and is thus subjective.

6. We removed restrictions on the use of "Rust" and "Cargo" in package names. The crates prefixes "rust-" and "cargo-" are no longer reserved to the Rust Project.

7. We will usually allow the community to use the marks on limited merchandise (more details in the updated draft)....

[T]he central purpose of these updates is to empower all Rustaceans to engage with the Rust language ecosystem more confidently. As a final step in this process, we invite you to review the updated policy and share any blocking concerns you might have... Thank you to everyone who weighed in with helpful suggestions on the initial trademark policy draft we shared. The level of engagement and passion within the Rust community is inspiring to all of us at the Rust Foundation.
The tech news site Heise Online writes "It is noticeable that the language is much clearer and dispenses with a lot of legal jargon," in a piece which argues the new draft "should calm the waves and create clarity." The new draft is not only formulated more simply, but is also significantly shorter. Some restrictions have been softened in the new rules or have disappeared completely...

Meanwhile, the Foundation has also adapted its logo so that it is clear which logo stands for the programming language and which for the Foundation. The use of the name Rust is explicitly permitted to identify projects that are either written in the programming language or are compatible with it...

Before the new trademark rules come into force, the Rust Foundation is collecting feedback on the current draft. The web form is open until November 20, 2024.

I had the opportunity to interview esteemed programmer Steve Yegge for the SourceForge Podcast to ask him all about AI-powered coding assistants and the future of programming. "We're moving from where you have to write the code to where the LLM will write the code and you're just having a conversation with it about the code," said Yegge. "That is much more accessible to people who are just getting into the industry."

Steve has nearly 30 years of programming experience working at Geoworks, Amazon, Google, Grab and now SourceGraph, working to build out the Cody AI assistant platform. Here's his Wikipedia page. He's not shy about sharing his opinions or predictions for the industry, no matter how difficult it may be for some to hear. "I'm going to make the claim that ... line-oriented programming, which we've done for the last 40, 50 years, ... is going away. It is dying just like assembly language did, and it will be completely dead within five years."

You can watch the episode on YouTube and stream on all major podcast platforms. A transcription of the podcast is available here.

Software engineer David Gomes writes in a blog post: I sometimes need to search for a website that will "convert a PNG to SVG", or "remove page from PDF" or "resize svg". And these apps are... okay. I don't really trust most of them with my data, and also a lot of times they just don't work or have too many ads. So, I've been noticing a trend of people just using AI agents to create full blown apps for these simple use cases.

I decided to try it myself for a "resize SVG" app since I recently had to go through a bunch of websites to do this. So, I pulled up Replit Agent and even though I've used it before, it doesn't cease to amaze me just how insanely good it is. The level of polish on this product is unlike any other AI agent out there right now. It starts off by drawing up a plan and asking you for feedback on that plan. Then, it'll just go to town and try to build the app. But what's super clever about it is that the agent asks you for feedback along the way. Effectively, the Replit Agent guides you, not the other way around (as one might have expected).