Welcome to the LWN.net Weekly Edition for January 28, 2021

This edition contains the following feature content:

• The endless browser wars: Google's decision to close off some APIs is another front in a long browser battle.
• Elastic promises "open"—delivers proprietary: open source is still not a business model.
• Avoiding blocking file-name lookups: a small change that can give big performance benefits.
• Preserving the mobility of ZONE_MOVABLE: a memory-allocation policy change to help prevent fragmentation.
• A year of Python in Fedora: the Fedora Python packagers show what they worked on last year.

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)

The endless browser wars

The term "browser wars" typically refers to Microsoft's attempts to dominate the World Wide Web with its Internet Explorer browser in the 1990s. That effort was thwarted by antitrust efforts and the rise of the free browser now known as Firefox; ever since, the web has been defined by free software. Or so some may have thought. In the 2020s, the browser wars continue with the growing dominance of Chrome and, it would seem, the imminent removal of Chromium from many Linux distributions.

Chrome, of course, is Google's proprietary browser, bundled with Android and widely installed on other systems as well. The Chrome browser, though, is built on top of Chromium, which is an open-source project; in theory, anybody can build Chromium and get a browser of nearly equal capability, minus perhaps some proprietary DRM modules. In practice, Chromium users are a tiny fraction of the browser-using population, while Chrome becomes increasingly dominant. Current estimates suggest that 60-70% of web users are running on Chrome.

Chromium users do exist, though, and many Linux distributions package a version of the Chromium browser; it's a way to deal with the increasing number of "only works on Chrome" web sites without having to run proprietary code.

Or so it seems. Much of what appears to be Chrome (or Chromium) functionality is, in truth, provided by servers in Google's data centers. These include bookmark synchronization, the safe-browsing feature, search suggestions, spell-checking, and more. These features are not part of Chromium, but Google has long provided API keys for distributors of Chromium builds to use, ensuring that Chromium users had equal access to them.

That era is coming to an end, though. On January 15, the Chromium blog carried this brief notice that, as of March 15, non-Chrome builds of Chromium would lose access to these APIs. The loss of the bookmark-synchronization API, in particular, has drawn a fair amount of attention, but there are quite a few others that, it seems, will be restricted as well. After that date, users wanting to use those features will have to run Chrome to do so.

In other words, as of March 15, Chromium-based browsers will become rather less capable than they were the day before; this will reduce the value of Chromium to many of its users. Some of them will certainly throw in the towel and just install Chrome instead. Anticipating this, distributors are already wondering whether packaging Chromium (evidently not the easiest of tasks) is still worth the effort. Longtime Fedora developer Tom Callaway, for example, posted a Twitter thread in which he said: "I am seriously reconsidering whether there is any value in a crippled version of Chromium remaining in Fedora/EPEL".

This concern goes far beyond Fedora. The openSUSE community is currently discussing whether shipping Chromium still makes sense. The Arch Linux Chromium maintainer has stated his intent to drop the package if Chromium cannot be made to work with services like synchronization. Eric Hameleers, who provides Chromium packages for Slackware, doesn't want to continue if this change causes users to switch to something else. And so on.

There is, of course, an alternative to dropping Chromium that Callaway hinted at: "The official Chrome API keys which will permit this usage have been known since 2013 (they're embedded in every Chrome binary). It would be terrible if everyone used them instead." Taking that approach has been discussed on some distribution lists, but it seems unlikely that anybody will try it. It is an uncertain path, in that Google could invalidate the keys — though that would involve force-upgrading a lot of Chrome users. But it's even more uncertain in a legal sense; there are likely to be few volunteers to find out how Google would respond to such a move among the established distributors.

The unhappiness emanating from Chromium users who are about to lose features is understandable. But this move on Google's part is just highlighting a situation that has existed for years already: you might use Chromium as a way of avoiding proprietary software, but if you use Chromium with features like synchronization, that objective has not been met. Chromium has taken a path similar to Android's; there is a core built with free software, but getting its full functionality requires accepting layers of proprietary code on top of it. The fact that said code is running on a remote server somewhere does not really change that situation.

Many of us run free software — and avoid proprietary software — because we want to remain in control of our systems. Free software can be counted on to not disappear at inopportune times; proprietary software works at the whim of its owner and has no such guarantee. The stripping of functionality from Chromium builds is just another example of an owner indulging a whim and taking away features that they no longer wish to make available.

Meanwhile, smug Firefox users are able to use Firefox Sync with no impending interruption in service. It is worth noting that this service, too, could be withdrawn at any time, but Firefox at least allows the use of alternative servers, so concerned users need not be dependent on the continued existence and good will of Mozilla. The server-side code is available for anybody wanting to take that approach.

The larger problem, though, is that it's not at all clear that Firefox will remain a viable alternative to Chrome. Its market share has been falling for years, and not everybody is pleased with the directions that the Mozilla Foundation has taken. The creators of web sites have responded by not caring about Firefox; having to retry broken web sites in Chrome is a ritual that many Firefox users have had to get used to. It's not surprising that users give up and just run Chrome from the outset.

This is not a great trajectory. A lot of effort went into wresting the web from a proprietary browser; we should really know better than to allow ourselves to get into that situation again. Ironically, Google might have helped in this regard by stripping some non-free components from Chromium; users will now be more aware of their exposure and might just be more motivated to support a free alternative. That all depends on fully free browsers remaining viable, though, and that is unlikely to happen if we all just give up and run Chrome.

Comments (67 posted)

Elastic promises "open"—delivers proprietary

Open-source software is famously able to be used by anyone for any purpose; those are some of the keystones of the open source definition. But some companies that run open-source projects are increasingly unhappy that others are reaping some of the profits from those projects. That has led to various efforts of "license reform" meant to try to capture those profits. So far, those efforts have just led to non-open-source licenses, thus projects that are no longer open source. We are seeing that play out yet again with Elastic's mid-January announcement that it was changing the license on some of its projects.

Elastic is switching the license of the Elasticsearch search-engine software and its data-visualization counterpart, Kibana, away from the Apache Software License version 2 (ASL) to the Server Side Public License (SSPL) starting with version 7.11. As with previous versions, those projects will be dual-licensed with the Elastic License, so that users who do not want to (or are unable to) comply with the SSPL can purchase a license from Elastic.

We have seen this movie before, of course, but this time around the disingenuous way that Elastic is presenting its move is raising hackles within the FOSS community. It is clear that the company is quite unhappy with Amazon Web Services (AWS) for turning Elasticsearch and Kibana into for-profit products that compete with Elastic's own offerings. It is less clear that the license switch really addresses the problems that Elastic is complaining about, however. Beyond that, AWS is using the components under the license that Elastic freely chose when the ASL suited its objectives. Now that the ASL apparently does not suit Elastic, it is rather ridiculous for the company to proclaim that switching to a proprietary license is "doubling down on open"—it manifestly is not.

There is obviously nothing wrong, in a legal sense, with Elastic changing the license of those products/projects. But in the eyes of many, the SSPL is simply another form of proprietary license. The SSPL was not approved by the Open Source Initiative (OSI) as an open-source license; it was withdrawn from consideration when the response made it clear that it would not be accepted. But all of the contributors to the projects have signed a contributor license agreement (CLA) that allows Elastic to relicense the code as it sees fit; it exercised that right with the announcement.

The prior releases that were made under the ASL are still freely available, of course; interested developers or organizations can fork from that point and continue maintaining the code. In what should not come as any real surprise, AWS has such an interest; it stepped right up to fork the projects. So it is possible that Elastic will not only be competing with the AWS product offerings, but also with a fork of its projects—which might just become more popular than its own versions. Elastic should have seen this coming, so it is not at all clear what it thinks it is gaining, at least assuming that the company intends to do what it said in the announcement:

The SSPL was created by MongoDB to try to stretch the idea of copyleft to cover additional software, beyond just the code released under the license. It is a modified version of the GPLv3 that, like the Affero GPL (AGPL), modifies the section on code being used in a network service. The AGPL requires releasing any modifications to the source code from network services, but the SSPL extends that requirement to a whole raft of barely related or unrelated code ("including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software"). Furthermore, the source code for those pieces must be released under the SSPL, not simply under a FOSS license.

That clause of the license is pretty clearly written as a "poison pill" to ensure that large service providers are required to use the other half of the dual license, thus pay the licensor (MongoDB or, in this case, Elastic) for its proprietary license. The SSPL has not been tested in court, but that clause could easily be interpreted to mean that all of the code on the server must be released under the SSPL, which is well-nigh impossible for many providers. Much of that code is already available under a FOSS license (e.g. Linux), but cannot simply be released under another license.

While the GPL itself expands its reach beyond just the code it covers (to the build scripts and such, as pointed out by Matthew Garrett shortly after the release of the SSPL), that "scope creep" is far smaller and, likely, more defensible than forcing the release of completely unrelated pieces, such as, say, backup software. The SSPL clearly makes the use of this supposed open-source software fraught with legal peril, no matter whether you are some giant cloud provider or not; in effect, if you want to make money using Elasticsearch or Kibana, you will need to be able to release all of the code you are using to do so under the SSPL—or get a proprietary license from Elastic.

This shift from open-source licenses to licenses that are less so has been ongoing for some time. Projects that can be used in the software-as-a-service (SaaS) model often begin as fully open source; that typically leads to more rapid adoption, which looks great to investors. Down the road, though, those same investors may be the ones getting cold feet about users exercising the freedoms they were given, so those freedoms are curtailed. In other industries, that strategy is called "bait and switch".

The success of the strategy depends in large part on the licensor being able to turn in a proprietary direction. It needs to be able to offer new features as "secret sauce" in order to out-compete both the older version of the code and any fork(s). That kind of precludes an open-source approach, or at least makes such an approach quite difficult. It will be interesting to see if Elastic keeps its promise this time, though one guesses that few are truly banking on it.

Back in mid-2019, VM (Vicky) Brasseur nicely summed up the problems with this strategy:

The reaction from the FOSS community to Elastic's announcement was swift and rather heated from some quarters. Part of the ire is due to Elastic's use of phrases like "free and open" in a deceptive way. As Drew DeVault put it:

He goes on to remind developers that signing a CLA sets up this kind of loophole; companies cannot relicense code if they are not granted those rights. He also suggested that Elastic, and other companies that require CLAs, have done so deliberately with the intention of making this kind of switch down the road. That's hard to judge, but companies don't ask for a CLA that they are sure they will never need—it is obviously done as type of insurance.

It remains to be seen if AWS is a better steward, however. So far, there is just the January 21 fork announcement, which does have some hopeful language:

There is no mention of a CLA requirement (or lack thereof), but unless all of the previous contributors (including Elastic) sign a new agreement, AWS would be unable to relicense the code anyway. It seems likely, then, that the forks will operate in more of a community-open-source fashion, rather than as a corporate-open-source project.

There have been several speculative bubbles in the FOSS world along the way. There was a time when having "Linux" in your company name was enough to attract investments that were, at best, overly optimistic in many cases. More recently, "open source" as a business model has taken over as the attention-getting idea in the startup world, but as Brasseur pointed out back in 2018, "open source is not a business model". Open source is a development method that can be used by a company to make money, but it is not magic fairy dust that can turn millions of users into paying customers—no matter how many Sand Hill Road companies believe otherwise.

A sad part of the story is that many of these companies are quite successful, even while being "hampered" by sharing their secret sauce with others. They just are not successful enough, or quickly enough, to satisfy today's venture capitalists and other investors. In the meantime, though, the FOSS community gets taken on a ride with an abrupt end, which makes for a rather unpleasant journey.

Comments (99 posted)

Avoiding blocking file-name lookups

As a general rule, when one attempts to open a file with a system call like openat2(), the expectation is that the call will not return until the job is done. But there are times where the desire to open the file is conditional on being able to open it immediately, without blocking. Linux has never supported that mode well, but that may be about to change with this patch set from Jens Axboe.

Opening a file can be a complex operation. Simply resolving the name of the file can require traversing a series of directories that may be located on different filesystems; each step may also require performing I/O and taking locks to serialize changes that might otherwise create unwelcome surprises. Once the file has been found, there may be more I/O required to perform the open itself. Each of these steps has the potential to block the opening task for an unknown period of time.

Axboe's patch set creates a new internal flag called LOOKUP_CACHED, which is then made available to callers of openat2() as RESOLVE_CACHED. This flag requests the kernel to only carry the open to completion if that can be done using only data that is cached in memory — without performing I/O, in other words. If it becomes clear during the attempt that I/O would be required, the openat2() call will fail with an EAGAIN error. The caller can then retry the operation without RESOLVE_CACHED — in a setting where blocking is tolerable — to successfully open the file.

One might well wonder what this new option is for; it is not often that a program needs to open a file only if it can be done quickly. The motivating use case here is in the io_uring subsystem, which has grown considerably in the two years since it first appeared. The core purpose for io_uring is performing asynchronous I/O, but it increasingly has the ability to run other system calls — including openat2() — intermixed with I/O operations.

Many of those other system calls were never designed with asynchronous use in mind, so they will happily block if need be; that is something that io_uring cannot allow, since it would block the handling of other operations as well. So io_uring creates a separate kernel thread to run system calls that might block at inopportune times. That effectively makes those calls asynchronous, but at a cost: moving ring operations into a separate thread can slow execution considerably. For an operation that can be carried out using only cached data, the overhead of shifting to another thread becomes a dominant performance factor.

The solution is to use this new LOOKUP_CACHED flag. Whenever an open operation is called for in io_uring, an attempt will be made to execute it directly with LOOKUP_CACHED. If that works, all is well and the operation completes successfully; otherwise, it will be pushed off to a thread and retried without LOOKUP_CACHED as before. According to Axboe, an open-heavy benchmark will run nearly three times faster if all of the necessary data is already cached.

Another question that might come to mind is: why was the existing O_NONBLOCK flag not used for this purpose? There may be a number of reasons, but one that jumps out is that O_NONBLOCK applies to the resulting file descriptor for its entire life; all operations performed on that descriptor will (potentially, at least) be non-blocking. The RESOLVE_CACHED flag, instead, applies only to the opening of the file.

Making open() calls be truly non-blocking has been a challenge for kernel developers for longer than Linux has existed. Given that, it can be surprising to see how small this patch set is; there was little that needed to be done. This work has benefited greatly from the RCU walk mechanism that was added ten years ago. The purpose then was to make file-name lookup operations faster by avoiding taking locks whenever possible; that required creating a lookup path that would bail out anytime an operation might block. Normally, a lookup operation will be retried with the slow path if a RCU-walk lookup fails; the LOOKUP_CACHED patch just has to restrict lookups to the RCU-walk path to get the needed result.

This patch set is in its fourth revision. Its fate can perhaps be foretold from this comment by Linus Torvalds:

In the absence of surprising problems, it seems likely that little will block this work from landing in the mainline as soon as the 5.12 merge window. Whether application developers will find a use for RESOLVE_CACHED remains to be seen, but io_uring users should benefit from this feature from the outset.

Comments (13 posted)

Preserving the mobility of ZONE_MOVABLE

Memory fragmentation has long been a problem for Linux systems, to the point that, for years, finding even two physically contiguous pages was an uncertain affair. That said, the situation has improved considerably in the last decade or so thanks to a number of changes implemented by the memory-management developers. One of those changes is the creation of "movable" memory zones where pages can be relocated if need be. All that work is for nothing, though, if somebody comes along and pins down a page in one of these movable zones. This patch set from Pavel Tatashin seeks to prevent that from happening, but may risk creating problems elsewhere.

The Linux kernel allocates and frees pages of memory at a high rate; at any given time, there is no real way to predict which pages will be free, and which will be in use. Those in-use pages have an annoying tendency to be spread out across physical memory, making it hard to find a range of free, physically contiguous pages. The increasing use of huge pages, though, has increased the demand for contiguous regions — regions that will not be available if the kernel does not make an active effort to create them.

Contemporary systems can also face a related problem: hotpluggable memory. While there are machines with memory that can be physically yanked out of the box, hotplugging is more commonly used in the context of virtualization. Virtual machines experiencing memory thrashing can have more memory "plugged" into them by the hypervisor, while those that are not fully using the memory they have can be made to give some back to the system. Unplugging memory can be seen as a special case of the "large, physically contiguous region" problem — the whole range of memory must be made to be free so it can be unplugged without data loss — with the added constraint that the region must be located at a specific address. It is fair to say that this rarely happens by chance.

In both cases, the kernel can respond by migrating in-use pages that are in the way of creating the needed region — if the pages can, in fact, be migrated. In practice, pages allocated for user space can be moved at will; they are always accessed through the page tables, so moving them is just a matter of changing the appropriate page-table entries to point to the new location, and user space will never be the wiser. Pages allocated for use by the kernel, instead, tend not to be movable. Technically they, too, are accessed via page tables, but those page-table entries generally cannot be changed, so the pages must remain where they are.

[For those who are curious about why the page-table entries cannot be changed, there are (at least) a couple of reasons. One is that those pages are usually accessed via the kernel's direct mapping, which is a mirror of physical memory and cannot be remapped in any practical way. The other is that moving a page requires invalidating the page-table entry while the move is in progress, and the kernel isn't prepared for the page faults that would result if the page is accessed during that time.]

It only takes one immobile page to ruin a block of memory; it takes relatively few of them to make large contiguous regions hard to create. So if these non-movable pages are placed randomly in memory, fragmentation is certain to happen.

The kernel already divides memory into a number of zones with differing characteristics, including their addressability for DMA operations and which NUMA node they are on; the full list of zone types is found in <linux/mmzone.h>. The zone known as ZONE_MOVABLE, in particular, is meant to be used solely for allocations of movable pages. By segregating movable and non-movable allocations, the kernel tries to avoid the problem of single, badly placed, non-movable pages. Within ZONE_MOVABLE, it should be possible to move pages around (or simply reclaim them) to create larger regions as necessary.

This all works fairly well until some rude process comes along and pins down a page in ZONE_MOVABLE. This can happen, for example, when I/O is performed directly to or from user-space memory; moving a page while a device is performing I/O to it tends to have unfortunate side effects. Often, this pinning is of short duration and tends not to be a big problem. At times, though, this pinning can last for long periods of time — weeks, for example. Memory buffers used for RDMA are often implicated in this sort of antisocial behavior, but there are other examples as well. A virtually contiguous user-space buffer may, of course, be widely scattered across physical memory, so pinning one of these buffers for long periods can create equally widely scattered problems.

The problems with long-term pinning have been understood for a while. The kernel community's grasp of the solutions tends to be a bit more fuzzy, with the result that have been many discussions over the years aimed at improving the situation. One outcome from this work has been the addition of some infrastructure to indicate when pages are being pinned for a long time. Not much has been done with regard to what the kernel should do when confronted with a long-term pin, but knowing about it is a starting point.

Tatashin's patch set aims to use that information for a specific goal: preventing the pinning of pages in ZONE_MOVABLE. To that end, it builds on work that was already done to deal with a related problem: non-movable pages in areas designed for the contiguous memory allocator (CMA). Specifically, in current kernels, a call to pin pages in memory assigned to CMA will cause an attempt to migrate those pages out of the CMA area before the pin takes effect.

Tatashin starts by fixing a couple of problems with that code, one of which being that it will happily migrate pages into ZONE_MOVABLE before pinning them. The migration code is now instructed to avoid that zone. The other is that, in current kernels, a failed attempt to move a page is met with a sort of kernel-space shrug of the shoulders; the page will be pinned anyway, even though it is stuck in the CMA area. The patch set changes this behavior; if a page cannot be moved to a more appropriate location, the attempt to pin it will fail.

Then, this mechanism is extended to operate on pages in ZONE_MOVABLE as well. If the kernel tries to pin pages in ZONE_MOVABLE, an attempt will be made to migrate them first; if that attempt fails, the pinning will not be allowed.

These changes should help to keep ZONE_MOVABLE true to its name. That should allow operations like the creation of huge pages to succeed more often and remove impediments to the hot-unplugging of memory. On the other hand, these changes increase the chances that pinning operations will fail; when that happens, the failure will almost certainly be propagated directly to user space. That could be the cause of some disgruntlement.

Whether this is a problem that will arise in practice is far from clear; in theory, now that pages cannot be pinned in ZONE_MOVABLE, migration failures should be rare. But this is the sort of change that can cause complaints years later when it turns up in an enterprise kernel. It would appear that the memory-management developers are not overly concerned about this possibility. The patch set has been through seven revisions and appears to be getting closer to the point where it can be accepted; the seventh version was mostly concerned with adding Reviewed-by tags to the series. So chances are that ZONE_MOVABLE will come closer to living up to its name in the near future.

Comments (5 posted)

A year of Python in Fedora

Distribution developers do a lot of work to keep a language ecosystem working well within the distribution. It is relatively thankless work that normally only becomes visible when there is a problem or complaint. But Miro Hrončok recently put together a look back at what the Fedora Python team did during 2020. While it is, obviously, Fedora-specific, it provides something of a look inside at the kinds of things that distribution teams work on.

In his announcement post to the Fedora devel mailing list, Hrončok said that he was inspired to create the report by a similar effort for the Cool Other Package Repo (Copr) team by Miroslav Suchý. That report was well-received, so Hrončok followed suit. Perhaps it will catch on with other Fedora teams as well as for other distributions.

Hrončok is on the Python maintenance team at Red Hat as well as a member of the Fedora Python special interest group (SIG). He noted that 2020 was special in the Python world because the Python 2 series reached its end of life on January 1 (notwithstanding the commemorative 2.7.18 release in April). Support for Python 2.7 from the core developers has ceased, but the Red Hat maintainers will still be making security updates to it for Red Hat Enterprise Linux for some time to come.

There were two releases of Fedora in 2020 (Fedora 32 at the end of April and 33 at the end of October) as well as a new Python 3.9 in early October. But Fedora 32 was released with the then-current Python, 3.8, which was released the previous October. Python 3.8 had missed being included in Fedora 31 "because the release schedules of Python and Fedora were a tad too misaligned to allow a safe upgrade so soon". Going forward, that alignment has been improved, so work on Python 3.9 for Fedora 33 began well in advance of the releases for both.

Retiring Python 2 led to some of the 2.7 compatibility features being dropped in Python 3.9. Getting an early jump on testing that release made Hrončok and Victor Stinner aware that many packages would not build due to those removals. They successfully lobbied the Python core developers to postpone those removals to Python 3.10 so that Python-using projects can have a bit more time to adapt to the new world. Meanwhile, work on Python 3.10, scheduled for October 2021 began in 2020 for Fedora, targeting Fedora 35, which is also due in October.

As can be seen, there are lots of moving parts to track and test. Another area that saw improvements in 2020 was the continuous-integration (CI) testing for the language. New architectures were added for both Fedora and RHEL CI testing for Python, including s390x, ppc64le, and aarch64. Testing upstream Python regularly has helped finding bugs in Python as well unrelated problems elsewhere in the distribution. Hrončok pointed to a bug in brk() for aarch64 and problems with building using GCC 10 on ppc64le as examples.

There is a truly eye-opening number of Python packages in Fedora; the language clearly makes up a big part of the distribution:

One interesting feature that came about in 2020 is a new marshalparser tool that can be used as part of the RPM-building process to ensure that compiled Python files (i.e. .pyc files) are bit-for-bit the same if they are built from the same source. The Python marshal serializer can produce different byte code under some circumstances, as described in a Bugzilla comment, so marshalparser can be used to fix that in places where it matters. This is obviously important for reproducible builds.

Fedora field-tested the use of the -fno-semantic-interposition GCC flag, which produced a significant performance boost for the language. That flag effectively shorts out the normal lookup of a function in a library by removing the default interposition mechanism that allows a library loaded using LD_PRELOAD to override a function. This precludes the use of LD_PRELOAD for libpython as a negative side-effect, but reduces pressure on the instruction cache of the CPU leading to a performance improvement of up to 27% depending on the workload. The change was made for Fedora 32 and is now part of the upstream CPython build process. It has also been backported to earlier versions of Python in RHEL 8 and CentOS.

A patch that most distributions had long carried to have Python install its modules to /usr/lib64 (rather than /usr/lib) has made it into the CPython mainline. Work from both Fedora and openSUSE developers means that those distributions, and others such as Gentoo and Debian, can stop carrying a patch that has been around for 16 years at this point.

These are only some of the highlights of the accomplishments that Hrončok documented in the report. He also speculated on the kinds of things that would be worked on in 2021:

The report gives a nice overview of the kinds of work that every Linux distribution does to integrate a language like Python into its ecosystem. Making two big projects work well together takes a lot of effort, but one of the goals for the Fedora Python SIG is to "ensure Fedora is the best operating system for a Python developer". Other distributions might beg to differ with that, but that just means there could be a friendly rivalry that can only lead to Python on Linux getting better. That benefits everyone.

Comments (10 posted)

An unpleasant sudo vulnerability

It would appear that "sudo" has a buffer-overflow vulnerability that allows any local user to gain root privileges, whether or not they are in the sudoers file. It has been there since 2011. See this advisory for details, but perhaps run an update first.

Comments (62 posted)

Kernel release status

The current development kernel is 5.11-rc5, released on January 24. "Nothing particularly stands out. We had a couple of splice() regressions that came in during the previous release as part of the 'get rid of set_fs()' development, but they were for odd cases that most people would never notice. I think it's just that 5.10 is now getting more widely deployed so people see the fallout from that rather fundamental change in the last release."

Stable updates: 5.10.10, 5.4.92, 4.19.170, 4.14.217, 4.9.253, and 4.4.253 were released on January 23, followed by 5.10.11, 5.4.93, and 4.19.171 on January 27.

Comments (none posted)

Corellium: How we ported Linux to the M1

The Corellium blog is carrying a description of how the Linux port to the Apple M1 processor was done. "Many components of the M1 are shared with Apple mobile SoCs, which gave us a good running start. But when writing Linux drivers, it became very apparent how non-standard Apple SoCs really are. Our virtual environment is extremely flexible in terms of models it can accommodate; but on the Linux side, the 64-bit ARM world has largely settled on a well-defined set of building blocks and firmware interfaces - nearly none of which were used on the M1."

Comments (43 posted)

Quote of the week

— Greg Kroah-Hartman

Comments (2 posted)

Firefox 85 released

Version 85 of the Firefox browser has been released. The headline change appears to be the isolation of internal caches to defeat the use of "supercookies" to track users; see this blog entry for details. "In fact, there are many different caches trackers can abuse to build supercookies. Firefox 85 partitions all of the following caches by the top-level site being visited: HTTP cache, image cache, favicon cache, HSTS cache, OCSP cache, style sheet cache, font cache, DNS cache, HTTP Authentication cache, Alt-Svc cache, and TLS certificate cache."

Comments (35 posted)

This is 2021: what’s coming in free/libre software (Libre Arts)

Libre Arts (formerly Libre Graphics World) has posted a comprehensive survey of what 2021 might hold for a wide range of free content-creation software.

Comments (102 posted)

pip 21.0 has now been released

The Python Packaging Authority (PyPA) has announced the release of pip 21.0. This version removes Python 2.7 and 3.5 support, and drops support for legacy cache entries from pip < 20.0.

Full Story (comments: 3)

Development quotes of the week

— Ben Cotton

— Russell Nelson (Thanks to Thorsten Glaser)

Comments (none posted)

• DistroWatch Weekly (January 25)

• Lunar Linux Weekly News (January 22)

• openSUSE Tumbleweed Review of the Week (January 24)

• Ubuntu Weekly Newsletter (January 23)

• Emacs News (January 25)

• What's cooking in git.git (January 25)

• LLVM Weekly (January 25)

• OCaml Weekly News (January 26)

• Perl Weekly (January 25)

• PostgreSQL Weekly News (January 24)

• Python Weekly Newsletter (January 21)

• Weekly Rakudo News (January 25)

• Ruby Weekly News (January 21)

• This Week in Rust (January 20)

• Document Foundation Board of Directors minutes (January 15)

• Fedora Council minutes (January 21)

• Fedora FESCO meeting minutes (January 27)

• Perl Steering Council meeting minutes (January 22)

CFP Deadlines: January 28, 2021 to March 29, 2021

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

Deadline	Event Dates	Event	Location
February 12	May 14 May 15	PyCon US 2021	Online
February 28	June 15 June 16	stackconf online 2021	Online
March 1	May 2 May 3	PyCon Israel 2021	Online
March 15	May 13 May 15	Linux App Summit	online
March 19	May 4 May 6	sambaXP 2021	Online
March 22	July 21 July 25	GUADEC	Online

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

Events: January 28, 2021 to March 29, 2021

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

Date(s)	Event	Location
February 6 February 7	FOSDEM 2021	Online
February 18 February 20	DevConf.CZ	Online
March 20 March 21	LibrePlanet 2021	Online

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

Alert summary January 21, 2021 to January 27, 2021

Dist.	ID	Release	Package	Date
Arch Linux	ASA-202101-25		sudo	2021-01-26
CentOS	CESA-2021:0153	C7	dnsmasq	2021-01-25
CentOS	CESA-2020:5350	C7	net-snmp	2021-01-25
CentOS	CESA-2021:0221	C7	sudo	2021-01-27
CentOS	CESA-2021:0162	C7	xstream	2021-01-25
Debian	DLA-2533-1	LTS	crmsh	2021-01-25
Debian	DLA-2532-1	LTS	debian-security-support	2021-01-25
Debian	DLA-2530-1	LTS	drupal7	2021-01-21
Debian	DSA-4830-2	stable	flatpak	2021-01-22
Debian	DSA-4833-2	stable	gst-plugins-bad1.0	2021-01-24
Debian	DLA-2529-1	LTS	mutt	2021-01-21
Debian	DSA-4838-1	stable	mutt	2021-01-25
Debian	DSA-4836-1	stable	openvswitch	2021-01-22
Debian	DLA-2531-1	LTS	python-bottle	2021-01-25
Debian	DSA-4837-1	stable	salt	2021-01-24
Debian	DLA-2534-1	LTS	sudo	2021-01-26
Debian	DSA-4839-1	stable	sudo	2021-01-26
Debian	DSA-4835-1	stable	tomcat9	2021-01-22
Debian	DSA-4834-1	stable	vlc	2021-01-22
Fedora	FEDORA-2021-d9faeff8eb	F32	chromium	2021-01-23
Fedora	FEDORA-2021-48866282e5	F33	chromium	2021-01-24
Fedora	FEDORA-2021-77a4202036	F32	dotnet3.1	2021-01-22
Fedora	FEDORA-2021-fb078913dd	F33	dotnet3.1	2021-01-22
Fedora	FEDORA-2021-3bcc7198c8	F33	kernel	2021-01-27
Fedora	FEDORA-2020-8794383d6f	F33	libntlm	2021-01-21
Fedora	FEDORA-2021-a8ddc1ce70	F33	mingw-python-pillow	2021-01-21
Fedora	FEDORA-2021-02996612f6	F32	php-pear	2021-01-27
Fedora	FEDORA-2021-880aa7bd27	F32	python-pillow	2021-01-24
Fedora	FEDORA-2021-a8ddc1ce70	F33	python-pillow	2021-01-21
Fedora	FEDORA-2021-7066b95c99	F33	sddm	2021-01-24
Fedora	FEDORA-2021-8840cbdccd	F32	sudo	2021-01-27
Fedora	FEDORA-2021-234d14bfcc	F32	sudo	2021-01-21
Fedora	FEDORA-2021-2cb63d912a	F33	sudo	2021-01-27
Fedora	FEDORA-2021-7785f6c616	F33	xen	2021-01-25
Gentoo	202101-23		PEAR-Archive_Tar	2021-01-26
Gentoo	202101-31		cacti	2021-01-26
Gentoo	202101-24		cfitsio	2021-01-26
Gentoo	202101-13		chromium	2021-01-22
Gentoo	202101-17		dnsmasq	2021-01-22
Gentoo	202101-26		f2fs-tools	2021-01-26
Gentoo	202101-21		flatpak	2021-01-24
Gentoo	202101-27		freeradius	2021-01-26
Gentoo	202101-20		glibc	2021-01-24
Gentoo	202101-16		kdeconnect	2021-01-22
Gentoo	202101-22		libvirt	2021-01-26
Gentoo	202101-25		mutt	2021-01-26
Gentoo	202101-32		mutt	2021-01-26
Gentoo	202101-28		ncurses	2021-01-26
Gentoo	202101-19		openjdk	2021-01-24
Gentoo	202101-29		openjpeg	2021-01-26
Gentoo	202101-18		python	2021-01-24
Gentoo	202101-30		qtwebengine	2021-01-26
Gentoo	202101-33		sudo	2021-01-26
Gentoo	202101-14		thunderbird	2021-01-22
Gentoo	202101-15		virtualbox	2021-01-22
Gentoo	202101-12		wireshark	2021-01-22
Gentoo	202101-11		zabbix	2021-01-21
Mageia	MGASA-2021-0051	7	blosc	2021-01-23
Mageia	MGASA-2021-0049	7	crmsh	2021-01-23
Mageia	MGASA-2021-0053	7	glibc	2021-01-24
Mageia	MGASA-2021-0047	7	kernel	2021-01-20
Mageia	MGASA-2021-0048	7	perl-DBI	2021-01-23
Mageia	MGASA-2021-0050	7	php-oojs-oojs-ui	2021-01-23
Mageia	MGASA-2021-0054	7	python-pip	2021-01-25
Mageia	MGASA-2021-0055	7	python-urllib3	2021-01-25
Mageia	MGASA-2021-0056	7	sudo	2021-01-27
Mageia	MGASA-2021-0052	7	undertow	2021-01-23
openSUSE	openSUSE-SU-2021:0148-1	15.1	ImageMagick	2021-01-24
openSUSE	openSUSE-SU-2021:0136-1	15.2	ImageMagick	2021-01-22
openSUSE	openSUSE-SU-2021:0166-1	15.1	chromium	2021-01-26
openSUSE	openSUSE-SU-2021:0150-1	15.2	gdk-pixbuf	2021-01-24
openSUSE	openSUSE-SU-2021:0147-1	15.1	hawk2	2021-01-24
openSUSE	openSUSE-SU-2021:0144-1	15.2	hawk2	2021-01-23
openSUSE	openSUSE-SU-2021:0161-1	15.1	mutt	2021-01-26
openSUSE	openSUSE-SU-2021:0162-1	15.2	mutt	2021-01-26
openSUSE	openSUSE-SU-2021:0138-1	15.1	opera	2021-01-22
openSUSE	openSUSE-SU-2021:0139-1	15.2	opera	2021-01-22
openSUSE	openSUSE-SU-2021:0132-1	15.1	python-autobahn	2021-01-21
openSUSE	openSUSE-SU-2021:0152-1	15.2	python-autobahn	2021-01-24
openSUSE	openSUSE-SU-2021:0160-1	15.2	stunnel	2021-01-25
openSUSE	openSUSE-SU-2021:0169-1	15.1	sudo	2021-01-27
openSUSE	openSUSE-SU-2021:0170-1	15.2	sudo	2021-01-27
openSUSE	openSUSE-SU-2021:0145-1		viewvc	2021-01-23
openSUSE	openSUSE-SU-2021:0165-1	15.2	virtualbox	2021-01-26
openSUSE	openSUSE-SU-2021:0154-1	15.1	wavpack	2021-01-25
openSUSE	openSUSE-SU-2021:0153-1	15.2	wavpack	2021-01-25
openSUSE	openSUSE-SU-2021:0140-1	15.2	xstream	2021-01-22
Oracle	ELSA-2021-0221	OL7	sudo	2021-01-26
Oracle	ELSA-2021-0221	OL7	sudo	2021-01-27
Oracle	ELSA-2021-0218	OL8	sudo	2021-01-27
Red Hat	RHSA-2021:0258-01	EL8.2	cryptsetup	2021-01-26
Red Hat	RHSA-2021:0240-01	EL7.2	dnsmasq	2021-01-25
Red Hat	RHSA-2021:0245-01	EL7.3	dnsmasq	2021-01-25
Red Hat	RHSA-2021:0266-01	EL8.2	gnome-settings-daemon	2021-01-26
Red Hat	RHSA-2021:0257-01	EL7.4	net-snmp	2021-01-26
Red Hat	RHSA-2021:0227-01	EL6	sudo	2021-01-26
Red Hat	RHSA-2021:0221-01	EL7	sudo	2021-01-26
Red Hat	RHSA-2021:0226-01	EL7.2	sudo	2021-01-26
Red Hat	RHSA-2021:0225-01	EL7.3	sudo	2021-01-26
Red Hat	RHSA-2021:0224-01	EL7.4	sudo	2021-01-26
Red Hat	RHSA-2021:0223-01	EL7.6	sudo	2021-01-26
Red Hat	RHSA-2021:0222-01	EL7.7	sudo	2021-01-26
Red Hat	RHSA-2021:0218-01	EL8	sudo	2021-01-26
Red Hat	RHSA-2021:0220-01	EL8.1	sudo	2021-01-26
Red Hat	RHSA-2021:0219-01	EL8.2	sudo	2021-01-26
Scientific Linux	SLSA-2021:0221-1	SL7	sudo	2021-01-26
Scientific Linux	SLSA-2021:0162-1	SL7	xstream	2021-01-26
Slackware	SSA:2021-024-01		seamonkey	2021-01-24
Slackware	SSA:2021-026-01		sudo	2021-01-26
SUSE	SUSE-SU-2021:0199-1	OS7 OS8 OS9 SLE12 SES5	ImageMagick	2021-01-22
SUSE	SUSE-SU-2021:0184-1	SLE15	gdk-pixbuf	2021-01-21
SUSE	SUSE-SU-2021:0222-1	MP4.0 SLE15 SES6	go1.14	2021-01-26
SUSE	SUSE-SU-2021:0223-1	MP4.0 SLE15 SES6	go1.15	2021-01-26
SUSE	SUSE-SU-2021:0192-1	SLE12	hawk2	2021-01-22
SUSE	SUSE-SU-2021:0198-1	SLE12	hawk2	2021-01-22
SUSE	SUSE-SU-2021:0200-1	SLE15	hawk2	2021-01-22
SUSE	SUSE-SU-2021:0196-1	SLE12	mutt	2021-01-22
SUSE	SUSE-SU-2021:0195-1	SLE15	mutt	2021-01-22
SUSE	SUSE-SU-2021:0224-1	MP4.0 SLE15 SES6	nodejs8	2021-01-26
SUSE	SUSE-SU-2021:0183-1	SLE15	perl-Convert-ASN1	2021-01-21
SUSE	SUSE-SU-2021:0197-1	SLE15	permissions	2021-01-22
SUSE	SUSE-SU-2021:0217-1	OS7 OS8 OS9 SLE12 SES5	postgresql, postgresql12, postgresql13	2021-01-26
SUSE	SUSE-SU-2021:0210-1	OS7	rubygem-nokogiri	2021-01-25
SUSE	SUSE-SU-2021:0185-1	SES7	samba	2021-01-21
SUSE	SUSE-SU-2021:0194-1	SLE15	stunnel	2021-01-22
SUSE	SUSE-SU-2021:0227-1	MP4.0 SLE15 SES6	sudo	2021-01-27
SUSE	SUSE-SU-2021:0232-1	OS7 SLE12	sudo	2021-01-27
SUSE	SUSE-SU-2021:0226-1	OS8 OS9 SLE12 SES5	sudo	2021-01-27
SUSE	SUSE-SU-2021:0225-1	SLE12	sudo	2021-01-27
SUSE	SUSE-SU-2021:0186-1	MP4.0 SLE15 SES6	wavpack	2021-01-21
SUSE	SUSE-SU-2021:0182-1	SLE12	yast2-multipath	2021-01-21
Ubuntu	USN-4704-1	14.04 16.04	libsndfile	2021-01-26
Ubuntu	USN-4689-4	18.04 20.04 20.10	linux, linux-aws, linux-azure, linux-gcp, linux-hwe-5.4, linux-hwe-5.8, linux-oracle	2021-01-20
Ubuntu	USN-4703-1	16.04 18.04 20.04 20.10	mutt	2021-01-25
Ubuntu	USN-4702-1	16.04	pound	2021-01-25
Ubuntu	USN-4705-2	12.04 14.04	sudo	2021-01-27
Ubuntu	USN-4705-1	16.04 18.04 20.04 20.10	sudo	2021-01-26

Full Story (comments: none)