LWN.net's Journal
[Most Recent Entries]
[Calendar View]
Tuesday, August 3rd, 2021
| Time |
Event |
| 2:48p |
Security updates for Tuesday
Security updates have been issued by Arch Linux (chromium, nodejs, nodejs-lts-erbium, and nodejs-lts-fermium), Debian (pyxdg, shiro, and vlc), openSUSE (qemu), Oracle (lasso), Red Hat (glibc, lasso, rh-php73-php, rh-varnish6-varnish, and varnish:6), Scientific Linux (lasso), SUSE (dbus-1, lasso, python-Pillow, and qemu), and Ubuntu (exiv2, gnutls28, and qpdf). | | 8:11p |
[$] New features in Neovim 0.5 Neovim 0.5, the fifth major version of the Neovim
editor, which descends from the venerable vi editor by way of Vim, was releasedon July 2. This release is the culmination of almost two years of work, and it comes with some major features that aim to modernize the editing experience significantly. Highlights include native support for the Language Server Protocol (LSP), which enables advanced editing features for a wide variety of languages, improvements to its Lua APIs for configuration and plugins, and better syntax highlighting using Tree-sitter. Overall, the 0.5 release is a solid upgrade for the editor; the improvements should please the existing fan base and potentially draw in new users and contributors to the project. | | 10:22p |
Linux Kernel Security Done Right (Google Security Blog) Over on the Google Security Blog, Kees Cook describes his vision for approaches to assuring kernel security in a more collaborative way. He sees a number of areas where companies could work together to make it easier for everyone to use recent kernels rather than redundantly backporting fixes to older kernel versions. It will take more engineers working on things like testing and its infrastructure, security tool development, toolchain improvements for security, and boosting the number of kernel maintainers:
Long-term Linux robustness depends on developers, but especially on effective kernel maintainers. Although there is effort in the industry to train new developers, this has been traditionally justified only by the "feature driven" jobs they can get. But focusing only on product timelines ultimately leads Linux into the Tragedy of the Commons. Expanding the number of maintainers can avoid it. Luckily the "pipeline" for new maintainers is straightforward.
Maintainers are built not only from their depth of knowledge of a subsystem's technology, but also from their experience with mentorship of other developers and code review. Training new reviewers must become the norm, motivated by making upstream review part of the job. Today's reviewers become tomorrow's maintainers. If each major kernel subsystem gained four more dedicated maintainers, we could double productivity.
|
|