Welcome to the LWN.net Weekly Edition for April 30, 2026

This edition contains the following feature content:

• Famfs, FUSE, and BPF: more delays in the long-running effort to merge the famfs filesystem.
• Python packaging council approved: steering council approves a PEP that creates a new body with authority over packaging standards, tools, and implementations.
• Zig explores structured concurrency: a look at a new interface to make writing correct concurrent applications easier with Zig.
• On pages and folios: a reference on pages and portfolios, as well as the state of the kernel's transition to folios.
• Strawberry is ripe for managing music collections: a music-management application with a classic interface and long history.
• The rest of the 7.1 merge window: more interesting changes coming to the next kernel release.

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)

Famfs, FUSE, and BPF

The famfs filesystem first showed up on the mailing lists in early 2024; since then, it has been the topic of regular discussions at the Linux Storage, Filesystem, Memory Management and BPF (LSFMM+BPF) Summit. It has also, as result of those discussions, been through some significant changes since that initial posting. So it is not surprising that a suggestion that it needed to be rewritten yet again was not entirely well received. How much more rewriting will actually be needed is unclear, but more discussion appears certain.

Famfs is designed to support large, read-mostly filesystems stored in shared memory. In practice, this means huge data sets kept in CXL-attached memory that is made available to multiple systems simultaneously. In normal usage, software running on those systems will access this data by mapping it directly into its address space with mmap(), so that the data is all immediately accessible without system calls, and without going through the system's page cache. It is possible to perform normal filesystem reads and writes, though write access is only minimally supported.

In its initial form, famfs was implemented like any other standalone filesystem, but it included a user-space component that drew a fair amount of attention from the filesystem developers at the 2024 LSFMM+BPF session. Given that some of famfs is already implemented in user space, they suggested, it might be better to just use FUSE, which was designed for just that kind of filesystem. At the time, famfs creator John Groves said that he was unsure about whether FUSE would work, but would be willing to give it a try. His concern was that famfs must operate at memory speeds, and could thus not afford to call into user space to resolve page faults.

At the 2025 LSFMM+BPF gathering, Groves returned with a shiny new FUSE-based implementation that appeared to have solved that problem. It introduces two new FUSE operations toward that goal. GET_FMAP is invoked when a file is opened; the user-space server responds by providing the kernel with a list of memory locations and lengths, providing a map of how the file is laid out in shared memory. Thereafter, the kernel is able to resolve page faults without having to go back to user space for more information. The other operation, GET_DAXDEV, provides information about the CXL devices on which the shared memory is hosted.

There did not appear to be fundamental objections to the FUSE implementation. Over the following year, Groves worked on refining the code; when he posted version 10 at the end of March, he had every reason to believe that the work, which he had described in February as having been "kinda hard", was close to ready for merging into the mainline. But, as he discovered, merging is never certain until it actually happens.

Better done in BPF?

Joanne Koong, who has done a fair amount of work with FUSE over the years, asked a seemingly simple question:

I'm curious to hear your thoughts on whether you think it makes sense for the famfs-specific logic in this series to be moved to a bpf program that goes through a generic fuse iomap dax layer.

Changing the code in that way, Koong suggested, would make the FUSE logic more extensible and applicable to other types of filesystems. It would also bring more flexibility to famfs, making it easier, for example, to adjust to changes to files after they have been opened, and allowing famfs updates to be made available more quickly to users, since they would not have to wait for the usual kernel release cycle. She also said that she had posted a prototype implementation of a BPF-based famfs back in November, and suggested that switching over to this approach would not involve a huge rewrite of the famfs code.

The FUSE maintainer is Miklos Szeredi; he entered the conversation saying that he would prefer to avoid adding a famfs-specific FUSE interface if it could be avoided. The BPF idea thus appealed to him; he suggested that it should be given a try before considering a merge of the existing famfs patches.

It is fair to say (and understandable) that Groves was not entirely pleased by this turn in the conversation. He would, he said, "object vehemently" to being required to undertake this rewrite before the code could be merged. The current implementation, he said, matches what had been asked of him two years ago. He later added that there would be some real risks involved with the BPF approach, starting with the fact that he would have to learn how to work with BPF, and the performance impacts of such a change would be unknown. The current version is already shipping to users, he said; it is too late to demand such changes now.

Possible solutions

The purpose of the famfs user-space component is to determine where the extents of a given file have been placed in memory and to inform the kernel of those placements. The BPF alternative would work similarly, with user space providing that information in a filesystem-independent way; the BPF program would then provide the filesystem-specific interpretation for the rest of the kernel. One possibility, for example, could be for user space to store the extent information in either a BPF map or an arena.

Various attempts at a solution along these lines exist already. As Darrick Wong pointed out in the discussion, he had posted one such in February, based loosely on Koong's work. In short, it provides access to the kernel's iomap layer, with BPF hooks to help FUSE filesystems complete the mappings. Wong complained that he had not gotten any review responses, and expressed disappointment with the pace of reviews in the FUSE subsystem in general. He thought that a BPF-based implementation could be upstreamed within two development cycles — if the relevant maintainers would accept it. Whether that would happen, he suggested, is far from clear:

The issues I was alluding to are BPF being used as a means to get around slow/unresponsive maintainers; and the kernel community's collective refusal to explore any other path to building new user APIs besides designing everything generically perfectly up front in the kernel UABI along with all the stress that involves.

Rather than trying to develop the perfect API from the beginning, he later said, the best approach might be to merge famfs in its current form, then experiment with alternative approaches afterward. If the interface is carefully designed, it should be possible to move to a better one in the future, should one be found. Others in the conversation also suggested that this might be the best way. Christoph Hellwig, though, was strongly against that idea, saying that the multitude of approaches under consideration showed that more thought needed to be put into designing a single interface.

Gregory Price, meanwhile, complained that working software was being held back in favor of an unproven approach that might well offer worse performance; "John is right to push back here". But he also suggested that the existing interface might, in fact, be more generic than it appears, and could be the basis for a longer-term solution as well:

That said - I'm looking at fs/fuse/famfs.c and I'm asking myself what in here is actually famfs-specific. If you just s/FAMFS/DAX/g - the file just reads like a simple DAX-iomap backend with optional striping.

Would it be reasonable to refactor the dax layer (and users) to create an ops structure that becomes the basis for the BPF solution?

That led memory-management developer David Hildenbrand to ask whether the BPF solution would be acceptable to the memory-management developers, a question that Groves was also acutely interested in. If the answer is "no", Groves said, much of the discussion described here would be moot. Meanwhile, he added, he had just received a prototype implementation from Price that could be interesting; Price then described that solution, which involves a BPF callback at file-open time to do the equivalent of the GET_FMAP call.

As of this writing, Groves is evaluating how well Price's prototype implementation will work. It seems clear, though, that no conclusion will be reached in the email discussion. The next LSFMM+BPF meeting, as it happens, is the first week in May. That will be the perfect opportunity to lock the filesystem, memory-management, and BPF developers into the same room and deprive them of beer until they come up with a solution that all can live with.

Comments (18 posted)

Python packaging council approved

The Python packaging world now has a formal governance council, of the form described in PEP 772 ("Packaging Council governance process"), which was approved by the steering council on April 16. It has been over a year since the PEP was first proposed in February 2025 and it has undergone lengthy discussions in multiple postings to the Python discussion forum. The packaging council will have "broad authority over packaging standards, tools, and implementations"; it will consist of five members who will be elected in a vote that is likely to come in June—after PyCon US 2026 is held mid-May.

The packaging council is modeled on the steering council and the more recent typing council. It is meant to be the decision-making body for Python packaging; the steering council will explicitly delegate its PEP-deciding role for relevant PEPs to the packaging council. Currently, the steering council has appointed Paul Moore and Donald Stufft as delegates to decide on packaging PEPs under the auspices of the Python packaging authority (PyPA).

The PyPA is a loose organization of packaging projects; it predates PEP 609 ("Python Packaging Authority (PyPA) Governance") from 2019 that set out to document how the group operates. The Packaging working group was set up by the Python Software Foundation (PSF) to help organize packaging projects, some of which attracted grants from sponsors, such as the overhaul of the Python Package Index (PyPI) in 2017. As PEP 772 points out, however, neither of those two groups has a "community elected body", which is what the PEP is meant to address.

Various hurdles

The makeup of the "Python packaging community", thus who gets to vote on the members of the packaging council, has been a difficult thing to work out. When the PEP was first discussed, there was a somewhat complicated mechanism to seed the initial group of "community members" (who were the voting members), along with a way for those who did not qualify to be voted into the group. As Charlie Marsh, developer of the uv package manager, pointed out, he and his colleagues would not qualify because uv was not part of the PyPA and the company behind it is not a nonprofit. There was widespread agreement that the nonprofit requirement should be removed, but the discussion made it clear that putting a box around the Python packaging community was going to be extremely difficult to do.

When an updated PEP was posted for comments in May 2025, after the Packaging Summit held at PyCon US 2025, an entirely different way to define voting members was proposed. Instead of trying to be somewhat exclusionary and finding some way to define what a packaging-community member "looked like", the electors for the packaging council were aligned with the PSF membership. As Barry Warsaw, who authored the PEP along with PSF executive director Deb Nicholson and PyPA member Pradyun Gedam, put it in the post, using PSF membership:

simplifies the whole question and can encompass everyone. If you contribute to a PyPA project, or CPython, or the Python community or ecosystem, you are clearly a Contributing Member. If you instead prefer to act as a Sponsoring Member by donating to the PSF, then you're a PSF Member too, and can receive a ballot to vote in Packaging Council elections. Everyone who wants to vote, can!

Contributing members of the PSF simply self-certify that they volunteer at least five hours per month on projects that advance the mission of the organization.

The other major change with the PEP revision was to give more explicit oversight of the packaging council to the steering council. That fits with the steering council's overall technical-oversight role. Steering council members would also be prohibited from concurrently serving on the packaging council. The response to that update was generally favorable, with a few queries for clarification, small suggestions for updates, nitpicks, and so on.

That led to the posting of round three in July 2025 with a strong sense that the PEP was on track to start the process for approval. Because the PEP touched on multiple parts of the Python ecosystem—PyPA, PSF, and CPython itself—it required more than the usual steering-council approval. The PSF board needed to approve it, as did the PyPA following its process in PEP 609; once those two did so, the steering council would get its turn.

Re-approval

After the PSF board had voted to approve the PEP in August, there was an abortive attempt to have the PyPA vote on it. Voting was opened on September 4, but canceled a few days later. There were several problems with the PEP that were raised, by Bernát Gábor and Adam Turner in particular, but the two main sticking points were opening up the voting to all PSF members and quorum questions when there are multiple packaging-council members from the same organization.

There was discussion throughout September, but the bottom line was that the PEP authors (and other contributors to the drafting process) could not come up with a better way to define the electorate, Warsaw said in a lengthy post:

I don't have a point-by-point breakdown of all the issues that we identified, but I will say that trying to come up with a broad and equitable membership plan under the previous version was the most contentious issue, and the more we found flaws in that approach, the more the authors and other participants soured on it. I simply don't think it can be made workable. Speaking as one of three co-authors of the PEP, I have zero motivation to go back.

Is the PSF membership requirement perfect? Of course not! But I strongly believe it's the most equitable and workable. PSF membership is open to any stakeholder who wants to participate.

Those who were unhappy with the definition of the electorate seemed to grudgingly accept that it was the "least bad" choice, though Moore requested that the eligibility and registration requirements to vote for the packaging council be prominently documented. A PEP update made in mid-December covered that request. The quorum question was more difficult, however.

Gábor was concerned that, since the PEP allowed up to two council members from the same company or organization, the quorum of three might effectively allow a single entity to dictate packaging policy at times. He wanted to see a clause that required members from three separate employers if there is a vote being taken by only three. Several did not think that would become a problem in practice; Brett Cannon noted that he could not remember a vote of only three steering-council members in his five years on it. "Plus I think there would be major yelling from the rooftops if two people got elected to any of these councils who put their employer before the community."

However, several also said that there would be no harm in adding a restriction like what Gábor was advocating. Carol Willing thought it might be better to phrase it somewhat differently to say that the majority on any vote "must include individuals from more than one organization/company". After describing some of the problems the Astropy community ran into with a similar clause, Thomas Robitaille suggested a simpler way forward: making the steering council the final arbiter of conflicts of interest. Warsaw agreed and added that to the PEP.

Final approval

Things went quiet for a few months, until PSF board member Jannis Leidel asked about the PEP's status on December 11. In a followup, he noted that the PSF board had approved an earlier version of the PEP and not the current one, which likely meant that the PEP text needed to be frozen and resubmitted. Gedam described the process for getting the PEP over the finish line on December 14 (in post number 100 of the third round of discussion); given the upcoming holidays, he was hopeful that the PEP could be approved by February.

That turned out to be a little overambitious. The PSF board approved the PEP on March 23 with a change to the conflict-of-interest wording. The steering council would be the arbiter for technical conflicts of interest, while the PSF board would be "the final arbiter for conflicts of interest related to governance for the Packaging Council". The PyPA vote started on April 6 and completed on April 14 with a unanimous adoption by the 30 voters. Just a few days later, the steering council chimed in and PEP 772 had—finally—been adopted.

While there were some hiccups along the way, establishing the packaging council will be a boon to the packaging community. With luck, it will potentially help the various package-management sub-communities—pip, conda, uv, and others—converge, or at least to cooperate and collaborate more. In the meantime, the PEPs currently under review, PEP 808 ("Including static values in dynamic metadata") and PEP 825 ("Wheel Variants: Package Format"), will proceed with Moore as the PEP delegate. The election of the inaugural packaging council will likely need to wait until June, but those interested in running will want to ensure they are PSF members, as that is required to either vote for or serve on the council. It will be interesting to see where things go from here; stay tuned ...

Comments (2 posted)

Zig explores structured concurrency

Version 0.16.0 of the Zig programming language was recently announced, and with it an expanded version of the new Io interface that we covered in December. The new interface is based on an idea called structured concurrency that makes writing correct concurrent applications easier. Zig's implementation of the idea is more explicit and verbose than other languages, however, which could offer an opportunity to explore the consequences of different designs.

Asynchronous background

Rather than special syntax to support asynchronous functions, Zig now has a new interface (i.e., a structure full of function pointers) that can be used to invoke functions asynchronously or concurrently. That distinction is important: the provided async() function invokes a callback that can be run simultaneously in another thread, but the concurrent() function invokes a callback that must be run in another thread. Like Zig's existing allocator API, an instance of the Io interface is passed around to functions that need to perform I/O operations, including introducing asynchronicity.

Both async() and concurrent() return a "future" (an object of type Future). Those objects have an await() method that waits for them to complete, and a cancel() method that cancels the future if possible. The methods are idempotent — it is legal to call await() multiple times, or to call cancel() on a future that has already been waited on. Similarly, both methods return the value of the future if it has already finished. This design makes it relatively simple to clean up any allocations or other resources associated with a future, because it is always permissible to cancel a future and clean up whatever the cancel() function returns, regardless of the future's state.

The documentation gives an example of what this could look like in a real program. The example asynchronously invokes a function foo() that returns a pointer to some kind of resource once the task is finished. If the task is canceled before it can finish, the return value will be null, which the example checks for using the fact that if statements in Zig can directly test whether a pointer is null. The defer statement ensures that the cleanup is run when the current function exits.

    var foo_future = io.async(foo, .{foo_args, ...});
    defer if (foo_future.cancel(io)) |resource| resource.free() else |_| {}

When the function containing this code exits, the future will be canceled, which does nothing if it was already complete. Any returned resources are cleaned up. Compare this to Rust's version of the same concept:

    let foo_future = foo(foo_args, ...);

That Rust code does the same thing: when the function ends, the future will be canceled and any returned resources will be cleaned up. The Rust version has less boilerplate, although that does also mean that the cleanup code has to be generic, and can't be customized for a particular situation (or perform its own asynchronous I/O). The implicit design has given Rust some sharp edges related to canceling asynchronous tasks. The ability to customize cleanup code gives Zig an easier way to encapsulate a particular pattern for asynchronous code into a library.

Structured concurrency

The basic design described above is no different than previously reported. What is new is a set of standard-library modules for handling asynchronous operations and documentation on how to use this new interface to avoid some common problems with asynchronous code in other languages. The Io.Group interface, for example, allows managing a batch of asynchronous tasks that all share the same lifetime. The tasks added to a group are all canceled or waited on at once. The Io.Select interface builds on top of that to make it possible to start many operations in parallel and wait for the first to finish, canceling the others.

This approach is not exactly new. Erlang has offered various ways to structure asynchronous and concurrent operations since the 1970s, for example, although its ideas have not penetrated the mainstream. More recently, programming-language designers have begun experimenting with the idea of structured concurrency as a way to handle the complexity of asynchronous operations. Structured concurrency was first outlined by Martin Sústrik in 2016. It suggests applying the same discipline to concurrent processes that Edsger Dijkstra's structured programming did to the use of goto statements: restrict the shape of programs such that the control flow is clear from examining the structure of the source code. The idea was later expanded on by the Trio Python library, and eventually adopted by the Swift and Kotlin programming languages as part of their standard libraries. Other languages, such as Rust, have third-party libraries inspired by the same idea.

Each of these takes on the idea implements a slightly different interface, but the basic idea of a "group" of tasks that are all awaited as one is present in all of the implementations — though Trio calls it a "nursery" and Kotlin calls it a "coroutine scope". This is a relatively straightforward notion, but it's easy to see how it makes the relationship between the lifetime of asynchronous tasks simpler to reason about. Other parts of the designs have less in common. Task cancellation, for example, is something that every language handles differently.

Zig, as explained above, handles task cancellation explicitly, with the cancel() method. Kotlin does the same, except that it propagates cancellation through an entire tree of tasks, instead of requiring the programmer to decide explicitly how cancellation should propagate. Rust's task cancellation is implicit: a task is effectively canceled as soon as no other code is interested in polling for its result. Trio relies on Python's support for exceptions; each task periodically checks whether it has been canceled, and if so, it raises a Cancelled exception. Swift uses a system much like Trio's, except that the type system ensures that CancellationError exceptions can only come from specific, annotated points.

To some extent, this kind of variation is inevitable, since the different languages have their own design aesthetics and priorities. But cancellation is such an important component of writing correct asynchronous programs that the inconsistencies between languages prevent them from really agreeing on a common definition for "structured concurrency". For example, if one task in a group runs into an error, should the entire group be canceled? In Trio, the answer is "yes", although the library allows programmers to separate out "cancellation scopes" from nurseries to exercise finer control. Swift and Kotlin don't offer that affordance, but they do differ in how exceptions are propagated through a tree of asynchronous tasks. Zig leaves it all up to the programmer. When every implementation disagrees about how to handle cancellations of tasks in a group, it makes it hard to claim that structured concurrency is really the same between languages.

Structured programming was a wild success, to put it mildly. Almost every programming language has a concept of an if statement or a while loop, and they nearly all work the same way. Some languages make these constructs into expressions, but the basic control-flow remains the same. For loops are more complicated, and the details frequently vary from language to language. The languages that lack these constructs (for example, Prolog) are typically outliers in other ways as well. In a real way, structured programming successfully identified a core set of control-flow primitives that were so useful and versatile that they were adopted across the world of programming.

Structured concurrency does not, so far, match up. It's clearly a useful idea, given that the number of implementations has been slowly growing over the past decade. And yet those implementations agree on few details beyond the core idea of a group of asynchronous tasks. Designs and intuitions built up with Zig's implementation do not transfer cleanly to Swift, or to Kotlin, and vice versa.

Zig's take on the idea is more verbose and explicit than the other languages, which is both a blessing and a curse. On the one hand, Zig programmers will have to deal with more boilerplate. On the other hand, Zig's explicitness makes it possible to experiment with details such as how results are stored, how cancellation is handled, and how these things are packaged up into a usable interface. Zig is a rapidly evolving language, and the developers have no problem with changing the standard-library APIs when better ideas come along — at least until version 1.0.0 arrives, which still appears to be some ways off. Perhaps Zig's adoption of structured concurrency in the standard library could provide an interesting playground to experiment with variations on the design. In the remote chance that there is a design as timeless and universal as the while loop waiting to be found, the investigation would be well worth it.

Comments (1 posted)

On pages and folios

The kernel coverage here at LWN often touches on memory-management topics and, as a result, tends to talk a lot about both pages and folios. As the folio transition in the kernel has moved forward, it has often become difficult to decide which term to use in writing that is meant to be both approachable and technically correct. As this work continues, it will be increasingly common to use "folio" rather than page. This article is intended to be a convenient reference for readers wanting to differentiate the two terms or understand the state of this transition.

Pages

Memory in all but the smallest of computing systems is divided into regularly-sized units called "pages"; the most common page size is 4KB, but there are systems that run with larger page sizes. A page is the smallest unit that the system's hardware units, including the memory-management unit and translation lookaside buffer (TLB) work with. When memory is swapped in or out, or when it is moved between NUMA nodes in a larger system, it is moved in chunks that are an integral number of pages. Pages are thus fundamental to the management of memory in Linux systems.

This structure is reflected in the way virtual addresses work. On a 64-bit x86 system with a 4KB page size, the upper 52 bits (the "page-frame number" or "PFN") identify the page referred to by the address, while the bottom 12 bits give the offset within the page:

Naturally, the full story is a bit more complex than that, starting with the fact that the PFN is really a physical concept, not a virtual one, so the usage here is a bit sloppy — the real page-frame number is only found as part of the address-translation process. Also, the PFN does not usually occupy the full upper 52 bits. Logically, the PFN can be looked at as an index into a large table that stores information about each page, most importantly whether it is resident in RAM and, if so, what its physical address is. In practice, the PFN is split into a maximum of five (as of this writing) nine-bit (on x86-64 systems) indices, each of which is an index into a different table; those tables are then organized into a hierarchy:

This structure enables a far more efficient representation of the page tables, and it also, as we will see, comes into play in how huge pages are implemented. On the other hand, it makes for expensive memory access. Every time the CPU encounters a virtual address, it must translate it into a physical address; that means iterating through that series of five levels of page tables, which is going to be slow. To minimize that expense, CPUs maintain a translation lookaside buffer to cache the result of address translations. If a given PFN is in the TLB, the translation will happen quickly; otherwise it will be slow. The TLB is not huge, so a lot of attention goes into ensuring that code uses the TLB efficiently.

The system memory map and struct page

The kernel needs to keep track of how every page of memory is being used — that is what "memory management" is all about, after all. To that end, it maintains a large array of page structures, one for each page of physical memory in the system. This structure has been made as small as kernel developers can get it, but it still (typically) requires 64 bytes. As a result, on a system with 4KB pages, the associated page structures occupy 1.6% of physical memory. That is a cost that the kernel community has long wanted to reduce.

The page structure has been used throughout the kernel for many years to refer to specific pages of physical memory. At times this ubiquity has proved to be problematic; struct page is a core memory-management data structure, but code in other parts of the system often make surprising use of its fields. Current work in the memory-management subsystem is reducing the importance of struct page, which may, someday, wither away altogether.

Huge pages

One way to get better use out of the TLB is to have each TLB entry cover a larger area of memory — to make the page size larger, in other words. Most contemporary CPUs implement a huge-page mechanism that does exactly that. In essence, the CPU implements the smallest huge-page size by taking the PTE portion of the page-frame number and turning it into the offset within a larger page instead:

The entry at the PMD level of the page tables is specially marked to indicate that the PFN stops there and points to a 2MB huge page (again, on x86; other architectures can vary somewhat but the idea remains the same). For this reason, this type of huge page is often referred to as a "PMD-level" (or just "PMD") huge page. By extending the range of a TLB entry from 4KB to 2MB, huge pages can significantly increase the amount of memory that can be addressed without having to go through the whole translation routine.

Traditionally, applications had to explicitly request huge pages to be able to make use of them. The transparent huge page (THP) feature makes it possible for the kernel to provide PMD-level huge pages to user space automatically in situations where it appears that they will help performance. THPs are not always a performance win; they can cause a lot of memory waste if the pages are only sparsely used and they stress the memory-management system more, so they can slow some workloads down. For this reason, the feature ends up being disabled on some systems.

Larger huge pages exist as well; a PUD-level huge page removes the PMD layer of the page-table hierarchy, yielding a 1GB page size. Such pages can be somewhat unwieldy to work with and can be difficult for the memory-management subsystem to reliably supply, but one common use case is to allocate them for use by virtual machines, which manage them internally, in smaller chunks, as the virtual machine's "physical" memory.

More recent processors have gained a separate, not-so-huge-page concept. Some x86 processors can mark a TLB entry as covering eight pages, and some Arm processors can perform a similar trick with 16-page chunks. That, again, allows the TLB to cover more of working memory, but without requiring the use of 2MB (or larger) huge pages. The result of these changes is that the sizing of huge pages is becoming more flexible; the term "mTHP" (multi-size transparent huge page) is often used for these smaller page clusters.

Folios

Even in the absence of huge pages, the kernel has long needed to work with larger chunks of physically contiguous memory. The concept of compound pages was added to the 2.6.6 kernel release in 2004 as one way of organizing such a chunk; a compound page is a power-of-two-sized group of pages managed, for a period of time, as a single unit. Since a compound page consists of at least two physically contiguous pages, it is represented by an equal number of adjacent page structures. The kernel takes advantage of this fact by treating the page structure for the first ("head") page as representing the whole set, and storing related information in the page structures for the following ("tail") pages.

Back in 2021, Matthew Wilcox noticed that there was a lot of kernel code that could be handed either a compound page or a single ("base") page, with the base page being perhaps located within a compound page. A surprising amount of overhead went into ensuring, in many places in the kernel, that any passed-in struct page pointer referred to the head page of a compound page, or to a solitary base page. He decided to improve the kernel's internal APIs to reduce that overhead. The result was the "folio", which was defined as a struct page that is known not to represent a tail of a compound page. After some significant discussion, the initial folio patches were merged for the 5.16 release at the beginning of 2022.

It became evident fairly quickly, though, that the folio concept has uses far beyond reducing the overhead of supporting compound pages. For decades, kernel developers have contemplated managing memory in larger chunks; the 4KB page size is unchanged from the 1990s, even though the amount of installed memory has grown by several orders of magnitude since then. Contemporary systems have to manage vast numbers of pages, and the associated overhead, in terms of both CPU and memory use, hurts. But attempts to move to larger pages have generally been thwarted by other costs, primarily the lost memory due to internal fragmentation.

What was needed was a way to deal with memory in variably sized chunks, rather than working with one fixed size (and, perhaps, the vastly larger huge-page sizes). Folios have, since their introduction, been evolving into that way. Over time, areas of the kernel that dealt with pages have been modified to work with variably sized folios instead.

For example, consider the page cache, which caches portions of files in memory to speed access. The page cache once, true to its name, cached data one page at a time. Now, though, it would be more properly called the "folio cache", with the ability to cache file contents in appropriately sized folios. A small file might well fit within a single-page folio in the page cache, while a much larger file could be cached in a relatively small number of large folios. Making this work required a lot of changes to the memory-management subsystem, the readahead code, and the individual filesystems as well.

To see how far this transformation has progressed, compare the definitions of struct address_space_operations, which (to simplify) describes the functions that move data between the page cache and the underlying persistent storage, from the 5.16 kernel (when folios were introduced but not yet widely used) and 7.0-rc5. The readpage() method is now read_folio(), many other methods have been changed similarly, and none of them take struct page arguments in the current version. These changes were not easy, but they allow the management of the page cache at varying levels of granularity, enable the support of filesystems with block sizes larger than the system page size, and ease the creation of larger (more efficient) I/O operations.

Anonymous memory for user-space processes has also traditionally been allocated and managed one page at a time. The addition of transparent huge pages helped in some situations, but THPs are too large to be a net performance improvement for many workloads. Instead, mTHPs are easier to work with, waste less memory through internal fragmentation, and can boost performance significantly; folios can represent them nicely within the kernel. The work to make full use of mTHPs is still ongoing, and may take a while yet to settle, but mTHPs may prove to be a more generally applicable performance enhancement than PMD-level huge pages for many workloads.

One significant advantage of moving to folios for both the page cache and anonymous memory is the effect on the kernel's least-recently-used (LRU) lists, which are used to identify which pages (now folios) have not been accessed for a while and should be considered for reclamation. Large numbers of pages lead to extremely long LRU lists, which are more expensive for the kernel to manipulate. Managing folios in those lists makes them shorter, again improving performance.

Within the kernel, folios are represented by struct folio. Since the introduction of folios, this structure has been carefully designed to overlay struct page (more correctly, it overlays the first four page structures representing a large folio). That work has been done to ensure that the folio structures are made up of valid page structures, allowing the transition to folios to be implemented incrementally. There will come a time, though, when struct folio will become entirely separate from struct page, but that will require some fundamental changes to the system's memory map.

Shrinking the memory map

As mentioned above, the kernel's memory map itself takes up a significant amount of memory, which developers would like to see put to better uses. The static nature of the map means that there must be a page structure for each physical page, and that said structure must be large enough to handle all of the possible uses to which a page might be put. Making the map more dynamic offers the hope of reducing its memory footprint considerably.

The eventual plan is to replace struct page with an eight-byte memory descriptor; it can be thought of as a pointer to a type-specific structure describing the memory in question, though the real story is a bit more complex. For memory that is organized into folios, the folio structure will be the descriptor. Unlike page structures, though, there would only need to be a single folio structure regardless of how many pages the folio holds. There would still need to be a descriptor entry for each PFN, but the entries in the memory map for the base pages that make up a single folio would all point to a single folio structure. There will be other descriptor types for other memory uses, including slab pages, page tables, and so on. See this page for a description of the descriptor types and how they are expected to work.

The memory-descriptor work is underway, and may take years yet to complete. This sort of transition in a production kernel can be compared to replacing the foundation of building that is in heavy use; it is not a small task. But the fundamental rethinking of the memory-management subsystem that was kicked off by the introduction of folios is moving quickly and has already shown some significant results.

Comments (12 posted)

Strawberry is ripe for managing music collections

There are dozens of music-player applications for Linux; the options range from bare-bones programs that only play local files to full-blown music-management projects with a full suite of tools for managing (and playing) a music collection. Strawberry is in the latter category; it has a bumper crop of features, including smart playlists, support for editing music metadata tags, the ability to organize music files, and more.

Strawberry is something of an old-school music manager; it is designed for users who are serious about maintaining a local music collection rather than simply consuming whatever is available via streaming services. Its set of features includes just about everything users need for importing new music, creating playlists for every occasion, and weeding out duplicate songs, as well as maintaining an accurate and searchable database of the collection. It's written in C++, uses the Qt 6 framework, depends on GStreamer for codec support, and is available under the GPLv3.

Growing Strawberry

Creator and maintainer Jonas Kvinge released the first version of Strawberry, which got its name from the English rock band Strawbs, in 2018. Its origins go back quite a bit farther than that, though. One might say that Amarok planted the seed for the project.

Kvinge had started working on a fork of the Clementine music player in 2013, because he wanted to take it in a different direction. Specifically, he wanted to focus on local music collections instead of music stored on cloud services, and to drop features, such as ripping CDs, that are better handled by other programs.

The Clementine project was also born out of a desire to go in a different direction than its predecessor; it started in 2010 as a fork of the Amarok music player's 1.4 release after Amarok 2.0 was released with a completely redesigned, but not universally beloved, user interface. Clementine's developers ported the Amarok 1.4 code base to the Qt 4 framework and carried on where it left off.

Like many folks, I didn't care for the Amarok redesign, and started using Clementine instead. Unfortunately, that project stopped receiving updates in early 2016, so it was fortunate that Kvinge decided to launch his fork not long afterward. Clementine development seems to have picked up again after a long absence; there are signs of life in its Git commit history and automated releases being published on GitHub; however, the front page of the project's web site still advertises the 1.3.1 release from April 2016.

Strawberry, meanwhile, has remained active since it appeared on the scene. The project's last major release, which dropped support for Qt5 and shed some unmaintained features, was the 1.2.1 release in 2024. The most recent minor release, 1.2.19, came out on April 17, 2026; it included a new shuffle mode and several bug fixes. Kvinge is the most active contributor by far, with more than 1,000 commits in the past two years. There are about 40 other contributors who show up in the commit history in the same time period, but all of their contributions are in the single digits.

Most popular desktop Linux distributions include it in their repositories, though they may lag a bit behind the most recent version. The project provides builds for several distributions, so users can grab the latest stable release build or an unstable version if they're feeling adventurous.

Music management

Strawberry largely retains the classic look and feel of Amarok 1.4 and other desktop music players from that era; the left-hand panel shows music sources and the majority of the real estate is devoted to the playlist area. Users can manually search through directories for music files each time they'd like to listen to something, but Strawberry is designed for people who want to manage their music collection and keep it well organized. The application is designed for cataloging a music collection contained in one or more directories, such as ~/Music.

The location of the collection is specified in the settings under "General -> Collection". After adding a directory (or directories), Strawberry will scan for music files, parse their metadata, and add the information to its SQLite database (~/.local/share/strawberry/strawberry/strawberry.db on Linux). This can take a while if the collection is fairly large; I have nearly 29,000 tracks in my collection on an external SSD and it takes more than 30 minutes to scan the whole thing. In addition to specifying the location of the collection, users can configure Strawberry to do new scan on each startup—or not. It's a good idea to turn off the "Update the collection when Strawberry starts" option to avoid unnecessary rescans since they can take quite a while; this is especially true if a music collection is stored on an external device that may not always be connected. Strawberry can be prompted to monitor the collection for changes only.

Once Strawberry finishes scanning, the collection will show up in the appropriately named "Collection" tab. Users can decide what kind of grouping to use to sort the collection depending on their preferences; for example, it's possible to group by artist and then album, or by year, genre, or by any of a number of other tags. For this reason, it's important that music in a collection is well-tagged.

Strawberry allows users to edit tags and even complete tags automatically using information from the same database that the MusicBrainz Picard music tagger uses. However, its automatic completion is much less ergonomic than Picard's; Strawberry's "tag fetcher" requires users to select matches from MusicBrainz for each track and does not display as much information as is shown when using Picard. I find that it's better to clean up tags with Picard before importing music into the collection, but Strawberry's tag-editing features are still handy for making small edits. Even the information in the MusicBrainz database is sometimes wrong.

One of the features I appreciate about Strawberry is the ability to rename files in the collection or when importing into the collection to organize them according to whatever naming scheme a user prefers; all that is required is to specify the file-naming options to use, and it will rename them accordingly.

Playlists

One thing that may be slightly counterintuitive is that Strawberry has a queue and playlists. The queue, as Kvinge explained to a user confused about the difference between the two, is meant to be a temporary list of songs to play in order. Playlists, on the other hand, are meant to persist, and the application is well designed for putting together playlists for every occasion. For those of us who miss crafting mixtapes, this is the next-best thing.

Users can manually add tracks from their collection to a playlist, save playlists for posterity, and so forth. Strawberry also has a smart playlist feature that can automatically generate playlists based on search criteria such as a song's rating, its genre, how long it has been since a song was played, and so on. The search terms can be combined to create a playlist, for example, of songs that are tagged as "Alternative", released between 1980 and 1989, and that have not been played in the past five days.

Sometimes, no matter how large one's music collection is, it's nice to let someone else handle the disc-jockey duties and hear some new music. Strawberry has built-in support (found in the "Radios" tab) for playing individual stations from two Internet radio station providers that offer a wide variety of music, Radio Paradise and SomaFM. It does not, however, support logging in to Radio Paradise and rating music, skipping tracks, etc.

There are, of course, many other Internet radio stations. Unfortunately, it's not immediately obvious how to add new stations, but it is possible. Users might rightly expect that there would be an "add new radio station" button or menu item but there is not; instead, users can add a station by selecting "Add Stream..." from the Playlist menu and providing the URL for the stream. This is a bit clunky, but it works. RadioBrowser is a good source for finding Internet stations by category, country, and more.

On occasion, one has to leave the computer—happily, Strawberry makes it easier to take music along for the ride. It has features for managing external music devices; in my case, Micro SD cards that I pop into my music player. As with the local music collection, Strawberry will scan and catalog the music on the external device; after that, users can copy over songs, albums, and playlists. It is also possible to configure Strawberry to transcode music for external devices; for example, if the local music collection is in FLAC format, it might be desirable to copy music over in a lossy format to save space.

The only complaint I really have with Strawberry is that it has little documentation. This is not a surprise, though, since the project is kept running by a single maintainer. Help is available via the forum, and Kvinge seems to be fairly active in responding to user questions. There is also a wiki with a bit of documentation; the FAQ is a good place to start when faced with common technical issues.

The lack of documentation is a minor problem; it is a music-management program and not rocket science, after all. Over the years I've tinkered with more music players and managers for Linux than I can recall. Strawberry is the one that I keep coming back to, because it is the best fit for local-music management.

Comments (8 posted)

The rest of the 7.1 merge window

By the time Linus Torvalds released 7.1-rc1 and closed the 7.1 merge window, 12,996 non-merge changesets had been pulled into the mainline repository; just over 9,000 of those arrived after the first-half summary was written. These changes were more driver-oriented than those seen earlier, but still also included many new features across the kernel as a whole.

Aside from the specific changes, it is worth noting that 2,011 developers contributed changes during the 7.1 merge window; 342 of those developers were first-time contributors to the kernel. The trend of increasing numbers of new developers coming into the community that was described in the development statistics article for 7.0 appears to be continuing.

The most interesting changes added in the latter part of the 7.1 merge window include:

Architecture-specific

• The Alpha architecture now has seccomp() support.
• High-memory support has been added to Loongarch, enabling 32-bit machines to use up to 2.25GB of physical memory. This change, of course, runs counter to the long-term plan to remove high-memory support altogether.
• Execute-in-place support for RISC-V has been removed due to a seeming lack of users (and maintainers); this merge message has some more information.

Core kernel

• The extensible scheduler class (sched_ext) subsystem now has the beginning of support for sub-schedulers, meaning that each control group can run with its own custom CPU scheduler. As of 7.1, this implementation is not complete (it lacks the enqueue path in particular), but much of the needed core structure is there. See this commit log for some more information.
• The work to modernize and improve the kernel's swap subsystem continues with the removal of the old swap map. With luck, the only user-visible changes will be better performance and reduced memory usage by the swap subsystem itself.
• The DAMON subsystem has gained the ability to support multiple tuning algorithms for active memory management. See this changelog and the DAMON documentation for details.
• The tracing subsystem has gained the concept of "remote ring buffers" that can be used to obtain tracing data from, for example, virtual machines. There is some information on how they work in Documentation/trace/remotes.rst.
• The kernel has long had a problem where a dying control group would hang around indefinitely, keeping a lot of memory pinned in the process; it was, for example, discussed at the 2019 Linux Storage, Filesystem, and Memory Management Summit, and again at the 2022 meeting. In 7.1, that problem has finally been solved thanks to this patch series from Qi Zheng and Muchun Song. Now, folios in memory will no longer pin their associated control group, allowing that group to be released more quickly once its final member has exited.
• User-space page-fault handling with userfaultfd() now works with guest_memfd memory.

Filesystems and block I/O

• There is a completely rewritten version of the NTFS filesystem with full support for writes, a conversion to use iomap internally, and more, along with a promise of more active maintenance. This implementation is an alternative to ntfs3, which has not progressed as quickly as some would have liked.
• The ntfs3 implementation has received a small set of improvements as well.
• The NFS server is now able, when the sign_fh mount option is used, to provide cryptographically signed file handles to clients as a way of protecting against handle-guessing attacks. There is some new documentation in Documentation/filesystems/nfs/exporting.rst describing this option.
• The new fs-dax char driver (commit) provides a filesystem-oriented interface to direct-access (DAX) devices. It is a precondition for the eventual merging of the famfs in-memory filesystem.
• The Ceph filesystem can now collect per-subvolume I/O metrics; from the commit: "This enables administrators to monitor I/O patterns at the subvolume granularity, which is useful for multi-tenant CephFS deployments."

Hardware support

• Clock: Qualcomm GLYMUR graphics and video clock controllers, Rockchip RV1103B clock controllers, Tenstorrent Atlantis PRCM clock controllers, Qualcomm Eliza global, display, and TCSR clock controllers, ESWIN EIC7700 clock controllers, Qualcomm IPQ5210 global clock controllers, Qualcomm SM8750 graphics clock controllers, and Qualcomm Nord global and TCSR clock controllers.
• GPIO and pin control: Qualcomm Eliza pin controllers, Qualcomm Milos LPASS LPI pin controllers, Qualcomm IPQ5210 pin controllers, Qualcomm SDM670 LPASS LPI pin controllers, Qualcomm Hawi pin controllers, Realtek DHC 1625 pin controllers, and GPIO-driven Charlieplex keypads.
• Graphics: Verisilicon DC-series display controllers, T-Head TH1520 DesignWare HDMI bridges, Coreboot framebuffers, LXD M9189A MIPI-DSI LCD panels, Novatek NT37700F DSI panels, Atrix 4G and Droid X2 540x960 DSI video-mode panels, Lontium LT8713SX DP MST bridges, Himax HX83121A-based DSI panels, Ilitek ILI9806E-based RGB SPI panels, and Samsung S6E8FC0 DSI controllers.

  The graphics layer has also gained support for the DRM-RAS subsystem, which "provides a standardized way for GPU/accelerator drivers to expose error counters and other reliability nodes to user space via Generic Netlink".

• Hardware monitoring: Infineon XDPE1A2G7B and XDP720 hardware-monitoring controllers, LattePanda Sigma EC hardware monitors, Lenovo Yoga fan-speed monitors, Sony APS-379 power supplies, and Microchip Technology MCP9982 automotive temperature monitors.
• Industrial I/O: Qualcomm SPMI PMIC5 GEN3 analog-to-digital converters, Qualcomm Eliza interconnects, and STMicroelectronics VL53L1X time-of-flight ranger sensors.
• Input: Lenovo Legion Go S controllers.
• Media: OmniVision OV2732 sensors and Toshiba T4KA3 sensors.
• Miscellaneous: Black Sesame Technologies BST C1200 digital host controller interfaces, Andes QiLai PCIe controllers, ESWIN PCIe controllers, IBM internal shared memory (ISM) adapters, Cix Sky1 reset controllers, Microchip PolarFire SoC's GPIO IRQ multiplexers, Switchtec PSX/PFX switch DMA engines, ESWIN eic7700 SATA SerDes/PHYs, Loongson chain multi-channel DMA controllers, Apple SMC battery and power monitors, Samsung S2MU005 PMIC fuel gauges, Maxim MAX77759 battery chargers, and Tenstorrent Atlantis reset controllers.
• Sound: Cirrus Logic CS42L43B codecs.
• USB: Canaan USB2 PHYs.

Miscellaneous

• The runtime verification subsystem has gained some new tools, including hybrid automata, a stall monitor tool, and a deadline monitor.
• Updates to the perf tool include a new comm_nodigit sort key to combine threads whose name differs only by a trailing number, a --pmu-filter option to select a specific performance monitoring unit, and more; see this merge log for the full list.
• The increase in LLM-driven security-bug reports is motivating the removal of a number of old and (seemingly) unused drivers and network protocols. Removals so far affect PCMCIA host-controllers and, via this big pull request, numerous networking drivers along with the ATM, ax25, amateur radio, ISDN, Bluetooth CMTP, and CAIF subsystems — over 140,000 lines of code in all.

Security-related

• The first-half summary noted that the libcrypto subsystem lacked documentation; that omission has now been rectified.

Virtualization and containers

• Protected KVM for anonymous memory — where pages used by guests are unmapped from the host's virtual address space — is now supported to an extent on Arm CPUs. Full isolation from the host remains a distant goal, and this feature is not yet considered ready for general use. See Documentation/virt/kvm/arm/pkvm.rst for more information.
• The protected KVM and nVHE hypervisors can now pass trace data to the host via the new remote ring buffer tracing feature.
• KVM has gained support for the ARM virtual generic interrupt controller v5.

Internal kernel changes

• The work to deprecate the mmap() file_operations continues with the addition of some new functionality and the conversion of a number of in-kernel users. There is a new document on how to convert existing code from mmap() to mmap_prepare().

All of this work now goes into the stabilization phase, where bugs are found and (hopefully) fixed. The most likely date for the release of the 7.1 kernel at the end of that process is June 14.

Comments (4 posted)

GnuPG 2.5.19 released

Werner Koch has announced the release of GnuPG 2.5.19. This release includes a few new options and a number of bug fixes, and comes with the reminder that the GnuPG 2.4 series will reach end-of-life soon

The main features in the 2.5 series are improvements for 64 bit Windows and the introduction of Kyber (aka ML-KEM or FIPS-203) as PQC encryption algorithm. Other than PQC support the 2.6 series will not differ a lot from 2.4 because the majority of changes are internal to make use of newer features from the supporting libraries.

Note that the old 2.4 series reaches end-of-life in just two months. Thus update to 2.5.19 in time. As always with GnuPG new versions are fully compatible with previous versions.

LWN recently covered Fedora's discussion about what to offer after GnuPG 2.4 is no longer supported.

Comments (none posted)

A security bug in AEAD sockets

Security analysis firm Xint has disclosed a security bug in the Linux kernel that allows for arbitrary 4-byte writes to the page cache, and which has been present since 2017. The vulnerability has been fixed in mainline kernels. A proof-of-concept script demonstrates how to use the flaw to corrupt a setuid binary, which works on multiple distributions, by requesting an AEAD-encrypted socket from user space and splicing a particular payload into it. A supplemental blog post gives more details about the discovery and remediation.

A core primitive underlying this bug is splice(): it transfers data between file descriptors and pipes without copying, passing page cache pages by reference. When a user splices a file into a pipe and then into an AF_ALG socket, the socket's input scatterlist holds direct references to the kernel's cached pages of that file. The pages are not duplicated; the scatterlist entries point at the same physical pages that back every read(), mmap(), and execve() of that file.

Comments (26 posted)

Security review of Plasma Login Manager (SUSE Security Team Blog)

SUSE's Security Team has published a detailed blog post on their recent review of the Plasma Login Manager version 6.6.2, which was forked from the SDDM display manager.

While most of the code remains the same, the new upstream added a privileged D-Bus helper called plasmaloginauthhelper, which suffers from defense-in-depth security issues.

[...] Based on the high severity of the defense-in-depth issues shown in this report, our assessment is that there is effectively no separation between root and the plasmalogin service user account.

At this time there is no bugfix available by upstream, but a security fix is planned for the next Plasma release on May 12. We have not been involved in upstream's bugfix process so far and have no knowledge about the approach that will be taken to address the issues from this report.

Comments (1 posted)

Security quote of the week

So this brings us to Linus's Law. It seems pretty clear now that nobody was in fact looking at the code. If they were, they would have found vulnerabilities in everything. But the number of people finding and reporting vulnerabilities was pretty small. It is hard to find security vulnerabilities as a human, but the whole point wasn't that a few very smart people were looking for bugs, the point was a sort of infinite monkey theorem of bug finding.

It would be easy to proclaim LLMs as our infinite eyeballs, but it's more complicated than that. While LLMs might be able to find vulnerabilities, the real challenge is going to be reporting and coordinating all of these new findings. Even without an LLM the disclosure process was always a thousand times more work than finding the security vulnerability.

The new version of Linus's Law should read something like

With enough LLMs, you're going to be disclosing this stuff forever

The next few years are going to be wild. Anyone telling you they know how to deal with this is full of crap. Nobody knows what to do and this is a human problem, we can't technology our way out of this.

— Josh Bressers

Comments (1 posted)

Kernel release status

The current development kernel is 7.1-rc1, released on April 26. Linus remarked:

Things look fairly normal, although we do have a few different projects to cull some old hardware support to help minimize maintenance burden: phasing out i486 support (configs deleted, code deletions to follow) and independently starting to remove some really old networking hardware support, and removing some SoC support that never went anywhere.

But we're more than making up for any stale code removal with all the new features and code added, so the diffstat still shows many more lines added than removed.

As of -rc1, the 7.1 development cycle has brought in 12,996 non-merge changesets from 2,011 developers:

RC	Date	Commits
v7.1-rc1	2026-04-26	13963	13963

See the KSDB 7.1 page for lots more information.

Stable updates: 7.0.1, 6.19.14, 6.18.24, and 6.12.83 were released on April 22, followed by 7.0.2, 6.18.25, 6.12.84, and 6.6.136 on April 27. Note that 6.19.14 will be the last of the 6.19 updates.

Comments (none posted)

Fedora Linux 44 has been released

The Fedora Project has announced the release of Fedora Linux 44. There are "what's new" articles for Fedora Workstation, Fedora KDE Plasma Desktop, and Fedora Atomic Desktops. The Fedora Asahi Remix for Apple Silicon Macs, based on Fedora 44, is also available. See the Fedora Spins page for a full list of alternative desktop options.

Fedora Linux 44 Workstation ships with the latest GNOME release, GNOME 50. This comes with a long list of refinements to your desktop, including everything from accessibility to color management and remote desktop. Many of the applications that are installed by default on Fedora Workstation have also seen improvements, from Document Viewer to File Manager and Calendar. To learn more about these and other changes, you can read the GNOME 50 release notes.

KDE Plasma Desktop: If you are a KDE user, you should also notice a couple of very obvious changes. Fedora KDE Plasma Desktop 44 is based on the latest Plasma 6.6, which includes the new Plasma Login Manager and Plasma Setup to provide a more cohesive and integrated experience from the moment the computer is powered on for the first time. The installation process has been simplified, enabling you to easily set up Fedora KDE Plasma Desktop for a computer for a friend or a loved one.

The release notes include important changes between Fedora 43 and Fedora 44 for desktop users, developers, and system administrators.

Comments (16 posted)

Ubuntu 26.04 LTS released

Ubuntu 26.04 ("Resolute Raccoon") LTS has been released on schedule.

This release brings a significant uplift in security, performance, and usability across desktop, server, and cloud environments. Ubuntu 26.04 LTS introduces TPM-backed full-disk encryption, expanded use of memory-safe components, improved application permission controls, and Livepatch support for Arm systems, helping reduce downtime and strengthen system resilience. [...]

The newest Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu Studio, Ubuntu Unity, and Xubuntu are also being released today. For more details on these, read their individual release notes under the Official flavors section:

https://documentation.ubuntu.com/release-notes/26.04/#official-flavors

Maintenance updates will be provided for 5 years for Ubuntu Desktop, Ubuntu Server, Ubuntu Cloud, Ubuntu WSL, and Ubuntu Core. All the remaining flavors will be supported for 3 years.

See the release notes for a list of changes, system requirements, and more.

Comments (35 posted)

The future of AI in Ubuntu

Jon Seager, VP engineering for Canonical, has posted an update on "what Canonical and Ubuntu will do (or not) to incorporate AI" that explains what part AI will play in the future of the company and its distribution.

The bottom line is that Canonical is ramping up its use of AI tools in a focused and principled manner that favours open weight models with license terms that feel most compatible with our values, combined with open source harnesses. AI features will be landing in Ubuntu throughout the next year as we feel that they're of sufficient maturity and quality, with a bias toward local inference by default.

AI features in Ubuntu features will come in two forms: first as a means of enhancing existing OS functionality with AI models in the background, and latterly in the form of "AI native" features and workflows for those who want them.

This year Canonical has begun a more deliberate push toward education and developing competence with AI tools. We are not setting shallow metrics on token usage, or percentages of code written with AI, but rather incentivising engineers to experiment and understand where AI tools add value. Rather than force a single early-choice AI stack, we're incentivising teams to each pick 'something different' and go deep, so we learn more as an org in the next six months.

Comments (27 posted)

Distributions quote of the week

Fedora is not 100% of my focus, in fact it is definitely less than 50%, so the problem I have with discourse is that I am never going to find the time to "go to a website" to read stuff. If it does not hit my inbox it may as well not exist. Mail is the collector of all the information I need to keep tabs on because it is neutral, independent and centrally aggregated in the only place I can pay attention to.

Discourse can be the most beautiful thing but fails at the most important thing, I need information to come to me, not the other way around.

For as long as the email bridge works reasonably well I can still follow some of the discussions, but as other noted there has been a duplication of tags and stuff, so I probably am blind to a large part of the discussions there .. too bad.

— Simo Sorce

Comments (none posted)

All FOSDEM 2026 videos are online

FOSDEM's organizers have announced that all of the video recordings "worth publishing" from FOSDEM 2026 are now available.

Videos are linked from the individual schedule pages for the talks and the full schedule page. They are also available, organised by room, at video.fosdem.org/2026.

LWN's coverage of talks from FOSDEM 2026 can be found on our conference index.

Comments (none posted)

Niri 26.04 released

Version 26.04 of the niri scrollable-tiling Wayland compositor has been released. The most notable change in this release, as the "most requested niri feature by far", is support for the blur effect using the Wayland protocol's ext-background-effect. This release also features optional configuration includes, screencasting support enhancements, and a number of improvements for input devices.

In short, background blur turned out to be a massive undertaking. Not because of the blur algorithm itself (by the way, if you want to learn about different blurs, including the widely used Dual Kawase, I highly recommend this blog post), but because window background effects in general required a lot of thinking and additions to the code, especially to make them as efficient as possible. This is one of the most complex niri features thus far.

LWN covered niri in July 2025.

Comments (none posted)

pgBackRest is no longer maintained

David Steele, maintainer of the popular pgBackRest backup and restore project for PostgreSQL, has archived the project and announced that it is no longer being maintained.

After a lot of thought, I have decided to stop working on pgBackRest. I did not come to this decision lightly. pgBackRest has been my passion project for the last thirteen years, and I was fortunate to have corporate sponsorship for much of this time, but there were also many late nights and weekends as I worked to make pgBackRest the project it is today, aided by numerous contributors. Every open-source developer knows exactly what I mean and how much of your life gets devoted to a special project.

Since Crunchy Data was sold, I have been maintaining pgBackRest and looking for a position that would allow me to continue the work, but so far I have not been successful. Likewise, my efforts to secure sponsorship have also fallen far short of what I need to make the project viable.

Comments (4 posted)

pip 26.1 released

Version 26.1 of the pip package installer for Python has been released. Richard Si has published a blog post that looks at some of the highlights of 26.1 including dependency cooldowns, experimental support for pylock (pylock.toml) files, and resolver improvements that will move pip closer to the goal of removing its legacy resolver. The release also includes several security fixes and drops support for Python 3.9.

Comments (5 posted)

Development quote of the week

The question is not how fast someone can create software. The question is how long after creating the software will someone support it.

— Jeff Johnson

Comments (none posted)

Remembering Seth Nickell

LWN has received the sad news that Seth Nickell passed away, on April 16, from his father, Eric Nickell:

Many of you knew Seth from his work in the GNOME Usability Project, but his roots in that community trace back to his high school years. As a father of a high school junior, I remember being terrified when he flashed the hard drive of a computer he purchased for himself with this weird "Linux" thing. And I was a bit awed by the college application essay he wrote about open source and Linus Torvalds.

It was his interest in packet radio that drew him into working with the Linux AX.25 HOWTO as a high schooler, and from there to his focus on making the Linux desktop work for everyone.

The family plans to share news of a memorial at a later time. He will be deeply missed.

Comments (11 posted)

In Memoriam: Tomáš Kalibera

We have received the sad news that Tomáš Kalibera, a member of the R Project core team, has passed away after a short illness.

A friend who knew him well wrote to me: he was very happy, and his work fulfilled him. That is, perhaps, the best thing one can say about a life in open source — that the work mattered, that it reached millions, and that the person who did it found meaning in it.

Kalibera was mentioned in this 2019 article about C programs passing strings to Fortran subroutines. He will be greatly missed.

Comments (1 posted)

CFP Deadlines: April 30, 2026 to June 29, 2026

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

Deadline	Event Dates	Event	Location
April 30	September 29 September 30	devopsdays Berlin 2026	Berlin, Germany
May 25	July 20 July 25	DebConf 26	Santa Fe, Argentina
May 31	October 1	Open Tech Day | Software-defined Storage	Nuremberg, Germany
June 14	June 14	Neocypherpunk Summit	Berlin, Germany
June 14	September 30 October 1	All Systems Go! 2026	Berlin, Germany
June 24	October 7 October 9	Embedded Linux Conference Europe	Prague, Czech Republic
June 24	October 7 October 9	Open Source Summit Europe	Prague, Czech Republic

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

Events: April 30, 2026 to June 29, 2026

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

Date(s)	Event	Location
April 29 May 1	Linaro Connect Madrid 2026	Madrid, Spain
May 2	22nd Linux Infotag Augsburg	Augsburg, Germany
May 4 May 6	Linux Storage, Filesystem, Memory Management and BPF Summit	Zagreb, Croatia
May 4 May 11	MiniDebConf Hamburg 2026	Hamburg, Germany
May 15 May 17	PyCon US	Long Beach, California, US
May 16 May 17	Lomiri Tech Meeting	Tilburg, The Netherlands
May 18 May 20	Open Source Summit North America	Minneapolis, Minnesota, US
May 18 May 23	RustWeek 2026	Utrecht, Netherlands
May 21 May 22	Linux Security Summit North America	Minneapolis, Minnesota, US
May 23 May 24	Curl up	Prague, Czechia
May 26	Media Summit	Nice, France
May 27 May 28	Embedded Recipes	Nice, France
May 29	libcamera workshop	Nice, France
May 29	Yocto Project Developer Day	Nice, France
May 30 May 31	Journées du Logiciel Libre 2026	Lyon, France
June 6	Hong Kong Open Source Conference	Hong Kong
June 8 June 12	RISC-V Summit Europe 2026	Bologna, Italy
June 12 June 14	Southeast Linuxfest	Charlotte, NC, US
June 14	Neocypherpunk Summit	Berlin, Germany
June 14 June 16	Flock to Fedora	Prague, Czechia
June 16 June 17	Open Source Summit India	Mumbai, India
June 18 June 20	Linux Audio Conference	Maynooth, Ireland

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

Alert summary April 23, 2026 to April 29, 2026

Dist.	ID	Release	Package	Date
AlmaLinux	ALSA-2026:10766	8	firefox	2026-04-29
AlmaLinux	ALSA-2026:10741	8	gdk-pixbuf2	2026-04-29
AlmaLinux	ALSA-2026:9686	8	java-17-openjdk	2026-04-29
AlmaLinux	ALSA-2026:9693	10	java-25-openjdk	2026-04-24
AlmaLinux	ALSA-2026:9693	9	java-25-openjdk	2026-04-24
AlmaLinux	ALSA-2026:9264	10	kernel	2026-04-24
AlmaLinux	ALSA-2026:8921	9	kernel	2026-04-22
AlmaLinux	ALSA-2026:11349	8	libxml2	2026-04-29
AlmaLinux	ALSA-2026:8456	8	osbuild-composer	2026-04-24
AlmaLinux	ALSA-2026:9044	9	osbuild-composer	2026-04-22
AlmaLinux	ALSA-2026:11077	8	python3	2026-04-29
AlmaLinux	ALSA-2026:11062	8	python3.11	2026-04-29
AlmaLinux	ALSA-2026:10950	8	python3.12	2026-04-29
AlmaLinux	ALSA-2026:11521	8	sudo	2026-04-29
AlmaLinux	ALSA-2026:9638	10	thunderbird	2026-04-24
AlmaLinux	ALSA-2026:9345	8	thunderbird	2026-04-24
AlmaLinux	ALSA-2026:10702	8	webkit2gtk3	2026-04-29
AlmaLinux	ALSA-2026:9692	9	webkit2gtk3	2026-04-24
AlmaLinux	ALSA-2026:9666	10	wireshark	2026-04-24
Debian	DSA-6230-1	stable	chromium	2026-04-25
Debian	DSA-6228-1	stable	cpp-httplib	2026-04-22
Debian	DLA-4548-1	LTS	distro-info-data	2026-04-25
Debian	DSA-6235-1	stable	dnsdist	2026-04-28
Debian	DLA-4546-1	LTS	firefox-esr	2026-04-23
Debian	DLA-4547-1	LTS	gimp	2026-04-23
Debian	DLA-4550-1	LTS	libde265	2026-04-27
Debian	DLA-4551-1	LTS	mbedtls	2026-04-27
Debian	DLA-4552-1	LTS	node-tar	2026-04-29
Debian	DSA-6231-1	stable	openjdk-21	2026-04-27
Debian	DLA-4545-1	LTS	packagekit	2026-04-22
Debian	DSA-6234-1	stable	pdns-recursor	2026-04-28
Debian	DSA-6233-1	stable	pdns	2026-04-28
Debian	DLA-4553-1	LTS	policykit-1	2026-04-29
Debian	DLA-4549-1	LTS	thunderbird	2026-04-26
Debian	DSA-6229-1	stable	thunderbird	2026-04-24
Debian	DSA-6232-1	stable	webkit2gtk	2026-04-28
Fedora	FEDORA-2026-41926fe792	F42	PackageKit	2026-04-28
Fedora	FEDORA-2026-7463cd3c32	F43	PackageKit	2026-04-28
Fedora	FEDORA-2026-de98ec2a35	F44	anaconda	2026-04-24
Fedora	FEDORA-2026-649970e065	F44	awstats	2026-04-25
Fedora	FEDORA-2026-01c20fe8ca	F44	bind9-next	2026-04-25
Fedora	FEDORA-2026-e7d1590ecd	F44	botan3	2026-04-28
Fedora	FEDORA-2026-2fc36ddefe	F44	bpfman	2026-04-25
Fedora	FEDORA-2026-605559bfe2	F44	buildah	2026-04-25
Fedora	FEDORA-2026-7de23151cd	F44	calibre	2026-04-25
Fedora	FEDORA-2026-83fdfd7e0e	F44	cef	2026-04-25
Fedora	FEDORA-2026-3675ac2066	F42	chromium	2026-04-23
Fedora	FEDORA-2026-3ca69d20ed	F43	chromium	2026-04-28
Fedora	FEDORA-2026-7521734dcc	F44	chromium	2026-04-29
Fedora	FEDORA-2026-ca6321e5f1	F44	chromium	2026-04-25
Fedora	FEDORA-2026-134819a61b	F42	cockpit	2026-04-28
Fedora	FEDORA-2026-d91f313a63	F42	composer	2026-04-23
Fedora	FEDORA-2026-1140c02041	F44	composer	2026-04-25
Fedora	FEDORA-2026-e34a334e81	F44	corosync	2026-04-25
Fedora	FEDORA-2026-e673311164	F42	coturn	2026-04-25
Fedora	FEDORA-2026-1adc5f1ef8	F43	coturn	2026-04-25
Fedora	FEDORA-2026-bce5853e95	F44	cups	2026-04-25
Fedora	FEDORA-2026-f13d888b0f	F44	curl	2026-04-25
Fedora	FEDORA-2026-7f8c20f800	F44	dnf5	2026-04-24
Fedora	FEDORA-2026-519446405a	F44	dnsdist	2026-04-25
Fedora	FEDORA-2026-9a360acefb	F44	doctl	2026-04-25
Fedora	FEDORA-2026-a484707720	F43	edk2	2026-04-29
Fedora	FEDORA-2026-2a93359b0b	F44	erlang	2026-04-25
Fedora	FEDORA-2026-9e223ca14f	F44	fido-device-onboard	2026-04-25
Fedora	FEDORA-2026-69538c9f7e	F42	firefox	2026-04-28
Fedora	FEDORA-2026-fb08ad61f2	F44	firefox	2026-04-24
Fedora	FEDORA-2026-2a3e305ac4	F42	flatpak	2026-04-28
Fedora	FEDORA-2026-631b9d535c	F42	flatpak-builder	2026-04-24
Fedora	FEDORA-2026-25ff246b4f	F43	flatpak-builder	2026-04-24
Fedora	FEDORA-2026-5e62b78a0c	F44	flatpak-builder	2026-04-25
Fedora	FEDORA-2026-a5b86bbf99	F44	freetype	2026-04-25
Fedora	FEDORA-2026-8b0a672383	F44	glab	2026-04-25
Fedora	FEDORA-2026-6ff3ef2d32	F44	goose	2026-04-25
Fedora	FEDORA-2026-bebf3b0544	F42	gum	2026-04-28
Fedora	FEDORA-2026-10cf6ce616	F44	gum	2026-04-28
Fedora	FEDORA-2026-0eb8e878b6	F44	jq	2026-04-25
Fedora	FEDORA-2026-2b21a4dafe	F44	kea	2026-04-25
Fedora	FEDORA-2026-54ce3fd147	F44	libarchive	2026-04-28
Fedora	FEDORA-2026-b42b8b1c00	F44	libarchive	2026-04-25
Fedora	FEDORA-2026-d4c643a2ba	F42	libcap	2026-04-23
Fedora	FEDORA-2026-418370d63b	F44	libcap	2026-04-25
Fedora	FEDORA-2026-7fd284c688	F44	libcgif	2026-04-25
Fedora	FEDORA-2026-a8ee24f019	F42	libcoap	2026-04-28
Fedora	FEDORA-2026-0ce923a09d	F43	libcoap	2026-04-28
Fedora	FEDORA-2026-148e35657a	F44	libcoap	2026-04-28
Fedora	FEDORA-2026-fd361a6f7f	F44	libexif	2026-04-24
Fedora	FEDORA-2026-5868a8d652	F44	libgsasl	2026-04-25
Fedora	FEDORA-2026-56fa441129	F44	libinput	2026-04-25
Fedora	FEDORA-2026-17060a5ba0	F44	libmicrohttpd	2026-04-25
Fedora	FEDORA-2026-c6c617fe35	F44	libpng	2026-04-25
Fedora	FEDORA-2026-3adf4e38cb	F44	libpng12	2026-04-25
Fedora	FEDORA-2026-bcba077d11	F44	libpng15	2026-04-25
Fedora	FEDORA-2026-b5a2da2c73	F44	mapserver	2026-04-25
Fedora	FEDORA-2026-3a9536df40	F44	mbedtls	2026-04-25
Fedora	FEDORA-2026-52a9a687f0	F44	micropython	2026-04-25
Fedora	FEDORA-2026-036e523144	F42	minetest	2026-04-25
Fedora	FEDORA-2026-52b9116b3d	F43	minetest	2026-04-24
Fedora	FEDORA-2026-a436c41faf	F44	mingw-LibRaw	2026-04-25
Fedora	FEDORA-2026-7f4c2d1a4e	F44	mingw-exiv2	2026-04-25
Fedora	FEDORA-2026-c33aec93da	F44	mingw-libpng	2026-04-25
Fedora	FEDORA-2026-11097124bf	F44	mingw-openexr	2026-04-25
Fedora	FEDORA-2026-763e814afa	F42	mingw-python3	2026-04-28
Fedora	FEDORA-2026-43577dc43b	F43	mingw-python3	2026-04-28
Fedora	FEDORA-2026-f04915ebfd	F44	mingw-python3	2026-04-28
Fedora	FEDORA-2026-3d13d52f58	F44	mingw-python3	2026-04-25
Fedora	FEDORA-2026-853a2fa7e5	F44	moby-engine	2026-04-25
Fedora	FEDORA-2026-0ebdbc98c5	F44	mupdf	2026-04-25
Fedora	FEDORA-2026-4de4d247a0	F44	nginx	2026-04-25
Fedora	FEDORA-2026-4de4d247a0	F44	nginx-mod-brotli	2026-04-25
Fedora	FEDORA-2026-4de4d247a0	F44	nginx-mod-fancyindex	2026-04-25
Fedora	FEDORA-2026-4de4d247a0	F44	nginx-mod-headers-more	2026-04-25
Fedora	FEDORA-2026-4de4d247a0	F44	nginx-mod-modsecurity	2026-04-25
Fedora	FEDORA-2026-4de4d247a0	F44	nginx-mod-naxsi	2026-04-25
Fedora	FEDORA-2026-4de4d247a0	F44	nginx-mod-vts	2026-04-25
Fedora	FEDORA-2026-a0f25484e9	F43	ngtcp2	2026-04-28
Fedora	FEDORA-2026-705eb9cf95	F44	ngtcp2	2026-04-28
Fedora	FEDORA-2026-69538c9f7e	F42	nss	2026-04-28
Fedora	FEDORA-2026-fb08ad61f2	F44	nss	2026-04-24
Fedora	FEDORA-2026-301505f38f	F42	opam	2026-04-25
Fedora	FEDORA-2026-42ff51d2c7	F43	opam	2026-04-25
Fedora	FEDORA-2026-bb074cb239	F44	openbao	2026-04-25
Fedora	FEDORA-2026-8c5856afbb	F44	opensc	2026-04-25
Fedora	FEDORA-2026-2cedc95af8	F43	openssh	2026-04-28
Fedora	FEDORA-2026-93679cc7c2	F44	openssh	2026-04-25
Fedora	FEDORA-2026-47fffff581	F43	openssl	2026-04-28
Fedora	FEDORA-2026-d3e275d525	F44	openssl	2026-04-25
Fedora	FEDORA-2026-670067411c	F43	openvpn	2026-04-28
Fedora	FEDORA-2026-af08c3b44f	F44	opkssh	2026-04-25
Fedora	FEDORA-2026-fe487aa625	F44	perl-Net-CIDR-Lite	2026-04-25
Fedora	FEDORA-2026-b4633cbe23	F42	pgadmin4	2026-04-23
Fedora	FEDORA-2026-e9ecdd44c4	F43	pgadmin4	2026-04-23
Fedora	FEDORA-2026-34c2bf6df4	F44	pgadmin4	2026-04-25
Fedora	FEDORA-2026-3b2063832d	F42	pie	2026-04-23
Fedora	FEDORA-2026-3f4283f831	F43	pie	2026-04-23
Fedora	FEDORA-2026-7acc0ad1fc	F44	pie	2026-04-25
Fedora	FEDORA-2026-15e5625973	F44	plasma-setup	2026-04-24
Fedora	FEDORA-2026-605559bfe2	F44	podman	2026-04-25
Fedora	FEDORA-2026-e153173659	F44	pspp	2026-04-25
Fedora	FEDORA-2026-fdc024ddc3	F44	pypy	2026-04-25
Fedora	FEDORA-2026-4802a7dbd4	F44	python-biopython	2026-04-25
Fedora	FEDORA-2026-985539cc51	F44	python-blivet	2026-04-24
Fedora	FEDORA-2026-448e26a9c8	F44	python-cairosvg	2026-04-25
Fedora	FEDORA-2026-71677aed1e	F44	python-cbor2	2026-04-25
Fedora	FEDORA-2026-aa318887d6	F44	python-cryptography	2026-04-25
Fedora	FEDORA-2026-fd53570465	F44	python-flask-httpauth	2026-04-25
Fedora	FEDORA-2026-64b1c7aa6b	F44	python-msal	2026-04-25
Fedora	FEDORA-2026-334e385bd4	F44	python-pillow	2026-04-25
Fedora	FEDORA-2026-9eecdef4e0	F44	python-pydicom	2026-04-25
Fedora	FEDORA-2026-42d4c822e4	F44	python-tomli	2026-04-25
Fedora	FEDORA-2026-13c6899032	F42	python3-docs	2026-04-28
Fedora	FEDORA-2026-9a8fddee0b	F43	python3-docs	2026-04-23
Fedora	FEDORA-2026-884eccdb03	F44	python3-docs	2026-04-25
Fedora	FEDORA-2026-952616f3d6	F43	python3.11	2026-04-28
Fedora	FEDORA-2026-6e657e937a	F44	python3.11	2026-04-28
Fedora	FEDORA-2026-bb0e94c26c	F44	python3.12	2026-04-28
Fedora	FEDORA-2026-13c6899032	F42	python3.13	2026-04-28
Fedora	FEDORA-2026-80165205dc	F44	python3.13	2026-04-25
Fedora	FEDORA-2026-1fd21102d1	F42	python3.14	2026-04-28
Fedora	FEDORA-2026-9a8fddee0b	F43	python3.14	2026-04-23
Fedora	FEDORA-2026-884eccdb03	F44	python3.14	2026-04-25
Fedora	FEDORA-2026-841a2250e4	F44	python3.14	2026-04-25
Fedora	FEDORA-2026-d494efe6a9	F44	python3.15	2026-04-25
Fedora	FEDORA-2026-f7b3ebe324	F44	python3.9	2026-04-25
Fedora	FEDORA-2026-17dbeca425	F44	rauc	2026-04-25
Fedora	FEDORA-2026-6d293b6889	F44	roundcubemail	2026-04-25
Fedora	FEDORA-2026-f7b4693f9d	F42	rpki-client	2026-04-24
Fedora	FEDORA-2026-27892c9184	F43	rpki-client	2026-04-24
Fedora	FEDORA-2026-879659f6c2	F44	rpki-client	2026-04-25
Fedora	FEDORA-2026-aef1b21b9c	F44	rust-sccache	2026-04-25
Fedora	FEDORA-2026-605559bfe2	F44	skopeo	2026-04-25
Fedora	FEDORA-2026-9094afb6f6	F44	smb4k	2026-04-25
Fedora	FEDORA-2026-f45664a58a	F44	stb	2026-04-25
Fedora	FEDORA-2026-e860be4db8	F43	sudo	2026-04-23
Fedora	FEDORA-2026-6894ade78f	F44	sudo	2026-04-25
Fedora	FEDORA-2026-3efb70d4da	F44	tcpflow	2026-04-25
Fedora	FEDORA-2026-1902c187b6	F44	thunderbird	2026-04-25
Fedora	FEDORA-2026-0b633ecc7c	F42	tigervnc	2026-04-25
Fedora	FEDORA-2026-492e92b32d	F43	tigervnc	2026-04-25
Fedora	FEDORA-2026-9695fbdabb	F44	tinyproxy	2026-04-25
Fedora	FEDORA-2026-7839a46d9d	F44	trafficserver	2026-04-25
Fedora	FEDORA-2026-6fc2f11089	F44	trivy	2026-04-25
Fedora	FEDORA-2026-502486fc61	F44	usd	2026-04-25
Fedora	FEDORA-2026-67cf3d6cca	F44	util-linux	2026-04-25
Fedora	FEDORA-2026-755c51e6a0	F43	vim	2026-04-28
Fedora	FEDORA-2026-3954a4ed07	F44	vim	2026-04-29
Fedora	FEDORA-2026-251d74645b	F44	vim	2026-04-25
Fedora	FEDORA-2026-205fd328d2	F44	xdg-dbus-proxy	2026-04-25
Fedora	FEDORA-2026-2c6941716b	F42	xorg-x11-server	2026-04-24
Fedora	FEDORA-2026-a7ec361237	F43	xorg-x11-server	2026-04-24
Fedora	FEDORA-2026-cf9e55a7a0	F44	xorg-x11-server	2026-04-25
Fedora	FEDORA-2026-922a6d4e1a	F44	xorg-x11-server-Xwayland	2026-04-25
Fedora	FEDORA-2026-f04c228c78	F42	xrdp	2026-04-28
Fedora	FEDORA-2026-9417ff0bc5	F43	xrdp	2026-04-28
Fedora	FEDORA-2026-ad9e109ad8	F44	xrdp	2026-04-28
Fedora	FEDORA-2026-8d34161d90	F44	yarnpkg	2026-04-25
Mageia	MGASA-2026-0107	9	gvfs	2026-04-23
Oracle	ELSA-2026-8468	OL8	.NET 8.0	2026-04-22
Oracle	ELSA-2026-8469	OL9	.NET 8.0	2026-04-22
Oracle	ELSA-2026-6713	OL7	ImageMagick	2026-04-22
Oracle	ELSA-2026-11360	OL9	LibRaw	2026-04-29
Oracle	ELSA-2026-8863	OL8	OpenEXR	2026-04-22
Oracle	ELSA-2026-8312	OL10	bind	2026-04-23
Oracle	ELSA-2026-10135	OL9	buildah	2026-04-27
Oracle	ELSA-2026-8842	OL10	delve	2026-04-22
Oracle	ELSA-2026-10767	OL10	firefox	2026-04-28
Oracle	ELSA-2026-10766	OL8	firefox	2026-04-28
Oracle	ELSA-2026-10757	OL9	firefox	2026-04-28
Oracle	ELSA-2026-8945	OL8	freerdp	2026-04-22
Oracle	ELSA-2026-10707	OL10	gdk-pixbuf2	2026-04-28
Oracle	ELSA-2026-10741	OL8	gdk-pixbuf2	2026-04-28
Oracle	ELSA-2026-10708	OL9	gdk-pixbuf2	2026-04-28
Oracle	ELSA-2026-8858	OL10	giflib	2026-04-22
Oracle	ELSA-2026-8861	OL8	giflib	2026-04-22
Oracle	ELSA-2026-8859	OL9	giflib	2026-04-22
Oracle	ELSA-2026-10704	OL8	go-toolset:rhel8	2026-04-29
Oracle	ELSA-2026-10217	OL10	golang	2026-04-27
Oracle	ELSA-2026-10219	OL9	golang	2026-04-27
Oracle	ELSA-2026-10223	OL10	grafana	2026-04-27
Oracle	ELSA-2026-10226	OL9	grafana	2026-04-27
Oracle	ELSA-2026-9683	OL9	java-1.8.0-openjdk	2026-04-28
Oracle	ELSA-2026-9686	OL8	java-17-openjdk	2026-04-27
Oracle	ELSA-2026-9686	OL9	java-17-openjdk	2026-04-27
Oracle	ELSA-2026-9689	OL10	java-21-openjdk	2026-04-28
Oracle	ELSA-2026-9689	OL9	java-21-openjdk	2026-04-28
Oracle	ELSA-2026-9693	OL10	java-25-openjdk	2026-04-27
Oracle	ELSA-2026-9693	OL9	java-25-openjdk	2026-04-27
Oracle	ELSA-2026-9264	OL10	kernel	2026-04-23
Oracle	ELSA-2026-9131	OL8	kernel	2026-04-23
Oracle	ELSA-2026-8921	OL9	kernel	2026-04-22
Oracle	ELSA-2026-7032	OL7	libpng12	2026-04-28
Oracle	ELSA-2026-11349	OL8	libxml2	2026-04-29
Oracle	ELSA-2026-8456	OL8	osbuild-composer	2026-04-23
Oracle	ELSA-2026-9044	OL9	osbuild-composer	2026-04-22
Oracle	ELSA-2026-6007	OL6	python	2026-04-29
Oracle	ELSA-2026-11077	OL8	python3	2026-04-28
Oracle	ELSA-2026-11062	OL8	python3.11	2026-04-28
Oracle	ELSA-2026-10774	OL9	python3.11	2026-04-28
Oracle	ELSA-2026-10711	OL10	python3.12	2026-04-28
Oracle	ELSA-2026-10950	OL8	python3.12	2026-04-28
Oracle	ELSA-2026-10745	OL9	python3.12	2026-04-28
Oracle	ELSA-2026-1939	OL9	python3.12-wheel	2026-04-29
Oracle	ELSA-2026-10949	OL9	python3.9	2026-04-28
Oracle	ELSA-2026-10758	OL10	sudo	2026-04-28
Oracle	ELSA-2026-9638	OL10	thunderbird	2026-04-23
Oracle	ELSA-2026-9345	OL8	thunderbird	2026-04-23
Oracle	ELSA-2026-10739	OL9	tigervnc	2026-04-28
Oracle	ELSA-2026-11389	OL10	vim	2026-04-29
Oracle	ELSA-2026-10702	OL8	webkit2gtk3	2026-04-28
Oracle	ELSA-2026-9692	OL9	webkit2gtk3	2026-04-23
Oracle	ELSA-2026-9666	OL10	wireshark	2026-04-23
Oracle	ELSA-2026-11388	OL9	xorg-x11-server	2026-04-29
Oracle	ELSA-2026-11352	OL10	xorg-x11-server-Xwayland	2026-04-29
Oracle	ELSA-2026-11369	OL9	xorg-x11-server-Xwayland	2026-04-29
Oracle	ELSA-2026-11413	OL10	yggdrasil	2026-04-29
Oracle	ELSA-2026-11412	OL10	yggdrasil-worker-package-manager	2026-04-29
Red Hat	RHSA-2026:10703-01	EL8.6	container-tools:rhel8	2026-04-29
Red Hat	RHSA-2026:8842-01	EL10	delve	2026-04-29
Red Hat	RHSA-2026:9435-01	EL10.0	git-lfs	2026-04-29
Red Hat	RHSA-2026:9436-01	EL9.0	git-lfs	2026-04-29
Red Hat	RHSA-2026:9434-01	EL9.2	git-lfs	2026-04-29
Red Hat	RHSA-2026:9439-01	EL9.6	git-lfs	2026-04-29
Red Hat	RHSA-2026:8840-01	EL10	go-rpm-macros	2026-04-29
Red Hat	RHSA-2026:8856-01	EL10.0	go-rpm-macros	2026-04-29
Red Hat	RHSA-2026:8841-01	EL9	go-rpm-macros	2026-04-29
Red Hat	RHSA-2026:8848-01	EL9.6	go-rpm-macros	2026-04-29
Red Hat	RHSA-2026:8849-01	EL10.0	grafana	2026-04-29
Red Hat	RHSA-2026:8853-01	EL8.2	grafana	2026-04-29
Red Hat	RHSA-2026:9043-01	EL8.4	grafana	2026-04-29
Red Hat	RHSA-2026:8860-01	EL8.6	grafana	2026-04-29
Red Hat	RHSA-2026:8877-01	EL8.8	grafana	2026-04-29
Red Hat	RHSA-2026:8881-01	EL9.0	grafana	2026-04-29
Red Hat	RHSA-2026:8879-01	EL9.2	grafana	2026-04-29
Red Hat	RHSA-2026:8930-01	EL9.4	grafana	2026-04-29
Red Hat	RHSA-2026:8847-01	EL9.6	grafana	2026-04-29
Red Hat	RHSA-2026:8931-01	EL10.0	grafana-pcp	2026-04-29
Red Hat	RHSA-2026:9094-01	EL8.4	grafana-pcp	2026-04-29
Red Hat	RHSA-2026:9093-01	EL8.6	grafana-pcp	2026-04-29
Red Hat	RHSA-2026:8878-01	EL8.8	grafana-pcp	2026-04-29
Red Hat	RHSA-2026:8949-01	EL9.0	grafana-pcp	2026-04-29
Red Hat	RHSA-2026:9090-01	EL9.2	grafana-pcp	2026-04-29
Red Hat	RHSA-2026:8882-01	EL9.4	grafana-pcp	2026-04-29
Red Hat	RHSA-2026:8845-01	EL9.6	grafana-pcp	2026-04-29
Red Hat	RHSA-2026:9693-01	EL9	java-25-openjdk	2026-04-24
Red Hat	RHSA-2026:9044-01	EL9	osbuild-composer	2026-04-29
Red Hat	RHSA-2026:8855-01	EL7	rhc	2026-04-29
Red Hat	RHSA-2026:8434-01	EL8.4	rhc	2026-04-29
Red Hat	RHSA-2026:8851-01	EL8.6	rhc	2026-04-29
Red Hat	RHSA-2026:9695-01	EL8.8	rhc	2026-04-29
Red Hat	RHSA-2026:8852-01	EL9.0	rhc	2026-04-29
Red Hat	RHSA-2026:10739-01	EL9	tigervnc	2026-04-28
Red Hat	RHSA-2026:11352-01	EL10	xorg-x11-server-Xwayland	2026-04-28
Slackware	SSA:2026-117-01		mpg123	2026-04-27
Slackware	SSA:2026-118-01		proftpd	2026-04-27
SUSE	openSUSE-SU-2026:10585-1	TW	GraphicsMagick	2026-04-22
SUSE	SUSE-SU-2026:1596-1	SLE12	ImageMagick	2026-04-24
SUSE	SUSE-SU-2026:1598-1	SLE15	ImageMagick	2026-04-24
SUSE	SUSE-SU-2026:1597-1	SLE15 oS15.6	ImageMagick	2026-04-24
SUSE	SUSE-SU-2026:21380-1	SLE16	ImageMagick	2026-04-28
SUSE	SUSE-SU-2026:21292-1	SLE-m6.1	Mesa	2026-04-27
SUSE	SUSE-SU-2026:1619-1	oS15.5	PackageKit	2026-04-24
SUSE	SUSE-SU-2026:1639-1	SLE15	bouncycastle	2026-04-28
SUSE	openSUSE-SU-2026:0148-1	osB15	cacti, cacti-spine	2026-04-24
SUSE	openSUSE-SU-2026:10599-1	TW	cacti	2026-04-23
SUSE	openSUSE-SU-2026:0152-1	osB15	chromium	2026-04-26
SUSE	openSUSE-SU-2026:0153-1	osB15	chromium	2026-04-26
SUSE	SUSE-SU-2026:21358-1	SLE16	clamav	2026-04-28
SUSE	SUSE-SU-2026:21246-1	SLE-m6.0	cockpit-machines	2026-04-23
SUSE	SUSE-SU-2026:21253-1	SLE-m6.1	cockpit-machines	2026-04-23
SUSE	SUSE-SU-2026:21321-1	SLE-m6.0	cockpit-podman	2026-04-27
SUSE	SUSE-SU-2026:21256-1	SLE-m6.1	cockpit-podman	2026-04-23
SUSE	SUSE-SU-2026:21245-1	SLE-m6.0	cockpit-tukit	2026-04-23
SUSE	openSUSE-SU-2026:20628-1	oS16.0	container-suseconnect	2026-04-28
SUSE	openSUSE-SU-2026:20619-1	oS16.0	coredns	2026-04-24
SUSE	SUSE-SU-2026:21285-1	SLE16	corosync	2026-04-27
SUSE	openSUSE-SU-2026:10600-1	TW	csync2	2026-04-23
SUSE	SUSE-SU-2026:1617-1	SLE12	cups	2026-04-24
SUSE	SUSE-SU-2026:1618-1	SLE15	dnsdist	2026-04-24
SUSE	SUSE-SU-2026:1641-1	SLE12	dovecot22	2026-04-28
SUSE	openSUSE-SU-2026:10619-1	TW	emacs	2026-04-27
SUSE	SUSE-SU-2026:21374-1	SLE16	erlang	2026-04-28
SUSE	openSUSE-SU-2026:20607-1	oS16.0	erlang	2026-04-23
SUSE	SUSE-SU-2026:1650-1	SLE12	firefox	2026-04-29
SUSE	SUSE-SU-2026:1649-1	SLE15	firefox	2026-04-29
SUSE	SUSE-SU-2026:21383-1	SLE16	firefox	2026-04-28
SUSE	openSUSE-SU-2026:20621-1	oS16.0	firefox	2026-04-27
SUSE	openSUSE-SU-2026:0149-1	osB15	flannel	2026-04-24
SUSE	openSUSE-SU-2026:0150-1	osB15	flannel	2026-04-24
SUSE	SUSE-SU-2026:1600-1	SLE15 oS15.6	flatpak	2026-04-24
SUSE	SUSE-SU-2026:1636-1	SLE15	fontforge	2026-04-28
SUSE	SUSE-SU-2026:21375-1	SLE16	fontforge	2026-04-28
SUSE	openSUSE-SU-2026:0155-1	osB15	freeciv	2026-04-27
SUSE	SUSE-SU-2026:1635-1	SLE12	freerdp	2026-04-27
SUSE	SUSE-SU-2026:1633-1	SLE15	freerdp	2026-04-27
SUSE	SUSE-SU-2026:1634-1	SLE15 oS15.4	freerdp	2026-04-27
SUSE	SUSE-SU-2026:1632-1	SLE15 oS15.6	freerdp	2026-04-27
SUSE	SUSE-SU-2026:1640-1	SLE15	freerdp2	2026-04-28
SUSE	openSUSE-SU-2026:10611-1	TW	freerdp2	2026-04-26
SUSE	openSUSE-SU-2026:10606-1	TW	frr	2026-04-24
SUSE	SUSE-SU-2026:21290-1	SLE-m6.1	gdk-pixbuf	2026-04-27
SUSE	SUSE-SU-2026:1576-1	SLE15 oS15.6	gdk-pixbuf	2026-04-23
SUSE	SUSE-SU-2026:21363-1	SLE16	ghostscript	2026-04-28
SUSE	SUSE-SU-2026:21368-1	SLE16	giflib	2026-04-28
SUSE	openSUSE-SU-2026:20601-1	oS16.0	giflib	2026-04-23
SUSE	SUSE-SU-2026:1646-1	SLE15	gnome-remote-desktop	2026-04-29
SUSE	SUSE-SU-2026:21362-1	SLE16	gnome-remote-desktop	2026-04-28
SUSE	SUSE-SU-2026:21355-1	SLE16	go1.25	2026-04-28
SUSE	SUSE-SU-2026:1581-1	SLE15	go1.25-openssl	2026-04-24
SUSE	SUSE-SU-2026:21356-1	SLE16	go1.26	2026-04-28
SUSE	SUSE-SU-2026:1580-1	SLE15	go1.26-openssl	2026-04-24
SUSE	openSUSE-SU-2026:10612-1	TW	golang-github-prometheus-alertmanager	2026-04-26
SUSE	openSUSE-SU-2026:10607-1	TW	golang-github-prometheus-prometheus	2026-04-24
SUSE	SUSE-SU-2026:21319-1	SLE-m6.0	google-guest-agent	2026-04-27
SUSE	SUSE-SU-2026:21376-1	SLE16	google-guest-agent	2026-04-28
SUSE	SUSE-SU-2026:21284-1	SLE16 SLE-m6.1	google-guest-agent	2026-04-27
SUSE	openSUSE-SU-2026:20609-1	oS16.0	google-guest-agent	2026-04-23
SUSE	SUSE-SU-2026:21318-1	SLE-m6.0	haproxy	2026-04-27
SUSE	SUSE-SU-2026:21289-1	SLE-m6.1	haproxy	2026-04-27
SUSE	SUSE-SU-2026:21280-1	SLE-m6.2	haproxy	2026-04-24
SUSE	SUSE-SU-2026:1568-1	SLE15 oS15.6	haproxy	2026-04-23
SUSE	SUSE-SU-2026:21353-1	SLE16	haproxy	2026-04-28
SUSE	SUSE-SU-2026:21390-1	SLE16	haproxy	2026-04-28
SUSE	openSUSE-SU-2026:20618-1	oS16.0	haproxy	2026-04-24
SUSE	SUSE-SU-2026:21272-1	SLE-m6.2	ignition	2026-04-24
SUSE	SUSE-SU-2026:21370-1	SLE16	ignition	2026-04-28
SUSE	openSUSE-SU-2026:20603-1	oS16.0	ignition	2026-04-23
SUSE	openSUSE-SU-2026:20606-1	oS16.0	imagemagick	2026-04-23
SUSE	SUSE-SU-2026:1548-1	SLE15 oS15.6	kea	2026-04-22
SUSE	SUSE-SU-2026:1563-1	MP4.3 SLE15 SLE-m5.3 SLE-m5.4 oS15.4	kernel	2026-04-23
SUSE	SUSE-SU-2026:21241-1	SLE-m6.0 SLE-m6.1	kernel	2026-04-23
SUSE	SUSE-SU-2026:21255-1	SLE-m6.1	kernel	2026-04-23
SUSE	SUSE-SU-2026:1573-1	SLE15	kernel	2026-04-23
SUSE	SUSE-SU-2026:1575-1	SLE15 SLE-m5.2	kernel	2026-04-23
SUSE	SUSE-SU-2026:1557-1	SLE15 SLE-m5.3 SLE-m5.4	kernel	2026-04-23
SUSE	SUSE-SU-2026:1606-1	SLE15 SLE-m5.5	kernel	2026-04-24
SUSE	SUSE-SU-2026:1574-1	SLE15 SLE-m5.5 oS15.5	kernel	2026-04-23
SUSE	SUSE-SU-2026:1643-1	SLE15 oS15.6	kernel	2026-04-29
SUSE	SUSE-SU-2026:21361-1	SLE16	kernel	2026-04-28
SUSE	SUSE-SU-2026:21352-1	SLE16	kernel	2026-04-28
SUSE	openSUSE-SU-2026:10591-1	TW	kissfft	2026-04-22
SUSE	openSUSE-SU-2026:10613-1	TW	kyverno	2026-04-26
SUSE	openSUSE-SU-2026:10608-1	TW	libXpm-devel	2026-04-24
SUSE	SUSE-SU-2026:21243-1	SLE-m6.0	libcap	2026-04-23
SUSE	SUSE-SU-2026:21257-1	SLE-m6.1	libcap	2026-04-23
SUSE	SUSE-SU-2026:21274-1	SLE-m6.2	libcap	2026-04-24
SUSE	SUSE-SU-2026:21373-1	SLE16	libcap	2026-04-28
SUSE	openSUSE-SU-2026:10617-1	TW	libminizip1	2026-04-26
SUSE	openSUSE-SU-2026:10621-1	TW	libngtcp2-16	2026-04-27
SUSE	SUSE-SU-2026:21251-1	SLE-m6.0	libpng16	2026-04-23
SUSE	SUSE-SU-2026:21262-1	SLE-m6.1	libpng16	2026-04-23
SUSE	SUSE-SU-2026:1601-1	SLE12	libpng16	2026-04-24
SUSE	SUSE-SU-2026:1602-1	SLE15 oS15.6	libpng16	2026-04-24
SUSE	SUSE-SU-2026:21364-1	SLE16	libpng16	2026-04-28
SUSE	SUSE-SU-2026:1556-1	SLE15 oS15.4	libraw	2026-04-23
SUSE	SUSE-SU-2026:1555-1	SLE15 oS15.6	libraw	2026-04-23
SUSE	SUSE-SU-2026:21360-1	SLE16	libraw	2026-04-28
SUSE	SUSE-SU-2026:21275-1	SLE-m6.2	librsvg	2026-04-24
SUSE	SUSE-SU-2026:1599-1	SLE15 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.4	librsvg	2026-04-24
SUSE	SUSE-SU-2026:21377-1	SLE16	librsvg	2026-04-28
SUSE	SUSE-SU-2026:1565-1	SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.4	libssh	2026-04-23
SUSE	openSUSE-SU-2026:10624-1	TW	libsystemd0	2026-04-27
SUSE	openSUSE-SU-2026:10598-1	TW	libtree-sitter0_26	2026-04-23
SUSE	SUSE-SU-2026:21263-1	SLE-m6.1	libvirt	2026-04-23
SUSE	openSUSE-SU-2026:20629-1	oS16.0	mariadb	2026-04-28
SUSE	SUSE-SU-2026:21247-1	SLE-m6.0	ncurses	2026-04-23
SUSE	SUSE-SU-2026:21261-1	SLE-m6.1	ncurses	2026-04-23
SUSE	SUSE-SU-2026:1571-1	SLE15	ntfs-3g_ntfsprogs	2026-04-23
SUSE	openSUSE-SU-2026:0145-1	osB15	ocaml-patch, opam	2026-04-23
SUSE	openSUSE-SU-2026:10593-1	TW	openCryptoki	2026-04-22
SUSE	SUSE-SU-2026:21372-1	SLE16	openexr	2026-04-28
SUSE	openSUSE-SU-2026:20605-1	oS16.0	openexr	2026-04-23
SUSE	SUSE-SU-2026:21320-1	SLE-m6.0	opensc	2026-04-27
SUSE	SUSE-SU-2026:21283-1	SLE-m6.1	opensc	2026-04-27
SUSE	SUSE-SU-2026:1549-1	SLE12	openssl-1_1	2026-04-22
SUSE	SUSE-SU-2026:1562-1	SLE15 SLE-m5.3 SLE-m5.4 oS15.4	openssl-1_1	2026-04-23
SUSE	SUSE-SU-2026:1550-1	SLE15 SLE-m5.5 oS15.5	openssl-1_1	2026-04-22
SUSE	SUSE-SU-2026:1577-1	SLE15 oS15.6	openssl-1_1	2026-04-23
SUSE	SUSE-SU-2026:21244-1	SLE-m6.0	openssl-3	2026-04-23
SUSE	SUSE-SU-2026:1605-1	SLE15 oS15.6	openssl-3	2026-04-24
SUSE	SUSE-SU-2026:21250-1	SLE-m6.0	openvswitch	2026-04-23
SUSE	openSUSE-SU-2026:10615-1	TW	ovmf-202602	2026-04-26
SUSE	SUSE-SU-2026:1567-1	SLE12	perl	2026-04-23
SUSE	openSUSE-SU-2026:10628-1	TW	pocketbase	2026-04-28
SUSE	SUSE-SU-2026:21291-1	SLE-m6.1	podman	2026-04-27
SUSE	SUSE-SU-2026:1653-1	MP4.3 SLE15 SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5	protobuf	2026-04-29
SUSE	SUSE-SU-2026:21382-1	SLE16	python-Pillow	2026-04-28
SUSE	SUSE-SU-2026:1608-1	SLE15	python-ecdsa	2026-04-24
SUSE	openSUSE-SU-2026:20617-1	oS16.0	python-pillow	2026-04-24
SUSE	SUSE-SU-2026:1582-1	SLE12	python-pyOpenSSL	2026-04-24
SUSE	SUSE-SU-2026:1647-1	MP4.3 SLE15 oS15.4 oS15.6	python-requests	2026-04-29
SUSE	SUSE-SU-2026:1644-1	SLE15 SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.3	python-requests	2026-04-29
SUSE	openSUSE-SU-2026:10616-1	TW	python311-Mako	2026-04-26
SUSE	SUSE-SU-2026:21254-1	SLE-m6.1	python311	2026-04-23
SUSE	SUSE-SU-2026:21354-1	SLE16	qemu	2026-04-28
SUSE	openSUSE-SU-2026:0151-1	osB15	rclone	2026-04-24
SUSE	SUSE-SU-2026:21357-1	SLE16	rust1.94	2026-04-28
SUSE	SUSE-SU-2026:1637-1	SLE15	strongswan	2026-04-28
SUSE	SUSE-SU-2026:21252-1	SLE-m6.1	sudo	2026-04-23
SUSE	SUSE-SU-2026:21273-1	SLE-m6.2	sudo	2026-04-24
SUSE	SUSE-SU-2026:21369-1	SLE16	sudo	2026-04-28
SUSE	openSUSE-SU-2026:10610-1	TW	thunderbird	2026-04-25
SUSE	SUSE-SU-2026:1572-1	SLE12	tomcat	2026-04-23
SUSE	SUSE-SU-2026:1604-1	SLE15	tomcat	2026-04-24
SUSE	SUSE-SU-2026:21378-1	SLE16	tomcat	2026-04-28
SUSE	openSUSE-SU-2026:20611-1	oS16.0	tomcat	2026-04-23
SUSE	SUSE-SU-2026:1603-1	SLE15	tomcat10	2026-04-24
SUSE	SUSE-SU-2026:21379-1	SLE16	tomcat10	2026-04-28
SUSE	openSUSE-SU-2026:20612-1	oS16.0	tomcat10	2026-04-23
SUSE	SUSE-SU-2026:1558-1	SLE15 oS15.6	tomcat11	2026-04-23
SUSE	SUSE-SU-2026:21366-1	SLE16	tomcat11	2026-04-28
SUSE	openSUSE-SU-2026:0147-1	osB15	tor	2026-04-23
SUSE	SUSE-SU-2026:1607-1	SLE15 SLE-m5.5 oS15.5 oS15.6	vim	2026-04-24
SUSE	SUSE-SU-2026:1648-1	SLE12	webkit2gtk3	2026-04-29
SUSE	SUSE-SU-2026:1645-1	SLE-m5.2 oS15.3	xen	2026-04-28
Ubuntu	USN-8212-1		authd	2026-04-27
Ubuntu	USN-8207-1	22.04 24.04 25.10	clamav	2026-04-27
Ubuntu	USN-8216-1		dotnet10	2026-04-29
Ubuntu	USN-8215-1	24.04 25.10	dotnet10	2026-04-29
Ubuntu	USN-8136-2	22.04 24.04	dovecot	2026-04-28
Ubuntu	USN-8199-1	16.04 18.04 20.04	glance	2026-04-27
Ubuntu	USN-8205-1	16.04 18.04	gst-plugins-bad1.0	2026-04-24
Ubuntu	USN-8208-1	24.04 25.10	haproxy	2026-04-27
Ubuntu	USN-8202-2		jq	2026-04-28
Ubuntu	USN-8202-1	14.04 16.04 18.04 20.04 22.04 24.04 25.10	jq	2026-04-24
Ubuntu	USN-8209-1	22.04 24.04 25.10	lcms2	2026-04-27
Ubuntu	USN-8206-1	18.04	libopenmpt	2026-04-23
Ubuntu	USN-8200-1	18.04 20.04	linux, linux-aws, linux-aws-5.4, linux-azure, linux-gcp, linux-gcp-5.4, linux-hwe-5.4, linux-ibm, linux-ibm-5.4, linux-iot, linux-kvm, linux-oracle, linux-oracle-5.4, linux-xilinx-zynqmp	2026-04-22
Ubuntu	USN-8183-2	24.04 25.10	linux-aws, linux-aws-6.17, linux-hwe-6.17, linux-oracle, linux-oracle-6.17	2026-04-23
Ubuntu	USN-8180-3	20.04 22.04	linux-azure, linux-intel-iotg, linux-intel-iotg-5.15, linux-kvm, linux-oracle-5.15	2026-04-23
Ubuntu	USN-8201-1	18.04	linux-azure-5.4	2026-04-22
Ubuntu	USN-8180-4	22.04	linux-azure-fips	2026-04-23
Ubuntu	USN-8200-2	20.04	linux-fips, linux-aws-fips, linux-azure-fips, linux-gcp-fips	2026-04-22
Ubuntu	USN-8179-3	22.04 24.04	linux-hwe-6.8, linux-ibm-6.8, linux-raspi	2026-04-23
Ubuntu	USN-8180-5	20.04 22.04	linux-ibm, linux-ibm-5.15	2026-04-24
Ubuntu	USN-8185-2	24.04	linux-nvidia-lowlatency	2026-04-28
Ubuntu	USN-8203-1	22.04 24.04	linux-oracle, linux-oracle-6.8	2026-04-23
Ubuntu	USN-8098-10	18.04 20.04	linux-raspi, linux-raspi-5.4	2026-04-23
Ubuntu	USN-8204-1	24.04	linux-raspi-realtime	2026-04-23
Ubuntu	USN-8210-1	22.04 24.04 25.10	nginx	2026-04-27
Ubuntu	USN-8214-1	14.04 16.04 18.04 20.04 22.04 24.04	nltk	2026-04-28
Ubuntu	USN-8217-1	18.04 20.04 22.04	node-follow-redirects	2026-04-28
Ubuntu	USN-8192-2		ntfs-3g	2026-04-27
Ubuntu	USN-8222-1	22.04 24.04 25.10 26.04	openssh	2026-04-29
Ubuntu	USN-8195-2		packagekit	2026-04-27
Ubuntu	USN-8195-3	16.04 18.04 20.04	packagekit	2026-04-29
Ubuntu	USN-8195-1	22.04 24.04 25.10	packagekit	2026-04-22
Ubuntu	USN-8194-1	20.04 22.04 24.04	php-league-commonmark	2026-04-23
Ubuntu	USN-8211-1	25.10	pillow	2026-04-27
Ubuntu	USN-8087-3	16.04 18.04 20.04	python-cryptography	2026-04-29
Ubuntu	USN-8198-1	16.04 18.04 20.04 22.04 24.04 25.10	python-tornado	2026-04-23
Ubuntu	USN-8198-2	26.04	python-tornado	2026-04-28
Ubuntu	USN-8190-1	25.10	ruby-rack-session	2026-04-23
Ubuntu	USN-8190-2	26.04	ruby-rack-session	2026-04-28
Ubuntu	USN-8197-1	14.04 16.04 18.04	slurm-llnl	2026-04-23
Ubuntu	USN-8196-2		strongswan	2026-04-27
Ubuntu	USN-8196-1	22.04 24.04 25.10	strongswan	2026-04-22
Ubuntu	USN-8219-1	22.04 24.04 25.10 26.04	ujson	2026-04-28
Ubuntu	USN-8213-1	14.04 16.04 18.04 20.04 22.04 24.04 25.10	vim	2026-04-28
Ubuntu	USN-8221-1	24.04	wheel	2026-04-29

Full Story (comments: none)