Welcome to the LWN.net Weekly Edition for January 2, 2020

• LWN's 2020 vision: our traditional selection of unlikely predictions for the coming year.
• Python first(): how to quickly find a matching string in Python — with several digressions.
• Cloning into a control group: a clone3() change to address a longstanding process-creation race condition.
• KRSI — the other BPF security module: a new approach to system monitoring using BPF.
• Fedora and fstrim: should Fedora systems run fstrim by default?

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)

LWN's 2020 vision

The Python community will continue to chart its post-Guido course. One relatively unnoticed development in the Python project's 2020 steering-council election was the quiet withdrawal of project founder Guido van Rossum's nomination. While he will still participate, he no longer wants a leadership role in the project. Increasingly, Python will have to find its way without the developer who has guided it since the beginning.

Similarly, the GNU Project will have to decide what it will be in the 2020s. This project's founder, Richard Stallman, retains his post as its leader, and it's possible that he will still be there at the end of the year. But there is ongoing restlessness in the project that brings a desire for new leadership and new directions. After all these years, it still sometimes seems like GNU is stuck trying to reproduce the Unix workstations of the 1980s, leaving much of the current computing environment to systems that are half-free at best. We need a GNU project for mobile devices, private clouds, home systems, embedded applications, and more. Stallman once famously said "I'm not really concerned with what's running inside my microwave oven." The time has long since come to be concerned about such things; wouldn't it be a great thing if a newly reinvigorated GNU project were to take on this challenge?

There is a common theme to those last two items that may not really arise in 2020, but will certainly come about in the 2020s: many of our leaders in the free-software community got their start in the 1980s and 1990s. In talking with those people, your editor increasingly gets the sense that many of them are thinking they have done this sort of work for just about long enough. Retirements will increase in the coming years, and we will lose much of the skill and experience that has gotten us this far. There are plenty of skilled and motivated younger developers who can certainly pick up where these folks leave off, but the transitions will go more smoothly if they are properly planned for.

The presence of highly experienced developers is perhaps felt most strongly in the kernel project. This is a good thing in a setting where mistakes can be catastrophic on a large scale, but it also partially explains why kernel developers have a distinctly old-school workflow. This is, remember, the project that only started using a source-code management system in 2002. Change is afoot, though, and the kernel workflow efforts will begin to bear fruit in 2020. We'll still be sending patches over email at the end of the year, but we'll have an improved understanding of what a better solution that can work at the kernel project's scale will look like. As part of this effort, the kernel's testing tools will also continue to improve at a rapid rate.

For all its faults, though, the kernel's workflow produces reliable results. Thus, it is relatively safe to predict that the next long-term stable kernel release will be 5.9, on November 1, 2020. Most kernel release cycles have taken ten weeks in recent times. Should the process run a little faster and produce some nine-week releases, then the LTS release will, instead, be 5.10 in late December.

Strife in the Debian community will continue despite the project's recent decision on init-system policy. Debian suffers from a combination of hostile outsiders and certain project members who actively work to create turmoil on its mailing lists. The Debian community is resilient, and it will get past these problems too. But its mailing lists may not be a lot of fun to read in the meantime. The Devuan project, despite having picked up a post-vote defector or two from Debian, will continue to struggle for developer time and relevance.

It is now 20 years since the year-2000 bug failed to destroy civilization. Some now see y2k as an irrational panic, but without a focused effort there would have indeed been serious problems. The year-2038 bug looks distant and harmless, but it, too, requires a determined effort to avert real problems. The good news is that the year-2038 fixes will be mostly completed in 2020, at least at the kernel level. Yes, your editor has predicted this before and taken some good-natured grief for it, but this time it's for real.

BPF API issues will not go away in 2020. The in-kernel BPF virtual machine makes a great deal of power available to user space, and that will only increase in the coming year. Software providers will realize that it is often far easier to ship a BPF program to customers than to get a needed feature into the kernel itself. Sooner or later, one of those programs will break as the result of internal kernel changes and those customers will complain, quite possibly causing needed work to be reverted. The fact that much BPF functionality is available to proprietary programs is likely to create troubles of its own. A quick check shows 142 BPF helper functions in the 5.5-rc4 kernel; only 34 of those are marked GPL-only. Some developers are sure to see the growing set of BPF functions available to proprietary code as an erosion of whatever GPL protection the kernel has left.

Expect perturbations in the employment market as various economic realities catch up with us. Both the dotcom crash and the 2008 crisis impacted the development community; the next downturn will do the same. As in the past, Linux and free software as a whole will not be significantly hurt when this happens, but the same cannot be said for individual developers, at least in the short term.

Finally, though this is perhaps more of a wishlist item than a prediction: the free-software community has to think more deeply about what it is creating and how that will affect the world. At many levels free software has won; the world's computing infrastructure is built on the code we have created. We have much more control over our computing environments than we would have believed all those years ago; it's a great success.

But we have also created — and continue to develop — the foundation for the most intensive surveillance machine the world has ever known. We have helped to build a world where sex toys report on their usage patterns, video doorbells cooperate with police, companies are attacked via fish-tank thermometers, cars can be disabled remotely, elections can be attacked by hostile countries, televisions report viewing habits, home devices phone home with audio recordings, and more. All of this machinery is used to sell us things, or to direct our behavior in even less benevolent ways. It is increasingly concentrated in the hands of a tiny number of huge companies; using it will inevitably prove to be a temptation that governments are unable to resist. We wanted a world where we controlled our computers, but we have created a world where our computers are used to control us. It is not enough to blame the companies involved; we have helped to build this world.

Back in 1983, the GNU project helped to focus attention on the need to create a free operating system for our desktop computers. Now we desperately need a project that can bring a similar level of attention to the need for free computing in every aspect of our lives. Free software was able to demonstrate enough advantages to convince companies to adopt it, even if it was less convenient in some ways at the time. The next generation of free software (along with freedom-respecting devices built on it) has to succeed in convincing people that there is a better way. If the free-software community can rally around this project, the outlook for the 2020s in general will be much improved.

On a more mundane level, LWN is about to celebrate its 22nd birthday. Thanks to the solid support from you, our readers, we are still going strong after all these years. We wish for a great 2020 for all of you and we look forward to write for the best set of readers any publication could hope for.

Comments (70 posted)

Python first()

Python prides itself on being a newbie-friendly language; its developers have gone out of their way to try to ensure that easy tasks are straightforward to program. A recent discussion on the python-ideas mailing list looked at a use case that is common, but often implemented in an inefficient, incorrect fashion, with an eye toward making it easier to do correctly. Finding the first match for a regular expression in a body of text is where the conversation started, but it went in some other interesting directions as well.

findfirst()

Juancarlo Añez started things off with a post about the use case, noting that there are "many ugly recipes" for getting the first match for a regular expression (regex), but that a lot of programmers resort to:

matched = re.findall(regex, text)[0]

That formulation will fail with an IndexError if there are no matches. Even if it succeeds, it does a lot of extra work that gets thrown away to produce the first match; the entire list of matches will be created by re.findall() and all but the first will be wasted effort. He suggested:

def findfirst(regex, text, default=None, flags=0):

    return next(finditer(regex, text, flags=flags), default=default)

That would use the next() function with a default value (None by default) on the iterator returned by re.finditer(). That would produce the first match or the default value without causing an exception if the iterator raised StopIteration because it had no more values. As pointed out in the thread, though, re.finditer() returns Match objects, rather than a list of strings or tuples like re.findall(). The "obvious" switch to re.findall() will not work because a list is not an iterator, so next() will raise a TypeError.

There was some additional confusion about the two functions and their return values in the thread. Serhiy Storchaka pointed out that re.search() could be used in place of the re.finditer() in the example as follows:

    re.search(regex, text, flags) or default

Storchaka was not convinced that a good case had been made for adding such a function, however. Añez tried to fill in the use case:

He pointed out that using the iter() function would make an iterator out of the list returned from re.findall(); that could be used to make his version of findfirst() behave as he wanted. But he also noted that a common extension to the itertools module is a function called first():

def first(seq, default=None):
    return next(iter(seq), default= default)

He suggested that first() would make a good addition as well:

Andrew Barnert pointed out that using re.findall() is not particularly efficient, though:

To Van Rossum, that indicates even more need for a findfirst(), presumably one that is optimized for its task, rather than using re.findall(). But in analyzing some examples posted by Kyle Stanley, Storchaka found that they could generally be rewritten to avoid the troublesome re.findall(...)[0] pattern, often using re.search()—which is optimized to find the first occurrence. "It seems that in most cases the author just [does] not know about re.search(). Adding re.findfirst() will not fix this."

But first()

Añez seemed to agree that basing findfirst() on re.search() made sense, but he also started a new thread to argue that first() should be added, perhaps as a builtin in the standard library. The example he gave in that message was unconvincing to a number of participants, but the general idea of adding a first() sparked a long discussion down several paths.

Steven D'Aprano thought that adding a builtin as a thin wrapper around next() was not providing much of an advantage. He also showed that there are some potential "gotchas" in first() as described:

    # non-iterator iterable
    py> obj = [1, 2, 3, 4]
    py> [first(obj) for __ in range(5)]
    [1, 1, 1, 1, 1]

    # iterator
    py> obj = iter([1, 2, 3, 4])
    py> [first(obj) for __ in range(5)]
    [1, 2, 3, 4, None]

That could be fixed by adding a way to peek ahead in an iterator, though there are some oddities to that as well. But Oscar Benjamin is concerned that the StopIteration exception essentially leaks an implementation detail to the users of a function that uses the one-argument form of next(). It would make more sense to catch that exception and return a ValueError instead. He pointed to PEP 479 ("Change StopIteration handling inside generators") as one proposal that changed the behavior for generators, but did not do so for iterators, which he sees as a problem.

It is interesting to note that there are some corners of Python that even Van Rossum has lost track of. Tim Peters said that the simple one-line implementation of first() is equivalent to a more complicated version that Van Rossum had posted. Peters suggested that there should be two bars to pass before something gets added as a builtin: "In other words, in that context, the bar for 'building it in' consists far more of 'will it be used?' than 'is it difficult or tricky or long-winded?'."

It turns out that the existence of the two-argument form of next(), which will not raise an exception and simply return the default (i.e. the second argument) if the iterator is exhausted, is something that Van Rossum only learned about in the thread. He thinks others may be in the same boat, which puts first() in the "tricky" category:

But Barnert asked: "Are people who never find 2-arg next going to find itertools.first?" Van Rossum acknowledged the problem but thought that adding first() to itertools would likely result in people finding out about it since that module tends to attract some attention in blogs and tutorials. Storchaka wondered if simply adding it to the itertools recipes section of the documentation would be sufficient. Van Rossum thought otherwise: "Not nearly as much as just adding the function. We'll be doing humanity a favor if we just add it."

The difference in behavior for first() on an iterator versus on an iterable (e.g. a list) that D'Aprano had pointed out showed up again later in the thread. Because next() changes the state of an iterator, first() will give surprising results. D'Aprano showed that first() is not idempotent so that calling it twice with the same iterator argument will not give the same results—which is not true for an iterable. He also said that this behavior makes the name "first" ambiguous:

That set off some discussion of the right spelling for first() and whether if should raise an exception (something other than StopIteration) if there is no default passed to it. The latter would effectively remove one of the main features of first() that many proponents preferred, at least early on. Like the get() method for dictionaries, first(), as it was originally proposed, would never raise an exception. As Van Rossum put it:

Peters, who is in favor of a first() that can raise an exception, suggested that first(iterator) and next(iterator) "look darned near identical" but act quite differently if the iterator is exhausted. He sees get() differently because it is a method on the dict object, but Van Rossum was unconvinced by that argument. He was not particularly interested in prolonging the discussion, however: "But if everyone thinks that first() should raise, fine, this thread is way too long already (I should have kept it muted :-)."

Others were not hesitant to keep the discussion going, though. In the end, Añez came to the conclusion that a one-argument first() should raise an exception "so it can be applied to iterables that may yield None as the legit, first value". He also noted that the the more-itertools module from the Python Package Index (PyPI) has a first() that raises ValueError on exhaustion if no default is given. Even if first() is not "promoted" into itertools itself, he is in favor of updating the itertools documentation and recipes to better address the proper way to get the first entry in iterators and iterables.

Getting back to the original problem, Añez posted a findalliter() that would return strings or tuples like re.findall(), but do so with an iterator, rather than creating a whole list that might just be thrown away. He then defined findfirst() in terms of that (and first()).

It is not entirely clear where things go from here. In order to add either function to the standard library, it would seem that a PEP is needed; there doesn't seem to be a lot of opposition to the overall idea. A documentation change is likely even easier. But the discussion provided an interesting look into the Python development process, which tends to start out with postings to python-ideas to be fully hashed out before moving over to python-dev once a PEP has been drafted. The discussion also seems to have brought some semi-obscure corners of the language out of the darkness; much was learned in the process of working through it.

Comments (5 posted)

Cloning into a control group

Before getting into the details, one might naturally ask why this capability is needed, given that Linux has done without it since control groups were first created. The answer is that current kernels present a bit of a race condition for process managers using control groups. A manager can create a process, and it can assign it to a group, but it has little control over what happens between those two actions. That means, for example, that a process might run briefly before being placed into a group where its resource usage can be accounted for properly. The amount of error introduced is likely to be small, but people who are into accounting tend to be intensely irritated by such things.

Placing a process into its intended control group at birth avoids that kind of messiness. It also enables actions like creating a process in a frozen group, ensuring that it will start in a frozen state and not run at all until the process manager allows it to. Finally, as Brauner notes, this feature "simplifies container creation and exec logic quite a bit".

Cloning a new process directly into a control group is only available with version-2 control groups, and it can only be invoked with the brand-new clone3() system call, which has this interface:

    int clone3(struct clone_args *args, size_t size);

The decision to put all of the arguments to clone3() into a structure simplifies the prototype, but it also adds extensibility. That is demonstrated in this patch set, which adds a new field to struct clone_args:

    u64 cgroup;

This new field naturally increases the size of the clone_args structure. Any call to clone3() must pass the size of the structure it is using as the size parameter, so the kernel is able to recognize whether the caller is using a version of the structure containing the cgroup field or not. This new field, in other words, can be added without breaking code that was built before its addition.

To create a process into a different control group than the parent, one places a file descriptor for the appropriate control-group directory into that cgroup field and adds CLONE_INTO_CGROUP to the flags field in that same structure. If all goes well, the child will be created in the indicated group; otherwise the call will fail.

Placing a process into a control group in this way must adhere to all of the usual rules. For example, processes are only allowed to be placed in leaf nodes in the hierarchy, not in the internal nodes; an attempt to create a process in an internal node will fail. Similarly, all threads of a process must normally be in the same control group (though thread mode can relax that restriction in some cases); an attempt to separate threads improperly will fail.

This patch set is quite new (this is its first posting), so there has been little time for the development community to review it. The feature seems useful enough that it is hard to imagine a great deal of opposition to the goal. Whether the implementation stands up to review remains to be seen, but it seems likely that this enhancement will find its way upstream in the relatively near future.

Comments (28 posted)

KRSI — the other BPF security module

While KRSI is implemented as a Linux security module and is able to make access-control decisions, access control does not appear to be the core goal behind this work. Instead, KRSI exists to keep an eye on system behavior overall in order to detect attacks. It is, in a sense, better thought of as an extension of the kernel's audit mechanism that uses BPF to provide a higher level of configurability beyond what the audit subsystem can do.

The concept behind KRSI is simple enough: it allows a suitably privileged user to attach a BPF program to any of the hundreds of hooks provided by the Linux security module subsystem. To make this attachment easy, KRSI exports a new filesystem hierarchy under /sys/kernel/security/bpf, with one file for each hook. The bpf() system call can be used to attach a BPF program (of the new type BPF_PROG_TYPE_LSM) to any of these hooks; there can be more than one program attached to any given hook. Whenever a security hook is called, all attached BPF programs will be called in turn; if any BPF program returns an error status, then the requested action will be denied.

Many readers will be thinking that this mechanism sounds a lot like Landlock. While the fundamental idea — attaching BPF programs to security-module hooks — is the same, the underlying goals are different, and that leads to a different implementation. KRSI is a tool for system administrators who are interested in monitoring the behavior of the system as a whole; attaching a BPF program requires the CAP_SYS_ADMIN capability. Landlock, instead, is intended to allow unprivileged users to sandbox programs that they are running, so no privilege is needed to attach a BPF program to a hook via Landlock.

This difference fundamentally affects how these modules execute. Consider, for example, the hook that the kernel calls in response to an mprotect() call from user space:

    int security_file_mprotect(struct vm_area_struct *vma, unsigned long reqprot,
			       unsigned long prot);

In KRSI, the three parameters to this hook will be passed directly to any attached BPF programs; those programs can follow the vma pointer to learn all about the affected memory area. They can also follow vma->vm_mm to get to the calling processes top-level memory-management data (the mm_struct structure). There is, in short, a lot of information available to these programs.

The Landlock situation is different. Since Landlock hooks are under the control of unprivileged users, they cannot be allowed to just wander through kernel data structures. So a Landlock hook for mprotect() is passed a structure like this:

    struct landlock_ctx_mem_prot {
        __u64 address;
	__u64 length;
	__u8 protections_current;
	__u8 protections_requested;
    };

In other words, the information passed to this hook contains nothing that user space did not already know. That makes it safe for the intended use case, but is likely to be too limiting for the global auditing case.

The advent of speculative-execution vulnerabilities, along with other factors, has led to a slow simmer of questions about whether it can ever be safe to allow unprivileged users to run extended BPF code in the kernel. The BPF developers themselves have been coming to the conclusion that it cannot be done, and have scaled back their plans to make unprivileged BPF available. Indeed, even Mickaël Salaün, the author of Landlock, now feels that "it is quite challenging to safely expose eBPF to malicious processes". He went on to say:

So, while it may tempting to see KRSI and Landlock as being in competition with each other, that does not really appear to be the case.

There does not appear to be any fundamental opposition to KRSI — so far — but Casey Schaufler did raise the inevitable concern with this approach: "This effectively exposes the LSM hooks as external APIs. It would mean that we can't change or delete them." API issues often come up around BPF, especially in the tracing area, so it is unsurprising that this question would arise here. In this case, Singh replied: "we *do not* want to make LSM hooks a stable API and expect the eBPF programs to adapt when such changes occur". It has repeatedly been made clear, though, that such expectations do not override the kernel's stable-ABI rules. Given the power that would be available to KRSI hooks, it is reasonable to expect that they would be used for a range of purposes far beyond those envisioned by its developers. If unrelated kernel changes break the resulting programs, there is a good chance that they would be reverted.

Additionally, one could argue that this kind of problem is more likely to come about with KRSI than with, for example, tracepoints. While tracepoints have been added as an explicit way to make specific information available to user space, the security-module hooks were designed for internal use. They expose a lot of information, in internal-kernel formats, that one might otherwise not choose to make available even to privileged users. That can only make them more likely to break as those kernel data structures change. Changes to the security hooks are not that common, but they do happen (example); developers are unlikely to react well to the idea that they would no longer be able to make that kind of change.

The ABI issue could thus end up being the biggest obstacle to the merging of KRSI, even though such concerns have not (yet) stalled efforts in areas like tracing. It will be interesting to see what happens as the awareness of this functionality spreads. The usefulness of KRSI seems clear, but the potential for long-term problems it could bring is rather murkier.

Comments (2 posted)

Fedora and fstrim

A proposal to periodically run the fstrim command on Fedora 32 systems was discussed recently on the Fedora devel mailing list. fstrim is used to cause a filesystem to inform the underlying storage of unused blocks, which can help SSDs and other types of block devices perform better. There were a number of questions and concerns raised, including whether to change the behavior of earlier versions of the distribution when they get upgraded and if the kernel should be responsible for handling the whole problem.

The proposal for a Fedora 32 system-wide change to "enable fstrim.timer by default" was posted by program manager Ben Cotton on behalf of its owner, Chris Murphy. The fstrim.timer systemd unit file simply runs fstrim.service (which runs fstrim) weekly on mounted filesystems.

But some devices have imperfect or broken support for the trim (or discard) operation; even those devices with good support may take some time to act on the trim commands, which delays other I/O to the device. The timer is set for Monday at 00:00 local time, which is meant to avoid affecting most users, though sleeping and powered-off systems will run fstrim when they wake up or boot. Under those circumstances, the delay may be more noticeable, but: "It's expected most users won't notice this."

Some are concerned with changing this behavior on package updates or upgrades from previous Fedora versions, however. Stuart D. Gathman said that if the user disables the feature, it should not be re-enabled with updates. John M. Harris Jr. thought it should only be enabled for new installs and not change when upgrading to a new Fedora version. Murphy disagreed to some extent:

He also noted that customizations made to the timer and service unit files should be done in /etc, which would allow those changes to survive an upgrade to the base files that live in /usr. Harris complained that it would be hard for users to discover this change, but others pointed out that there would be an entry in the release notes, which could contain information on how to disable the functionality.

Lennart Poettering wondered why the kernel did not simply handle the trimming itself. Waking up user space to tell the kernel to do something strikes him as sub-optimal: "If this is generally desirable, why is something as trivial as that not a kernel functionality anyway?" Vitaly Zaitsev suggested that the trim operation may cause data corruption on some devices, but Poettering pointed out that moving the decision to user space did not change that one way or the other. Beyond that, though, he asked about the difference between this new Fedora feature and the discard mount option for (at least) ext4, XFS, and Btrfs; "So why do we need a userspace component to enqueue the same operation if the file systems can do that anyway, at much better times?"

The mount option does the trim/discard operation for each freed block, Louis Lagendijk said, which may lead to unpredictable latencies at unexpected times. Part of the problem is that there is insufficient information available from the devices that would allow the kernel to make the "right" decision, Murphy said. So other distributions (and operating systems) have simply been periodically doing a batch trim of the free blocks.

In another message, Murphy noted an LWN article from May that described some of the problems with discard. He is not opposed to eventually finding a kernel solution, but it is all rather messy at this point:

There was also some discussion of the discard option in /etc/crypttab that allows discard operations on LUKS-encrypted device-mapper volumes to be passed down to the underlying storage device. Setting that option was done for Fedora 27, but, since there is no periodic fstrim being done by default, it may not really have helped all that many users, Murphy said. There are some information leaks doing discards on LUKS volumes, however, as Zaitsev noted, which may cause some security-conscious users to disable the feature.

As the proposal notes, Ubuntu and openSUSE have been enabling fstrim.timer for some time now, which makes Fedora late to the table. It also means that the feature has been pretty well tested at this point, though. Sometime early in the new year, one would expect the Fedora Engineering Steering Committee (FESCo) to weigh in. Given that Fedora aims to be "first", it would seem likely that FESCo will not want the distribution to be left further behind on this.

Comments (29 posted)

Cloud Native Computing Foundation announces TUF graduation

Kernel release status

Previously, 5.5-rc3 was released on December 22.

Stable updates: 5.4.6, 4.19.91, 4.14.160, 4.9.207, and 4.4.207 were released on December 21, followed by 5.4.7, 4.19.92, and 4.14.161 on December 31.

Comments (none posted)

Quotes of the week

Comments (4 posted)

Alpine Linux 3.11 released

Comments (none posted)

The results from the Debian init-system GR

Full Story (comments: 93)

Górny: A distribution kernel for Gentoo

Comments (41 posted)

Distribution quote of the fortnight

Comments (none posted)

Development quotes of the fortnight

Comments (4 posted)

• DistroWatch Weekly (December 23)

• Linux Mint Monthly News (December)

• Lunar Linux Weekly News (December 20)

• Lunar Linux Weekly News (December 27)

• openSUSE Tumbleweed Review of the Week (December 23)

• openSUSE Tumbleweed Review of the Week (December 27)

• SparkyLinux News (December 31)

• Ubuntu Weekly Newsletter (December 21)

• Ubuntu Weekly Newsletter (December 28)

• Emacs News (December 23)

• Emacs News (December 30)

• Git Rev News (December 25)

• Koha Community Newsletter (December)

• LLVM Weekly (December 23)

• LLVM Weekly (December 30)

• OCaml Weekly News (December 31)

• Perl Weekly (December 23)

• Perl Weekly (December 30)

• PostgreSQL Weekly News (December 22)

• PostgreSQL Weekly News (December 29)

• Python Weekly Newsletter (December 19)

• Python Weekly Newsletter (December 26)

• Weekly Rakudo News (December 24)

• Ruby Weekly News (December 19)

• This Week in Rust (December 17)

• This Week in Rust (December 24)

• Wikimedia Tech News (December 23)

[CFP] Power Management and Scheduling in the Linux Kernel (OSPM-summit)

Full Story (comments: none)

CFP Deadlines: January 2, 2020 to March 2, 2020

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

Events: January 2, 2020 to March 2, 2020

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

Alert summary December 26, 2019 to January 1, 2020