LWN.net's Journal
 
 [Most Recent Entries] [Calendar View]

Wednesday, July 31st, 2019

    Time Event
    2:59p
    Security updates for Wednesday
    Security updates have been issued by CentOS (389-ds-base, curl, and kernel), Debian (libssh2), Fedora (kernel, kernel-headers, and oniguruma), openSUSE (chromium, openexr, thunderbird, and virtualbox), Oracle (389-ds-base, curl, httpd, kernel, and libssh2), Red Hat (nss and nspr and ruby:2.5), Scientific Linux (httpd and kernel), SUSE (java-1_8_0-openjdk, mariadb, mariadb-connector-c, polkit, and python-requests), and Ubuntu (openjdk-8, openldap, and sox).
    3:13p
    Three stable kernels
    Stable kernels 5.2.5, 4.19.63, and 4.14.135 have been released. These updates are
    on the large side. The 4.14 kernel is largest with 4748 insertions and 3145
    deletions. As usual, users should upgrade.
    4:39p
    [$] Bounded loops in BPF for the 5.3 kernel
    BPF programs have gained significantly in capabilities over the last few
    years and can now perform many useful operations. That said, BPF
    developers have had to work around an annoying limitation until
    recently: they could not use loops. This restriction was recently lifted
    by a patch
    set     from Alexei Starovoitov that was merged for Linux 5.3. In addition to
    adding support for loops, it also greatly decreases the load time of
    most BPF programs.
    4:52p
    [$] KernelShark releases version 1.0
    It has been the better part of a decade since the last KernelShark article appeared here; in the
    interim, the kernel-tracing visualization tool has undergone some major changes.
    While the high-level appearance is largely similar, the underlying code
    has switched from GTK+ 2.0 to Qt 5. On July 26,
    maintainer Steven Rostedt announced
    the release of KernelShark version 1.0, which makes it a good time to
    take another peek.
    9:12p
    [$] Python and public APIs
    In theory, the public API of a Python standard library module is fully
    specified as part of its documentation, but in practice it may not be
    quite so clear cut. There are other ways to specify the names in a module that
    are meant to be public, and there are naming conventions for things that
    should not be public (e.g. the name starts with an underscore), but
    there is
    no real consistency in how those are used throughout the standard library.
    A mid-July discussion
    on the python-dev mailing list considered the problem and some possible
    solutions; the main outcome seems to be interest in making the rules more
    explicit.

    << Previous Day 2019/07/31
    [Calendar]     		Next Day >>

LWN.net   About LJ.Rossia.org