Brief items

Security quote of the week

We have seen a number of cases where a security bug identified by AI tools is subsequently independently discovered by a different researcher. This suggests that adversaries who do not report bugs to OSS projects are likely to be able to discover these bugs too. Given this, the OpenSSH team will, for now, be making more frequent releases to get bugfixes into users' hands more quickly rather than batching them until the next planned release.

— Damien Miller in the OpenSSH 10.5 release

Comments (none posted)

Kernel release status

The current development kernel is 7.2-rc7, released on August 9. Quoth Linus: "I don't currently see any value in delaying the 7.2 release, so I would expect that to happen next weekend unless something really bad pops up."

This release has seen 16,223 non-merge changesets from 2,628 developers, a record-breaking 599 of whom were first-time kernel contributors. The release history looks like:

RC	Date	Commits
v7.2-rc1	2026-06-28	14395	14395
v7.2-rc2	2026-07-05	433	433
v7.2-rc3	2026-07-12	475	475
v7.2-rc4	2026-07-19	557	557
v7.2-rc5	2026-07-26	611	611
v7.2-rc6	2026-08-02	615	615
v7.2-rc7	2026-08-09	500	500

See the LWN KSDB v7.2 page for a lot more details.

Stable updates: the 7.1.7, 6.18.43, 6.6.149, 6.1.181, 5.15.214, and 5.10.263 stable kernels were released on August 6, followed swiftly by the 6.12.102, 6.6.150, 6.1.182, 5.15.215, and 5.10.264 stable kernels on August 7, all of which corrected a single bug. On August 9, the 7.1.8, 6.18.44, 6.12.103, and 6.6.151 stable kernels were released.

Comments (none posted)

Distributions quotes of the week

As far as the concern about the electricity and water usage, I will point folks at the estimates of how much electricity and water might be used to watch a movie on Netflix or Hulu or Disney+. Or to make a pair of jeans, for that matter. Or the amount of CO2 generated when someone flies to a DebConf. Should we worry about ecological sustainability? Sure! But I sometimes think that this is more of an excuse to justify a position that someone has already has made for other reasons.

— Ted Ts'o

I don't have a concern with the LLM _technology_ as such: it's just maths and enough training material, which outputs a very large set of numbers that we can use to infer new material from existing material. But I am firmly of the camp that says we cannot talk about the LLM technology without talking about who is pushing for its usage, who is doing the training and how, what effect those have on our limited resources, and what are the economical and political motives of these.

And so I object to reducing the "ecological" discussion to just a "it's not that bad, $duration of LLM agent usage is the same as buying a pair of jeans", because I think that type of argument is either ill-advised, or in bad faith.

— Didier "OdyX" Raboud

Comments (9 posted)

Django moves to an annual release cycle

The Django Python web-framework project has announced that it has accepted an annual release cycle proposal. This means that the project is moving from a somewhat complicated schedule that interspersed short-lived feature releases and long-term-support (LTS) releases to a simpler annual cycle where each release is supported for three years.

Every feature release gets three years of support: one year of mainstream bugfixes, then two years of security and data-loss fixes. The "LTS" label is retired — every feature release now carries that same, unique commitment.

No more LTS gap: no racing a deadline to jump two years of changes at once. Upgrade one year at a time, whenever suits you within the support window. Three versions are supported at any time, giving third-party packages a clear, rolling target.

This will take effect with the upcoming Django 2028 release, expected in January 2028.

Comments (3 posted)

Bernard: GNOME Shell design dreams

GNOME contributor Tobias Bernard has published a blog post that details some of the design team's ideas for the GNOME Shell over the long term:

Some of these we have relatively complete plans for, others are more vague ideas that need more research and prototyping. As always, getting things like these implemented depends on developer capacity and interest (and sometimes funding).

While each of these ideas may require additional discussion, prototyping, and testing, we (the design team) have collected them all together here to share our longer-term vision and to give each idea more visibility.

Comments (27 posted)

LightDM lives: version 1.33.0 released

Version 1.33.0 of the LightDM display manager has been released. This is the first release in four years: the project had been sponsored by Canonical but was effectively unmaintained in recent years. It has been transferred to a new community repository and is now maintained by Joshua Peisach and Neal Gompa.

The new release includes Qt6 support, code optimizations, and a list of other fixes that had been in limbo pending a new release.

Comments (2 posted)

QEMU 11.1 released

Version 11.1 of the QEMU emulator has been released. The release contains more than 3,200 commits from 285 authors and includes a long list of improvements; see the announcement and changelog for the details.

Comments (none posted)

Rust Coreutils 0.10 released

Version 0.10 of the uutils project's Rust Coreutils has been released. This release focused on compatibility with the GNU Core Utilities suite, with Rust Coreutils now passing 645 of 690 tests, up from 625 with version 0.9.0. Notable changes in this release include addition of the mv --exchange option, an OpenSSL backend for checksum utilities, applying SELinux labels at creation when using mkdir, mkfifo, and mknod, as well as a number of performance and security improvements.

The project has an online playground that runs the Rust Coreutils directly in the browser via WebAssembly for those who would like to try the utilities without installing them. LWN covered the uutils project in February 2025.

Comments (31 posted)

Development quote of the week

Thank you for your pull request. Yes, that does seem like a useful feature, but you shouldn't have, and I mean you really shouldn't have. I read all 3700 words of the PR description (I appreciated the bulletpoints and bolded sections throughout), and god only knows why, I also reviewed the commits. I see the commits say they were co-authored by Claude, but from having read the code, I think you haven't given Claude enough credit. I have now turned off PRs for everyone who isn't on the approved list of contributors. Yes, that list only has me and my friend Kyla, who doesn't really write any code. Thank you for your contribution.

Yes, I know that other project has implemented this feature, and many others that have been on my backlog. If you want to depend on people who have no taste in software, you are welcome to use their project instead of mine. Open source is not a competition. Yes, I know they support Windows, which we don't. PRs welcome. No, not from you, and definitely not from them. We do support Plan 9, because one day I ate the mushrooms my friend Kyla gave me for my birthday, and realised we needed that to heal the Universe.

Yes, I know they have about ten times more stars than me. Their project is on GitHub, and mine is on Codeberg, where every star is worth 100 on GitHub. Sure, whatever, it doesn't work that way. The point is, I don't care. I have other values. Those stars don't pay the bills anyway. I know because I tried, and was told I had to stop.

— Lake Hope

Comments (none posted)

The Software Stewardship Lab launches

The Software Stewardship Lab, a nonprofit organization based in Scotland, has announced its existence.

Our current research focuses are:

• Software supply chain security — We're working on an observatory that allows users to identify and monitor the world's critical Open Source packages in real time, including previously hidden parts of the dependency graph.
• Maintainer burnout — Our report on burnout in Open Source has been well-received. We're working on yearly follow-ups, plus a companion report on how AI is affecting maintainer burnout.

Moving forward, the Lab's experts will direct funding to and supervise Open Source sustainability researchers doing critical work. We are already working with universities to teach the next generations of software supply chain experts.

Comments (3 posted)