What appears to be very clear (to me at any rate!) is that DNSSEC as we know it today is just not going anywhere. It's too complex, too fragile and just too slow to use for the majority of services and their users. Some value its benefits highly enough that they are prepared to live with its shortcomings, but that's not the case for the overall majority of name holders and for the majority of users, and no amount of passionate exhortations about DNSSEC will change this.

Alan Jowett gave a remote presentation at the 2024 Linux Storage, Filesystem, Memory Management, and BPF Summit about what features could be added to LLVM to make writing BPF programs easier. While there is nothing specific to LLVM about BPF code (and the next session in the track was led by GCC developer José Marchesi about better support for that compiler), LLVM is currently the most common way to turn C code into BPF bytecode. That translation, however, runs into problems when the BPF verifier cannot understand the code LLVM's optimizations produce.

The 6.9.2, 6.8.11, 6.6.32, 6.1.92, 5.15.160, 5.10.218, 5.4.277, and 4.19.315 stable kernel updates have all been released. Each contains an important set of fixes. Users of those kernels should upgrade.

Kui-Feng Lee spoke early in the BPF track at the 2024 Linux Storage, Filesystem, Memory Management, and BPF Summit about some of the recent improvements to BPF. These changes were largely driven by the sched_ext work that David Vernet had covered in the previous talk. Lee focused on changes relevant to struct_ops programs, but several of those changes apply to all BPF programs.

With the release of Fedora 40 it's time to start looking ahead to what Fedora 41 has in store. One of the largest changes planned for the next release is a switch to DNF5, a C++ rewrite of the DNF package manager. A previous attempt to make the switch, during the Fedora 39 cycle, was called off, and deferred to Fedora 41. The developers have had nearly a year to address compatibility problems and bring DNF5 to a state suitable to replace DNF4. Signs point to a successful switch in the upcoming release, though there may be a few surprises lurking for Fedora users.

When we think of history, we often romanticize it as being born of a sudden stroke of inspiration. But the creation of git shows the far harsher reality of invention: a slowly escalating disagreement over a license; the need for a scrappy backup solution to unblock work; and then continued polishing and iteration through years and years, led not by the inventor, but rather a community.

For those who weren't around in those days, a perusal of the LWN coverage from the time might be of interest too, including:

• Our first mention of BitKeeper in October 1998
• Not quite open source, 1999
• Linus tries out BitKeeper, 2002
• The free software community and proprietary packages, 2002
• The kernel and BitKeeper part ways, 2005
• How Tridge reverse engineered BitKeeper, 2005
• The guts of Git, 2005

...and a lot more for those who care to search for it.