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

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

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

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

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

Anthropic researcher Nicholas Carlini set 16 instances of Claude Opus 4.6 loose on a shared codebase over two weeks to build a C compiler from scratch, and the AI agents produced a 100,000-line Rust-based compiler capable of building a bootable Linux 6.9 kernel on x86, ARM and RISC-V architectures.

The project ran through nearly 2,000 Claude Code sessions and cost about $20,000 in API fees. Each instance operated inside its own Docker container, independently claiming tasks via lock files and pushing completed code to a shared Git repository. No orchestration agent directed traffic. The compiler achieved a 99% pass rate on the GCC torture test suite and can compile major open source projects including PostgreSQL, SQLite, Redis, FFmpeg and Doom. But it lacks a 16-bit x86 backend and calls out to GCC for that step, its assembler and linker remain buggy, and it produces less efficient code than GCC running with all optimizations disabled.

Carlini also invested significant effort building test harnesses and feedback systems to keep the agents productive, and the model hit a practical ceiling at around 100,000 lines as bug fixes and new features frequently broke existing functionality.

After more than 30 years of development, GNU gettext finally "crossed the symbolic 'v1.0' milestone," according to Phoronix's Michael Larabel. "GNU gettext 1.0 brings PO file handling improvements, a new 'po-fetch' program to fetch translated PO files from a translation project's site on the Internet, new 'msgpre' and 'spit' pre-translation programs, and Ocaml and Rust programming language improvements." From the report: With this v1.0 release in 2026, the "msgpre" and "spit" programs do involve.... Large Language Models (LLMs) in the era of AI: "Two new programs, 'msgpre' and 'spit', are provided, that implement machine translation through a locally installed Large Language Model (LLM). 'msgpre' applies to an entire PO file, 'spit' to a single message."

And when dealing with LLMs, added documentation warns users to look out for the licensing of the LLM in the spirit of free software. More details on the GNU gettext 1.0 changes via the NEWS file. GNU gettext 1.0 can be downloaded from GNU.org.

Richard Stallman spoke Friday at Atlanta's Georgia Institute of Technology, continuing his activism for free software while also addressing today's new technologies.

Speaking about AI, Stallman warned that "nowadays, people often use the term artificial intelligence for things that aren't intelligent at all..." He makes a point of calling large language models "generators" because "They generate text and they don't understand really what that text means." (And they also make mistakes "without batting a virtual eyelash. So you can't trust anything that they generate.") Stallman says "Every time you call them AI, you are endorsing the claim that they are intelligent and they're not. So let's let's refuse to do that."

"So I've come up with the term Pretend Intelligence. We could call it PI. And if we start saying this more often, we might help overcome this marketing hype campaign that wants people to trust those systems, and trust their lives and all their activities to the control of those systems and the big companies that develop and control them."

"By the way, as far as I can tell, none of them is free software."

When it comes to today's cars, Stallman says they contain "malicious functionalities... Cars should not be connected. They should not upload anything." (He adds that "I am hoping to find a skilled mechanic to work with me in a project to make disconnected cars.")

And later Stallman calls the smartphone "an Orwellian tracking and surveillance device," saying he refuses to own one. (An advantage of free software is that it allows the removal of malicious functionalities.)

Stallman spoke for about 53 minutes — but then answered questions for nearly 90 minutes longer. Here's some of the highlights...

After widespread backlash over its 2022 decision to remove JPEG-XL support, Google has quietly restored the image format in the latest Chrome/Chromium codebase. Phoronix reports: Back in December they merged jxl-rs as a pure Rust-based JPEG-XL image decoder from the official libjxl organization. At the end of December they did more JPEG-XL plumbing with the enums and build flags for the support. Now as of yesterday they wired up the JXL decoder! The jxl-rs-powered JPEG-XL image decoding is gated by the enable_jxl_decoder build flag but it's enabled by default.

Gentoo Linux posted its 2025 project retrospective this week. Some interesting details: Mostly because of the continuous attempts to force Copilot usage for our repositories, Gentoo currently considers and plans the migration of our repository mirrors and pull request contributions to Codeberg. Codeberg is a site based on Forgejo, maintained by a non-profit organization, and located in Berlin, Germany. Gentoo continues to host its own primary git, bugs, etc infrastructure and has no plans to change that...

We now publish weekly Gentoo images for Windows Subsystem for Linux (WSL), based on the amd64 stages, see our mirrors. While these images are not present in the Microsoft store yet, that's something we intend to fix soon...

Given the unfortunate fracturing of the GnuPG / OpenPGP / LibrePGP ecosystem due to competing standards, we now provide an alternatives mechanism to choose the system gpg provider and ease compatibility testing...

We have added a bootstrap path for Rust from C++ using Mutabah's Rust compiler mrustc, which alleviates the need for pre-built binaries and makes it significantly easier to support more configurations. Similarly, Ada and D support in gcc now have clean bootstrap paths, which makes enabling these in the compiler as easy as switching the useflags on gcc and running emerge.
Other interesting statistics for the year:

• Gentoo currently consists of 31,663 ebuilds for 19,174 different packages.
• For amd64 (x86-64), there are 89 GBytes of binary packages available on the mirrors.
• Gentoo each week builds 154 distinct installation stages for different processor architectures and system configurations, with an overwhelming part of these fully up-to-date.
• The number of commits to the main ::gentoo repository has remained at an overall high level in 2025, with a slight decrease from 123,942 to 112,927.
• The number of commits by external contributors was 9,396, now across 377 unique external authors.

Thanks to long-time Slashdot reader Heraklit for sharing the 2025 retrospective.

For a quarter century, the TIOBE Index has attempted to rank the popularity of programming languages by the number of search engine results they bring up — and this week they had an announcement.

Over the last year the language showing the largest increase in its share of TIOBE's results was C#.

TIOBE founder/CEO Paul Jansen looks back at how C++ evolved: From a language-design perspective, C# has often been an early adopter of new trends among mainstream languages. At the same time, it successfully made two major paradigm shifts: from Windows-only to cross-platform, and from Microsoft-owned to open source. C# has consistently evolved at the right moment.

For many years now, there has been a direct battle between Java and C# for dominance in the business software market. I always assumed Java would eventually prevail, but after all this time the contest remains undecided. It is an open question whether Java — with its verbose, boilerplate-heavy style and Oracle ownership — can continue to keep C# at bay.
While C# remains stuck in the same #5 position it was in a year ago, its share of TIOBE's results rose 2.94% — the largest increase of the 100 languages in their rankngs.

But TIOBE's CEO notes that his rankings for the top 10 highest-scoring languages delivered "some interesting movements" in 2025: C and C++ swapped positions. [C rose to the #2 position — behind Python — while C++ dropped from #2 to the #4 rank that C held in January of 2025]. Although C++ is evolving faster than ever, some of its more radical changes — such as the modules concept — have yet to see widespread industry adoption. Meanwhile, C remains simple, fast, and extremely well suited to the ever-growing market of small embedded systems. Even Rust has struggled to penetrate this space, despite reaching an all-time high of position #13 this month.

So who were the other winners of 2025, besides C#? Perl made a surprising comeback, jumping from position #32 to #11 and re-entering the top 20. Another language returning to the top 10 is R, driven largely by continued growth in data science and statistical computing.

Of course, where there are winners, there are also losers. Go appears to have permanently lost its place in the top 10 during 2025. The same seems true for Ruby, which fell out of the top 20 and is unlikely to return anytime soon.

What can we expect from 2026? I have a long history of making incorrect predictions, but I suspect that TypeScript will finally break into the top 20. Additionally, Zig, which climbed from position #61 to #42 in 2025, looks like a strong candidate to enter the TIOBE top 30.
Here's how TIOBE estimated the 10 most popularity programming languages at the end of 2025

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

Microsoft has denied any plans to rewrite Windows 11 using AI and Rust after a LinkedIn post from one of its top-level engineers sparked a wave of online backlash by claiming the company's goal was to "eliminate every line of C and C++ from Microsoft by 2030."

Galen Hunt, a principal software engineer responsible for several large-scale research projects at Microsoft, made the claim in what was originally a hiring post for his team. His original wording described a "North Star" of "1 engineer, 1 month, 1 million lines of code" and outlined a strategy to "combine AI and Algorithms to rewrite Microsoft's largest codebases." The repeated use of "our" in the post led many to interpret it as an official company direction rather than a personal research ambition.

Frank X. Shaw, Microsoft's head of communications, told Windows Latest that the company has no such plans. Hunt subsequently edited his LinkedIn post to clarify that "Windows is NOT being rewritten in Rust with AI" and that his team's work is a research project focused on building technology to enable language-to-language migration. He characterized the reaction as "speculative reading between the lines."

theodp writes: We all mix pictures, emojis, and text freely in our communications. So why not in our code? That's the premise of "Fun With Python and Emoji: What Might Adding Pictures to Text Programming Languages Look Like?" (two-image Bluesky explainer; full slides), which takes a look at what mixing emoji with Python and SQL might look like. A GitHub repo includes a Google Colab-ready Python notebook proof of concept that does rudimentary emoji-to-text translation via an IPython input transformer.

So, in the Golden Age of AI -- some 60+ years after Kenneth Iverson introduced the chock-full-of-symbols APL -- are valid technical reasons still keeping symbols and pictures out of code, or is their absence more of a programming dogma thing?

Microsoft plans to eliminate all C and C++ code across its major codebases by 2030, replacing it with Rust using AI-assisted, large-scale refactoring. "My goal is to eliminate every line of C and C++ from Microsoft by 2030," Microsoft Distinguished Engineer Galen Hunt writes in a post on LinkedIn. "Our strategy is to combine AI and Algorithms to rewrite Microsoft's largest codebases. Our North Star is '1 engineer, 1 month, 1 million lines of code.' To accomplish this previously unimaginable task, we've built a powerful code processing infrastructure. Our algorithmic infrastructure creates a scalable graph over source code at scale. Our AI processing infrastructure then enables us to apply AI agents, guided by algorithms, to make code modifications at scale. The core of this infrastructure is already operating at scale on problems such as code understanding."

Hunt says he's looking to hire a Principal Software Engineer to help with this effort. "The purpose of this Principal Software Engineer role is to help us evolve and augment our infrastructure to enable translating Microsoft's largest C and C++ systems to Rust," writes Hunt. "A critical requirement for this role is experience building production quality systems-level code in Rust -- preferably at least 3 years of experience writing systems-level code in Rust. Compiler, database, or OS implementation experience is highly desired. While compiler implementation experience is not required to apply, the willingness to acquire that experience in our team is required."

The team authoring the Rust 2025 Vision Doc interviewed Rust developers to find out what they liked about the language — and have now issued three recommendations "to help Rust continue to scale across domains and usage levels."

— Enumerate and describe Rust's design goals and integrate them into our processes, helping to ensure they are observed by future language designers and the broader ecosystem.

— Double down on extensibility, introducing the ability for crates to influence the develop experience and the compilation pipeline.

— Help users to navigate the crates.io ecosystem and enable smoother interop

The real "empowering magic" of Rust arises from achieving a number of different attributes all at once — reliability, efficiency, low-level control, supportiveness, and so forth. It would be valuable to have a canonical list of those values that we could collectively refer to as a community and that we could use when evaluating RFCs or other proposed designs... We recommend creating an RFC that defines the goals we are shooting for as we work on Rust... One insight from our research is that we don't need to define which values are "most important". We've seen that for Rust to truly work, it must achieveallthe factors at once...

We recommenddoubling down on extensibilityas a core strategy. Rust's extensibility — traits, macros, operator overloading — has been key to its versatility. But that extensibility is currently concentrated in certain areas: the type system and early-stage proc macros. We should expand it to coversupportive interfaces(better diagnostics and guidance from crates) andcompilation workflow(letting crates integrate at more stages of the build process)... Doubling down on extensibility will not only make current Rust easier to use, it will enable and support Rust's use in new domains. Safety Critical applications in particular require a host of custom lints and tooling to support the associated standards. Compiler extensibility allows Rust to support those niche needs in a more general way.

We recommend finding ways to help users navigate the crates.io ecosystem... [F]inding which crates to use presents a real obstacle when people are getting started. The Rust org maintains a carefully neutral stance, which is good, but also means that people don't have anywhere to go for advice on a good "starter set" crates... Part of the solution is enabling better interop between libraries.

Longtime Linux developer Greg Kroah-Hartman announced that the Linux kernel has received its first CVE tied to Rust code. Phoronix reports: This first CVE (CVE-2025-68260) for Rust code in the Linux kernel pertains to the Android Binder rewrite in Rust. There is a race condition that can occur due to some noted unsafe Rust code. That code can lead to memory corruption of the previous/next pointers and in turn cause a crash. This CVE for the possible system crash is for Linux 6.18 and newer since the introduction of the Rust Binder driver. At least though it's just a possible system crash and not any more serious system compromise with remote code execution or other more severe issues.

The R programming language "is sometimes frowned upon by 'traditional' software engineers," says the CEO of software quality services vendor Tiobe, "due to its unconventional syntax and limited scalability for large production systems." But he says it "continues to thrive at universities and in research-driven industries, and "for domain experts, it remains a powerful and elegant tool."

Yet it's now gaining more popularity as statistics and large-scale data visualization become important (a trend he also sees reflected in the rise of Wolfram/Mathematica). That's according to December's edition of his TIOBE Index, which attempts to rank the popularity of programming languages based on search-engine results for courses, third-party vendors, and skilled engineers. InfoWorld explains: In the December 2025 index, published December 7, R ranks 10th with a 1.96% rating. R has cracked the Tiobe index's top 10 before, such as in April 2020 and July 2020, but not in recent years. The rival Pypl Popularity of Programming Language Index, meanwhile, has R ranked fifth this month with a 5.84% share. "Programming language R is known for fitting statisticians and data scientists like a glove," said Paul Jansen, CEO of software quality services vendor Tiobe, in a bulletin accompanying the December index...

Although data science rival Python has eclipsed R in terms of general adoption, Jansen said R has carved out a solid and enduring niche, excelling at rapid experimentation, statistical modeling, and exploratory data analysis. "We have seen many Tiobe index top 10 entrants rising and falling," Jansen wrote. "It will be interesting to see whether R can maintain its current position."
"Python remains ahead at 23.64%," notes TechRepublic, "while the familiar chase group behind it holds steady for the moment. The real movement comes deeper in the list, where SQL edges upward, R rises to the top 10, and Delphi/Object Pascal slips away... SQLclimbs from tenth to eighth at 2.10%, adding a small +0.11% that's enough to move it upward in a tightly packed section of the table. Perl holds ninth at 1.97%, strengthened by a +1.33% gain that extends its late-year resurgence."

It's interesting to see how TIOBE's ranking compare with PYPL's (which ranks languages based solely on how often language tutorials are searched on Google):

TIOBE	PYPL
Python	Python
C	C/C++
C++	Objective-C
Java	Java
C#	R
JavaScript	JavaScript
Visual Basic	Swift
SQL	C#
Perl	PHP
R	Rust

Despite their different methodologies, both lists put Python at #1, Java at #5, and JavaScript at #7.

This week System76 launched the first stable release of its Rust-based COSMIC desktop environment. Announced in 2021, it's designed for all GNU/Linux distributions — and it shipping with Pop!_OS 24.04 LTS (based on Ubuntu 24.04 LTS).

An anonymous reader shared this report from 9to5Linux: Previous Pop!_OS releases used a version of the COSMIC desktop that was based on the GNOME desktop environment. However, System76 wanted to create a new desktop environment from scratch while keeping the same familiar interface and user experience built for efficiency and fun. This means that some GNOME apps have been replaced by COSMIC apps, including COSMIC Files instead of Nautilus (Files), COSMIC Terminal instead of GNOME Terminal, COSMIC Text Editor instead of GNOME Text Editor, and COSMIC Media Player instead of Totem (Video Player).

Also, the Pop!_Shop graphical package manager used in previous Pop!_OS releases has now been replaced by a new app called COSMIC Store.
"If you're ambitious enough, or maybe just crazy enough, there eventually comes a time when you realize you've reached the limits of current potential, and must create something completely new if you're to go further..." explains System76 founder/CEO Carl Richell: For twenty years we have shipped Linux computers. For seven years we've built the Pop!_OS Linux distribution. Three years ago it became clear we had reached the limit of our current potential and had to create something new. Today, we break through that limit with the release of Pop!_OS 24.04 LTS with the COSMIC Desktop Environment. Today is special not only in that it's the culmination of over three years of work, but even more so in that System76 has built a complete desktop environment for the open source community... I hope you love what we've built for you. Now go out there and create. Push the limits, make incredible things, and have fun doing it!

Steven J. Vaughan-Nichols files this report from Tokyo: At the invitation-only Linux Kernel Maintainers Summit here, the top Linux maintainers decided, as Jonathan Corbet, Linux kernel developer, put it, "The consensus among the assembled developers is that Rust in the kernel is no longer experimental — it is now a core part of the kernel and is here to stay. So the 'experimental' tag will be coming off." As Linux kernel maintainer Steven Rosted told me, "There was zero pushback."

This has been a long time coming. This shift caps five years of sometimes-fierce debate over whether the memory-safe language belonged alongside C at the heart of the world's most widely deployed open source operating system... It all began when Alex Gaynor and Geoffrey Thomas at the 2019 Linux Security Summit said that about two-thirds of Linux kernel vulnerabilities come from memory safety issues. Rust, in theory, could avoid these by using Rust's inherently safer application programming interfaces (API)... In those early days, the plan was not to rewrite Linux in Rust; it still isn't, but to adopt it selectively where it can provide the most security benefit without destabilizing mature C code. In short, new drivers, subsystems, and helper libraries would be the first targets...

Despite the fuss, more and more programs were ported to Rust. By April 2025, the Linux kernel contained about 34 million lines of C code, with only 25 thousand lines written in Rust. At the same time, more and more drivers and higher-level utilities were being written in Rust. For instance, the Debian Linux distro developers announced that going forward, Rust would be a required dependency in its foundational Advanced Package Tool (APT).

This change doesn't mean everyone will need to use Rust. C is not going anywhere. Still, as several maintainers told me, they expect to see many more drivers being written in Rust. In particular, Rust looks especially attractive for "leaf" drivers (network, storage, NVMe, etc.), where the Rust-for-Linux bindings expose safe wrappers over kernel C APIs. Nevertheless, for would-be kernel and systems programmers, Rust's new status in Linux hints at a career path that blends deep understanding of C with fluency in Rust's safety guarantees. This combination may define the next generation of low-level development work.

From the blog 9to5Linux: Linux kernel 6.18 is now available for download, as announced today by Linus Torvalds himself, featuring enhanced hardware support through new and updated drivers, improvements to file systems and networking, and more. Highlights of Linux 6.18 include the removal of the Bcachefs file system, support for the Rust Binder driver, a new dm-pcache device-mapper target to enable persistent memory as a cache for slower block devices, and a new microcode= command-line option to control the microcode loader's behavior on x86 platforms. Linux kernel 6.18 also extends the support for file handles to kernel namespaces, implements initial 'block size > page size' support for the Btrfs file system, adds PTW feature detection on new hardware for LoongArch KVM, and adds support for running the kernel as a guest on FreeBSD's Bhyve hypervisor.

Linus Torvalds is "fairly positive" about vibe coding as a way for people to get computers to do things they otherwise could not. The Linux kernel maintainer made the comments during an interview at the Linux Foundation Open Source Summit in Seoul earlier this month. But he cautioned that vibe coding would be a "horrible, horrible idea from a maintenance standpoint" for production code.

Torvalds told Dirk Hohndel, head of open source at Verizon, that computers have become more complicated than when he learned to code by typing in programs from computer magazines. He said vibe coding offers a path into computing for newcomers. The kernel maintainer is not using AI-assisted coding himself. He said his role has shifted from rejecting new ideas to sometimes pushing for them against opposition from longstanding maintainers who "kind of get stuck in a rut."

Rust is "actually becoming a real part of the kernel instead of being this experimental thing," he said. Torvalds said AI crawlers have been "very disruptive to a lot of our infrastructure" because they gather data from kernel.org source code. Kernel maintainers receive bugs and security notices that are "made up by people who misuse AI," though the problem is smaller than for other projects such as curl.

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

Slashdot readers Tablizer and fjo3 share news that an AI-generated country song has topped the U.S. sales chart for the first time this week. ABC News reports: The new country tune, "Walk my Walk" by Breaking Rust, recently hit No. 1 on Billboard's Country Digital Song Sales chart, reaching over 3 million streams on Spotify in less than a month. That success has garnered mixed reactions from music fans and artists alike, particularly on TikTok, where hundreds of users have posted videos addressing the tune and others discussing the music in the comments.

Billboard has acknowledged Breaking Rust is an AI act and said it is one of at least six to chart in the past few months alone. "Ultimately, this feels like an experiment to see just how far something like this can go and what happens in the future and in other disciplines of art as well," senior entertainment reporter Kelley L. Carter told ABC News. "AI artists won't require things that a real human artist will require, and once companies start considering it and looking at bottom lines, I think that's when artists should rightly be concerned about it," she added.

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.