To commemorate the tenth anniversary of the 1.0 release of the Rust language, version 1.87.0 was announced live today at the 10 Years of Rust celebration in Utrecht, Netherlands. Notable changes include the addition of anonymous pipes to the standard library and the ability for inline assembly (asm!) to jump to labeled blocks within Rust code.
make it more suitable for current kernels". He told the assembled storage and filesystem developers that the progress on the proposal has stalled, but that it was the basis for further work in various areas, so he hoped to find a way to move forward with it.
The Tor project has announced the oniux utility which provides Tor network isolation, using Linux namespaces, for third-party applications.
Namespaces are a powerful feature that gives us the ability to isolate Tor network access of an arbitrary application. We put each application in a network namespace that doesn't provide access to system-wide network interfaces (such as eth0), and instead provides a custom network interface onion0.
This allows us to isolate an arbitrary application over Tor in the most secure way possible software-wise, namely by relying on a security primitive offered by the operating system kernel. Unlike SOCKS, the application cannot accidentally leak data by failing to make some connection via the configured SOCKS, which may happen due to a mistake by the developer.
The Tor project cautions that oniux is considered experimental as the software it depends on, such as Arti and onionmasq, are still new.
At the Linux Application Summit (LAS) in April, Sebastian Wick said that, by many metrics, Flatpak is doing great. The Flatpak application-packaging format is popular with upstream developers, and with many users. More and more applications are being published in the Flathub application store, and the format is even being adopted by Linux distributions like Fedora. However, he worried that work on the Flatpak project itself had stagnated, and that there were too few developers able to review and merge code beyond basic maintenance.
Version 5.5.0 of the Podman container-management tool has been released. Notable features include the addition of a podman machine cp command to copy files into a running Podman VM, a podman artifact extract command to copy contents of an OCI artifact to disk, and a --mount=artifact option to mount OCI artifacts into containers. See the release announcement for a full list of improvements and bug fixes.
From servers in a data center to desktop computers, many devices communicating on a network will eventually have to filter network traffic, whether it's for security or performance reasons. As a result, this is a domain where a lot of work is put into improving performance: a tiny performance improvement can have considerable gains. Bpfilter is a project that allows for packet filtering to easily be done with BPF, which can be faster than other mechanisms.
BPF arenas are areas of memory where the verifier can safely relax its checking of pointers, allowing programmers to write arbitrary data structures in BPF. Emil Tsalapatis reported on how his team has used arenas in writing sched_ext schedulers at the 2025 Linux Storage, Filesystem, Memory-Management, and BPF Summit. His biggest complaint was about the fact that kernel pointers can't be stored in BPF arenas — something that the BPF developers hope to address, although there are some implementation problems that must be sorted out first.
The SUSE Security Team has published an article detailing several security issues it has uncovered with GNU Screen. This includes a local root exploit when Screen is shipped setuid-root, as it is in some Linux and BSD distributions. The security team also reports problems in coordinating disclosure with the upstream Screen project.
We are not satisfied with how this coordinated disclosure developed, and we will try to be more attentive to such problematic situations early on in the future. This experience also sheds light on the overall situation of Screen upstream. It looks like it suffers from a lack of manpower and expertise, which is worrying for such a widespread open source utility. We hope this publication can help to draw attention to this and to improve this situation in the future.
The article includes a table of operating systems, screen versions, and which vulnerabilities they may be affected by.
The Guix project has announced that it is migrating all of its Git repositories, as well as bug tracking and patch tracking, from Savannah to the Codeberg Git forge.
As a user, the main change is that your channels.scm configuration files, if they refer to the git.savannah.gnu.org URL, should be changed to refer to https://codeberg.org/guix/guix.git once migration is complete. But don't worry: guix pull will tell you if/when you need to update your config files and the old URL will remain a mirror for at least a year anyway.
The motivation for the move, which is spelled out in a Guix
Consensus Document (GCD), is to improve the contribution
experience and improve quality assurance efforts. Migration of Git
repositories should be completed by June 7, though they will
continue to be mirrored on Savannah until "at least
" May 2026. LWN covered Guix in February 2024.
The announcement
of the openSUSE Leap 16.0 beta contained something of a
surprise—along with the usual set of changes and updates, it
informed the community of the retirement of "the traditional YaST
stack
" from Leap. The YaST ("Yet another Setup Tool")
installation and configuration utility has been a core part of the
openSUSE distribution since its inception
in 2005, and part of SUSE Linux since 1996. It will not, immediately,
be removed from the openSUSE Tumbleweed rolling-release
distribution, but its future is uncertain and its fate is up to the larger
community to decide.
Everything still looks fairly normal - we've got a bit more commits than we did in rc5, which isn't the trend I want to see as the release progresses, but the difference isn't all that big and it feels more like just the normal noise in timing fluctuation in pull requests of fixes than any real signal.So I won't worry about it. We've got another two weeks to go in the normal release schedule, and it still feels like everything is on track.
Lance Albertson writes that the Oregon State University Open Source Lab has been funded for the next year, following his announcement in April that the future of OSL was in jeopardy. OSL is now focusing on becoming self-sustainable long term.
The recent support was amazing for our immediate team needs. But for the OSL to thrive long-term, we need a sustainable financial foundation. This is crucial, as the university expects units like ours to become self-sufficient beyond this current year.
So, our big focus this next year is locking in ongoing support – think annualized pledges, different kinds of regular income, and other recurring help. This is vital, especially with potential new data center costs and hardware needs. Getting this right means we can stop worrying about short-term funding and plan for the future: investing in our tech and people, growing our awesome student programs, and serving the FOSS community. We're looking for partners, big and small, who get why foundational open source infrastructure matters and want to help us build this sustainable future together.
Connexion