Brief items

Kernel release status

The current development kernel is 6.2-rc3, released on January 8. Linus said: "Here we are, another week done, and things are starting to look a lot more normal after that very quiet holiday week that made rc2 so very small".

Stable updates: 6.1.4, 6.0.18, and 4.9.337 were released on January 7. Greg Kroah-Hartman has let it be known that 4.9.337 is the end of the line for the 4.9 kernel, which was released just over six years ago. "This kernel is now END-OF-LIFE and you should move to 4.14.y at the least, 6.1.y is the better option."

The 6.1.5, 6.0.19, and 5.15.87 stable updates are in the review process; they are due on January 12.

Comments (none posted)

Discourse 3.0 released

Version 3.0 of the Discourse forum platform is out.

We are bringing our customers and users some major new capabilities to enable communities to have thoughtful, purposeful discussions online. This new release includes real-time chat and user status to enable more informal communication, a customizable sidebar for easier access to the things each user cares about most, and a new notifications interface that makes it easier to decide what is important to follow up on, along with many other improvements.

Comments (14 posted)

PEP 703: Making the Python global interpreter lock optional

In late 2021, LWN covered a plan to eliminate the Python global interpreter lock (GIL), thus improving the language's thread-level concurrency. This plan has now been codified as PEP 703, which includes an extensive discussion of the changes that would be made.

The global interpreter lock will remain the default for CPython builds and python.org downloads. A new build configuration flag, --without-gil will be added to the configure script that will build CPython without the global interpreter lock.

The posting of a PEP is only one step in a long path toward integrating this change into the CPython interpreter; expect some extended discussions over the coming months.

Comments (21 posted)

Hutterer: X servers no longer allow byte-swapped clients

Peter Hutterer writes about the disabling of support for byte-swapped clients in the X.org server and the reasons why this was done.

These days, encountering a Big Endian host is increasingly niche, letting it run an X client that connects to your local little-endian X server is even more niche. I think the only regular real-world use-case for this is running X clients on an s390x, connecting to your local intel-ish (and thus little endian) workstation. Not something most users do on a regular basis. So right now, the byte-swapping code is mainly a free attack surface that 99% of users never actually use for anything real. So... let's not do that?

Comments (65 posted)