System76 Launches First Stable Release of COSMIC Desktop and Pop!_OS 24.04 LTS
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!
Read more of this story at Slashdot.
Categories: Linux
Rust in Linux's Kernel 'is No Longer Experimental'
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.
Read more of this story at Slashdot.
Categories: Linux
HDMI Forum Continues To Block HDMI 2.1 For Linux, Valve Says
New submitter emangwiro shares a report: The HDMI Forum, responsible for the HDMI specification, continues to stonewall open source. Valve's Steam Machine theoretically supports HDMI 2.1, but the mini-PC is software-limited to HDMI 2.0. As a result, more than 60 frames per second at 4K resolution are only possible with limitations. In a statement to Ars Technica, a Valve spokesperson confirmed that HDMI 2.1 support is "still a work-in-progress on the software side." "We've been working on trying to unblock things there."
The Steam Machine uses an AMD Ryzen APU with a Radeon graphics unit. Valve strictly adheres to open-source drivers, but the HDMI Forum is unwilling to disclose the 2.1 specification. According to Valve, they have validated the HDMI 2.1 hardware under Windows to ensure basic functionality.
Read more of this story at Slashdot.
Categories: Linux
OpenAI Joins the Linux Foundation's New Agentic AI Foundation
OpenAI, alongside Anthropic and Block, have launched the Agentic AI Foundation under the Linux Foundation, describing it as a neutral home for standards as agentic systems move into real production. It may sound well-meaning, but Slashdot reader and NERDS.xyz founder BrianFagioli isn't buying the narrative. In a report for NERDS.xyz, Fagioli writes: Instead of opening models, training data, or anything that would meaningfully shift power toward the community, the companies involved are donating lightweight artifacts like AGENTS.md, MCP, and goose. They're useful, but they're also the safest, least threatening pieces of their ecosystem to "open." From where I sit, it looks like a strategic attempt to lock in influence over emerging standards before truly open projects get a chance to define the space. I see the entire move as smoke and mirrors.
With regulators paying closer attention and developer trust slipping, creating a Linux Foundation directed fund gives these companies convenient cover to say they're being transparent and collaborative. But nothing about this structure forces them to share anything substantial, and nothing about it changes the closed nature of their core technology. To me, it looks like Big Tech trying to set the rules of the game early, using the language of openness without actually embracing it. Slashdot readers have seen this pattern before, and this one feels no different.
Read more of this story at Slashdot.
Categories: Linux
