[Posted June 19, 2026 by jzb]
Systemd v261 has been released with a long list of changes, including a new cloud "Instance Metadata Service" (IMDS) subsystem, "boot secret" functionality for use on systems that lack a physical TPM, as well as support for the kernel's Live Update Orchestration (LUO) / Kexec Handover (KHO) systems when they are present and enabled. See the release notes for the full list of changes.
to post comments
All according to plans
Posted Jun 19, 2026 21:03 UTC (Fri) by bluca (subscriber, #118303) [Link] (10 responses)
Just 2 days late on the schedule. Keeping a 3 months release cadence is not exhausting at all.
All according to plans
Posted Jun 20, 2026 12:29 UTC (Sat) by Vorpal (guest, #136011) [Link] (9 responses)
All according to plans
Posted Jun 20, 2026 14:28 UTC (Sat) by magfr (subscriber, #16052) [Link]
Actually the C++ experience is also a data point here. Everyone agrees that the 13 years from C++98 to C++11 was a disaster.
The current 3-year release cycle seems to work in that community.
All according to plans
Posted Jun 20, 2026 15:36 UTC (Sat) by ibukanov (subscriber, #3942) [Link] (1 responses)
Rust editions are not releases but just versions of Rust syntax/semantic. Critically older editions are still supported by the compiler and one can link against crates using different editions.
All according to plans
Posted Jun 22, 2026 7:43 UTC (Mon) by taladar (subscriber, #68407) [Link]
They are the only point for 3 years where certain changes can happen though which is probably more relevant to the stress factor. If you miss it you have to wait another 3 years.
All according to plans
Posted Jun 21, 2026 10:52 UTC (Sun) by farnz (subscriber, #17727) [Link] (1 responses)
The other big thing, IME, is that once you've got fast enough releases, you stop letting the release date slip so that an important feature or bug-fix can make it in. That change in attitude from "delay the release" to "delay the feature" is surprisingly helpful.
All according to plans
Posted Jun 21, 2026 12:01 UTC (Sun) by iabervon (subscriber, #722) [Link]
I think a key aspect is that, at a certain cadence, you can can say that work doesn't happen on a feature after the previous release comes out, and you're not losing a significant amount of development time from the schedule. This means that your release process doesn't have to predict how long it will take for a feature to be finished (because it doesn't get assigned to a release until it's already finished), and release engineering doesn't have to make any judgment calls.
All according to plans
Posted Jun 21, 2026 21:49 UTC (Sun) by ballombe (subscriber, #9523) [Link] (3 responses)
All according to plans
Posted Jun 22, 2026 7:54 UTC (Mon) by taladar (subscriber, #68407) [Link] (2 responses)
All according to plans
Posted Jun 22, 2026 9:00 UTC (Mon) by nim-nim (subscriber, #34454) [Link]
As you wrote yourself the key success factor is getting your users to update regularly instead of locking down a “good enough” version and then freaking out before accumulated changes when this locked version needs replacement. And avoiding drastic fell-good greenfield revolutions that invalidate user trust in the safety of updates. The steady stream of small controlled changes builds trust.
All according to plans
Posted Jun 22, 2026 16:42 UTC (Mon) by rgmoore (✭ supporter ✭, #75) [Link]
On the other hand if releases are frequent and small the whole long term support use case sort of collapses
That depends a lot on who your users are. If users are other developers who are expected to be constantly updating their projects anyway, then change is just part of the landscape. But if you're building for end users who are just trying to get their work done, constant change is the enemy. Most end users would rather have their application work consistently than have to adapt to constant change, even if that change is supposedly an improvement.
If I'm working on a years-long project, it's critical that my software work consistently the whole time so my results at the beginning and end are truly comparable. Maybe there will be an improvement that's worth spending the time to redo my work, but you're going to have to sell me on it. Even people with less stringent requirements than mine- and I am working in an area where consistency is unusually important- the temporary loss of productivity adapting to change is a real cost. Developers need to be mindful that those costs don't disappear just because they've pushed them onto their users.
Instagram Engineering
Shopify Engineering