Welcome to the LWN.net Weekly Edition for October 22, 2020

This edition contains the following feature content:

• What is coming in PHP 8: the next major PHP release brings many significant changes.
• 5.10 Merge window, part 1: the first installment of changes for the 5.10 kernel release.
• The Arm64 memory tagging extension in Linux: the 5.10 kernel will include support for an upcoming Arm memory-safety feature.
• Resource management in KDE: how the KDE desktop is taking advantage of Linux resource-management capabilities.
• The accelerating adoption of Julia: recent changes to the language and a look at why users like it.

This week's edition also includes these inner pages:

• Brief items: Brief news items from throughout the community.
• Announcements: Newsletters, conferences, security updates, patches, and more.

Please enjoy this week's edition, and, as always, thank you for supporting LWN.net.

Comments (none posted)

What is coming in PHP 8

Recently, PHP 8 release candidate 2 was posted by the project. A lot of changes are coming with this release, including a just-in-time compiler, a good number of backward-compatibility breaks, and new features that developers have been requesting for years. Now that the dust has settled, and the community is focusing on squashing bugs for the general-availability release scheduled for November 26, it's a good time to look at what to expect.

General impressions, improvements, and changes

To a certain degree, PHP 8 represents a departure from the project's past. Historically, the community has placed a high value on backward compatibility, even between major releases. This doesn't seem to have been as much of a concern for this release, judging by the upgrade notes. With the scope and quantity of backward-incompatible changes, even relatively modern PHP applications will require a little tweaking to bring them up to speed.

The community has expended considerable effort in making PHP 8 into a more consistent language, both in terms of behaviors and syntax. Four separate proposals with a focus on making PHP into a more consistent language — in terms of behavior and syntax — have been implemented. These changes generally concern themselves with edge cases or preexisting quirks of the language; there are, however, a few notable changes worth mentioning explicitly.

Starting with the variable syntax tweaks proposal, the new and instanceof statements can now be used with expressions. The new statement is common across many languages, which is used to create a new instance of a class; instanceof checks if a particular class instance is of a particular type, accounting for class hierarchies. Prior to PHP 8, these statements were syntactically limited: a statement like new $myClassName that created a class whose name was stored in $myClassName was valid, but not an expression like new ("{$myClassName}{$i}"). This behavior has been corrected for PHP 8, allowing expressions to be used in both cases:

    // Create an instance of the built-in stdClass
    $obj = new ("std" . "Class");
    $trueValue = $obj instanceof ("std" . "Class");

The parentheses are important in order for PHP 8 to parse the statements correctly.

The saner numeric strings proposal significantly reworks the way PHP handles string-to-numeric type conversions, producing a more reasonable set of behaviors. This is especially true of numbers padded by white space, which are a frequent occurrence when dealing with user input:

    // PHP 8 type conversion behaviors for numeric values

    function foo(int $i) { return $i; }

    $a = foo(" 123  "); // int(123)
    $a = foo("123abc"); // throws TypeError, int type required
    $a = 123 + " 123  "; // int(246)
    $a = 123 + "123abc"; // int(246) with E_WARNING

    $intVal = "1  ";
    $a = ++$intVal; // int(2)
    $a = ("123" == " 123  "); // bool(true)

The last example is perhaps the most confusing: ("123" == " 123 ") equals true. This is not an intuitive result to many programmers, as they are both string values and it seems reasonable they should be compared as such. When PHP 8 encounters these comparisons, it first examines the strings to determine if they both appear to be numeric values. Since they both meet the conversion criteria, PHP will convert them to their numeric values before comparing them, which evaluates to true; using the strict-comparison operator === would ensure that the literal strings were compared instead.

In a similar direction, the saner string-to-number comparisons proposal cleans up some long-standing problems when comparing strings that represent numeric values. Consider the following code:

    $validValues = ["foo", "bar", "baz"];
    $value = 0;
    // search for $value in $validValues
    $result = in_array($value, $validValues));

In PHP 7, $result equals true, because any string such as "foo" would be converted to an integer zero by the in_array() function. In PHP 8, behaviors like this have been corrected to return a more intuitive result. Here is a table of how these changes will impact various expressions in PHP 8:

Expression	PHP 7	PHP 8
0 == "0"	true	true
0 == "0.0"	true	true
0 == "foo"	true	false
0 == ""	true	false
42 == " 42"	true	true
42 == "42foo"	true	false

Per the proposal, "an alternative way to view these comparison semantics is that the number operand is cast to a string, and the strings are then compared using the non-strict 'smart' string comparison algorithm."

Finally, precedence changes have been made in PHP 8 for the string concatenation operator. The change ensures an expression like the one below matches the developer's likely intent:

    $a = 5;
    $b = 10;
    echo "sum: " . $a + b;

In PHP 7, the output of the above would evaluate as ("sum: " . $a) + $b, where in PHP 8 it more reasonably evaluates as "sum: " . ($a + $b).

PHP 8 has made some significant changes to various aspects of error handling, both for built-in functions and in the language itself. One specific change that stands out is the @ operator, which is used (and misused) in PHP to block errors, warnings, and notices for a single expression. Starting with PHP 8, the @ operator will no longer block fatal errors as it has previously done; the new behavior may cause errors to be revealed in existing applications that were previously ignored.

There have also been substantial changes for warnings and errors generated by built-in PHP functions. Per the request for comments (RFC), there are over 30 changes to how PHP responds to a variety of error conditions; this includes over a dozen errors that would previously have caused an ignorable warning, but which will now throw exceptions.

Lastly, developers should review the deprecation warnings that were introduced to a variety of functions and features in PHP 7. These deprecations can be found in RFCs for versions 7.2, 7.3, and 7.4; they have all been finalized for PHP 8 and will need to be addressed before upgrading.

Taken as a whole, these changes indicate that upgrading to PHP 8 won't be as straightforward a process as the transition from PHP 5 to PHP 7 was; readers will recall the project abandoned PHP 6.

PHP 8 has a lot more than the above to offer; there are also plenty of new features. In fact, too many to cover at one time. Two of our previous articles on PHP attributes and match expressions are recommended reading for details on those specific features. Readers are also encouraged to review the PHP 8.0 release notes for bug fixes, and the project's RFC section on PHP 8 for an exhaustive listing of changes and improvements.

New string functionality

String handling in PHP 8.0 received a fair amount of attention, with a variety of new functions and types being added to the language. First up is str_contains(), which determines whether a substring exists within another string; it replaces strpos() when the location of the substring is not needed:

    $str = "Linux is great";

    if  (strpos($str, "Linux")) { /* Incorrect usage */
        print "found";
    }

This code represents a common mistake in PHP. strpos() returns the position of a string found within another string, or false if not found. In this case, it returns 0; this is the equivalent to false based on PHP's type-conversion rules. The correct way to implement this using the strpos() function would be to use the strict-comparison operator:

    $str = "Linux is great";

    if (strpos($str, "Linux") !== false) {
        print "found";
    }

As Nikita Popov noted, "this operation is needed often enough that it deserves a dedicated function." str_contains() provides an alternative to strpos() that is less likely to introduce bugs:

    $str = "Linux is great";

    if (str_contains($str, "Linux")) {
        print "found";
    }

While useful, str_contains() only returns a boolean if the substring is found or not, not the position of it; if the position is needed, strpos() must be used.

In the same vein are the new str_starts_with() and str_ends_with() functions. As their names imply, they allow developers to determine if a string starts (or ends) with another string:

    $str = "Linux is great";

    if (str_starts_with($str, "Linux")) {
        print "found\n";
    }

    if (str_ends_with($str, "great")) {
        print "found\n";
    }

Lastly, PHP 8 introduces the Stringable built-in interface. This interface can be used as a type-hint for any object that implements the __toString() method:

    function needsString(string | Stringable $str) {
        /* ... */
    }

The declaration of needsString() also makes use of another addition, type unions, which enable the use of multiple type-hints in function or method declarations. The example is verbose to highlight type unions; in reality, a string type-hint supports both string types and Stringable objects. However, note that the opposite is not true: only specifying Stringable as a type does not permit string types.

New types

On the subject of types, a couple of new ones have been added. The first is the mixed type, which can be best thought of as a union of these internal types: array, bool, callable, int, float, null, object, resource, and string. In previous versions of PHP, the only way to represent a "mixed" type would be to omit typing information completely; a functional but ambiguous solution. The new mixed type provides a better way for developers to explicitly indicate their intent.

The second type added is the static type, which applies only to method return values. In PHP, static is a special class name referring to the class a method was called from, even if the method was inherited; it is known as late static binding. Prior to now, PHP has supported the self-referencing self and parent return types for class methods, but those two types alone are insufficient to cover all the cases; prior to PHP 8 there was no way for a method that was inherited from a parent class to indicate that the return value must be an instance of the child class.

Object-oriented features

A shorthand syntax was added for assigning properties when creating an instance of a class, called constructor property promotion. Essentially, it allows class properties to be implicitly declared and assigned by specifying them as constructor parameters. Consider the following, traditional, example declaring a class in PHP:

    class Foo {
        private string $bar;

        public function __construct(string $bar) {
            $this->bar = $bar;
        }
    }

In PHP 8, the class can be defined with much less code:

    class Foo {
        public function __construct(private string $bar) {}
    }

In the example, the private property $bar is automatically created in the Foo class, being assigned its value when the object is instantiated. The syntax does not prevent developers from adding additional logic to the constructor; properties will automatically be defined and assigned their values first, followed by any custom logic. If a parameter is modified by custom logic, then the corresponding property must be updated manually.

PHP 7.4 introduced support for weak references, and in PHP 8, that concept was expanded further into a new WeakMap class. To understand what these features do, a slight tangent into PHP garbage collection is necessary. When a data structure, such as an object, is created, the allocated memory remains until all references in the script to that data have been destroyed. Once the object is no longer referenced, PHP will release that memory for something else. This becomes problematic when objects are cached, since the reference to an object in the cache will prevent PHP from freeing the memory — even if the only place that object still exists is in the cache. For a longer-running PHP process, the result is, functionally, a memory leak.

Weak references are implemented using the WeakReference class, which is to be used to indicate an object can be destroyed by the garbage collector once the only references to it are "weak" references. An example taken from the PHP documentation is provided below:

    $obj = new stdClass;
    $weakref = WeakReference::create($obj);

    var_dump($weakref->get()); // returns the object
    unset($obj);
    var_dump($weakref->get()); // returns NULL

In PHP 8, weak references have been expanded to include a new WeakMap class; it provides an array-like interface for storing weak object references in a single data structure. Here's an example of how WeakMap might be used in a caching mechanism:

    class StatsGenerator {

        private WeakMap $cache;

        public function __construct() {
            $cache = new WeakMap;
        }

        public function getUserStats(User $user) : UserStats {
            return $this->cache[$user] ??= $this->generateUserStats($user);
        }

        protected function generateUserStats(User $user) : UserStats {
            /* Do expensive stats generation */
        }

    }

In the StatsGenerator class, a simplistic caching mechanism is created that uses a WeakMap instance to store the result of a statistics-generating operation in memory. The first time getUserStats() is called, the generateUserStats() method performs an (expensive) operation to build a UserStats object; subsequent calls to the method return the previously-generated UserStats object. This cache will persist as long as $user has references that exist in the application outside of the StatsGenerator class. Once all references to $user are gone, PHP will garbage-collect the UserStats object from $cache as well:

    // Find a user by ID
    $user = getUserById(42);

    $generator = new StatsGenerator;

    // This call generates new statistics based on $user
    $userStats = $generator->getUserStats($user);

    // This returns the previously-generated statistics
    $userStats = $generator->getUserStats($user);

    // Destroy the only real reference to the $user object,
    // also destroys the UserStats instance inside of StatsGenerator
    unset($user); 

    // Regenerate the statistics
    $user = getUserById(42);
    $userStats = $generator->getUserStats($user);

There are also some exception-related improvements to be found in PHP 8. Moving forward, exceptions can be caught without having to create a variable to store the exception in the catch block:

    try {
        throw new Exception("Something went wrong.");
    } catch(Exception) { // no need to provide a variable here in PHP 8
        Log::error("Something broke.");
    }

Additionally, the throw operation has been changed from a statement to an expression in PHP, which enables exceptions to be thrown in a variety of new ways that previously required substantially more code to accomplish:

    // Pre-PHP 8
    if (!isset($user['email'])) {
        throw new UserMissingEmail($user);
    }

    $email = $user['email'];

    // With PHP 8
    $email = $user['email'] ?? throw new UserMissingEmail($user);

The nullsafe operator and named parameters

Then, there is the nullsafe operator, which allows null-coalescing-like behavior for read-only operations. For PHP developers like myself, it is a welcome addition to the language. Consider the following example taken from the proposal for the operator, representative of typical error checking in a PHP application:

    $country =  null;

    if ($session !== null) {
        $user = $session->user;
            if ($user !== null) {
                $address = $user->getAddress();
                if ($address !== null) {
                    $country = $address->country;
                }
            }
        }
    }

With the nullsafe operator, this verbosity can be eliminated entirely:

    $country = $session?->user?->getAddress()?->country;

Last in our look at new features in PHP 8 is named arguments, which expand the way parameters can be passed into methods and functions:

    function register(?string $email = null, string $first, string $last) {
        /* ... */
    }

    // Call register(), passing in the parameters by their declared names
    register(
        first: "Joe",
        last: "Example"
    );

Named parameters are a long-desired feature for PHP developers; the proposal for them was first created in 2013. With this implementation, many doors open for the types of code PHP developers can write.

Conclusion

PHP 8 looks to be a significant step forward for the language, and it is great to see the project continuing to improve after over 25 years. While it does seem that developers will have their work cut out for them in upgrading their applications, it would appear that all of the backward-compatibility breaks were done for good reasons. For those of us who maintain PHP code bases, now would be a perfect time to start testing and reporting any unexpected issues to the PHP bug tracker. Two more release candidates are expected before the final version 8.0 release; the next, release candidate 3, is scheduled for October 29.

Comments (8 posted)

5.10 Merge window, part 1

As of this writing, 7,153 non-merge changesets have been pulled into the mainline Git repository for the 5.10 release — over a period of four days. This development cycle is clearly off to a strong start. Read on for an overview of the significant changes merged thus far for the 5.10 kernel release.

Architecture-specific

• The arm64 architecture can now do performance-events monitoring over Arm's CMN-600 interconnect.
• The Arm v8.5 memory tagging extension [PDF] is now supported. This feature allows a four-bit tag to be assigned to every 16-byte "granule" in physical memory; whenever a pointer into a specific granule is dereferenced, the CPU will ensure that the tag stored in the pointer matches that assigned to the granule. Proper use of this extension can trap use-after-free and buffer-overflow bugs (and attempts to exploit those bugs). See this article for more information on this feature.
• The ia64 performance-monitoring code has been removed. Few are likely to miss it, since it hasn't worked for years.
• AMD's "secure encrypted virtualization" (SEV) feature encrypts memory assigned to virtualized guests; Linux has supported SEV for a while. The new SEV-ES feature, merged for 5.10, expands SEV by encrypting the guest's processor registers as well, making them unavailable to the host unless the guest explicitly shares them.

Core kernel

• The io_uring subsystem now supports the creation of restricted rings that can be passed safely to a less-trusted process.
• The pidfd_open() system call now supports a PIDFD_NONBLOCK flag to create a non-blocking file descriptor. See this commit for a thorough description of the semantics of non-blocking pidfds.

Filesystems and block I/O

• The Btrfs filesystem has gained some significant performance improvements in fsync() operations.
• XFS has seen a bunch of work to resolve its year-2038 problems; timestamps in this filesystem are now good through 2468. Developers now have clear warning of a problem coming in 448 years, but chances are they will procrastinate on addressing it for at least 440 of them.

Hardware support

• Graphics: Lontium LT9611 DSI/HDMI bridges, Toshiba TC358775 DSI/LVDS bridges, Toshiba TC358762 DSI/DPI bridges, Mantix MLAF057WE51-X MIPI-DSI LCD panels, Cadence DPI/DP bridges, Samsung S6E63M0 RGB DSI interfaces, and NXP i.MX8MQ display controllers.
• Hardware monitoring: Analog Devices ADM1266 sequencers, MPS MP2975 multi-phase controllers, Intel MAX10 BMC monitoring chips, and Moortec Semiconductor MR75203 PVT controllers.
• Industrial I/O: Analog Devices ADXRS290 dual-axis MEMS gyroscopes, AMS AS73211 XYZ color sensors, and TI HDC2010 relative humidity and temperature sensors.
• Miscellaneous: Amazon Annapurna Lab memory controllers, MediaTek MStar interrupt controllers, Xiphera XIP8001B true random number generators, Ingenic true random number generators, MCHP Sparx5 SDHC interfaces, Baikal-T1 SPI controllers, TI LP5036/30/24/18/12/9 LED controllers, Kontron sl28cpld interrupt/watchdog/PWM controllers, ENE KB3930 embedded controllers, Intel MAX 10 board management controllers, Kinetic KTD253 backlight drivers, Hisilicon 3670 SPMI controllers, Hisilicon Hi6421v600 SPMI power-management ICs, and Qualcomm SM8150 and SM8250 interconnect buses.
• Pin control: Qualcomm 8226 pin controllers, Actions Semi S500 pin controllers, Mediatek MT8192 and MT8167 pin controllers, Toshiba Visconti TMPV7700 series pin controllers, and Allwinner A100 pin controllers.
• Regulator: Richtek RT4801 regulators, Raspberry Pi 7-inch touchscreen panel ATTINY regulators, MediaTek MT6360 SubPMIC regulators, and Richtek RTMV20 load switch regulators.
• Sound: MediaTek MT6359 codecs, Microchip S/PDIF controllers, Cirrus Logic CS4234 codecs, and Texas Instruments TAS2764 mono audio amplifiers.
• USB: Hisilicon hi3670 USB PHYs, Mediatek MT6360 Type-C controllers, UniPhier AHCI PHYs, Intel Lightning Mountain USB PHYs, STMicroelectronics STUSB160x Type-C controllers, Maxim TCPCI based Type-C chips, and Qualcomm PMIC USB Type-C detectors.
• There is an entirely new user-space API for GPIO lines. Naturally, this API is rigorously undocumented, but some information can be gleaned from this commit.
• The "raw" char device, which provides a classic Unix-style char interface to block devices, has been deprecated with the intention of removing it in the 5.14 release. The raw device was primarily used for direct I/O, which has been supported via the O_DIRECT flag since 2002.

Security-related

• Support for the RC4-HMAC-MD5 KerberosV algorithm has been removed from the crypto subsystem. This algorithm was created for compatibility with Windows 2000; according to the commit, its removal "should only adversely affect interoperability with Windows NT/2000 systems that have not received any updates since 2008 (but are connected to a network nonetheless)".
• The SM2 digital-signature algorithm is now supported.
• It is now possible to remove security.selinux extended attributes from files, but only before the SELinux policy is loaded. This makes it possible to "unlabel" files when SELinux is not being used.

Virtualization and containers

• Support for Amazon Nitro enclaves has been added. See Documentation/virt/ne_overview.rst for some more information.

Internal kernel changes

• The seqcount latch specialized lock type has been added.
• "Orphan sections" — code or data sections that find their way into the kernel image without having been explicitly put there by the linker script — will now generate warnings during the kernel build. This change was made to protect the kernel from the possibility of unwanted changes in how linkers place those sections; the merge changelog describes orphan sections as "a long-standing source of obscure bugs".
• Static calls are a mechanism for performing indirect function calls with better performance, especially on systems where retpolines would otherwise have to be used to protect against Spectre vulnerabilities. This mechanism has been under development since 2018; it was finally merged for 5.10.
• The printk() subsystem has gained a new lockless ring buffer meant to be a first step in resolving a number of problems in this area. See this article for an overall description of the printk() work, including the new ring buffer.
• The minimum version of Clang needed to build the kernel is now 10.0.1.

The 5.10 merge window can be expected to close on October 25, after which the stabilization portion of the development cycle will begin. Stay tuned for LWN's coverage of the second half of the 5.10 merge window, to be published shortly after the window closes.

Comments (41 posted)

The Arm64 memory tagging extension in Linux

One of the first features merged for the 5.10 kernel development cycle was support for the Arm v8.5 memory tagging extension [PDF]. By adding a "key" value to pointers, this mechanism enables the automated detection of a wide range of memory-safety issues. The result should be safer and more secure code — once support for the feature shows up in actual hardware.

As one might expect, the Arm64 architecture uses 64-bit pointers to address memory. There is no need (yet!) for an address space that large, though, so normally only 48 of those bits are actually used by the hardware — or 52 bits if a special large-address-space option is enabled. So there are 12-16 bits that can be used for other purposes. Arm systems have long supported a "top byte ignore" feature that allows software to store arbitrary data in the uppermost byte of a virtual address, but the hardware designers have been busy coming up with other uses for those bits as well. The memory tagging extension (MTE) is one of those uses.

Specifically, MTE allows the storage of a four-bit "key" in bits 59-56 of a virtual address — the lower "nibble" of the top byte. It is also possible to associate a specific key value with one or more 16-byte ranges of memory. When a pointer is dereferenced, the key stored in the pointer itself is compared to that associated with the memory the pointer references; if the two do not match, a trap may be raised. Keys can be managed by the application, or they can be randomly generated by the CPU.

Four bits only allow for 16 distinct key values, but that is enough to do some interesting things. If a function like malloc() ensures that allocations that are adjacent in memory have different key values, then an access that overruns any given allocation will be detected by the processor. Use-after-free bugs can be detected by changing the key value immediately when a range of memory is freed. If each stack frame is given its own key, buffer overruns on the stack will also generate traps. An attempt to dereference a completely wild pointer (or one injected by an attacker) also has a good chance of being detected.

MTE thus has two levels of applicability. If enabled during the normal software-development process, it should help to identify a range of bugs before they ever make it into a release. But it can also be enabled on production systems to add one more obstacle that an attacker must overcome to exploit a known vulnerability.

MTE is disabled by default on Linux systems, even on hardware that supports it. A user-space process can enable MTE for a specific region of memory by specifying the new PROT_MTE flag in the mmap() call creating that region. mprotect() can also be used to enable MTE on already-mapped memory. Only anonymous memory can have PROT_MTE set; attempts to use it with file-backed memory will fail.

The default key associated with all memory is zero; using any other value requires a couple of steps. The first of those is usually to create a tagged address for the memory of interest; that is simply a matter of storing the key value in bits 59-56 of the address. There is a new instruction (IRG) that will generate a random key and store it into an address. The other piece is to associate the key with the memory itself. To that end, another new instruction (STG) takes a pointer value and sets the key for the 16-byte "granule" containing the pointed-to memory to the key found in that pointer. Various other instructions exist for managing tags, setting the contents of memory along with the tag, etc. These are all unprivileged operations that do not require assistance from the kernel.

If a process attempts to access memory with the wrong key, the processor will, by default, do nothing. This can be changed by using the PR_SET_TAGGED_ADDR_CTRL command to the prctl() system call. Providing a value of PR_MTE_TCF_NONE disables tag checking (the default). There are two values (PR_MTE_TCF_SYNC and PR_MTE_TCF_ASYNC) that will cause a SIGSEGV to be delivered on a key mismatch; the former causes the signal to be delivered immediately (synchronously), while the latter queues it asynchronously. A synchronous signal will be delivered immediately to the offending thread and the operation will not be performed; if the signal is not handled the process will be terminated. An asynchronous signal will be queued for later delivery to the process, and the mismatched operation will proceed.

There are some other features associated with MTE that are supported by the kernel, including a set of ptrace() commands for manipulating tags for another process. Some more information (and a sample program) can be found in Documentation/arm64/memory-tagging-extension.rst in the kernel source. Note that, in 5.10, use of MTE is only supported for user space; support for MTE within the kernel itself will come in a future development cycle.

Some readers may note a resemblance to the Arm pointer authentication feature, which stores a short cryptographic signature into the upper bits of pointer values. Pointer authentication can prevent the creation of new pointers by an attacker; it depends entirely on the knowledge of a secret key value and does not associate any sort of key with the memory itself. This feature and MTE can be used together, though MTE will rob some bits and make the pointer-authentication signature shorter. There is value in both; MTE can prevent overruns on the stack, while authentication can prevent the corruption of the stack pointer itself.

While the MTE feature seems useful, the number of applications that will gain direct support for it is likely to be small. Happily, much of the benefit can be had without the need to change applications at all. If the C library (and its memory allocator in particular) supports MTE, then all applications should gain the extra memory-safety checks automatically. MTE patches for the GNU C library have been posted for consideration, so that support should be available eventually. The LLVM compiler has support for stack tagging now; GCC should gain that support eventually.

None of this is helpful to anybody now, though, since hardware with MTE support is not actually shipping yet. The good news is that, once that hardware is available, the software side should be ready for it immediately. That, with any luck at all, should lead to more secure systems and software with fewer bugs, even on hardware without the memory-tagging feature.

Comments (9 posted)

Resource management in KDE

Applications that run on the Linux desktop have changed significantly under the hood in recent years; for example, they use more processes than before. Desktop environments need to adapt to this change. During Akademy 2020, KDE developers David Edmundson and Henri Chain delivered a talk (YouTube video) about how KDE, working with other desktop environments, is starting to use advanced kernel features to give users more control over their systems. This talk complements a presentation by GNOME developers that was recently covered here.

Process-management issues in Plasma

Edmundson started by explaining that the job of a desktop environment is deliver applications to the user. Users "need to be in control", he said. That role has become more complicated in recent years. Some time ago, when a user was running a web browser like Firefox or a chat application like Kopete, the management of running processes was easy. The user could run a ps command and would see just one line of output for each of those applications. This was easy to understand and self-explanatory.

Now, the situation is "very different". When a user opens a Firefox instance they can get a dozen processes; Discord in a Flatpak ("because it is cool now") launches 13 processes. The ps output is unreadable; it consists of "random names doing random things". Just understanding that output is difficult; aggregating the results to get an idea of how much CPU time or power the application is using has become even more challenging. There is thus a need to track processes properly in desktop environments, since the available data no longer means anything. We "need some metadata", Edmundson concluded.

Fairness is also an increasingly important issue. Edmundson gave an example of Krita, an advanced graphics application. It performs some heavy processing, all contained within a single process. On the other hand, Discord has those 13 processes, many of which will be making heavy use of the CPU "because it is written in Electron". The system's CPU scheduler will see those two applications as 14 opaque processes, not knowing what they correspond to. This means that Krita could get only 1/14 of the available CPU time, even though it represents half of the applications running. Metadata about running applications needs to propagate through the whole software stack to be available to the scheduler, he said.

One of Plasma's tasks is mapping windows to applications. More precisely, it tries to map windows to their associated desktop files — the configuration files containing metadata that are used, for example, to create menu entries. Applications open windows and "we hope we can match it all up". The Plasma developers use a lot of hacks and heuristics to perform this matching, but "we do not like guessing", he said. He made an example of a Firefox window being used to watch an Akademy talk like his. There is an audio icon inside that window, but this icon is not managed by the same process as the one controlling the outer window, he explained. Plasma needs to find the link between them, and "it is an arbitrary guessing game".

Introducing control groups

Chain came in to explain that "the good news is that this is essentially a solved problem". The solution exists in the form of control groups (or cgroups), a kernel feature available since the 2.6.24 kernel release in January 2008. Control groups enable a partitioning of the process space with a hierarchical structure. Originally cgroups were designed for servers; there is a lot of use in containers, he added.

Resource controllers can be attached to control groups; there are three main ones: CPU, memory and I/O (for disk access). Their basic functions are to limit overall resource use, influence the scheduler, and account for resource use at the group level. Another feature of cgroups is a finer control over the out-of-memory policy. The CPU controller influences scheduling through "weights", which can be defined in relation to siblings in the process tree. Groups with a higher weight receive proportionately more CPU time. For the desktop, the weight strategy is more interesting than setting priorities with nice. Among other things, weights can be used to raise a process's priority within a control group as well as to lower it.

Cgroups can be controlled directly from sysfs, but in practice there is a need for a central daemon to manage the placement of processes withing groups. In Linux systems, systemd has been supporting that "forever", Chain said, adding that every systemd unit is placed into its own cgroup already. Systemd is capable of delegating management of the cgroup tree to another user-space process; this is done by a separate systemd instance. Systemd also provides a D-Bus interface that can be used from user space, allowing cgroups to be controlled from any application. The configuration issue is also solved, as it can be configured at several levels.

Cgroups were redesigned in 2015 to solve a number of problems; the resulting API is called cgroups v2. However, most distributions configure systemd to work using a hybrid hierarchy (described in this document) that does not use all of the new features. All modern distributions except Fedora use this model at this time. In consequence, systemd is usually not capable of grouping at the user level.

Then Chain explained that even cgroups v2 has some constraints. For example, inner nodes cannot contain processes; the reason is to keep accounting simple "for the kernel". This includes also a case where a cgroup has other cgroups as children. In this case it is not possible to attach processes to the parent cgroup. Those inner nodes are called slices in systemd.

Configurations for cgroups can be prepared in advance. In the case the configuration is not available, there are two ways to leverage systemd for new applications. One of them uses scopes: the process is launched as usual, and then systemd is asked to put it into a cgroup. A scope thus contains a group of processes that were started separately from systemd. The other mode uses services: like typical daemons, in this case systemd launches the application and manages its lifetime.

Chain showed an example output of the systemd-cgls command, which shows the control-group hierarchy. This output (seen on the right or in the slides from the talk [PDF]) shows slices and services, the systemd user instance is also visible (as the user:@1000.slice) entry.

Edmundson explained that Plasma 5.19 spawns every application in its own cgroup. This is a tiny part of the code in KIO, he said, but it required a lot of effort across the KDE code base to unify the methods for launching applications. "This is something that became fragmented in the last 20 years", he noted, "so it was worth unifying anyway". The developers found dozens of edge cases that needed to be fixed. Their goal is to do the migration safely.

Introducing cgroups is a sizeable change; the first step is to start using cgroups with scopes with as few changes from the previous setup as possible. Application processes are started, then they are tagged as belonging to a cgroup. Once it is all working, developers will be able to start using more metadata. For now, the scheduler is using it already. Taskmanager patches are in review, and libksysguard can expose this information to the user. Edmundson showed the old ksysguard alongside a rewritten version; they show the same information, but organized differently. In the new version, the main list shows only the application name; the processes list is shown separately. Aggregation is more reliable than before, he noted.

Cooperation with GNOME

"Plasma doing things on its own isn't going far", Edmundson said as he explained how the collaboration with other projects was put in place. The Plasma team started working on the problem and talking to GNOME developers. It turned out that both teams wanted to do the same thing (albeit for different reasons — GNOME was concentrating on out-of-memory handling). They started working together, unifying the tagging of desktop files, which map application names to cgroup names. They came up with a common set of slices the applications will be running in. The KDE and GNOME teams met with some kernel developers to work on this problem; they came up with a common solution. "It is going to be universal", Edmundson said.

Upcoming features

The basic functionality is currently working and the Plasma team is planning its next steps. One of them consists of statically assigning weights to some services and programs to control the CPU time they use. There will be three slices, one of which will be a specific session slice for KWin and Plasma. This is especially important on Wayland, where "KWin is doing some very important jobs". Another slice will include all user-run applications; they will be competing for system resources within their slice. Finally, the background slice will include processes (like file indexing) that need to run at some point but which can run at a lower priority.

In the future, users will be able to apply limits to applications, For example, it will be possible to limit the file indexer to only 10% of the CPU, set out-of-memory parameters, and stop fork bombs from happening.

Chain has been working on changing resource allocation based on run-time information. He created a small library wrapping the systemd DBus API to expose resource control for currently running applications. The audience was encouraged to take a look. The library includes a demo application (YouTube video available), which talks to the window manager to get the currently focused application in order to change its weight. This feature is useful for improving battery life on mobile systems, Chain explained in a response to a question from the audience.

Another upcoming change is to move from scopes to systemd services. The process lifetime management will be done by systemd then, with extra configuration available compared to scopes. The use of services also avoids a bug in systemd older than 238 where applications could not be grouped into scopes. The implementation of this is already ready, hidden behind a flag, but the developers have run into issues with systemd and the experience is not as good now as using scopes. More work is needed also to get crash handling working, Chain added.

The remaining work is converting the rest of Plasma, including the background services. The goal is to have the Plasma session as a systemd unit. Another goal is to make the experience familiar for sysadmins. That was requested by a distributor, so that there is no new layer to learn and administrators could continue to use familiar tools. The desktop files are being converted "magically" to systemd, thanks to the work from Benjamin Berg (from the GNOME team). Also, all environment variables should "just work".

Conclusion

The KDE and GNOME teams have accomplished some important tasks to prepare the desktop to use cgroups. As the basic infrastructure has already been laid out, users may check out how those improvements influence the overall experience right now. More work is still needed to complete the work, and we should be witnessing improvements in this area in the months and years to come.

Comments (8 posted)

The accelerating adoption of Julia

The Julia programming language has seen a major increase in its use and popularity over the last few years. We last looked at it two years ago, around the time of the Julia 1.0 release. Here, we will look at some of the changes since that release, none of which are major, as well as some newer resources for learning the language, but the main focus of this article is a case study that is meant to help show why the language has been taking off. A follow-up article will introduce a new computational notebook for Julia, called Pluto, that is akin to Jupyter notebooks.

Julia is a programming language that was first released in 2012; its implementation is released under the MIT license. It is a general-purpose language, but with a particular suitability for scientific programming and numerical work. Julia is a dynamic language, with an interactive mode and easy-to-learn syntax that is simple for novice programmers; it also has deeper layers of sophistication for the expert. The language allows introspection and metaprogramming, with Lisp-like macros, an optional Lisp syntax, and access to syntax-tree and assembly-language views of functions. It features a rich type system with performant user-defined types, multiple dispatch of functions, and several flavors of concurrent programming built in.

Julia recently passed a kind of popularity milestone, breaking into the top 20 in the IEEE Spectrum list of programming languages. Beyond that, the language is being adopted in many new research projects, such as: the Climate Machine, the computational engine used by the Caltech Climate Modeling Alliance; a new space weather forecasting initiative, funded by the NSF; quantum machine learning; drug development; and a computational collaboration called Celeste to create a massive star map of the universe.

Professor Mykel Kochenderfer is the creator of an international standard aircraft collision avoidance system, ACAS X. In an email interview, he told me that the Julia version of his system runs as fast as a previous version he wrote in highly optimized C++. Since he wrote the Julia version intending it to merely document the algorithm, this was a surprise. He was able to replace the C++ version with the easier to read and maintain Julia code.

The recently concluded annual Julia conference, online this year, naturally, was a good indicator of the audience that Julia is attracting. The presentations (YouTube videos) that one would expect of various computer science topics were outweighed by talks about applications to scientific research in an impressive variety of fields. A recurring theme was the way that the language facilitated collaboration and code reuse, giving scientists an opportunity to take advantage of the packages and algorithms of others.

Case study: the power of combining libraries

Julia's organization around the concept of multiple dispatch (described in part two of our Julia introduction), combined with a certain care taken by package authors to write extensible code, creates an environment where it is unusually easy to combine the features of several packages. Multiple dispatch means that a function can be defined with a variety of available methods, each one operating on a different set of argument types; the particular method used is chosen at run time, based on the types of all of the arguments. Crucially, the user of a library can define new methods for functions in the library, without having to modify the existing library code.

Our case study involves an activity fundamental to most computational science: the numerical solution to a differential equation. The Julia package DifferentialEquations has become the standard for this purpose in the ecosystem. Packages can be added to Julia from the the read-eval-print loop (REPL) using the language's package manager. It will download the package from GitHub, along with any dependencies, and store the result in the user's .julia directory.

Once it is installed, we need to import the functions provided by DifferentialEquations, so that we can use them in calculations. In a program, we would use an import statement to pull in just what we need to use, and keep everything namespaced. But, for convenience in the REPL, we'll use the command:

    julia> using DifferentialEquations

That will import everything into the top level and allow us to use the package's functions as bare names. The first time this command is issued on a previously unseen package, it will lead to a spate of pre-compiling. For a complex and large package such as DifferentialEquations, this could take significant time. True story: I entered this command and went to take a shower. When I returned, it was still working. After a total of about 20 minutes, the pre-compilation was complete. The compiled code is stored on disk, however, so starting up the REPL and using DifferentialEquations in future sessions does not incur this delay.

We will want to use the packages Plots and Measurements in our demonstration as well, so we install them and repeat the using commands on them.

Our example will involve the numerical solution to the differential equation:

    f' = f - f²

where f' is the time derivative of f. This is sometimes called the logistic equation; it represents the initial exponential growth of a population, followed by its saturation, as space or food becomes scarce.

We begin by defining the differential equation in a form that can be used by the numerical solver:

    julia> r(f,p,t) = f - f^2

This uses Julia's concise notation for defining a function on one line. To use the differential equation solver, we need to create a function of three arguments, whose value is the derivative of the function, which appears as the first argument. The second, p, is for optional parameters that we are not using here, and the third is the independent variable, which we are calling time. The function, which will be passed to the solver, can be named anything.

Next, we need to define a time interval (tint) over which we want the solution, and an initial value (r0), to nail down a particular solution from the infinitely many possible solutions to the equation:

    julia> tint = (0.0, 8.0)
    julia> r0 = 0.05

Now we give this information to a constructor that creates a "problem". This is a convenience, because it is often the case that we will want to experiment with, for example, different numerical methods, while the definition of the problem itself doesn't change. The constructor, called ODEProblem() (ODE stands for ordinary differential equation), is provided by the DifferentialEquations package:

    julia> prob = ODEProblem(r, r0, tint)

Now to calculate a solution:

    julia> sol = solve(prob)

That's all there is to it. Julia will respond with some numbers summarizing the numerical solution that it found. The solve() function is also provided by DifferentialEquations; a detailed tutorial is worth looking at for another example of solving a differential equation using ODEProblem() and solve(). The solve() function accepts many optional arguments, including one that selects from a myriad of available approximation methods; but I am making this example as streamlined as possible, and the default, in this case, does an excellent job. I know this, because this differential equation has an analytic solution, so I was able to check Julia's work.

The Plots package is already imported, so we can have a look at the solution:

    julia> plot(sol.t, sol.u, key=false)

This command immediately pops up a plot window:

Note that sol is a data type with various bits of information packed into it about the solution; in order to plot it, we passed arrays of the independent (sol.t) and dependent (sol.u) variables.

Above I mentioned that we also wanted to import a package called Measurements. This library, among other things, extends floating-point numbers to include errors, or uncertainties in their values. Once you have imported it, you can write a number as, for example:

    1.0 ± 0.1

That attaches an error value to it, which makes nice use of Julia's embrace of Unicode. These numbers behave as normal floats, except that they carry along error ranges with them. Arithmetic with these types treats the error ranges according to linear error propagation theory.

Suppose there was some uncertainty attached to our knowledge of the initial condition in the above problem. We could then write the initial value as:

    julia> r0m = 0.05 ± 0.01

Now, logically, there would be some uncertainty in the solution, and to be consistent, in everything else. So everywhere where we had exact numbers, we replace them with uncertain numbers, even if we assume the errors to be zero:

    julia> rm(f,p,t) = (1 ± 0.0)*(f - f^2)
    julia> tintm = (0.0*1 ± 0, 8.0*1 ± 0)

Can we use the DifferentialEquations package to solve this equation? It may seem unreasonable to expect this to work. DifferentialEquations only claims to deal with floating-point numbers for initial values and time intervals, and it is a package for solving for functions that map numbers to numbers. Different people created the Measurements package, and DifferentialEquations knows nothing of this exotic new data type. Let's ignore all of this and forge ahead:

    julia> probm = ODEProblem(rm,r0m,tintm)
    julia> solm = solve(probm)

Julia not only proceeds without complaining, but it prints out the solution in the form of numbers with ± values appended. If DifferentialEquations can somehow handle this data type, can we push our luck with Plots?

    julia> plot(solm.t, solm.u, key=false)

Typing that in the REPL gets us this figure:

We see here the same solution plotted as before, but this time with the uncertainties rendered as error bars. I've verified that the errors were propagated correctly, and that they are plotted accurately.

We had no right to expect that any of this would work, yet by some magic, it all does. Chris Rackauckas, the MIT professor who is the chief author of the DifferentialEquations package, and who suggested that I look at combining it with Measurements data types, tells me that his package was written with no knowledge of these data types. It was a delightful surprise for him when he discovered that his code handles numbers with error intervals in the correct way. It works because these libraries are written in a generic fashion, with functions that can be extended to work on new data types. This is made possible by Julia's type system and its organization around multiple dispatch. This is Julia's solution to the expression problem, allowing one to extend and combine existing libraries without having to modify those libraries, or even having to look at their source code.

Another example is the plot() function. It is designed to plot arrays of floating-point numbers, yet is able to produce sensible renderings of other data types, such as the uncertain numbers used in the example. This is because the Measurements package comes with a simple recipe that tells the plotting routines what to do when they encounter this data type; and that, again, is only possible because of Julia's multiple function dispatch.

One can, for example, use quaternions instead of floating-point numbers. These are like complex numbers, but with four components instead of two, and there is a Julia package that defines the data type. DifferentialEquations will happily solve equations for quaternion-valued functions (although, again, it knows nothing about them). They can be combined with Measurements to produce quaternions with error intervals attached to the components, and DifferentialEquations will propagate all of the errors correctly. A plot of the solution using the Plots package will display four lines, one for each component, and each one will have its own error bars.

Language changes

There have been no major breaking changes since version 1.0. There are some minor tweaks to the syntax, which generally make things more convenient, that are detailed in the the release notes for v1.5, v1.4, and v1.3. Here I'll describe several more significant changes.

The latest release brings a substantial change to scoping rules when using the REPL. In Julia, blocks such as for loops create their own lexical scopes. Variables that appear in such blocks are local to the block, unless explicitly declared to be global. In Julia 1.5, when using the REPL, an assignment inside a block to an undeclared variable that already exists in global scope will use that global variable. For code in files, the same code will get you a warning, because it is ambiguous; this change does not break any code in files. This was thought to be more convenient for interactive use in the REPL, where it can be tedious, and surprising for new users, to have to track global variables. Nevertheless, this change generated some controversy, because now the same code in a file and in the REPL will behave differently; that returns to the behavior of pre-1.0 Julia versions.

This version also introduces a syntax option that reduces visual noise and typing when using keyword arguments. If one's local variables have the same name as a function's named parameters, which is often the case, then a function call winds up looking like function(var1=var1, var2=var2); this is the normal syntax in Python and previous versions of Julia. Now this can be streamlined to function(; var1, var2).

The most common perennial complaint about Julia is the long startup time when pre-compiling a package. The latest version introduces an experimental module-level setting for the compiler optimization level. Turning off optimizations for code that is not crucial for performance can significantly reduce compilation time and, thus, latency.

Task-based parallelism, introduced in v1.3, is a convenient way to fire off long-running processes. Briefly, a simple @spawn macro allows the programmer to execute a function in a separate thread. The calls can be nested, with the function using @spawn to run other functions, while the language runtime coordinates everything.

Learning resources

In the last few years, some new books and useful websites have appeared, which makes it easier to get started with the language.

A few of the notable books are: Hands-On Design Patterns and Best Practices with Julia; Think Julia; The Little Book of Julia Algorithms, which is unusual in that it is aimed at middle- and high-school students; and Julia Programming Projects.

The official, online documentation is quite comprehensive, and may be all that an experienced programmer will require. But it mixes deep discussions of advanced topics together with introductory sections in a way that would be likely to bewilder a relative beginner.

Some websites and online resources that provide a gentler approach are Julia By Example, a Wikibook introduction to Julia, a series of classes at the JuliaAcademy, a set of Julia exercises, a Coursera course on Julia for scientists, and an introduction to the language for data scientists. There has been an explosion of learning resources—this is just a tiny sample.

I hope that the small example above helps demonstrate, in miniature, what's special about Julia, and why it is making such a splash in the scientific community. Julia is not the first language to make a multiple dispatch system available to programmers; Common Lisp included this 40 years ago. But it was a breakthrough to combine this with Fortran-class numerical performance and with a syntax as easy to pick up and read as Python's.

Julia is certainly worth considering for a scientist or engineer who is beginning a new project. Although it still doesn't have the vast coverage of the Python libraries, it is particularly easy to call Python (and Fortran or C) functions from Julia code—and the Julia code will, generally, run fast. For everyone else, I can recommend Julia simply as an interesting, fun, and instructive language to play around in.

Comments (38 posted)

Combating abuse in Matrix - without backdoors (Matrix blog)

This Matrix blog entry describes a planned reputation-management system that, it is claimed, accomplishes some of the same goals as government backdoors without the need to compromise end-to-end encryption. "Just like the Web, Email or the Internet as a whole, there is literally no way to unilaterally censor or block content in Matrix. But what we can do is provide first-class infrastructure to let users (and room/community moderators and server admins) make up their own mind about who to trust, and what content to allow. This would also provide a means for authorities to publish reputation data about illegal content, providing a privacy-respecting mechanism that admins/mods/users can use to keep illegal content away from their servers/clients."

Comments (22 posted)

Security Quote of the Week

— Andy Greenberg at Wired

Comments (1 posted)

Kernel release status

The 5.10 merge window remains open; it can be expected to close with a 5.10-rc1 release on October 25.

Stable updates: 5.9.1, 5.8.16, 5.4.72, 4.19.152, 4.14.202, 4.9.240, and 4.4.240 were all released on October 17.

Comments (none posted)

Distribution quotes of the week

— Sam Hartman

— Theo de Raadt

Comments (none posted)

Firefox 82.0 and ESR 78.4.0

Firefox 82.0 has been released, with improvements "that make watching videos more delightful" and improved performance. Firefox ESR 78.4.0 is also available with various stability, functionality, and security fixes. See the release notes (82.0, 78.4.0) for details.

Comments (8 posted)

Git v2.29.0 released

Version 2.29.0 of the Git source-code management system is out. This release includes a long list of smallish improvements; click below for the details. Also present is the code enabling Git to switch to the SHA-256 hash algorithm; this feature is still deemed experimental, though, and interoperability with SHA-1 repositories is not yet available.

Full Story (comments: none)

Development quote of the week

— Jose E. Marchesi (Thanks to Paul Wise)

Comments (none posted)

• DistroWatch Weekly (October 19)

• Lunar Linux Weekly News (October 16)

• openSUSE Tumbleweed Review of the Week (October 16)

• Ubuntu Weekly Newsletter (October 17)

• Emacs News (October 19)

• GCC 11.0.0 Status Report (October 16)

• What's cooking in git.git (October 19)

• LLVM Weekly (October 19)

• LXC/LXD/LXCFS Weekly Status (October 19)

• OCaml Weekly News (October 20)

• Perl Weekly (October 19)

• Python Weekly Newsletter (October 15)

• Racket News (October 20)

• Weekly Rakudo News (October 19)

• Ruby Weekly News (October 15)

• This Week in Rust (October 14)

• Wikimedia Tech News (October 19)

• Fedora Council minutes (October 15)

• Fedora FESCO meeting minutes (October 21)

linux.conf.au 2021 call for sessions and miniconfs

The 2021 edition of linux.conf.au will be held online on January 23-25, 2021; the call for proposals has gone out with a relatively tight deadline of November 6. "Our theme is 'So what's next?'. We all know we're living through unprecedented change and uncertain times. How can open source play a role in creating, helping and adapting to this ongoing change? What new developments in software and coding can we look forward to in 2021 and beyond?" Since there is no travel involved, this is a rare opportunity for those who have not normally been able to participate in LCA.

Full Story (comments: none)

CFP Deadlines: October 22, 2020 to December 21, 2020

The following listing of CFP deadlines is taken from the LWN.net CFP Calendar.

Deadline	Event Dates	Event	Location
October 25	November 5 November 7	Ohio LinuxFest	Online
October 30	November 21 November 22	MiniDebConf - Gaming Edition	Online
October 31	February 6 February 7	FOSDEM 2021	Online
November 1	November 14 November 15	Battlemesh v13	online
November 5	November 10	S&T 2020 (SQLite & TCL)	Online
November 6	January 23 January 25	linux.conf.au 2021	Online
November 6	November 16 November 22	Guix Days	Online
November 6	February 18 February 20	DevConf.CZ	Online
November 10	December 3	Live Embedded Event	Online
November 11	March 20 March 21	LibrePlanet 2021	Online
December 18	January 23	LCA Systems Administration Miniconf	Online, UTC+11
December 18	January 23	LCA Kernel Miniconf	Online, UTC+11

If the CFP deadline for your event does not appear here, please tell us about it.

EuroPython 2021 (and 2022)

The EuroPython Society has announced that EuroPython 2021 will be an online event. There are plans for a hybrid in-person and online event for 2022.

Comments (none posted)

Events: October 22, 2020 to December 21, 2020

The following event listing is taken from the LWN.net Calendar.

Date(s)	Event	Location
October 19 October 23	EPICS collaboration meeting 2020	Virtual
October 19 October 23	Open Infrastructure Summit	Virtual
October 20 October 23	[Canceled] PostgreSQL Conference Europe	Berlin, Germany
October 24 October 25	[Cancelled] T-Dose 2020	Geldrop (Eindhoven), Netherlands
October 26 October 29	Open Source Summit Europe	online
October 28 October 29	eBPF Summit	online
October 28 October 29	[Canceled] DevOpsDays Berlin 2020	Berlin, Germany
October 28 October 30	[Virtual] KVM Forum	Virtual
October 29 October 30	[Virtual] Linux Security Summit Europe	Virtual
November 5 November 7	Ohio LinuxFest	Online
November 7 November 8	RustFest Global	Online
November 7 November 8	OpenFest 2020	online
November 10	S&T 2020 (SQLite & TCL)	Online
November 12 November 14	Linux App Summit	Online
November 14 November 15	Battlemesh v13	online
November 16 November 22	Guix Days	Online
November 21 November 22	MiniDebConf - Gaming Edition	Online
November 25 November 27	Linux Audio Conference	Online
November 28 November 29	EmacsConf 2020	Online
November 28 November 29	MiniDebConf Online Brasil 2020	Online
December 1 December 3	Open Source Firmware Conference	online
December 3	Live Embedded Event	Online

If your event does not appear here, please tell us about it.

EuroPython 2020 videos available

Edited videos from EuroPython Online 2020 are available on YouTube.

Comments (none posted)

Alert summary October 15, 2020 to October 21, 2020

Dist.	ID	Release	Package	Date
Arch Linux	ASA-202010-1		chromium	2020-10-14
Arch Linux	ASA-202010-7		kdeconnect	2020-10-21
Arch Linux	ASA-202010-2		kernel	2020-10-21
Arch Linux	ASA-202010-8		kpmcore	2020-10-21
Arch Linux	ASA-202010-11		lib32-freetype2	2020-10-21
Arch Linux	ASA-202010-9		linux-hardened	2020-10-21
Arch Linux	ASA-202010-4		linux-lts	2020-10-21
Arch Linux	ASA-202010-3		linux-zen	2020-10-21
Arch Linux	ASA-202010-5		lua	2020-10-21
Arch Linux	ASA-202010-6		powerdns-recursor	2020-10-21
Debian	DSA-4772-1	stable	httpcomponents-client	2020-10-14
Debian	DSA-4774-1	stable	kernel	2020-10-19
Debian	DLA-2409-1	LTS	mariadb-10.1	2020-10-21
Debian	DSA-4776-1	stable	mariadb-10.3	2020-10-20
Debian	DSA-4775-1	stable	python-flask-cors	2020-10-19
Debian	DLA-2408-1	LTS	thunderbird	2020-10-17
Debian	DSA-4773-1	stable	yaws	2020-10-16
Fedora	FEDORA-2020-90e2b01f4a	F31	claws-mail	2020-10-15
Fedora	FEDORA-2020-67d9661fe2	F32	claws-mail	2020-10-15
Fedora	FEDORA-2020-5d9f0ce2b3	F32	createrepo_c	2020-10-18
Fedora	FEDORA-2020-47a7fbf50d	F32	dnf	2020-10-15
Fedora	FEDORA-2020-5d9f0ce2b3	F32	dnf	2020-10-18
Fedora	FEDORA-2020-5d9f0ce2b3	F32	dnf-plugins-core	2020-10-18
Fedora	FEDORA-2020-5d9f0ce2b3	F32	dnf-plugins-extras	2020-10-18
Fedora	FEDORA-2020-c33083813d	F31	kata-agent	2020-10-18
Fedora	FEDORA-2020-ad980d282f	F31	kernel	2020-10-16
Fedora	FEDORA-2020-e288acda9a	F32	kernel	2020-10-15
Fedora	FEDORA-2020-9b441d3153	F32	kleopatra	2020-10-19
Fedora	FEDORA-2020-47a7fbf50d	F32	libdnf	2020-10-15
Fedora	FEDORA-2020-5d9f0ce2b3	F32	libdnf	2020-10-18
Fedora	FEDORA-2020-7906a64449	F31	librepo	2020-10-18
Fedora	FEDORA-2020-5d9f0ce2b3	F32	librepo	2020-10-18
Fedora	FEDORA-2020-c9863904de	F32	nextcloud	2020-10-19
Fedora	FEDORA-2020-eadda524a8	F31	phpMyAdmin	2020-10-19
Fedora	FEDORA-2020-4e78c86902	F32	phpMyAdmin	2020-10-19
Fedora	FEDORA-2020-887d3fa26f	F32	python27	2020-10-16
Fedora	FEDORA-2020-d30881c970	F32	python34	2020-10-16
Fedora	FEDORA-2020-07c5770aa1	F31	thunderbird	2020-10-20
Fedora	FEDORA-2020-1b390bec14	F31	wireshark	2020-10-17
Fedora	FEDORA-2020-1bf4b97c16	F32	wireshark	2020-10-17
Gentoo	202010-06		ark	2020-10-20
Gentoo	202010-01		chromium	2020-10-17
Gentoo	202010-02		firefox	2020-10-17
Gentoo	202010-03		libjpeg-turbo	2020-10-20
Gentoo	202010-05		libraw	2020-10-20
Gentoo	202010-04		libxml2	2020-10-20
Mageia	MGASA-2020-0385	7	brotli	2020-10-16
Mageia	MGASA-2020-0391	7	claw-mail	2020-10-21
Mageia	MGASA-2020-0386	7	flash-player-plugin	2020-10-16
Mageia	MGASA-2020-0389	7	freetype2	2020-10-20
Mageia	MGASA-2020-0390	7	geary	2020-10-21
Mageia	MGASA-2020-0392	7	kernel	2020-10-21
Mageia	MGASA-2020-0387	7	php	2020-10-16
Mageia	MGASA-2020-0383	7	phpmyadmin	2020-10-16
Mageia	MGASA-2020-0388	7	tigervnc	2020-10-20
Mageia	MGASA-2020-0384	7	wireshark	2020-10-16
openSUSE	openSUSE-SU-2020:1701-1	15.1	bind	2020-10-20
openSUSE	openSUSE-SU-2020:1699-1	15.2	bind	2020-10-20
openSUSE	openSUSE-SU-2020:1688-1	15.1	crmsh	2020-10-18
openSUSE	openSUSE-SU-2020:1678-1	15.2	crmsh	2020-10-17
openSUSE	openSUSE-SU-2020:1692-1	15.1	gcc10, nvptx-tools	2020-10-18
openSUSE	openSUSE-SU-2020:1693-1	15.2	gcc10, nvptx-tools	2020-10-18
openSUSE	openSUSE-SU-2020:1674-1		icingaweb2	2020-10-16
openSUSE	openSUSE-SU-2020:1674-1	15.1 15.2	icingaweb2	2020-10-16
openSUSE	openSUSE-SU-2020:1682-1	15.1	kernel	2020-10-17
openSUSE	openSUSE-SU-2020:1698-1	15.2	kernel	2020-10-20
openSUSE	openSUSE-SU-2020:1676-1	15.1	libproxy	2020-10-17
openSUSE	openSUSE-SU-2020:1680-1	15.2	libproxy	2020-10-17
openSUSE	openSUSE-SU-2020:1687-1	15.1 15.2	pdns-recursor	2020-10-17
openSUSE	openSUSE-SU-2020:1687-1	15.1 15.2	pdns-recursor	2020-10-17
openSUSE	openSUSE-SU-2020:1703-1	15.2	php7	2020-10-20
openSUSE	openSUSE-SU-2020:1675-1	15.1 15.2	phpMyAdmin	2020-10-16
openSUSE	openSUSE-SU-2020:1675-1	15.1 15.2	phpMyAdmin	2020-10-16
openSUSE	openSUSE-SU-2020:1677-1	15.1	rubygem-activesupport-5_1	2020-10-17
openSUSE	openSUSE-SU-2020:1679-1	15.2	rubygem-activesupport-5_1	2020-10-17
openSUSE	openSUSE-SU-2020:1702-1	15.2	transfig	2020-10-20
Oracle	ELSA-2020-4272	OL8	nodejs:12	2020-10-21
Red Hat	RHSA-2020:4276-01	EL7	kernel	2020-10-20
Red Hat	RHSA-2020:4278-01	EL7.4	kernel	2020-10-19
Red Hat	RHSA-2020:4281-01	EL7.6	kernel	2020-10-19
Red Hat	RHSA-2020:4277-01	EL7.7	kernel	2020-10-19
Red Hat	RHSA-2020:4286-01	EL8	kernel	2020-10-20
Red Hat	RHSA-2020:4288-01	EL8.0	kernel	2020-10-20
Red Hat	RHSA-2020:4287-01	EL8.1	kernel	2020-10-20
Red Hat	RHSA-2020:4279-01	EL7	kernel-alt	2020-10-19
Red Hat	RHSA-2020:4280-01	EL7	kernel-rt	2020-10-19
Red Hat	RHSA-2020:4289-01	EL8	kernel-rt	2020-10-20
Red Hat	RHSA-2020:4272-01	EL8	nodejs:12	2020-10-19
Red Hat	RHSA-2020:4273-01	SCL	python27	2020-10-20
Red Hat	RHSA-2020:4274-01	SCL	rh-maven35-apache-commons-collections4	2020-10-19
Red Hat	RHSA-2020:4295-01	SCL	rh-postgresql96-postgresql	2020-10-21
Red Hat	RHSA-2020:4285-01	SCL	rh-python36	2020-10-19
Red Hat	RHSA-2020:4299-01	SCL	rh-python38	2020-10-20
Red Hat	RHSA-2020:4290-01	EL8.1.1	virt:8.1 and virt-devel:8.1	2020-10-20
Red Hat	RHSA-2020:4291-01	EL8.2.1	virt:8.2 and virt-devel:8.2	2020-10-20
Slackware	SSA:2020-294-01		freetype	2020-10-20
SUSE	SUSE-SU-2020:2931-1	SLE12	bcm43xx-firmware	2020-10-15
SUSE	SUSE-SU-2020:2942-1	SLE12	blktrace	2020-10-16
SUSE	SUSE-SU-2020:2930-1	SLE12	crmsh	2020-10-15
SUSE	SUSE-SU-2020:2928-1	SLE15	crmsh	2020-10-14
SUSE	SUSE-SU-2020:2939-1	SLE15	crmsh	2020-10-15
SUSE	SUSE-SU-2020:2947-1	SLE15	gcc10, nvptx-tools	2020-10-16
SUSE	SUSE-SU-2020:2967-1	SLE12	hunspell	2020-10-20
SUSE	SUSE-SU-2020:2966-1	SLE15	hunspell	2020-10-20
SUSE	SUSE-SU-2020:2972-1	SLE15	kernel	2020-10-20
SUSE	SUSE-SU-2020:2972-1	SLE15	kernel	2020-10-20
SUSE	SUSE-SU-2020:2923-1	SLE12	libqt5-qtimageformats	2020-10-14
SUSE	SUSE-SU-2020:2924-1	SLE12	libqt5-qtsvg	2020-10-14
SUSE	SUSE-SU-2020:2969-1	SLE15	libvirt	2020-10-20
SUSE	SUSE-SU-2020:2970-1	SLE15	libvirt	2020-10-20
SUSE	SUSE-SU-2020:14516-1	SLE11	php53	2020-10-14
SUSE	SUSE-SU-2020:2920-1	SLE12	php7	2020-10-14
SUSE	SUSE-SU-2020:2941-1	SLE15	php7	2020-10-16
SUSE	SUSE-SU-2020:2943-1	SLE12	php72	2020-10-16
SUSE	SUSE-SU-2020:2929-1	OS7	rubygem-activesupport-4_2	2020-10-15
SUSE	SUSE-SU-2020:2968-1	SLE12	taglib	2020-10-20
SUSE	SUSE-SU-2020:2951-1	SLE15	transfig	2020-10-16
Ubuntu	USN-4590-1	16.04	collabtive	2020-10-19
Ubuntu	USN-4589-1	16.04	containerd	2020-10-15
Ubuntu	USN-4589-2	16.04 18.04 20.04	docker.io	2020-10-15
Ubuntu	USN-4546-2	16.04 18.04 20.04	firefox	2020-10-16
Ubuntu	USN-4593-1	16.04 18.04 20.04	freetype	2020-10-20
Ubuntu	USN-4595-1	18.04	grunt	2020-10-20
Ubuntu	USN-4584-1	16.04	htmlunit	2020-10-15
Ubuntu	USN-4591-1	16.04 18.04 20.04	linux, linux-hwe, linux-hwe-5.4, linux-oem, linux-raspi, linux-raspi-5.4, linux-snapdragon	2020-10-19
Ubuntu	USN-4592-1	18.04	linux-oem-osp1, linux-raspi2-5.3	2020-10-19
Ubuntu	USN-4585-1	16.04	newsbeuter	2020-10-15
Ubuntu	USN-4583-1	12.04 14.04 16.04 18.04 20.04	php5, php7.0, php7.2, php7.4	2020-10-14
Ubuntu	USN-4581-1	12.04 14.04 16.04 18.04	python2.7, python3.4, python3.5, python3.6	2020-10-14
Ubuntu	USN-4594-1	18.04	quassel	2020-10-20
Ubuntu	USN-4596-1	20.04	tomcat9	2020-10-21
Ubuntu	USN-4582-1	16.04 18.04	vim	2020-10-14

Full Story (comments: none)