news
Programming/Development Leftovers
-
Python
-
LWN ☛ Following up on the Python JIT [Ed: Python infiltrated by Microsoft]
Performance of Python programs has been a major focus of development for the language over the last five years or so; the Faster CPython project has been a big part of that effort. One of its subprojects is to add an experimental just-in-time (JIT) compiler to the language; at last year's PyCon US, project member Brandt Bucher gave an introduction to the copy-and-patch JIT compiler. At PyCon US 2025, he followed that up with a talk on "What they don't tell you about building a JIT compiler for CPython" to describe some of the things he wishes he had known when he set out to work on that project. There was something of an elephant in the room, however, in that Microsoft dropped support for the project and laid off most of its Faster CPython team a few days before the talk.
Bucher only alluded to that event in the talk, and elsewhere has made it clear that he intends to continue working on the JIT compiler whatever the fallout. When he gave the talk back in May, he said that he had been working with Python for around eight years, as a core developer for six, part of the Microsoft CPython performance engineering team for four, and has been working on the JIT compiler for the last two years. While the team at Microsoft is often equated with the Faster CPython project, it is really just a part of it; ""our team collaborates with lots of people outside of Microsoft"".
-
LWN ☛ Fedora SIG changes Python packaging strategy
Fedora's NeuroFedora special-interest group (SIG) is considering a change of strategy when it comes to packaging Python modules. The SIG, which consists of three active members, is struggling to keep up with maintaining the hundreds of packages that it has taken on. What's more, it's not clear that the majority of packages are even being consumed by Fedora users; the group is trying to determine the right strategy to meet its goals and shed unnecessary work. If its new packaging strategy is successful, it may point the way to a more sustainable model for Linux distributions to provide value to users without trying to package everything under the sun.
-
-
Linux Kernel Space
-
LWN ☛ SFrame-based stack unwinding for the kernel
The kernel's perf events subsystem can produce high-quality profiles, with full function-call chains, of resource usage within the kernel itself. Developers, however, often would like to see profiles of the whole system in one integrated report with, for example, call-stack information that crosses the boundary between the kernel and user space. Support for unwinding user-space call stacks in the perf events subsystem is currently inefficient at best. A long-running effort to provide reliable, user-space call-stack unwinding within the kernel, which will improve that situation considerably, appears to be reaching fruition.
A process's call stack (normally) contains all of the information that is needed to recreate the chain of function calls that led to a given point in its execution. Each call pushes a frame onto the stack; that frame contains, among other things, the return address for the call. The problem is that exactly where that information lives on the stack is not always clear. Functions can (and do) put other information there, so there may be an arbitrary distance between the address in the stack pointer register and the base of the current call frame at any given time. That makes it hard for the kernel (or any program) to reliably work through the call chain on the stack.
-
LWN ☛ Enforcement (or not) for module-specific exported symbols
Loadable kernel modules require access to kernel data structures and functions to get their job done; the kernel provides this access by way of exported symbols. Almost since this mechanism was created, there have been debates over which symbols should be exported, and how. The 6.16 kernel gained a new export mechanism that limits access to symbols to specific kernel modules. That code is likely to change soon, but the addition of an enforcement mechanism has since been backed out.
Restrictions on exported symbols are driven by two core motivations, the first of which is to ensure that kernel modules are truly modular and do not access core parts of the kernel. The intent is limit the amount of damage a module can do, and to keep kernel modules from changing fundamental aspects of the kernel's operation. The other motivation is a desire to make life difficult for proprietary kernel modules by explicitly marking exports that are so fundamental to the kernel's design that any code making use of them must be a derived product of the kernel. Those symbols are unavailable to any module that does not declare a GPL-compatible license.
There have been many discussions about the proper exporting of symbols over the years; see the LWN kernel index for the history. The most recent example may be this discussion on whether the in-progress user-space stack-unwinding improvements should be made available to the out-of-tree LTTng module. These discussions do not appear to have impeded the exporting of symbols in general; there are nearly 38,000 exported symbols in the upcoming 6.16 kernel.
-
-
Fedora Family / IBM
-
Red Hat Releases Free RHEL Version for Developer Testing [Ed: Red Trap]
To promote and grow its enterprise Linux offerings among business developers in the IT market, open-source vendor Red Hat has created a new version of its operating system, Red Hat Enterprise Linux (RHEL) for Business Developers, which it is offering at no cost through the self-service Red Hat Developer Program.
-
-
Open Hardware/Modding
-
Hackaday ☛ 2025 One Hertz Challenge: A 555, But Not As We Know It
We did explicitly ask for projects that use a 555 timer for the One Hertz Challenge, but we weren’t expecting the 555 to be the project. Yet, here we are, with [matt venn]’s Open Source 1Hz Blinky, that blinks a light with a 555 timer… but not one you’d get from Digikey.
-