LWN.net's Journal
[Most Recent Entries]
[Calendar View]
Friday, February 7th, 2020
| Time |
Event |
| 4:37p |
Security updates for Friday
Security updates have been issued by Arch Linux (chromium, python-django, and sudo), Debian (libexif and libxmlrpc3-java), Fedora (upx and xar), openSUSE (ucl and upx), Oracle (ipa), Scientific Linux (kernel), SUSE (e2fsprogs, libqt5-qtbase, nginx, pcp, php7, rubygem-rack, systemd, wicked, and xen), and Ubuntu (mariadb-10.1, mariadb-10.3, mesa, pillow, and python-reportlab). | | 4:49p |
Davis: Is Open Source a diversion from what users really want? Over on the Ardour forum, Paul Davis wonders whether access to the source code is truly what users these days want or need. There are other closed-source digital audio workstations that are far more customizable than Ardour via a scripting language without needing any access to the source. " But perhaps for applications like Ardour, ones that do not yet exist, there ought to be a different development pathway. I remember once wondering if we should have implemented the entire GUI in PyGTK (i.e. Python). We didn't, and most of my curiosity was about whether it would have helped or hindered our development process. However, had we done so, one of the consequences would have been that many changes to the program would have been made simpler, easier to access and would require no 'rebuild'. I wonder if going forward, large-scale apps like Ardour ought to (as Reaper did relatively early in its life) consider the 'script extension system' to be a vital and critical part of the application infrastructure. This would mean, for example, writing large parts of 'core functionality' using this system, rather than dropping back into C++ to get things done. There are precedents for this: GNU Emacs, for example, is at some level written in C, but almost everything about the program is actually constructed in Emacs Lisp, its own 'scripting extension'. The C core of Emacs is so small and so irrelevant that it almost doesn't matter that it is there: if you want to modify or extend Emacs, you (almost always) write Lisp, not C." | | 7:27p |
[$] Kernel operations structures in BPF One of the more eyebrow-raising features to go into the 5.6 kernel is the ability to load TCP congestion-control algorithms as BPF programs; networking developer Toke Høiland-Jørgensen described it as a continuation of the kernel's " march towards becoming BPF
runtime-powered microkernel". On its face, congestion control is a significant new functionality to hand over to BPF, taking it far beyond its existing capabilities. When one looks closer, though, one's eyebrow altitude may well increase further; the implementation of this feature breaks new ground in a couple of areas. |
|