This is a living document. Everything in this document is made in good faith of being accurate, but like I just said; we don't yet know everything about what's going on.
On March 29th, 2024, a backdoor was discovered in xz-utils, a suite of software that
| #!/usr/bin/env perl | |
| # | |
| # Cat file to terminal at particular speed of lines per second | |
| # https://superuser.com/a/526249 | |
| # | |
| # Usage: cat-lps.pl [lps] [file]... | |
| # | |
| use warnings; | |
| use strict; |
| #!/bin/sh | |
| # | |
| # Generate version information based on Git tags/commits. | |
| # | |
| # License: Public Domain | |
| # | |
| # URL: https://gist.github.com/liweitianux/9fce0fc404c41b8f28512e87fbca1562 | |
| # | |
| dirty_mark='+' |
Libuv and libev, two I/O libraries with similar names, recently had the privilege to use both libraries to write something. Now let's talk about my own subjective expression of common and different points.
The topic of high-performance network programming has been discussed. Asynchronous, asynchronous, or asynchronous. Whether it is epoll or kqueue, it is always indispensable to the asynchronous topic.
Libuv is asynchronous, and libev is synchronous multiplexing IO multiplexing.
Libev is a simple encapsulation of system I/O reuse. Basically, it solves the problem of different APIs between epoll and kqueuq. Ensure that programs written using livev's API can run on most *nix platforms. However, the disadvantages of libev are also obvious. Because it basically just encapsulates the Event Library, it is inconvenient to use. For example, accept(3) requires manual setnonblocking after connection. EAGAIN, EWOULDBLOCK, and EINTER need to be detected when reading from a socket. This is a
Short (72 chars or less) summary
More detailed explanatory text. Wrap it to 72 characters. The blank
line separating the summary from the body is critical (unless you omit
the body entirely).
Write your commit message in the imperative: "Fix bug" and not "Fixed
bug" or "Fixes bug." This convention matches up with commit messages
| # <type>: (If applied, this commit will...) <subject> (Max 50 char) | |
| # |<---- Using a Maximum Of 50 Characters ---->| | |
| # Explain why this change is being made | |
| # |<---- Try To Limit Each Line to a Maximum Of 72 Characters ---->| | |
| # Provide links or keys to any relevant tickets, articles or other resources | |
| # Example: Github issue #23 |