Welcome to the LWN.net Weekly Edition for January 8, 2026

This edition contains the following feature content:

• Predictions for the new year: once again, we attempt to predict what will happen in the coming year.
• Reporting from the 2025 Linux Plumbers Conference:
• Lessons from creating a gaming-oriented scheduler: Changwoo Min spoke about what he learned while working on the LAVD scheduler.
• The difficulty of safe path traversal: runc maintainer Aleksa Sarai discussed path-traversal vulnerabilities and encouraged use of the libpathrs library for safe path traversal.
• Questions for the Technical Advisory Board: a Q&A with the TAB.
• An early look at the Graphite 2D graphics editor: an attempt to unify illustration, raster editing, desktop publishing, and animation in one application.
• 2025 Linux and free software timeline: a look back on the year that was.

This week's edition also includes these inner pages:

• Brief items: Brief news items from throughout the community.
• Announcements: Newsletters, conferences, security updates, patches, and more.

Please enjoy this week's edition, and, as always, thank you for supporting LWN.net.

Comments (none posted)

Predictions for the new year

The calendar has flipped over to 2026; a new year has begun. That means the moment we all dread has arrived: it is time for LWN to put out a set of lame predictions for what may happen in the coming year. Needless to say, we do not know any more than anybody else, but that doesn't stop us from making authoritative-sounding pronouncements anyway.

Some of the things that might just happen in 2026 are:

This will be a make-or-break year for the Firefox browser. For years, longtime Firefox users have hung on while Mozilla has pursued random directions, added advertiser-friendly features, and tried repeatedly to jump onto the AI bandwagon. But all those users want is a reliable, standards-compliant browser that gives them control over their web experience and protects their privacy. The result is that Firefox's usage has been declining for years.

Mozilla now has a new CEO who has one last chance to turn things around. A refocused Firefox determined to protect its users from an increasingly hostile web environment could regain users. A Firefox that continues to chase buzzwords or appease advertisers will sink without a trace. The world desperately needs an independent browser project that serves its users; one can only hope that Mozilla rediscovers its old mission to fill that need.

Meanwhile, an overall increase in interest in Linux and free software will be driven by a combination of surveillance concerns, forced upgrades, unwanted AI features, and increasing hardware prices. A lot of forces are coming together to show the virtues of a system that is free, user-centered, and resource-efficient.

The gccrs project will deliver a working Rust compiler this year; it will be usable to build the kernel's Rust code. This ambitious project to bring Rust support to the GCC compiler seemed to languish for years, but has recently picked up its pace. In the coming year, it will begin to be useful, even though the to-do list is likely to remain long.

The availability of gccrs is important because, among other reasons, an increasing number important projects will require Rust to build over the course of the year. The availability of a GCC-based compiler will make that transition easier for many people, especially those working with architectures that the LLVM-based rustc compiler does not support. It is possible, though far from certain, that building the 2026 long-term-support kernel (likely 7.4, to be released on December 20) will require Rust for some use cases.

In 2025, many projects, including distributions, grappled with the question of whether to accept code generated by large language models (LLMs). In 2026, though, distributors will increasingly face the question of whether to ship LLM-based tools and other machine-learning software itself. Many of these tools claim to be open-source software, but the true status of code built around large binary blobs of model data is far from clear.

The Git project's transition away from SHA-1 will make big steps in 2026 as the efforts to switch to SHA-256 by default reach fruition. As the final interoperability pieces fall into place, there will be little reason to use the older hash algorithm for new repositories, and some established ones may make the switch as well.

Whether LLMs will prove useful for large-scale code generation remains unclear, but the use of LLMs for code review will increase sharply in 2026. The creation of new code has not been a limiting factor for much of the free-software community for a long time, but code review is in chronically short supply. It seems that LLMs can be good at finding the kinds of problems that humans often miss, and they do not (yet) get upset about being asked to review version 17 of a patch rather than implementing cool new features. The benefits of the use of these tools seem clear. The risk is that projects will quickly become dependent on proprietary systems that are unsustainable (in both climate and economic senses). If that dependence comes about, the possibility of disruptive rug-pulls will increase as well.

As a related point, it will become clear that attackers are using these systems to find vulnerabilities as they are added to free-software projects. It is hard to imagine a world where people who seek to break into systems would not use a tool like this. Security has always been (among other things) an arms race, and the attackers have a new weapon.

Restrictions on Android app installation will make the non-free nature of Android systems clear. Specifically, the planned restrictions on "sideloading" will create pain for many users. As Eugen Rochko commented: "'Sideloading' is the rentseeker word for 'being able to run software of your choosing on a computing device you purchased'". A platform that denies this ability is not free. This restriction may increase interest in alternatives based on the Android Open Source Project. But the world needs a truly free operating system for mobile devices. Perhaps the LibrePhone project will help us to get there, but do not expect this problem to be solved in 2026.

Distributors will have to rethink what they are creating. In the early days of Linux, a distribution was the source for most interesting software on a system; the rest was typically built from source. The growth in the amount of available software and the emergence of alternative software sources (language-specific repositories and sites like Flathub, for example) has challenged that model. Often, it seems like distributors offer nowhere near enough software, and they are too slow to ship it.

That leads to a situation where distributors consider falling back to a base (perhaps immutable) platform and leaving the task of shipping application software to others. That, however, takes away much of the value that distributions offer for their users. A collection of software that has been selected and built according to a set of consistent policies, with perhaps some user-unfriendly features removed, is not to be let go of lightly. Distributors that leave much of their work to third-repositories may end up losing users to those that hold to their original mission.

The European Cyber Resilience Act (CRA) will start to make itself felt. While the main requirements of the CRA do not apply until the end of 2027, the requirement to report exploited vulnerabilities and serious incidents takes effect in September 2026. By that time, vendors shipping open-source software in their products will need to have mechanisms in place to meet those requirements when vulnerabilities turn up in that software.

Digital sovereignty efforts, in Europe and beyond, will pick up over the year. Even if the tensions that have caused many to question their reliance on US-based companies miraculously disappear, the point that this reliance can be a security risk has been made clear, and it will take years to rebuild trust, if that can be done at all. Free software is the obvious platform on which an independent digital infrastructure can be built, so expect an increase in interest in projects that can help countries increase their independence and control. We can only hope that the rest of the world opts to build platforms that support freedom and privacy, rather than creating its own native versions of the surveillance and control economy.

The desire to give a new shape to the Internet is felt far beyond Europe, of course. The net (and the World Wide Web specifically), as originally conceived, was a widely distributed collection of independent sites. Now it is dominated by a handful of massive companies that appear to be strip-mining what remains for content while steadily increasing their revenue-extraction efforts. Perhaps 2026 will be the year when the early Internet, updated for current times, begins to make a recovery. Efforts like the Resonant Computing Manifesto show the kind of thought that is starting to be heard more widely.

This year may be a turbulent one in which a lot of change becomes possible. If the AI bubble collapses, it may free the industry from its current large-model obsession and allow us to find ways to make some of that technology useful on a smaller, more distributed scale. There are faint signs of political change in the US that, just maybe, will eventually slow the efforts to tear apart the mechanisms of global cooperation. Since global cooperation is what our community depends on, there is reason to hope. We have shown how we can work together across the planet to build something of benefit to all. Maybe, if we are truly lucky, more of that work can truly be to everybody's benefit, and less for a few huge corporations.

Finally, LWN will complete its 28th year at the end of January; we would have never guessed that we would be doing this for so long. Some people are just slow learners. It has been a great ride, and we are far from done. We're looking forward to discovering 2026 with you, and thank you for your support. We will, as always, review these predictions at the end of the year to see just how wrong we were.

Comments (125 posted)

Lessons from creating a gaming-oriented scheduler

At the 2025 Linux Plumbers Conference (LPC), held in Tokyo in mid-December, Changwoo Min led a session on what he has learned while developing the "latency-criticality aware virtual deadline" (LAVD) scheduler, which is aimed at gaming workloads. The session was part of the Gaming on Linux microconference, which is a new entrant into LPC; organizers hope to see it return next year in Prague and, presumably, beyond. LAVD uses the extensible scheduler class (sched_ext) and has the primary goal of minimizing stuttering in games; it is implemented in a combination of BPF and Rust.

Min said that he has been developing LAVD as part of his work at Igalia on SteamOS and the Steam Deck. The name of the scheduler is a bit of a mouthful, but it is focused on making Windows games run better on Linux. SteamOS (and the Steam application for Linux) use Wine and the Proton compatibility layer. Most of the scheduling decision-making code for LAVD is written in BPF, with a thin, Rust-based user-space piece.

Some additional information about sched_ext and LAVD can be found in an article from last year's LPC. In addition, there were sessions on LAVD as part of the sched_ext microconference this year, including one about adapting LAVD to be the default scheduler for Meta's production fleet.

Most of his experience that has shaped LAVD is based on Windows games and their needs on Linux. The session was meant to raise awareness of some missing pieces of tooling that could be used to help better support Linux gaming. He hoped to start some discussion of ways to gather better performance information from games and to reliably benchmark them to improve scheduling.

Gaming workloads

There are two things to target in a scheduler for gaming, he said, performance and energy consumption. Gaming is unique because it has "a widely accepted, universal performance metric, which is frames-per-second" (or FPS). There are two types of FPS measures: average and the "low 1%" or minimum FPS. The average is a measure of application throughput, while the low 1% measures 99th percentile latency, which is what causes stuttering. So the goal is to provide high average FPS while keeping the low 1% as high as possible so that the gamer does not get angry—it is the most important aspect for the gaming experience.

Many gaming devices, such as the Steam Deck, are powered by batteries, so energy efficiency is important. The underlying hardware often uses processors that have a mix of different types of cores (big, medium, and little) with different energy-use characteristics. For games, there are usually multiple tasks, but some of them can be run on the slower, more energy-efficient cores. Most of the tasks are fairly short running, around 1ms, though there are a few that run for 2-3ms or more. There are also tasks that run for less than 100µs, which means there is more flexibility in terms of their task placement, he said.

In his view, the scheduler can make three separate decisions that affect performance. It chooses which task runs first; if latency-critical tasks are delayed, it can lead to a "cascading delay or the UI jank or the stuttering", which affects the user experience. The scheduler also determines how long a task should run; the time slice chosen needs to balance between long enough to benefit from a warm cache, while not so long that tasks monopolize the processor. Beyond that, the scheduler chooses which CPU to use for each task; the cost of making that decision also affects latency and energy efficiency. Quick decisions reduce scheduler overhead, but may increase the other costs because of a bad decision that is made; a problem can also occur if the scheduler overhead gets too high because it is trying to make a better decision.

Understanding gaming workloads is critical to developing scheduling policies that are optimized for games. When he started out, Min was not confident that he could come up with a gaming-optimized scheduler, so he set out to measure the workloads to see if there were some characteristics that were shared, which the scheduler could use. So he developed VaporMark—the name refers to Steam—which analyzes data collected using "perf sched record". "After collecting huge amounts of data, post-processing it for an hour or two, it shows some reports."

He showed a sample VaporMark report (seen above from his slides). It is a useful report, he said, that shows information like the typical run-time duration of each task and can allow determining whether statistically valid predictions can be made about upcoming durations. It provides insight into why and how tasks are being scheduled for the game.

The key finding that came out of his analysis is perhaps somewhat obvious: a single high-level action, such as moving a character on-screen and emitting a sound based on a key-press event, requires that many tasks work together. Some of the tasks are threads in the game process, but others are not because they are in the game engine, kernel, and device drivers; there are often 20 or 30 tasks in a chain that all need to collaborate. Finding tasks with a high waker or wakee frequency and prioritizing them is the basis of the LAVD scheduling policy.

More tools

VaporMark was useful for understanding the high-level properties of the game, but once he finished a prototype of LAVD, he found that it was inadequate for further work. He tried Perfetto, which was better, especially for doing "microscopic analysis to find out the pathological scheduling behaviors". It did not solve his analysis problems, though, perhaps because he is not a Perfetto expert, Min said.

Part of the problem for both VaporMark and Perfetto is that the problems he wants to analyze occur rarely. For example, a game may run smoothly most of the time, but have a latency spike every five minutes or so that results in a drop in the FPS rate. "How should I catch this?" He was not able to find a way to trigger on the problem so that his trace showed what led to it; instead he used brute-force methods of sampling every ten seconds, hoping to catch the problem occurring. "The correlation between the high-level view and the microscopic view is just something missing" in the tool set.

Track co-organizer David Vernet noted that Perfetto does have ways to track more than just CPU time, such as memory use, but that it is sampling-based, so it may not provide all of the details that Min is looking for. Another attendee wondered about tracing the latency of key-press events, which is important to certain types of games, especially those favored by professional gamers. That analysis may require more of a view into the game engine than is available, but he wondered if LAVD had done anything to minimize that latency. Min said that LAVD did not focus on that, but that he thought that its policies would naturally prioritize the tasks involved in key-press handling.

Vernet noted that some games, such as Civilization VI, have CPU-intensive tasks that may need to be handled differently. Some of the workloads where he works (Meta) have similar characteristics and he wondered if Min had done any analysis of the whole chain of tasks from an initial wakeup to the last task completing its work and then using that to derive deadlines and frame rates. Min said that he had not, but that it was an area he wanted to look into; for example, there may be ways to use information from the GPU to help make better CPU-scheduling decisions.

An attendee raised the issue of choosing which CPU to run a wakee on and whether it makes sense to move tasks to other CPUs based on their relationships. Min said that making those decisions is "a pretty tricky thing". He has been looking at the timeline-management aspect of the scheduler, but there are other resources to consider, such as cache locality and memory distance. There is a need for a tool to generate a "more holistic view of the resource contention"; it might be possible to do that with Perfetto, but it still remains to be done.

And benchmarks

Another problem he has encountered while working on the scheduler is that benchmarking games is "super hard". In order to show that a new scheduling policy is better (or worse) than an old one, a "reliably reproducible benchmark is absolutely necessary", but games lack that, unlike other domains, such as databases, that have standard benchmarks. Fortunately, some games, such as Cyberpunk 2077, Far Cry, and Forza Horizon, have an in-game benchmark, which is useful; others, like Counter-Strike, allow replaying recorded game sequences, which also helps.

Unfortunately, it is not clear how representative the results from those games are with respect to other games that lack those abilities; for example, some users have complained that LAVD does not work well with the games using the Unreal engine. Another problem is that games are updated frequently so any data gathered can quickly age out; comparing results before and after a 2GB game update "does not make any sense", he said. The in-game benchmarks sometimes rely on the performance of external resources, such as the game server, as well.

Even when reliable benchmark results are available, it is difficult to correlate observed FPS changes with the scheduler change(s) that caused them. So, microbenchmarks are of interest as well, but most of the ones he has found for schedulers (e.g. stress-ng and hackbench) are focused on stressing schedulers and measuring the scheduling overhead. That is useful, but improving those numbers does not always lead to better game performance.

There are some microbenchmarks that mimic specific workloads; one example is schbench, which is meant to reproduce the scheduling characteristics of production web-server workloads. There is a need for something like that to mimic gaming workloads, he said. Vernet asked how that kind of benchmark might be built; would it use existing game engines or somehow incorporate AAA games? Min said that he was not sure how to approach it; one problem is that the most important games and engines to consider changes based on market share.

One thing that could help is a suite of benchmarks. He noted that CloudSuite provides a set of representative cloud applications packaged into a benchmark suite. A collection of games could perhaps be turned into a "gamesuite" for scheduler testing; it would augment a few microbenchmarks that run for a short time to give quick feedback. The in-game benchmarks often only give the average FPS, "which is useful but not ideal"; they lack the low 1% and minimum FPS information that is also really needed.

André Almeida, who was the other track organizer, suggested using MangoHud to gather more FPS data; Min concurred, but said that MangoHud needs to be carefully configured. When using it in "batch" mode, the logging from MangoHud can interfere with the game, which can cause stuttering. A gamesuite could potentially have a recommended MangoHud configuration along with a set of representative games to run.

Locks

His focus has largely been on Windows games, which use the synchronization primitives of that underlying operating system. For Linux, those are emulated by the Wine layer using futexes, but there is still work to be done. Most of the tasks in a Windows game are short-running and computation-intensive, so it is important to avoid situations where locking prevents a task from quickly completing. That means avoiding lock-holder preemption (or priority inversion)—when a lock holder is scheduled out, but a newly scheduled task needs the lock so it cannot progress. The work that Almeida has been doing to rework the futex API will also help with priority inversion, Min said.

In the kernel, proxy execution seems to him to be the right approach, but it does not help with user-space futexes. LAVD attempts to track tasks and futexes to determine when to provide a longer time slice to a task in order to give it time to release a lock; that is not a complete solution to the problem, however. Meanwhile, Wine is moving to using the ntsync driver, which is designed to better support the Windows NT synchronization primitives. Eventually, ntsync and proxy execution should help alleviate these kinds of problems, he thought.

Almeida noted that, on the fast path, the kernel does not know which task holds a futex, so it does not have that information for making scheduling decisions. He has heard that FreeBSD programs always inform the kernel about the futex owner so that it can avoid priority inversion. The cost of a system call is high, though, so requiring that could be problematic. There was some discussion of other Windows lock types and whether those were supported well in Linux; the upshot seemed to be that those are built on top of the futex interface, so fixing futexes should take of care of most problems for Windows locks—at least for games.

An attendee asked whether LAVD used the same scheduler for all games on the Steam Deck. Min said that LAVD is a single scheduler, though there are some tuning knobs that can be changed with command-line parameters. The attendee wondered if it made sense to consider something like "profile-guided scheduling" where a game's profile could be used to set parameters for the scheduler. For the most part, the profiles would only need to be engine-specific, since most games use an off-the-shelf or internal engine that governs their performance characteristics. Min agreed that it sounded like an interesting approach, but it was not one he has explored.

In a followup question, he wondered about reproducible game testing; if there is no network server involved, are there elements beyond the generation of random numbers that need to be constrained in order to reproduce a game run? Min said that random numbers were the main impediment to determinism for a game, but there are some other factors at play too. If a game runs too fast, it may cause the CPU to overheat and be throttled; that will obviously change the characteristics as well.

The session ended with a bit of discussion about using the WF_SYNC (or WF_CURRENT_CPU) flag to indicate tasks that will return to sleep immediately after waking. That can help the kernel make better scheduling decisions and is used on Android that way. Interested readers may want to consult the YouTube video of the session for the finer details.

[ I would like to thank our travel sponsor, the Linux Foundation, for assistance with my travel to Tokyo for Linux Plumbers Conference. ]

Comments (13 posted)

The difficulty of safe path traversal

Aleksa Sarai, as the maintainer of the runc container runtime, faces a constant battle against security problems. Recently, runc has seen another instance of a security vulnerability that can be traced back to the difficulty of handling file paths on Linux. Sarai spoke at the 2025 Linux Plumbers Conference (slides; video) about some of the problems runc has had with path-traversal vulnerabilities, and to ask people to please use libpathrs, the library that he has been developing for safe path traversal.

Sarai began by defining what he meant by path safety. There are two kinds of path safety that are relevant to runc, he said. The first is "regular" path safety, which applies to any application working with files: when operating on a path, one of the components might change unexpectedly. For example, a program could be reading several files from a directory using absolute paths, only for a directory in the middle of the path to be changed, causing the program to see a mixture of files from different directories. That kind of time-of-check-to-time-of-use (TOCTTOU) error comes up all of the time in path-handling code. He shared a slide showing 14 different CVEs in runc since 2017, all of which involved this kind of problem. LWN covered one in 2024 and one in 2019 that were particularly noteworthy. The second kind of path safety deals with the peculiarities of virtual filesystems, and needs to be handled separately, Sarai added.

There are some partial solutions to regular path safety, Sarai said. The openat2() system call, for example, lets programmers specify to the kernel how it should handle certain kinds of ambiguities. On the other hand, openat2() is often blocked by seccomp(), since one of the arguments is a pointer. So, the only real alternative is to implement path traversal in user space, by opening each directory along the path by hand. That is "quite finicky, but you can do it." The Go programming language recently added standard library support for doing that kind of traversal, for instance. Sarai's recommendation is to use libpathrs, the MPL-and-LGPL-licensed Rust library (with C bindings) that he has written to do this delicate dance correctly.

The second kind of path safety that runc has to deal with, above and beyond what most applications deal with, is what Sarai calls "strict" path safety. Some virtual filesystems, such as procfs, require extra attention to detail to use safely. On a normal filesystem, one does not typically care which exact inode one opens, so long as it is for a file located at the right path. But on procfs, it's important to operate on the exact file the program was expecting: "overmounts or fake mounts can trick us into doing dangerous things." For example, a program that reexecutes itself using /proc/self/exe would be quite broken if a user bind-mounted a different file into that path.

This isn't a new problem. For regular files, one can use the RESOLVE_NO_XDEV option to openat2() to avoid crossing any filesystem boundaries. But that doesn't work for procfs's magic links (such as /proc/self/exe) "for some reason." [Sarai later wrote to me to clarify that the reason is actually straightforward: since /proc/self/exe refers to an executable file on another file system, of course RESOLVE_NO_XDEV blocks it. The trick is making sure that the magic link hasn't been overmounted with a reference to the wrong other filesystem.] The solution is to use the filesystem mount API to obtain a file descriptor for the root of procfs that no other process can interfere with.

That solution doesn't work inside nested user namespaces, however. So, programs that need to work inside nested namespaces (such as runc, when people want to nest containers) have to resort to some extremely delicate checks that particular paths haven't been overmounted.

Sarai expected some people to be skeptical that this was a real problem, on the basis that only root can mount things. That's not really true in the context of runc, though. There are, of course, mount namespaces to deal with. But there is also the fact that runc is used as a backend by a large number of different high-level containerization programs. Those programs often give users a lot of flexibility to configure container mounts, which can result in unprivileged mounting into containers that runc is working with, sometimes in ways that permit a program to escape the container. Almost all of the vulnerabilities in runc have been misconfiguration bugs, he said. Sometimes, runc can prevent those by recognizing an obviously invalid configuration, and sometimes the higher-level programs need to be patched to avoid generating the problematic configuration in the first place.

He then went through a series of pop quizzes to illustrate the difficulties that come up in configuring a container. Two of runc's most recent vulnerabilities, CVE-2025-31133 and CVE-2025-52565, involved using a mount and a symbolic link to trick runc into giving a container access to /proc/sys/kernel/core_pattern, the procfs file used to configure the kernel's core-dump handler. Writing into that file could let processes escape from inside a container.

Sarai didn't go into detail on why setting the core-dump handler could enable an escape in the talk, but he was probably referring to the problem Christian Brauner highlighted in May. When the kernel launches the configured core-dump handler, it runs with full privileges in the root namespace; if the container can configure the core-dump handler to be a file that it controls, this allows it to effectively take over the system.

The solution in runc was to use much stricter validation of special inodes, to move to libpathrs for path traversal, and to use TIOCGPTPEER to validate that console files are really console files and not sneakily overmounted regular files. But the work also brought to light some potential kernel changes that could make writing this kind of path-handling code much safer. Sarai suggested adding a RESOLVE_NO_DOTDOT option to openat2(), to prevent traversing into a parent directory by accident ban the use of ".." in paths at all. He said that it would also help to block all overmounts of procfs magic links; most have been blocked since kernel version 6.12, but "most" and "all" are different prospects in the world of security.

For people writing user-space applications, Sarai's recommendation is to switch to a more file-descriptor based design, rather than relying on paths. Ideally, use openat2() or libpathrs to handle path manipulation. Every system call that works with path names is potentially dangerous, he said.

One member of the audience asked whether Sarai had any advice for safely dealing with paths in cgroupfs (the virtual filesystem for manipulating control groups). Sarai replied that the RESOLVE_NO_XDEV flag to openat2() was quite helpful for making sure that one stays within cgroupfs. Version 1 control groups are "annoying," and he didn't have much advice for dealing with them correctly. For version 2 control groups, however, he recommended opening a file descriptor for the root of the filesystem and checking the inode number. If that is correct, it's much more certain that the program is interacting with the real cgroupfs.

Another member of the audience asked how the CVEs that Sarai had highlighted were discovered. "Not through fuzzing or anything, just people looking," he answered. In 2018, he "provided a very general script" for creating scenarios that can result in path-traversal problems. Since then, people have been poking at runc and slowly evolving the attacks to reach increasingly obscure corner cases. Each year's CVEs tend to be an evolution of the previous year's, he said.

Someone else asked whether he thought that using virtual filesystems such as procfs and cgroupfs to present kernel interfaces was a mistake. "Well, there's several attacks that could never happen if it were [designed using system calls instead], and that makes you wonder, right?" Sarai replied. On the other hand, virtual filesystems do provide some nice benefits. The LXC container runtime has a fake procfs implementation to help control-group-unaware programs to identify process and memory limits, for example, he said.

That didn't satisfy some people, who pointed out that there are also ways to intercept system calls. At that point, however, the session ran out of time and the discussion spilled over into the hallway.

[ Thanks to the Linux Foundation, LWN's travel sponsor, for helping with travel to Tokyo to cover the Linux Plumbers Conference. ]

Comments (21 posted)

Questions for the Technical Advisory Board

The nature and role of the Linux Foundation's Technical Advisory Board (TAB) is not well-understood, though a recent LWN article shed some light on its role and history. At the 2025 Linux Plumbers Conference (LPC), the TAB held a question and answer session to address whatever it was the community wanted to know (video). Those questions ended up covering the role of large language models in kernel development, what it is like to be on the TAB, how the TAB can help grease the wheels of corporate bureaucracy, and more.

Dan Williams opened the session by reminding everyone that the TAB has no formal authority to do anything — but, being composed of people who have spent years demonstrating leadership in the kernel community, it has a lot of influence and experience. The primary role of the TAB is to be a group of people who can be asked what "Linux" thinks about something, and have a reasonable chance of coming to an answer that the community will be happy with. With that in mind, he called for questions.

At the time of the talk, the TAB consisted of Sasha Levin, Jonathan Corbet, Steven Rostedt, Dave Hansen, Shuah Khan, Williams, Kees Cook, Ted Ts'o, Miguel Ojeda, and Greg Kroah-Hartman — the last of whom could not be there for the conference. Keen-eyed readers will notice that Ts'o and Ojeda don't appear in the photos below; they arrived after the others, and I failed to get them in the group shots.

Large language models

An audience member asked whether any of the members of the TAB had explored using AI in their workflows, and whether they had found it helpful. Levin answered that some people had brought up their experiences at the Maintainers Summit a few days prior — "it was mostly positive, but there were some concerns." AI is evolving quickly, he said, so it's hard to set a firm policy at this point. Rostedt said that he thought there was a lot of fear of the unknown here, but that most of the actual conversations so far have ended up favoring a wait-and-see approach.

Kees Cook thought that the recent review work was potentially going to be quite helpful for addressing maintainers' workloads. Corbet had a more jaundiced view: "I see a lot of the less pleasant sides of the AI thing, [...] trying to keep LWN.net running." He also reminded everyone of the problem with becoming dependent on proprietary tools, such as happened with BitKeeper. "I asked Linus if he would go off for a weekend and create a replacement system. He said yes, but I'm not sure if I believe it."

Khan said that AI was making it increasingly difficult to screen mentorship candidates, but that she was optimistic about the utility of automatic patch review. Hanson pointed out that, although people often think of using large language models to write code directly, generating code is "a very different thing than using AI in your workflow." He found using AI to find the right sections of AMD and Intel CPU documentation (which can run to thousands of pages) helpful.

The role of the TAB

Another question was about the role of the TAB — is it meant to be a bridge between the Linux Foundation and the kernel community? How much of the TAB's work involves the Linux Foundation? A lot more of the TAB's work is directly with the community now, Rostedt said, compared to the first days of the TAB. Ts'o clarified that when people say that the TAB does outreach to the Linux Foundation, that also means outreach to the members of the Linux Foundation. For example, the TAB published a Linux kernel contribution maturity document to encourage companies to allow their employees participate in community work while on the clock. That has a lot of benefits, he said, in reminding the companies that they should send people to LPC, dedicate time to reviewing patches, and so on.

Levin pointed out that the TAB also finds ways that the Linux Foundation can help the kernel community, and oversees LPC. Khan gave the example of getting a professional mental health speaker to present at LPC a few years ago to help support maintainers struggling with burnout. "We're the interface layer, within our own community and the Linux Foundation," Cook summarized.

Williams said that the TAB's work is "kind of interrupt-driven". When a company has a question for "Linux", or when a kernel developer has a need that requires some kind of perceived authority to handle, that's when the TAB steps in. The power of the TAB comes from the fact that the members have done work and shown leadership in the past, Ts'o said. Electing the members of the TAB is really just a recognition of that leadership; elevation to the TAB doesn't grant special powers, but it does make it obvious that people should come to you with problems when they don't know who to ask.

A lot of the TAB's meetings are just about coming to a consensus on different topics so that they have answers ready to go to upcoming problems, Williams said. "And we disagree a lot, too, which is a good thing," Levin added — only for Williams to insist: "No we don't!" Khan clarified that when the TAB does disagree it's "with respect"; their disagreements represent the community as a whole.

Elections

Williams then posed a question to his fellow TAB members: with the (recently closed) TAB election, what do they want to see next year? What should the TAB be looking at? And for the non-TAB audience members: what conversations can the TAB drive that would help you in your work?

Levin opined that the TAB is at its best when it's boring: it only becomes exciting when something's going wrong. Williams said that he thought the TAB should be helping people figure out how to talk about kernel deadlines and schedules to their management chains: "Some of you promise kernel deadlines — does there need to be a discussion about that? Can the TAB help?"

Cook thought that was an interesting topic, and maybe worthy of an extension to the contribution maturity model document. A member of the audience asked about a specific case that he had run into trying to add LLVM code-coverage (llvm-cov) build-options: the kernel already supports gcov and kcov, but llvm-cov offered some non-overlapping features that he needed. The maintainer saw that there was (potentially) a lot of common support code between gcov, kcov, and llvm-cov, and told him to go away and refactor things to have a single code-coverage interface, instead of just adding llvm-cov into things. Ojeda agreed that this kind of situation was definitely a place where the TAB could help manage expectations on all sides.

Khan said that there were two aspects to the problem of being asked to go and do a bunch of supporting work for a change: justifying schedules to management, but also the problem of balancing an employer's interests against community interests. The community wants to see things that benefit Linux in the long term. Ts'o thought that having pressure to get things upstream was "in some ways a great problem to have," since it's an indication of the kernel's success. When a maintainer pushes back against something like llvm-cov, that's often driven by a worry about drive-by contributions, he said. The members of the TAB have experience explaining these things to different stakeholders.

That is really what the TAB is at its core, Levin added:

Ten people who want to help the community. And you folks don't use that as much as you should. You can email us, email the TAB mailing list. We don't promise we can fix it, but we're here to help.

Politics

One member of the audience spoke up with "less of a question, more of a hope": as polarity and divisiveness grow in different parts of the world, they hoped that the TAB would continue to support the Linux community in showing that collaboration works. They specifically cited the recent banning of some Russian maintainers as something that could have been better.

Corbet echoed their worry, saying that he was also concerned about the feasibility of having technical conferences in the US. Many people don't want to go there — for good reason — and many people can't leave, he said. "That's going to be a hard one for us to navigate." The TAB's guiding principle in cases like this, Ts'o said, is "what is best for the community?". It isn't about whether we believe a given sanctions regime is correct, he said, it's about how we get the community together. Sometimes that's not something that the TAB can control, and they just have to try to make the best out of a tough tradeoff.

Promotions

Most kernel developers work in big companies, Hansen said. How does one go about mapping the things one does in the community to the things that one's company wants, he asked? Williams suggested that being elected to the TAB might be good for one's promotion chances, to general laughter. Rostedt said that he'd actually never been promoted while at a company, but that he had frequently been hired away for a higher position. Sometimes other companies can see the benefit of kernel work more strongly than someone's current employer.

Hansen agreed that the mobility of kernel work was a nice benefit — when he walked into Intel, he already knew several people there from conferences and from kernel work, he said. Ts'o said that he's been trying to promote the idea that it's useful for companies to reach out and get recommendations from senior open-source developers for anyone going up for promotion. That's something that individual employees can do too: "See if your company can accept letters of recommendation for your promotion packet." Hansen added that writing letters of recommendation was something that the TAB could help with. Ojeda said that he'd written just such a letter for a student last week, so that can help with academic careers as well as corporate ones.

Time commitment

Another member of the audience asked how much time per week or per month being on the TAB required. Ojeda answered that there's a one hour meeting every month, plus time spent on emails, but it's generally not too much work. Levin said that when it becomes "exciting" there can be additional work. Cook likened it to working on multiple patch series — sometimes a patch series will be small, sometimes big, but one can generally fit it in around other kernel work.

Ts'o said that many times, people join the TAB because they're passionate about contributing to the community, in which case they will find additional work to do. So, being on the TAB can blend into time spent on other community work. When he ran for the TAB, Rostedt said, it was because there was tension between systemd folks and kernel folks, and he wanted to be on the TAB to have resources to bring the community together. Getting elected let him talk to the Linux Foundation about obtaining funding for systemd developers to attend kernel events and vice versa.

At that point, the time allocated for the session was nearly over; Williams brought up one final item: Corbet has been a constant on the TAB. He has always had our back, Williams said. And after 18 years, he has decided to step away. Williams called for a round of applause, which quickly manifested.

[ Thanks to the Linux Foundation for enabling my travel to Tokyo to cover the Linux Plumbers Conference. ]

Comments (none posted)

An early look at the Graphite 2D graphics editor

Graphite is an effort to unify illustration, raster editing, desktop publishing, and animation in one browser-based application. The project has been in development since 2021 and announced its first alpha release in 2022. According to creator Keavon Chambers, the project's mission is to become "the 2D counterpart to Blender", by bringing a node-based, non-destructive workflow to 2D graphics. The project, currently still in alpha, is a long way from complete; but it is worth testing for anyone involved with open-source-graphics production. Current builds, from September 2025, include vector-illustration tools, a node-based compositor, and early brush tooling, with broader pixel-based- and photo-editing work still in progress.

Graphite in a nutshell

As a non-destructive editor, each step in Graphite's workflow remains discretely editable later. For example, a designer can tweak or remove a curve or brush stroke without redoing later steps. It is also often possible to reorder operations without losing work. Graphite is meant for professional users and designed to offer predictable performance across platforms, with a flexible, generalized core that can be extended beyond pure illustration into areas such as photo editing, page layout, animation, and potentially video- or audio-editing workflows.

Graphite is written in Rust and compiled to WebAssembly (Wasm); it runs in the web browser as a progressive web application (PWA). The project does not publish an official list of supported browsers, but it can be installed as a PWA in browsers that support that feature, such as Chromium and its derivatives, allowing Graphite to be installed for offline use. I have also tested Graphite in Firefox extensively and have not run into any problems.

A desktop build using Tauri—a Rust framework for creating lightweight native wrappers for applications built on web technologies—is was planned for the end of 2025though it may slip. (Update: Chambers has informed us that the Tauri build was abandoned "due to an insurmountable technical incompatibility".) Source code and development builds are hosted on GitHub, with code under the Apache-2.0 license. According to Graphite's mission statement, the developers aim "to unshackle the creativity of every budding artist and seasoned professional by building the best comprehensive art and design tool that's accessible to all". Funding comes from the community and is managed through Graphite Labs, LLC, an organization wholly owned by Chambers.

Why convergence matters

Designers working in the 2D space often move between multiple applications and file formats. A typical publishing workflow might involve editing images in GIMP, making small edits in a lighter application like Pinta, creating illustrations in Inkscape, and assembling the final layout in Scribus.

At each stage, assets need to be exported and imported between those tools. This model is unwieldy even if each task is done by separate designers, but it is especially burdensome for a single user who has to learn multiple applications to accomplish these tasks. Open-source-graphics applications have generally adhered to "do one thing well" or served as extensible platforms, with broader workflows enabled by plugins and scripting. Moving assets between these applications and models typically requires export/import steps and format conversions that may flatten features that the target format doesn't support, such as text being converted to paths or pixels. For example, some applications convert text to raster graphics, and various layer blend modes are not universally supported between different applications.

From an architectural standpoint, general-purpose image editors (for example, GIMP or Pinta) are typically built on a layer-based editing model (called a layer stack). In a layer-based system, images consist of one or more pixel-based layers that may also have metadata such as layer blend modes, rotation, or boundaries. In contrast, vector-graphics editors like Inkscape typically use object hierarchies, which represent scenes through a list or table of data, including individual shapes or images and any associated metadata (size, color, rotation, or effects). Animation tools (like Synfig or Glaxnimate) use scene graphs or timelines.

Each model is tailored to its domain, such as page layout or illustration. Practical limitations become evident when attempting to combine illustration, image-editing, layout, and motion-graphics workflows. Specifications like OpenRaster aim to improve sharing assets between applications, but support for it varies by application and coverage is incomplete. For example, this format can store vector graphics, but this feature is not supported across all applications that can process it.

How Graphite works

From a technical perspective, Graphite takes a different approach from most image editors, using a single procedural model (a node graph). Graphite evaluates this node graph in realtime, and renders the result via wgpu, a Rust implementation of the WebGPU graphics API. This differs from more common models where pixels are rendered directly, or vectors are rasterized through a 2D library like Skia or Cairo.

The goal of this approach is to allow users to use the same basic tools across domains without the need to rebuild assets or switch between file formats and applications. This mirrors the model implemented by Blender, where users can do 3D modeling, video editing, compositing, and other disparate tasks in one application.

Graphics definitions are the underlying information that describe an artwork's shapes and images, the operations applied to them, and their parameters. In Graphite, these definitions are represented in Graphene, which the project describes as a programming language and runtime for its node-based scripting system and rendering engine. Graphite is the user-facing editor, exposing Graphene's operations as nodes—composable functions that can be chained into a graph and inserted or removed anywhere in the pipeline. Users interact with Graphene indirectly through this node graph UI; Graphite doesn't provide a direct method for editing Graphene code as text.

Nodes can represent either a standard graphics function or a custom operation, each with its own distinct parameters. The documentation describes the node network as "a box containing a finite set of nodes that are connected together as a directed acyclic graph (DAG)". Some nodes also serve to load images and other assets from the filesystem. The complete node graph represents a programmatic definition of the final image. Graphene executes this description to produce what the user sees on screen. This system is non-destructive, meaning that edits can be made at any point along the graph without affecting the original data. The description is deterministic: given the same node graph and filesystem inputs, Graphite produces the same result on any supported platform.

The plan is for Graphene to support multiple modes, though only one is currently implemented. That one, editing mode, runs Graphene in an interpreted mode for immediate feedback during editing. The plan for the future is to compile code generated during editing to bytecode through just-in-time compilation (JIT) as the user works, so that established edits render more quickly. The Graphene documentation also describes a "compiled" export mode, where a document's node graph could be compiled into a standalone application for running procedural artwork outside the editor. The JIT and compiled export modes are on hold until its Rust toolchain is fully developed.

A portable solution

Graphite is designed to work without platform-specific GUI frameworks. It compiles to Wasm and runs in the browser, with a frontend built using Svelte and TypeScript.

In the browser, Graphite runs directly on the user's machine and uses wgpu with a WebGPU backend for hardware acceleration. The Svelte user interface delegates performance-sensitive work to a WASM module to maximize performance. The goal of the project is to deliver performance comparable to a native application, even when running in the browser.

The Graphite editor module sits between the frontend and the Graphene backend. It consists of various subsystems, each supplying a component of the overall functionality. This application passes user inputs and rendered graphics between the frontend and the Graphene system beneath, and contains the logic required to facilitate visual editing.

Interoperability is still limited at this early stage. Graphite saves files in its own ".graphite" format. Artwork can be exported in three standard formats: PNG, JPEG, and SVG. Users can export either the entire canvas or a selection, and scaling and transparency can be adjusted from the export dialog.

Graphite also supports importing files in several formats, including SVG, PNG, JPEG, and WebP, though SVG gradients and filters are not consistently preserved on import. Graphite does not currently support importing native project formats from other applications, such as GIMP, Scribus, or Inkscape-specific SVG extensions and metadata. The same is true of proprietary formats from Adobe's Creative Cloud applications or the Affinity Suite.

Using Graphite today

So far, the project has implemented only a subset of its full stated goals, but it already combines three key domains that are typically found in distinct applications: procedural design, vector graphics, and drawing/painting. It can also be used for basic layout and desktop publishing, though with its lack of certain features, such as guides and pages, users may prefer a more mature tool for this purpose. Apart from performance hits when working with especially large imported vectors, Graphite appears to be stable during editing, importing, or exporting files.

Its native vector illustration tools are sufficiently mature for early adopters to get a sense of real-world use. Users can add basic shapes, edit vector points, and manage layers. For example, the "Path Editor" tool works similarly to Inkscape's "Node Editor" mode, having essentially the same functionality and similar mouse-driven interactivity.

Presently, Graphite's raster tools are still experimental, and full non-destructive raster editing is yet to be implemented. The intent for these tools is that brush and pencil strokes should be both procedural and replayable, extending the same non-destructive guarantees available with vector editing to painting and drawing.

In practice, this would let users adjust or remove brush strokes made several steps before, without undoing later edits. In its present state, the brush tool generally works smoothly in testing, though smaller brush sizes (1–2 pixels) can cause missed strokes. That said, it is already possible to draw, erase, and restore brush strokes with a single tool. Furthermore, deleted brush strokes can be restored in the node graph if they've not been completely removed from project (in the node editor).

Currently, raster compositing is limited to importing and manipulating raster images with the node-based compositor and drawing with the (still experimental) brush tool. Every object, including vectors, images, and brush strokes, is treated as an individual layer on the canvas, and can be edited or deleted from the scene. Layer blend modes are available for each layer, along with opacity, visibility, and layer locking. Animation tooling has not yet been fully implemented; only a play and reset button are available, but there is no animation timeline or key frames.

According to the project roadmap, the long-term aim is to abstract the node-based core behind conventional tools for illustration, layout, digital painting, drawing, and animation. In practice, this would offer familiar features like layers, brushes, selections, paths, and key frames, so typical workflows don't require opening the graph at all. This is intended to ease adoption for users migrating from other applications.

Meanwhile, advanced users would still be able to open and edit the node graph directly, whether creating or rearranging nodes, or adjusting effect parameters, with changes reflected immediately in the conventional tools. The node graph can already be used in this manner.

An ambitious but useful undertaking

While there is no shortage of 2D graphics solutions for Linux, Graphite aims for a unique goal: a single procedural core that spans illustration, raster editing, layout, and animation. Its node-graph workflow enables reproducible pipelines that can be adapted across designs without rebuilding assets.

Graphite is under development, with several critical areas to complete before a beta release. The production build is stable, though feature-incomplete; it is intended to let users try the application and become familiar with its design and feature set. A development (edge) build is also available on GitHub, exposing newer features but with a higher risk of regressions and crashes. Both builds run within the browser and can be installed as PWAs if one is running a Chromium-based browser. Progress on the desktop build can be tracked via the relevant GitHub issue.

The production release was updated in September 2025, with more than 300 changes since the previous release. Day-to-day development is driven by a small core team, but more than 170 people have contributed to the project so far. The project also released a video detailing some of these changes. Testers are encouraged to report issues on the project's bug tracker, and code contributions are welcome.

Comments (14 posted)

2025 Linux and free software timeline

Last year we revived the tradition of publishing a timeline of notable events from the previous year. Since that seemed to go over well, we decided we should continue the practice and look back on some of the most noteworthy events and releases of 2025.

As always, our subscribers have made creation of the timeline—and our weekly coverage throughout the year—possible. If you like what you see here (and elsewhere on the site) please consider subscribing to LWN. Thanks a lot to all of our subscribers for making this and all of the rest of our coverage possible.

January February March

April May June

July August September

October November December

January

José Marchesi released an Algol 68 front end for GCC (announcement). The feature was approved in November 2025, and will be in the next release.

Libvirt 11.0.0 was released (announcement).

Bill Gianopoulos, a core developer and release engineer for the SeaMonkey Project, passed away (LWN brief).

Steve Langasek, longtime Debian and Ubuntu contributor, passed away. (LWN brief).

Mastodon founder Eugen Rochko announced that he will transfer the Mastodon name, copyrights, and other assets to a new non-profit organization (LWN brief).

Automattic announced that it will reduce its contributions to the WordPress project as a result of the WP Engine lawsuit (announcement).

Serious vulnerabilities discovered in rsync; version 3.4.0 released (announcement, LWN article).

Paolo Mantegazza, who drove the Real Time Application Interface project and a key figure in the development of realtime Linux, passed away.

The Software Freedom Conservancy announced the success of a Lesser GNU Public License (LGPL) suit in Germany against AVM, a maker of home-networking equipment.

Helen Borrie, a longtime contributor to the Firebird relational-database project, passed away.

Linux 6.13 released (announcement), LWN kernel index.)

Friction emerged between the direct rendering (DRM) subsystem and stable kernel maintainers over multiple git commit IDs referring to the same commit (article).

Version 3.2.0 of the Dillo web browser was released with SVG support for math formulas, optional support for WebP images, and more (announcement).

OpenVox had its first release; the project is a fork of the Puppet automation framework (announcement).

Wine 10.0 was released with full support for the Arm64EC architecture, better high-DPI display support, Wayland enabled by default, and more (announcement).

Credential-leaking were vulnerabilities found in some Git credential managers. Security researcher RyotaK shared a series of vulnerabilities that affect password-based authentication with an external credential manager (announcement).

LWN added an EPUB format for articles and the weekly editions (announcement).

Jack Dorsey's scheduled keynote for the Free and Open Source Software Developers' European Meeting (FOSDEM) is canceled after questions arise and protests are planned over the keynote (article).

The Linux Foundation explained the reasoning behind taking away kernel maintainership from several people with Russian citizenship; the removal happened in October 2024 (announcement).

Rust ran into resistance in the kernel's direct-memory-access (DMA) subsystem (LWN article).

Freedesktop.org scrambled to find a new home after its hosting provider asked it to move or start paying by the end of April 2025 (LWN brief). It migrated its infrastructure to Hetzner and Fastly CDN later in the year.

February

FOSDEM was held in Brussels, Belgium from February 1 to February 2 (LWN coverage).

Sylvestre Ledru announced that the uutils project intends to rewrite essential Linux tools in Rust at FOSDEM 2025 (LWN article).

Miguel Ojeda released policies for the use of Rust in the Linux kernel (announcement).

OpenWrt 24.10.0 was released (announcement).

Codeberg responded to hate attacks (LWN brief).

Asahi Linux adopted a new governance model after Hector "marcan" Martin stepped down as lead (announcement).

The openSUSE project switched to SELinux for its rolling-release distribution, Tumbleweed (announcement).

Jonathan Corbet described LWN's efforts to fight the AI scraperbot scourge, which continues to plague the site and the internet at large well into 2026 (LWN article).

Mesa 25.0.0 was released (announcement).

Mozilla announced leadership updates and a desire to "take steps to diversify" beyond Firefox (announcement).

Linus Torvalds made it clear he will accept Rust bindings for the kernel's DMA-mapping layer over Christoph Hellwig's objections (LWN brief).

Christoph Hellwig stepped down as maintainer of the DMA-mapping layer (LWN brief).

Pi-hole v6 was released with a redesigned user interface, new REST API, and embedded web server (announcement).

Gentoo began offering qcow2 disk images (announcement).

Gapless music player Aqualung 2.0 was released (announcement).

Emacs 30.1 was released with fixes for two security vulnerabilities, including a code-execution vulnerability in the flymake syntax-checking code (announcement, LWN article).

Rust 1.85.0 was released, which stabilizes the Rust 2024 edition (announcement).

Mozilla changed its terms of use and privacy policy; its apparent removal of the promise not to sell users' personal data raised concerns about the organization's intentions (LWN brief). The organization reversed course shortly afterward.

Fedora discussed Flatpak repository priorities after the Open Broadcaster Software (OBS) Studio project complained about how its software is packaged (LWN article).

Jennifer Miller discovered a hole in the kernel's FineIBT protection (LWN article).

The Python Package Index's (PyPI) new terms of service raised concerns (LWN article).

March

LWN took a look at Firefox forks as alternatives for users rubbed the wrong way by Mozilla's stewardship of the browser (LWN article).

Fish shell 4.0, a port to Rust from C++, was released (announcement).

Xen 4.20 was released with support for AMD Zen 5 CPUs, improved compliance with the MISRA C standard, PCI-passthrough on Arm, and more (announcement).

Zig 0.14 was released (LWN article).

Python's tail-call speedup was found to be based on LLVM regression (announcement).

Framework Mono 6.14.0 was released. This is the first release since WineHQ took over the project (announcement).

The LLVM project stabilized its Fortran compiler (announcement).

Ubuntu announced a plan to switch away from GNU utilities to the Rust-based uutils project for the 25.10 release (LWN article).

SystemRescue 12.00 was released (announcement).

A menu-driven interface for the Emacs Makefile mode, Casual Make was released as part of Casual 2.4.0 (announcement).

GIMP 3.0 was released with an update to GTK 3, non-destructive editing for most filters, and better color-space management (announcement, LWN article).

GNOME 48 was released (announcement).

OSI election ended with unsatisfying results after the organization disqualified candidates that were included on the ballot (LWN article).

SCALE 22x was held in Pasadena, California from March 6 to March 9 (LWN coverage).

Julien Malka proposed a method for detecting XZ-like backdoors (LWN brief).

Linux 6.14 was released (announcement, LWN kernel index).

Debian developer Roland Clobus announced that Debian bookworm live images are fully reproducible (LWN brief).

Freedesktop.org dropped OpenH264 from its SDK for Flatpak applications and runtimes (LWN brief).

Neovim 0.11 was released; notable changes included improved tree-sitter performance, better emoji support, and enhancements for Neovim's embedded terminal emulator (announcement).

Raspberry Pi released rpi-image-gen, a tool to create custom images for its devices (announcement).

Kernel.org found a new home (announcement).

Cryptome co-founder John L. Young passed away (LWN brief).

OSPM Summit held was held in Uhldingen-Mühlhofen, Germany from March 18 to March 20 (LWN coverage).

The Linux Storage, Filesystem, Memory-Management, and BPF Summit (LSFMM+BPF) was held in Montreal, Canada from March 24 to March 26 (LWN coverage).

Arthur Cohen posted a massive series of patches resulting in a burst of progress for the GCC Rust front end (LWN brief).

Python Setuptools updates caused headaches (LWN article).

Rust adopted the Ferrocene Language Specification (FHS) (announcement).

April

Dave Täht, who worked tirelessly to battle bufferbloat and other networking ills, passed away (LWN brief).

Slackware-based PorteuX 2.0 was released (announcement).

Rockbox 4.0 was released with support for a number of new audio-player devices, updated codecs, user-interface improvements, and more (announcement).

Thunderbird expanded its sights to offering web services; the project hopes to compete with proprietary services such as Gmail and Office365 (announcement).

OpenSSH 10.0 was released; support for DSA signature algorithms was removed, while Portable OpenSSH gained support for systemd-style socket activation (announcement).

ACM Queue looked at 50 years of open source software supply chain security (announcement).

OpenSSL 3.5.0 was released (announcement).

FreeDOS 1.4 was released; this was the first release of the open-source replacement for MS-DOS in three years (announcement).

APT 3.0 was released in time to be included with Debian 13 (LWN article).

Fedora 42 was released (announcement, LWN article).

MITRE program funding was extended after reports surfaced that funding was due to run out on April 16, 2025 (LWN brief).

An arbitrary file read vulnerability was announced in Yelp, GNOME's help browser (announcement).

Pinta 3.0 was released; the most notable change is that the image editor had been ported to GTK 4.0 and libadwaita (announcement).

Arch-based Manjaro 25.0 was released (announcement).

Ubuntu 25.04 was released with Linux 6.14, GNOME 48, APT 3.0, and more (announcement).

Template strings were accepted for Python 3.14 (announcement, LWN article).

Debian discussed how the DFSG applies to AI models (LWN article).

OpenBSD 7.7 was released (announcement).

GCC 15.1 was released: notable changes included implementing the C23 dialect by default, a number of new C++26 features, a new COBOL front end, and more (announcement).

Andreas Tille was re-elected Debian Project Leader (announcement, LWN election coverage).

Meson 1.8.0 was released (announcement).

The Free Software Foundation (FSF) completed the review of its board of directors; the process resulted in the reconfirmation of all five sitting board members (announcement).

OSI published an election retrospective as a quiet update to its March blog post announcing the new members of the board (LWN brief).

Oregon State University Open Source Lab faced a shutdown due to budget problems (announcement).

May

Deepin Desktop was removed from openSUSE over security concerns (announcement).

Sasha Levin released a new version of AUTOSEL, the tool that selects kernel patches for possible backporting into the stable releases (LWN brief).

Home Assistant 2025.5 was released with improvements to its backup system, Z-Wave Long Range support, and more. The home-automation system project celebrated two million active installations with this release (announcement).

System-monitoring application Mission Center 1.0.0 was released with the addition of SMART data for SATA and NVMe devices, display of per-process network usage, and more (announcement).

The Document Foundation celebrated the 20th anniversary of the OASIS Open Document Format's ratification (announcement).

Redis was re-licensed under the AGPLv3 (LWN brief).

USENIX announced the end of its Annual Technical Conference (LWN brief).

SUSE pulled the plug on the venerable YaST installation and configuration utility after more than 25 years in development (LWN article).

Linaro Connect was held in Lisbon, Portugal from May 14 to May 17 (LWN coverage).

PyCon US 2025 was held in Pittsburgh, Pennsylvania from May 14 to May 22 (LWN coverage).

Multiple security vulnerabilities were found in GNU Screen (announcement).

The GNOME Foundation named Steven Deobald as its new executive director (announcement).

Container-management tool Podman 5.5.0 was released (announcement).

Oregon State University Open Source Lab announced it has found funding (LWN brief).

The Tor project released the oniux utility to provide Tor network isolation, using Linux namespaces, for third-party applications (announcement).

The Debian AI General Resolution to require training data was withdrawn (LWN article).

Red Hat Enterprise Linux 10 was released (announcement).

Fedora Council overturned FESCo's decision to revoke Peter Robinson's provenpackager status and issues an apology (announcement, LWN article).

Linux 6.15 was released (announcement, LWN kernel index).

The GNU C Library (glibc) project revisited its infrastructure security (LWN article).

NixOS 25.05 was released (announcement).

Mozilla shut down Pocket, a bookmarking service it acquired in 2017 (announcement).

AlmaLinux OS 10.0 was released (announcement).

Kees Cook's kernel.org account was briefly banned following a mistake using b4's trailers subcommand (LWN article).

Block-layer bounce buffering bounced out of the kernel (LWN article).

June

OpenH264 update procedure caused headaches for Fedora; relying on Cisco for updates to the patent-encumbered codec does not go well for the project (LWN article).

Alpine Linux 3.22.0 was released (announcement).

Fedora updated its strategy through 2028 (announcement).

Flock 2025 was held in Prague, Czech Republic from June 5 to June 8 (LWN coverage).

/e/OS 3.0 was released; the Android-based mobile operating system included improved privacy tools, a "find my device" feature, and more (announcement).

The Open Invention Network celebrated its 20th anniversary (announcement).

A covert web-to-app tracking via localhost exploit on Android, used by Meta and Yandex, was disclosed (LWN brief).

Rocky Linux 10.0 was released (announcement).

A group of WordPress community participants launched the Federated and Independent Repositories Package Manager (FAIR.pm) project as a decentralized alternative to WordPress.org's package distribution (LWN article).

KDE Plasma 6.4 was released with more flexible tiling features, accessibility enhancements, and more (announcement).

Radicle Desktop was released, a graphical interface to simplify using the Radicle peer-to-peer code collaboration software (announcement).

Torvalds told Kent Overstreet that bcachefs would likely be removed from the kernel (LWN brief).

The Libxml2 maintainer adopted a "no security embargoes" policy (LWN article).

GNOME deepened its dependencies on systemd in order to shed its homegrown service manager and improve its ability to run concurrent user sessions (LWN article).

PostmarketOS 25.06 was released with support for systemd (announcement).

The OsmAnd map and navigation app project celebrated its 15th anniversary (announcement).

Firefox 140 was released with more control over vertical tabs, a dialog for custom search engines, and more (announcement).

Fedora i686 received a reprieve; support for 32-bit x86 applications on Fedora will continue, for now (LWN article).

The copyleft-next project was relaunched by Bradley Kuhn and Richard Fontana. The effort to develop a next-generation copyleft license began in 2012, but had stalled in recent years (LWN brief).

July

The Netdev Foundation launched (announcement).

Oracle Linux 10 was released (announcement).

GNU Health Hospital Information System 5.0 released (announcement).

Amarok 3.3 was released based on the KDE Frameworks 6 and Qt6; it featured a major rework of its audio engine to use GStreamer for audio playback (announcement).

Thunderbird 140 was released (announcement).

GNU Bash 5.3 was released (announcement).

U-Boot v2025.07 was released (announcement).

DebConf25 was held in Brest, France from July 14 to July 19 (LWN coverage).

EuroPython 2025 was held in Prague, Czech Republic from July 14 to July 20 (LWN coverage).

Version 6.4 of Parrot, a Debian-based distribution with an emphasis on security improvement and tools, was released (announcement).

Intel abruptly pulled the plug on Clear Linux (announcement).

Malicious packages were uploaded to the Arch User Repository (AUR) (announcement).

Google launched OSS Rebuild (announcement).

Forgejo 12.0 was released (announcement).

Fedora's quality team looked to reduce its workload after six of ten Red Hat employees on the team moved to other projects or left the company altogether (LWN article).

HeliumOS 10 was released; the project is a relatively new image-based desktop distribution based on packages from CentOS Stream and AlmaLinux. The distribution uses the KDE Plasma Desktop, Zsh as its default shell, and Btrfs as its default filesystem (announcement).

Wayback X11 compatibility layer project was launched (announcement).

Linux 6.16 was released (announcement, LWN kernel index).

Till Kamppeter put out a call for sponsors for the OpenPrinting project after being laid off by Canonical (LWN brief). He announced in November that the Sovereign Tech Fund would fund his work through 2026.

August

More malware was uploaded to Arch Linux AUR repository (announcement).

Debian grappled with offensive packages, again; two "offensive" fortune packages were dropped ahead of the Debian 13 release (LWN article).

Proxmox Virtual Environment 9.0 was released (announcement).

Masahiro Yamada stepped down as the sole maintainer of the kernel's build and configuration systems; Nathan Chancellor and Nicolas Schier stepped up to maintain Kbuild system, but the Kconfig is currently unmaintained (LWN brief).

Richard Hughes announced a sustainability plan for the Linux Vendor Firmware Service (LVFS) and asked for vendors that use the service to help fund its development (LWN brief).

CalyxOS Android distribution project told users to uninstall the OS after co-founder Nicholas Merrill left the project. The project did not resume releases in 2025 (LWN brief).

NGINX added native support for the ACME protocol (announcement).

Debian 13 ("trixie") was released with GNOME 48, KDE Plasma 6.3, Xfce 4.20, Linux 6.12, GCC 14.2, Python 3.13, and systemd 257. Trixie added riscv64 as an officially supported architecture, and dropped i386. The release will be supported through 2030 (announcement, LWN article).

Debian GNU/Hurd 2025 was released (announcement).

Google announced new restrictions on Android app sideloading that would require "all apps to be registered by verified developers in order to be installed by users on certified Android devices" (LWN brief).

FFmpeg 8.0 was released (announcement).

Radicle 1.3.0 was released (announcement).

Syncthing 2.0 was released (announcement).

LibreOffice 25.8 was released (announcement).

Zig 0.15.1 was released with major changes to the Reader and Writer interfaces (announcement).

The Groklaw domain fell into hostile hands (LWN article).

GhostBSD 25.02 was released with a new "OS X-like" desktop environment based on GNUstep (announcement).

Major web browser vendors prepared to dump XSLT support (LWN article).

GNOME discussed changing its technical governance model (LWN article).

The 2025 Open Source Summit Europe was held in Amsterdam, Netherlands from August 25 to August 27 (LWN coverage).

The 2025 Linux Security Summit Europe was held in Amsterdam, Netherlands from August 28 to August 29 (LWN coverage).

Bcachefs maintainer status changed to "externally maintained" (announcement).

Python: The Documentary was released. The 90-minute film features Guido van Rossum, Travis Oliphant, Barry Warsaw, and many more (announcement).

September

GNOME executive director Steven Deobald stepped down after just four months (announcement).

The Guix package manager was removed from Debian following an update to fix security vulnerabilities that contained too many changes to backport to Debian stable (LWN article).

The Rust Innovation Lab was announced by the Rust Foundation (LWN brief).

Cary Coutant released a new ELF specification for public review (LWN brief).

Niri 25.08 was released (announcement).

RustConf 2025 was held in Seattle, Washington from September 2 to September 5 (LWN coverage).

KDE launched its own Linux distribution (again) (LWN article).

npm debug and chalk packages were compromised (LWN brief).

openSUSE disabled bcachefs (LWN brief).

GNOME 49 was released with a new default video player (Showtime), PDF-viewing application (Papers), and a number of other enhancements and updates (announcement).

systemd v258 was released (announcement, LWN coverage part one, part two).

Varnish 8.0.0 was released; the project also announced it will be changing its name to "Vinyl Cache" due to legal difficulties in securing the Varnish name (announcement).

The Universal Blue project announced Bluefin LTS, a long-term-support distribution based on CentOS Stream 10 and EPEL as its base (announcement).

Kangrejos 2025 was held in Oviedo, Spain from September 17 to September 18 (LWN coverage).

RPM 6.0.0 was released (announcement).

Tails 7.0 was released, based on Debian 13 (announcement).

PostgreSQL 18 was released with "skip scan" lookups for multicolumn B-tree indexes, virtual generated columns, better text processing, oauth authentication, a new asynchronous I/O (AIO) subsystem to improve performance and more (announcement).

The 2025 GNU Tools Cauldron was held in Porto, Portugal from September 26 to September 28 (LWN coverage).

Linux 6.17 was released (announcement, LWN kernel index).

The entire NixOS moderation team resigned following a conflict with the project's steering committee (LWN brief).

Bcachefs removed from the mainline kernel (LWN brief).

Ruby Central conducted a takeover of RubyGems and Bundler GitHub repositories against the wishes of the maintainers (LWN article).

October

openSUSE Leap 16 released; this was the first major release since Leap 15 in 2018. It included the new Agama installer, Cockpit replacing YaST for system management, and more (announcement, LWN article).

Python 3.14.0 was released with official support for free threading, template string literals, and much more (announcement).

U-Boot v2025.10 was released (announcement).

The FSF named Ian Kelling as its new president (announcement).

Fedora made a last-minute change to /boot ahead of the Fedora 43 release (LWN article).

FSF announced the launch of the Librephone project (LWN brief).

"Pixnapping" paper outlined a new class of attacks against Android phones (LWN article).

Linux Mint Debian Edition (LMDE) 7 was released, based on Debian 13 (announcement).

Ubuntu 25.10 was released with the Rust-based uutils and sudo-rs, Linux 6.17, GNOME 49, and more (announcement).

Julia 1.12 was released with new multi-threading features, an experimental --trim feature, and more (announcement, LWN article).

Fedora Council approved an AI-assisted contributions policy; disclosure of AI-assistance is now required if "the significant part of the contribution is taken from a tool without changes" (announcement, LWN article).

Ruby Central transferred control of RubyGems and Bundler to the Ruby core team; the original maintainers were not consulted (announcement).

KDE Plasma 6.5 was released; noteworthy features included support for the experimental Wayland picture-in-picture protocol, automatic light-to-dark theme switching based on time of day, and more (announcement).

Valkey 9.0.0 was released with major improvements to performance and scaling of Valkey clusters to more than 2,000 nodes and one billion requests per second (announcement).

DigiKam 8.8.0 was released (announcement).

OpenBSD 7.8 was released (announcement).

Python Software Foundation withdrew a security-related grant proposal; accepting the grant would have required the foundation not to pursue diversity, equity, and inclusion programs (announcement).

GoFundMe was caught creating profiles for open-source nonprofits without permission; the company eventually said it would remove the pages (LWN article).

Fedora 43 was released (announcement).

Debian splits the ftpmaster team (LWN article).

A date bug in Rust-based uutils broke Ubuntu 25.10 automatic updates; all part of the growing pains in adopting a new set of utilities (LWN brief).

Tor Browser 15.0 was released, based on Firefox 140 (announcement).

Typst 0.14 was released; noteworthy features included generating accessible documents by default, support for PDFs as a native image format, and improvements to its HTML export features (announcement, LWN article).

Valgrind 3.26.0 was released with a license change from GPLv2 to GPLv3 (announcement).

November

CHERIoT 1.0, a hardware-software system for secure embedded devices, was released (announcement).

Linux kernel was ported to WebAssembly by Joel Severin (announcement).

Ubuntu introduced architecture variants (announcement).

LXQt 2.3.0 was released with improved Wayland support (announcement).

FreeBSD added to the Open Container Initiative (OCI) Runtime Specification (announcement).

The Python steering council announced that it accepted PEP 810 ("Explicit lazy imports") (LWN brief, LWN article).

Google reported success in use of Rust for Android; the company claimed a "1000x reduction in memory safety vulnerability density compared to Android's C and C++ code" (LWN brief).

Homebrew 5.0.0 was released (announcement, LWN article).

Public-inbox version 2.0.0 was released; the mail-archiving system powers LWN and lore.kernel.org's email archives (announcement).

The Racket programming language version 9.0 was released. A descendant of Scheme, it is part of the Lisp family of languages (announcement).

KDE announced that Plasma 6.8 will Be Wayland-only; the 6.8 release is expected in early 2027 (LWN brief).

Pytest 9.0.0 was released; noteworthy changes included the addition of subtests, native support for TOML configuration files, and a new strict mode (announcement).

Blender 5.0 was released; notable improvements include improved color management, HDR capabilities, and a new storyboarding template (announcement).

NixOS 25.11 was released with 7,002 new packages, GNOME 49, LLVM 21, firewalld support, and more (announcement).

December

Linux 6.18 was released (announcement, LWN kernel index).

FreeBSD 15.0 was released with a new method for installing the base system using the pkg manager, an update to OpenZFS 2.4.0-rc4, native support for the inotify(2) interface, and more (announcement).

Django 6.0 was released; highlights of the release included template partials for modularizing templates, a flexible task framework for running background tasks, a modernized email API, and a Content Security Policy (CSP) feature (announcement).

CPython considered including Rust code; the result of the discussion so far is that it will be a long time before Rust code is in core CPython, if ever (LWN article).

The kernel Rust experiment came to an end—successfully, we might add (announcement).

Alpine Linux 3.23.0 was released with an upgrade to version 3.0 of the Alpine Package Keeper (apk) (announcement).

Andreas Schneider announced version 2.0 of the cmocka unit-testing framework for C (announcement).

Calibre added a controversial AI "discussion" feature (LWN article).

The 2025 Open Source Summit Japan was held in Tokyo, Japan from December 7 to December 9 (LWN coverage).

The 2025 Maintainers Summit was held in Tokyo, Japan on December 10 (LWN coverage).

The 2025 Linux Plumbers Conference was held in Tokyo, Japan from December 11 to December 13 (LWN coverage).

Pop!_OS 24.04 LTS was released with the first stable version of the Rust-based COSMIC Desktop Environment (announcement, LWN article).

KDE Gear 25.12 was released with improved Git support in the Kate text editor, better PDF export in Konqueror, and much more (announcement).

Vojtěch Polášek announced Vojtux: an unofficial effort to create a Fedora-based distribution designed for visually impaired users (LWN brief).

Stephen Rothwell stepped down as maintainer of linux-next; Mark Brown became the new maintainer (LWN brief).

A new Linux Foundation Technical Advisory Board was elected; Greg Kroah-Hartman, Steven Rostedt, Julia Lawall, David Hildenbrand, and Ted Ts'o are the new members (announcement). After 18 years on the board, LWN founder Jonathan Corbet decided not to run for a seat.

Loong64 became an official Debian architecture (announcement).

Qubes OS 4.3.0 was released with more recent distribution templates, preloaded disposable virtual machines, and the reintroduction of the Qubes Windows Tools set (announcement).

systemd v259 was released after a three-month development cycle. Changes included a new "--empower" option for run0 that provides elevated privileges to a user without switching to root, ability to propagate a user's home directory into a VM with systemd-vmspawn, and more (announcement, LWN article).

LWN looked back at our predictions for 2025 (article).

Ruby 4.0 was released on Christmas day. Notable changes included the experimental Ruby Box feature for in-process isolation of classes and modules, a new just-in-time compiler called ZJIT, and more (announcement).

Shadow-utils 4.19.0 was released; the release notes also included an announcement that the project is deprecating a number of programs, hashing algorithms, and the ability to periodically expire passwords (announcement).

Comments (none posted)

Shadow-utils 4.19.0 released

Version 4.19.0 of the shadow-utils project has been released. Notable changes in this release include disallowing some usernames that were previously accepted with the --badname option, and removing support for escaped newlines in configuration files. Possibly more interesting is the announcement that the project is deprecating a number of programs, hashing algorithms, and the ability to periodically expire passwords:

Scientific research shows that periodic password expiration leads to predictable password patterns, and that even in a theoretical scenario where that wouldn't happen the gains in security are mathematically negligible (paper link).

Modern security standards, such as NIST SP 800-63B-4 in the USA, prohibit periodic password expiration. [...]

To align with these, we're deprecating the ability to periodically expire passwords. The specifics and long-term roadmap are currently being discussed, and we invite feedback from users, particularly from those in regulated environments. See #1432.

The release announcement notes that the features will remain functional "for a significant period" to minimize disruption.

Comments (95 posted)

Kernel release status

The current development kernel is 6.19-rc4, released on January 4. Linus said:

So this rc is still a bit smaller than usual, but it's not _much_ smaller, and I think next week is likely going to be more or less back to normal.

Which is all exactly as expected, and nothing here looks particularly odd. I'll make an rc8 this release just because of the time lost to the holidays, not because it looks like we'd have any particular issues pending (knock wood).

Previously, 6.19-rc3 was released on December 28.

Stable updates: 6.18.3 was released on January 2.

The 6.18.4 and 6.12.64 updates are in the review process; they are due on January 8.

Comments (none posted)

Kroah-Hartman: Linux kernel security work

Greg Kroah-Hartman has written an overview of how the kernel's security team works.

The members of the security team contain a handful of core kernel developers that have experience dealing with security bugs, and represent different major subsystems of the kernel. They do this work as individuals, and specifically can NOT tell their employer, or anyone else, anything that is discussed on the security alias before it is resolved. This arrangement has allowed the kernel security team to remain independent and continue to operate across the different governments that the members operate in, and it looks to become the normal way project security teams work with the advent of the European Union's new CRA law coming into effect.

Comments (36 posted)

Google will now only release Android source code twice a year (Android Authority)

Android Authority reports that Google will be reducing the frequency of releases of code to the Android Open Source Project to only twice per year.

A spokesperson for Google offered some additional context on this decision, stating that it helps simplify development, eliminates the complexity of managing multiple code branches, and allows them to deliver more stable and secure code to Android platform developers. The spokesperson also reiterated that Google's commitment to AOSP is unchanged and that this new release schedule helps the company build a more robust and secure foundation for the Android ecosystem.

The release schedule for security patches is unchanged.

Comments (7 posted)

IPFire 2.29 Core Update 199 released

The IPFire project, an open-source firewall Linux distribution, has released version 2.29 - Core Update 199. Notable changes in this release include an update to Linux 6.12.58, support for WiFi 6 and 7 features on wireless access points, as well as native support for link-local discovery protocol (LLDP) and Cisco discovery protocol (CDP).

Comments (none posted)

Manjaro 26.0 released

Version 26.0 ("Anh-Linh") of the Arch-based Manjaro Linux distribution has been released. Manjaro 26.0 includes Linux 6.18, GNOME 49, KDE Plasma 6.5, Xfce 4.20, and more.

Comments (none posted)

Distributions quote of the fortnight

We are keeping the Fedora version of GnuPG on the 2.4 branch as said above intentionally. The 2.5 [branch] started as mostly [an] experiment implementing the LibrePGP standard, which is not compatible with anything else (IETF's OpenPGP) and would likely result in users shooting themselves into their feet. I also synced couple of patches over the last years with FreePG project, which is trying to maintain the version 2.4 in a compatible manner:

https://gitlab.com/freepg/gnupg

Updating to 2.5 would result in new users generating incompatible LibrePGP keys, which I do not think is a good idea to do now for all Fedora users. I am hoping we will have some better solution by the time the 2.4 version will reach EOL, but I can not anticipate what it is going to be.

— Jakub Jelen

Comments (none posted)

Stenberg: No strcpy either

Daniel Stenberg has written a blog post about the decision to ban the use strcpy() in curl:

The main challenge with strcpy is that when using it we do not specify the length of the target buffer nor of the source string. [...]

To make sure that the size checks cannot be separated from the copy itself we introduced a string copy replacement function the other day that takes the target buffer, target size, source buffer and source string length as arguments and only if the copy can be made and the null terminator also fits there, the operation is done.

Comments (83 posted)

GNU ddrescue 1.30 released

Version 1.30 of the GNU ddrescue data recovery tool has been released. Notable changes in this release include improvements to automatic recovery of a drive with a dead head, addition of a --no-sweep option to disable reading of skipped areas, and more.

Full Story (comments: 2)

Graham: [KDE] Highlights from 2025

Nate Graham looks back at how 2025 went for the KDE project.

Today Plasma is the default desktop environment in a bunch of the hottest new gaming-focused distros, including Bazzite, CachyOS, Garuda, Nobara, and of course SteamOS on Valve's gaming devices. Fedora's Plasma edition was also promoted to co-equal status with the GNOME edition, and Asahi Linux — the single practical option for Linux on newer Macs — only supports KDE Plasma. Parrot Linux recently switched to Plasma by default, too. And Plasma remains the default on old standbys like EndeavourOS, Manjaro, NixOS, OpenMandriva, Slackware and TuxedoOS — which ships on all devices sold by Tuxedo Computers!

Comments (11 posted)

Ruby 4.0 released

Once again there is a brand-new release under the tree from the Ruby programming-language project: Ruby 4.0 has been released with many new features and improvements. Notable changes include the experimental Ruby Box feature for in-process isolation of classes and modules, a new just-in-time compiler called ZJIT, and improvements to Ruby's parallel-execution mechanism (Ractor). There are a number of language changes as well. See the documentation for Ruby 4.0 for more.

Comments (none posted)

Development quote of the fortnight

There's a lot of AI-slop bashing, and sure, we now definitely need a policy too to protect ourselves from it becoming a time sink. But I think we shouldn't forget the often good intentions that are behind these contributions. There is an educational aspect here as well, especially for a younger generation of software developers who think AI gives them programming powers beyond their wildest dreams.

We honestly welcome contributions, but as guardians of our code base we often feel that the timing doesn't quite line up with our planning, the design choices don't quite match the existing or desired architecture, and now, with AI, it becomes easier than ever to put a lot of code on our doorstep to review. Contributors may feel they're doing something good, without considering the consequences on the receiving end.

So, I think our contributing guidelines should start with "Before you start coding, talk to us first."

— Alex Band

Comments (none posted)

A partial ruling in the Vizio GPL suit

The judge in the Vizio GPL-compliance lawsuit has ruled, in a summary judgment, that the GNU General Public License, version 2, does not require the provision of signing keys needed to install modified software on a device.

Read as a whole, the Agreements require Vizio to make the source code available in such a manner that the source code can be readily obtained and modified by Plaintiff or other third parties. While source code is defined to include "the scripts used to control compilation and installation," this does not mean that Vizio must allow users to reinstall the software, modified or otherwise, back onto its smart TVs in a manner that preserves all features of the original program and/or ensures the smart TVs continue to function properly. Rather, in the context of the Agreements, the disputed language means that Vizio must provide the source code in a manner that allows the source code to be obtained and revised by Plaintiff or others for use in other applications.

As the Software Freedom Conservancy, the plaintiff in the case, has pointed out, the judge has ruled against a claim that was never actually made.

SFC has never held the position, nor do we today hold the position, that any version of the GPL (even including GPLv3!) require "that the device continues to function properly" after a user installs their modified version of the copyleft components.

Linus Torvalds, meanwhile, has posted his own take on the ruling that has, as one might imagine, sparked an extended discussion as well.

Comments (40 posted)

CFP Deadlines: January 8, 2026 to March 9, 2026

The following listing of CFP deadlines is taken from the LWN.net CFP Calendar.

Deadline	Event Dates	Event	Location
January 12	March 28 March 29	Chemnitz Linux Days	Chemnitz, Germany
January 12	March 28	Central Pennsylvania Open Source Conference	Lancaster, Pennsylvania, US
January 31	April 10 April 11	Grazer Linuxtage	Graz, Austria
February 7	April 20 April 21	SambaXP	Göttingen, Germany
February 9	May 18 May 20	Open Source Summit North America	Minneapolis, Minnesota, US
February 14	April 23	OpenSUSE Open Developers Summit	Prague, Czech Republic
February 15	July 13 July 19	EuroPython	Kraków, Poland
February 15	April 27 April 28	foss-north	Gothenburg, Sweden

If the CFP deadline for your event does not appear here, please tell us about it.

Events: January 8, 2026 to March 9, 2026

The following event listing is taken from the LWN.net Calendar.

Date(s)	Event	Location
January 21 January 23	Everything Open	Canberra, Australia
January 29 January 30	CentOS Connect	Brussels, Belgium
January 31 February 1	Free and Open source Software Developers' European Meeting	Brussels, Belgium
February 2	OpenEmbedded Workshop 2026	Brussels, Belgium
February 2 February 4	Config Management Camp	Ghent, Belgium
February 17	AlpOSS 2026	Échirolles, France
February 24 February 25	Linux Foundation Member Summit	Napa, CA, US
March 5 March 8	SCALE	Pasadena, CA, US

If your event does not appear here, please tell us about it.

Alert summary January 1, 2026 to January 7, 2026

Dist.	ID	Release	Package	Date
AlmaLinux	ALSA-2025:23279	10	kernel	2026-01-06
AlmaLinux	ALSA-2025:14999	8	resource-agents	2026-01-07
AlmaLinux	ALSA-2025:23141	10	ruby	2026-01-06
AlmaLinux	ALSA-2025:23062	8	ruby:3.3	2026-01-07
AlmaLinux	ALSA-2026:0002	10	tar	2026-01-05
AlmaLinux	ALSA-2026:0025	10	thunderbird	2026-01-06
AlmaLinux	ALSA-2026:0026	8	thunderbird	2026-01-07
AlmaLinux	ALSA-2025:19434	8	xorg-x11-server	2026-01-07
Debian	DLA-4432-1	LTS	curl	2026-01-04
Debian	DLA-4431-1	LTS	gimp	2026-01-02
Debian	DSA-6093-1	stable	gimp	2026-01-04
Debian	DLA-4419-1	LTS	gst-plugins-good1.0	2025-12-25
Debian	DLA-4429-1	LTS	imagemagick	2025-12-31
Debian	DLA-4423-1	LTS	kodi	2025-12-28
Debian	DSA-6094-1	stable	libsodium	2026-01-05
Debian	DLA-4428-1	LTS	mediawiki	2025-12-30
Debian	DLA-4430-1	LTS	net-snmp	2026-01-01
Debian	DLA-4424-1	LTS	openjpeg2	2025-12-29
Debian	DLA-4426-1	LTS	osslsigncode	2025-12-30
Debian	DLA-4422-1	LTS	pgbouncer	2025-12-27
Debian	DLA-4427-1	LTS	php-dompdf	2025-12-30
Debian	DLA-4420-1	LTS	postgresql-13	2025-12-26
Debian	DLA-4425-1	LTS	python-django	2025-12-29
Debian	DLA-4421-1	LTS	python-urllib3	2025-12-26
Debian	DLA-4416-1	LTS	rails	2025-12-26
Debian	DLA-4433-1	LTS	ruby-rmagick	2026-01-05
Debian	DSA-6092-1	stable	smb4k	2026-01-01
Fedora	FEDORA-2025-28e625afa6	F43	chezmoi	2025-12-26
Fedora	FEDORA-2025-6d4139dafe	F42	delve	2026-01-01
Fedora	FEDORA-2025-3591ae9dd3	F43	delve	2026-01-01
Fedora	FEDORA-2025-614bda8830	F42	direwolf	2026-01-02
Fedora	FEDORA-2025-793e1e1341	F43	direwolf	2026-01-02
Fedora	FEDORA-2025-9cf9edf688	F42	docker-buildkit	2025-12-26
Fedora	FEDORA-2025-94f9b9b1b1	F43	docker-buildkit	2025-12-26
Fedora	FEDORA-2025-cfdb90b52d	F42	doctl	2026-01-04
Fedora	FEDORA-2025-714a42ffeb	F43	doctl	2026-01-04
Fedora	FEDORA-2025-d73e0a567d	F42	duc	2025-12-31
Fedora	FEDORA-2025-4d1c51d90a	F43	duc	2025-12-28
Fedora	FEDORA-2025-202d079b40	F42	fluidsynth	2025-12-29
Fedora	FEDORA-2025-16548b7718	F43	fluidsynth	2025-12-28
Fedora	FEDORA-2025-3b0fa1ac26	F42	gdu	2025-12-28
Fedora	FEDORA-2025-709790fda7	F43	gdu	2025-12-28
Fedora	FEDORA-2025-c6b2100f44	F43	gh	2026-01-02
Fedora	FEDORA-2025-55bf0b6949	F43	gitleaks	2026-01-04
Fedora	FEDORA-2026-e630ec5c0a	F42	gnupg2	2026-01-06
Fedora	FEDORA-2026-acea06489d	F43	gnupg2	2026-01-05
Fedora	FEDORA-2025-570618af7e	F42	golang-github-alecthomas-chroma-2	2025-12-30
Fedora	FEDORA-2025-cfdd59f20f	F43	golang-github-alecthomas-chroma-2	2025-12-30
Fedora	FEDORA-2025-be54db24e3	F42	golang-github-evanw-esbuild	2025-12-30
Fedora	FEDORA-2025-4068748872	F43	golang-github-evanw-esbuild	2025-12-30
Fedora	FEDORA-2025-f8e5522ee0	F42	golang-github-google-wire	2026-01-01
Fedora	FEDORA-2025-582e97b7b4	F42	golang-github-googlecloudplatform-cloudsql-proxy	2026-01-01
Fedora	FEDORA-2025-5906618a59	F43	golang-github-googlecloudplatform-cloudsql-proxy	2026-01-01
Fedora	FEDORA-2025-17f9c28389	F42	golang-github-jwt-5	2025-12-30
Fedora	FEDORA-2025-12b00d8e2c	F43	golang-github-jwt-5	2025-12-30
Fedora	FEDORA-2025-73b0006102	F42	golang-github-projectdiscovery-mapcidr	2025-12-31
Fedora	FEDORA-2025-1ba6ab39aa	F43	golang-github-projectdiscovery-mapcidr	2025-12-31
Fedora	FEDORA-2025-7da33c2d62	F43	grpcurl	2026-01-04
Fedora	FEDORA-2025-f7c75ffee2	F42	httpd	2025-12-25
Fedora	FEDORA-2025-a887e86abc	F42	kustomize	2025-12-31
Fedora	FEDORA-2025-ecfd96d6a3	F43	kustomize	2025-12-31
Fedora	FEDORA-2026-274010c760	F43	libpcap	2026-01-07
Fedora	FEDORA-2025-8caa129b2e	F42	nginx	2026-01-04
Fedora	FEDORA-2025-8aa169ea14	F43	nginx	2026-01-03
Fedora	FEDORA-2025-8caa129b2e	F42	nginx-mod-brotli	2026-01-04
Fedora	FEDORA-2025-8aa169ea14	F43	nginx-mod-brotli	2026-01-03
Fedora	FEDORA-2025-8caa129b2e	F42	nginx-mod-fancyindex	2026-01-04
Fedora	FEDORA-2025-8aa169ea14	F43	nginx-mod-fancyindex	2026-01-03
Fedora	FEDORA-2025-8caa129b2e	F42	nginx-mod-headers-more	2026-01-04
Fedora	FEDORA-2025-8aa169ea14	F43	nginx-mod-headers-more	2026-01-03
Fedora	FEDORA-2025-8caa129b2e	F42	nginx-mod-modsecurity	2026-01-04
Fedora	FEDORA-2025-8aa169ea14	F43	nginx-mod-modsecurity	2026-01-03
Fedora	FEDORA-2025-8caa129b2e	F42	nginx-mod-naxsi	2026-01-04
Fedora	FEDORA-2025-8aa169ea14	F43	nginx-mod-naxsi	2026-01-03
Fedora	FEDORA-2025-8caa129b2e	F42	nginx-mod-vts	2026-01-04
Fedora	FEDORA-2025-8aa169ea14	F43	nginx-mod-vts	2026-01-03
Fedora	FEDORA-2025-6968ab200a	F43	opentofu	2025-12-29
Fedora	FEDORA-2025-9ded4c3651	F42	ov	2025-12-26
Fedora	FEDORA-2025-0d2748fa32	F43	ov	2025-12-26
Fedora	FEDORA-2025-ec760de8e2	F42	proxychains-ng	2026-01-06
Fedora	FEDORA-2025-58fe871812	F43	proxychains-ng	2026-01-06
Fedora	FEDORA-2025-dda924d757	F42	retroarch	2025-12-25
Fedora	FEDORA-2025-6e0627440a	F43	retroarch	2025-12-25
Fedora	FEDORA-2025-fec36f9eaf	F42	roundcubemail	2025-12-25
Fedora	FEDORA-2025-58eb59741f	F43	roundcubemail	2025-12-25
Fedora	FEDORA-2025-3ff2f4efe3	F42	singularity-ce	2025-12-27
Fedora	FEDORA-2025-d3cd3e7cf0	F43	singularity-ce	2025-12-27
Fedora	FEDORA-2025-6b23a0b058	F43	subfinder	2025-12-26
Fedora	FEDORA-2025-419c60783f	F42	tkimg	2025-12-28
Fedora	FEDORA-2025-13b23a6952	F43	tkimg	2025-12-28
Fedora	FEDORA-2025-2e7d5d49f2	F42	usd	2026-01-03
Fedora	FEDORA-2025-f882263432	F43	usd	2026-01-02
Fedora	FEDORA-2025-3e5ba4315a	F42	webkitgtk	2026-01-02
Mageia	MGASA-2025-0333	9	ceph	2025-12-29
Mageia	MGASA-2026-0001	9	cups	2026-01-02
Mageia	MGASA-2025-0334	9	ruby-rack	2025-12-29
Oracle	ELSA-2025-23374	OL8	container-tools:rhel8	2025-12-24
Oracle	ELSA-2025-23543	OL8	container-tools:rhel8	2025-12-24
Oracle	ELSA-2026-0052	OL9	gcc-toolset-14-binutils	2026-01-06
Oracle	ELSA-2025-23948	OL8	grafana	2025-12-24
Oracle	ELSA-2025-23932	OL10	httpd	2025-12-24
Oracle	ELSA-2025-23919	OL9	httpd	2025-12-24
Oracle	ELSA-2025-23732	OL8	httpd:2.4	2025-12-26
Oracle	ELSA-2025-28068	OL7	kernel	2025-12-24
Oracle	ELSA-2025-28068	OL8	kernel	2025-12-24
Oracle	ELSA-2025-28068	OL8	kernel	2025-12-24
Oracle	ELSA-2025-28067	OL8	kernel	2025-12-24
Oracle	ELSA-2025-28067	OL9	kernel	2025-12-24
Oracle	ELSA-2025-28067	OL9	kernel	2025-12-24
Oracle	ELSA-2025-28066	OL9	kernel	2025-12-24
Oracle	ELSA-2025-23940	OL10	python3.12	2025-12-24
Oracle	ELSA-2025-23530	OL8	python39:3.9	2025-12-24
Oracle	ELSA-2025-23415	OL7	rsync	2026-01-06
Oracle	ELSA-2026-0002	OL10	tar	2026-01-06
Oracle	ELSA-2026-0067	OL9	tar	2026-01-06
Oracle	ELSA-2026-0025	OL10	thunderbird	2026-01-06
Oracle	ELSA-2026-0026	OL8	thunderbird	2026-01-06
Oracle	ELSA-2025-23856	OL9	thunderbird	2025-12-24
Oracle	ELSA-2025-28066		uek-kernel	2025-12-24
Red Hat	RHSA-2026:0008-01	EL10.0	brotli	2026-01-07
Red Hat	RHSA-2025:21633-01	EL10.0	buildah	2026-01-06
Red Hat	RHSA-2025:21634-01	EL9.6	buildah	2026-01-06
Red Hat	RHSA-2025:23543-01	EL8	container-tools:rhel8	2026-01-05
Red Hat	RHSA-2025:23374-01	EL8	container-tools:rhel8	2026-01-05
Red Hat	RHSA-2025:23740-01	EL8.2	go-toolset:rhel8	2026-01-05
Red Hat	RHSA-2025:23741-01	EL8.4	go-toolset:rhel8	2026-01-05
Red Hat	RHSA-2025:23733-01	EL8.6	go-toolset:rhel8	2026-01-05
Red Hat	RHSA-2025:23737-01	EL8.8	go-toolset:rhel8	2026-01-05
Red Hat	RHSA-2025:23948-01	EL8	grafana	2026-01-05
Red Hat	RHSA-2025:23736-01	EL9.0	grafana	2026-01-05
Red Hat	RHSA-2025:23747-01	EL9.2	grafana	2026-01-05
Red Hat	RHSA-2025:23746-01	EL9.4	grafana	2026-01-05
Red Hat	RHSA-2026:0112-01	EL9.2	mariadb	2026-01-06
Red Hat	RHSA-2026:0061-01	EL9.4	mariadb	2026-01-06
Red Hat	RHSA-2026:0111-01	EL9.6	mariadb	2026-01-06
Red Hat	RHSA-2026:0136-01	EL10	mariadb10.11	2026-01-06
Red Hat	RHSA-2025:21702-01	EL9	podman	2026-01-06
Red Hat	RHSA-2025:23326-01	EL9	skopeo	2026-01-05
Red Hat	RHSA-2026:0002-01	EL10	tar	2026-01-06
Red Hat	RHSA-2026:0135-01	EL10.0	tar	2026-01-06
Red Hat	RHSA-2026:0067-01	EL9	tar	2026-01-06
Slackware	SSA:2026-001-02		libpcap	2026-01-01
Slackware	SSA:2026-006-01		libsodium	2026-01-06
Slackware	SSA:2025-359-01		net	2025-12-25
Slackware	SSA:2026-001-01		seamonkey	2026-01-01
Slackware	SSA:2025-361-01		vim	2025-12-27
Slackware	SSA:2025-364-02		wget2	2025-12-30
SUSE	SUSE-SU-2026:0013-1	SLE15 oS15.4	ImageMagick	2026-01-05
SUSE	SUSE-SU-2026:0011-1	SLE15 oS15.6	ImageMagick	2026-01-05
SUSE	SUSE-SU-2026:0028-1	SLE15	alloy	2026-01-05
SUSE	openSUSE-SU-2025:15847-1	TW	anubis	2025-12-29
SUSE	SUSE-SU-2026:0019-1	MP4.3 SLE15 oS15.4	apache2	2026-01-05
SUSE	SUSE-SU-2025:4518-1	SLE15	apache2	2025-12-24
SUSE	SUSE-SU-2026:0020-1	SLE15 oS15.6	apache2	2026-01-05
SUSE	SUSE-SU-2025:4532-1	SLE15 oS15.6	apache2-mod_auth_openidc	2025-12-29
SUSE	SUSE-SU-2025:4526-1	SLE15 oS15.4	buildah	2025-12-26
SUSE	SUSE-SU-2026:0014-1	SLE15 oS15.5 oS15.6	buildah	2026-01-05
SUSE	openSUSE-SU-2025:15843-1	TW	buildah	2025-12-25
SUSE	openSUSE-SU-2025:0492-1	osB15	cheat	2025-12-31
SUSE	openSUSE-SU-2025:0482-1	osB15	cheat	2025-12-24
SUSE	openSUSE-SU-2026:10006-1	TW	dcmtk	2026-01-06
SUSE	openSUSE-SU-2026:10001-1	TW	dirmngr	2026-01-02
SUSE	SUSE-SU-2025:4534-1	SLE15 SLE-m5.5 oS15.5 oS15.6	dpdk22	2025-12-30
SUSE	openSUSE-SU-2025:0487-1	osB15	duc	2025-12-26
SUSE	openSUSE-SU-2025:0496-1	osB15	duc	2025-12-31
SUSE	SUSE-SU-2026:0023-1	SLE15 oS15.3 oS15.6	erlang26	2026-01-05
SUSE	openSUSE-SU-2025:0491-1	osB15	flannel	2025-12-31
SUSE	openSUSE-SU-2026:10004-1	TW	fluidsynth	2026-01-04
SUSE	SUSE-SU-2026:0018-1	SLE15 oS15.6	glib2	2026-01-05
SUSE	openSUSE-SU-2026:10000-1	TW	gnu-recutils	2026-01-02
SUSE	SUSE-SU-2025:4525-1	SLE-m5.4 SLE-m5.5 oS15.4	gnutls	2025-12-26
SUSE	openSUSE-SU-2025:0493-1	osB15	go-sendxmpp	2025-12-31
SUSE	openSUSE-SU-2025:0483-1	osB15	go-sendxmpp	2025-12-24
SUSE	SUSE-SU-2026:0037-1	oS15.6	govulncheck-vulndb	2026-01-06
SUSE	openSUSE-SU-2025:15854-1	TW	kepler	2026-01-01
SUSE	SUSE-SU-2025:4530-1	MP4.2 SLE15 SLE-m5.1 SLE-m5.2 SES7.1 oS15.3	kernel	2025-12-29
SUSE	SUSE-SU-2026:0029-1	MP4.3 SLE15 SLE-m5.3 SLE-m5.4 oS15.4	kernel	2026-01-05
SUSE	SUSE-SU-2025:4515-1	SLE12	kernel	2025-12-24
SUSE	SUSE-SU-2025:4517-1	SLE15	kernel	2025-12-24
SUSE	SUSE-SU-2025:4516-1	SLE15	kernel	2025-12-24
SUSE	SUSE-SU-2026:0032-1	SLE15 SLE-m5.2	kernel	2026-01-06
SUSE	SUSE-SU-2026:0033-1	SLE15 SLE-m5.3 SLE-m5.4	kernel	2026-01-06
SUSE	SUSE-SU-2026:0034-1	SLE15 SLE-m5.5 oS15.5	kernel	2026-01-06
SUSE	SUSE-SU-2025:4521-1	SLE15 oS15.6	kernel	2025-12-24
SUSE	openSUSE-SU-2026:10002-1	TW	libmatio-devel	2026-01-02
SUSE	SUSE-SU-2026:0036-1	oS15.6	libpcap	2026-01-06
SUSE	SUSE-SU-2025:4533-1	SLE12	libpng16	2025-12-30
SUSE	SUSE-SU-2026:0017-1	SLE15 oS15.6	libsoup	2026-01-05
SUSE	SUSE-SU-2025:4520-1	SLE12	mariadb	2025-12-24
SUSE	SUSE-SU-2026:0044-1	SLE15 SLE-m5.2 SLE-m5.3 SLE-m5.4 oS15.6	mozjs60	2026-01-07
SUSE	SUSE-SU-2026:0016-1	MP4.3 SLE15 oS15.3	pgadmin4	2026-01-05
SUSE	SUSE-SU-2026:0015-1	SLE15 oS15.6	pgadmin4	2026-01-05
SUSE	SUSE-SU-2025:4536-1	SLE15 SLE-m5.2 SES7.1 oS15.3	podman	2025-12-31
SUSE	SUSE-SU-2026:0010-1	SLE15 oS15.4 oS15.6	python-tornado6	2026-01-05
SUSE	SUSE-SU-2025:4538-1	SLE12	python3	2025-12-31
SUSE	SUSE-SU-2026:0027-1	SLE15 SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.3 oS15.6	python3	2026-01-05
SUSE	openSUSE-SU-2025:15849-1	TW	python311	2025-12-30
SUSE	openSUSE-SU-2026:10003-1	TW	python311-marshmallow	2026-01-03
SUSE	openSUSE-SU-2025:15848-1	TW	python311-openapi-core	2025-12-29
SUSE	openSUSE-SU-2026:10005-1	TW	python312-Django6	2026-01-04
SUSE	openSUSE-SU-2025:15850-1	TW	python312	2025-12-30
SUSE	SUSE-SU-2026:0025-1	oS15.6	python312	2026-01-05
SUSE	SUSE-SU-2026:0024-1	SLE15	python313	2026-01-05
SUSE	openSUSE-SU-2025:15851-1	TW	python313	2025-12-30
SUSE	SUSE-SU-2025:4539-1	SLE12	python36	2025-12-31
SUSE	SUSE-SU-2025:4522-1	oS15.3 oS15.6	python39	2025-12-26
SUSE	SUSE-SU-2026:0043-1	MP4.3 SLE15 SLE-m5.3 SLE-m5.4 oS15.4	qemu	2026-01-07
SUSE	SUSE-SU-2025:4523-1	SLE12	qemu	2025-12-26
SUSE	SUSE-SU-2026:0039-1	SLE15 SLE-m5.5 oS15.5	qemu	2026-01-06
SUSE	SUSE-SU-2026:0022-1	SLE15 oS15.6	qemu	2026-01-05
SUSE	SUSE-SU-2026:0041-1	SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.4	rsync	2026-01-06
SUSE	SUSE-SU-2026:0005-1	SLE12	rsync	2026-01-02
SUSE	openSUSE-SU-2026:20002-1	oS16.0	thunderbird	2026-01-03
SUSE	openSUSE-SU-2025:15852-1	TW	trivy	2025-12-30
SUSE	openSUSE-SU-2025:0490-1	osB15	trivy	2025-12-30
SUSE	openSUSE-SU-2025:0489-1	osB15	trivy	2025-12-30
SUSE	SUSE-SU-2026:0042-1	SLE15 oS15.4 oS15.6	usbmuxd	2026-01-06
SUSE	SUSE-SU-2025:4527-1	MP4.3 SLE15 oS15.4	webkit2gtk3	2025-12-26
SUSE	SUSE-SU-2025:4528-1	SLE12	webkit2gtk3	2025-12-26
SUSE	SUSE-SU-2026:0021-1	SLE15 oS15.6	webkit2gtk3	2026-01-05
SUSE	SUSE-SU-2026:0012-1	SLE15 oS15.6	xen	2026-01-05
Ubuntu	USN-7942-1	22.04 24.04 25.04 25.10	glib2.0	2026-01-06
Ubuntu	USN-7922-4	18.04 20.04	linux-raspi, linux-raspi-5.4	2026-01-06
Ubuntu	USN-7941-1	22.04 24.04 25.04 25.10	webkit2gtk	2026-01-05

Full Story (comments: none)