news
LWN on Kernel, IBM Fedora, Python, and Slop
-
Fedora / IBM
-
LWN ☛ Fedora shares strategy updates and "weird research university" model [Ed: IBM kills Fedora by neglect]
In early February, members of the Fedora Council met in Tirana, Albania to discuss and set the strategic direction for the Fedora Project. The council has published summaries from its strategy summit, and Fedora Project Leader (FPL) Jef Spaleta, as well as some of the council members, held a video meeting to discuss outcomes from the summit on February 25. Topics included a plan to experiment with Open Collective to raise funds for specific Fedora projects, tools to build image-based editions, and more. Spaleta also explained his model for Fedora governance.
-
-
Kernel Space
-
LWN ☛ Reconsidering the multi-generational LRU [LWN.net]
The multi-generational LRU (MGLRU) is an alternative memory-management algorithm that was merged for the 6.1 kernel in late 2022. It brought a promise of much-improved performance and simplified code. Since then, though, progress on MGLRU has stalled, and it still is not enabled on many systems. As the 2026 Linux Storage, Filesystem, Memory-Management and BPF Summit (LSFMM+BPF) approaches, several memory-management developers have indicated a desire to talk about the future of MGLRU. While some developers are looking for ways to improve the subsystem, another has called for it to be removed entirely.
-
-
Programming/Development
-
LWN ☛ Debian decides not to decide on AI-generated contributions [Ed: So people who cannot code sneak trash into Debian]
Debian is the latest in an ever-growing list of projects to wrestle (again) with the question of LLM-generated contributions; the latest debate stared in mid-February, after Lucas Nussbaum opened a discussion with a draft general resolution (GR) on whether Debian should accept AI-assisted contributions. It seems to have, mostly, subsided without a GR being put forward or any decisions being made, but the conversation was illuminating nonetheless.
Nussbaum said that Debian probably needed to have a discussion ""to understand where we stand regarding AI-assisted contributions to Debian"" based on some recent discussions, though it was not clear what discussions he was referring to. Whatever the spark was, Nussbaum put forward the draft GR to clarify Debian's stance on allowing AI-assisted contributions. He said that he would wait a couple of days to collect feedback before formally submitting the GR.
His proposal would allow ""AI-assisted contributions (partially or fully generated by an LLM)"" if a number of conditions were met. For example, it would require explicit disclosure if ""a significant portion of the contribution is taken from a tool without manual modification"", and labeling of such contributions with ""a clear disclaimer or a machine-readable tag like '[AI-Generated]'"." It also spells out that contributors should ""fully understand"" their submissions and would be accountable for the contributions, ""including vouching for the technical merit, security, license compliance, and utility of their submissions"". The GR would also prohibit using generative-AI tools with non-public or sensitive project information, including private mailing lists or embargoed security reports.
-
Python
-
LWN ☛ The relicensing of chardet [LWN.net]
Chardet is a Python module that attempts to determine which character set was used to encode a text string. It was originally written by Mark Pilgrim, who is also the author of a number of Python books; the 1.0 release happened in 2006. For many years, this module has been under the maintainership of Dan Blanchard. Chardet has always been licensed under the LGPL, but, with the 7.0.0 release, Blanchard changed the terms to the permissive MIT license. That has led to an extensive (and ongoing) discussion on when code can be relicensed against the wishes of its original author, and whether using a large language model to rewrite code is a legitimate way to strip copyleft requirements from code.
The fact that chardet is LGPL-licensed has indeed caused some unhappiness in the past. That license is incompatible with the requirements for the Python standard library, frustrating those who would like to see chardet become one of the "batteries" that are included with Python; that licensing has also blocked the inclusion of some other modules that use chardet.
-
LWN ☛ Disabling Python's lazy imports from the command line [LWN.net]
The advent of lazy imports in the Python language is upon us, now that PEP 810 ("Explicit lazy imports") was accepted by the steering council and the feature will appear in the upcoming Python 3.15 release in October. There are a number of good reasons, performance foremost, for wanting to defer spending—perhaps wasting—the time to do an import before a needed symbol is used. However, there are also good reasons not to want that behavior, at least in some cases. The tension between those two positions is what led to an earlier PEP rejection, but it is also playing into a recent discussion of the API used to control lazy imports.
We looked at the PEP shortly before its acceptance and there is quite a bit of history of the idea going much further back than the 2022 rejection of a different PEP that would have made all imports lazy by default. PEP 810 adds a new "lazy" soft keyword that can be used to indicate a module (or symbol) that should not be imported immediately. Instead, proxy objects are created for the symbols that are resolved (instantiated or "reified") when they are needed.
-
LWN ☛ Inspecting and modifying Python types during type checking [LWN.net]
Python has a unique approach to static typing. Python programs can contain type annotations, and even access those annotations at run time, but the annotations aren't evaluated by default. Instead, it is up to external programs to ascribe meaning to those annotations. The annotations themselves can be arbitrary Python expressions, but in practice usually involve using helpers from the built-in typing module, the meanings of which external type-checkers mostly agree upon. Yet the type system implicitly defined by the typing module and common type-checkers is insufficiently powerful to model all of the kinds of dynamic metaprogramming found in real-world Python programs. PEP 827 ("Type Manipulation") aims to add additional capabilities to Python's type system to fix this, but discussion of the PEP has been of mixed sentiment.
-
-
-
Confidentiality
-
LWN ☛ HTTPS certificates in the age of quantum computing [LWN.net]
There has been ongoing discussion in the Internet Engineering Task Force (IETF) about how to protect internet traffic against future quantum computers. So far, that work has focused on key exchange as the most urgent problem; now, a new IETF working group is looking at adopting post-quantum cryptography for authentication and certificate transparency as well. The main challenge to doing so is the increased size of certificates — around 40 times larger. The techniques that the working group is investigating to reduce that overhead could have efficiency benefits for traditional certificates as well.
-