So things all look good, and unless something odd happens we'll have a final 6.19 next weekend."
It's impossible to overstate the importance of the work Greg has done on Linux. In software, innovation grabs headlines, but stability saves lives and livelihoods. Every Android phone, every web server, every critical system running Linux depends on Greg's meticulous work. He ensures that when hospitals, banks, governments, and individuals rely on Linux, it doesn't fail them. His work represents the highest form of service: unglamorous, relentless, and essential.
It's meant to be a way to move from governance by volume or persistence toward governance by legitimacy, transparency, and process - so that disagreements can be resolved fairly and the project can keep moving forward. Introducing structure and predictability means it easier for newcomers to the project to participate without needing to understand decades of accumulated history. It potentially could provide a clearer roadmap for developers to find a place to contribute.
The stated purpose is to start a discussion; this is openSUSE, so he is likely to succeed.
The scheduler is full of bizarre features, like its ability to perform real planetary calculations based on accurate geocentric planetary positions, lunar phase scheduling (the full moon gives a 1.4x boost to tasking, apparently) and "zodiac-based task classification".That latter feature is easily one of my favourite bits. Specific planetary bodies "rule" over specific system tasks, so the Sun is in charge of critical system processes, the Moon (tied to emotions, of course) rules over interactive tasks, and Jupiter is assigned to memory-heavy applications, among others.
critical security bug" in recent GnuPG releases.
A crafted CMS (S/MIME) EnvelopedData message carrying an oversized wrapped session key can cause a stack buffer overflow in gpg-agent during the PKDECRYPT--kem=CMS handling. This can easily be used for a DoS but, worse, the memory corruption can very likley also be used to mount a remote code execution attack. The bug was introduced while changing an internal API to the FIPS required KEM API.
Only versions 2.5.13 through 2.5.16 are affected.
While it was clear to the GNU Toolchain leadership that requirements were coming to improve the toolchain cyber-security posture, these requirements were not clear to all project developers. As part of receiving this feedback we have worked to document and define a secure development policy for glibc and at a higher level the GNU Toolchain. While Sourceware has started making some critical technical changes, the GNU Toolchain still faces serious, systemic concerns about securing a global, highly available service and building a sustainable, diverse sponsorship model.
This has been a long-running discussion; see this 2022 article for some background.
So normally this would be the last rc of the release, but as I've mentioned every rc (because I really want people to be aware and be able to plan for things) this release we'll have an rc8 due to the holiday season.And while some of the early rc's were smaller than usual and it didn't seem necessary, right now I'm quite happy I made that call. Not because there's anything particularly scary here - the release seems to be going fairly smoothly - but because this rc7 really is larger than things normally are and should be at this point.
Along with the usual fixes, this -rc also includes a new document describing the process to replace the kernel project leadership should that become necessary in the absence of an arranged transition. The plan largely follows what was decided at the Maintainers Summit in December.
We cannot fix email delivery, but we can sidestep it entirely. Public-inbox archives like lore.kernel.org store all mailing list traffic in git repositories. In its simplest configuration, korgalore can shallow-clone these repositories directly and upload any new messages straight to your mailbox using the provider's API.
Connexion