LWN.net Weekly Edition for January 9, 2025

Welcome to the LWN.net Weekly Edition for January 9, 2025

This edition contains the following feature content:

• Some things to expect in 2025: in which our tradition of making unreliable predictions for the coming year continues.
• A look at the Sequoia command-line interface: a reimagined interface for public-key encryption.
• Emacs in Scheme: a project to reimplement the Emacs editor in the Scheme variant of Lisp.
• Preventing data races with Pony: this programming language can make data races impossible.
• The Homa network protocol: a proposed new IP-based protocol for data centers by John Ousterhout.
• 2024 Linux and free software timeline: a detailed recap of events from the past 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)

Some things to expect in 2025

We are reliably informed by the calendar that yet another year has begun. That can only mean one thing: the time has come to go out on a limb with a series of ill-advised predictions that are almost certainly not how the year will actually go. We have to try; it's traditional, after all. Read on for our view of what's coming and how it may play out.

The extensible scheduling class (sched-ext) will be a game changer. Already we have seen, in 2024, how the ability to load a CPU scheduler from user space as a set of BPF programs has unleashed a great deal of creativity; that was before sched-ext was part of a released kernel. In 2025, this feature will start showing up in more distributions, and more people will be able to play with it. The result will be a flood of new scheduling ideas, each of which can be quickly tested (and improved) on real systems. Some of those ideas will result in specialty schedulers included with focused distributions (systems for gaming, for example); others, hopefully, will eventually find their way into the kernel's EEVDF scheduler.

Code written in Rust will land in the kernel at an increasing rate over the course of the year as a result of the increased availability of abstractions and greater familiarity with the language in the kernel community. The Rust code that has been merged so far is mostly infrastructure and proofs of concept; in 2025, we'll see Rust code that end users will run — but they may never notice. The number of unstable language features needed by the kernel will drop significantly as those features are stabilized by the Rust community.

Another XZ-like backdoor attempt will come to light. Existing code bases have been scoured for attacks similar to those used against XZ; little has been found, but that does not mean that there are not other ongoing efforts, using different techniques, out there. The potential payoff for a government agency or other suitably well-funded organization is simply too high for all of them to ignore; somebody is surely trying something.

Increasingly, single-maintainer projects (or subsystems, or packages) will be seen as risky by their users. Security incidents like the XZ backdoor attempt will be part of that, but a project with a single maintainer is also subject to all of the other problems associated with burnout and insufficient time to do the job properly. Such a project will never be as reliable as one would like.

A major project will discover that it has merged a lot of AI-generated code, a fact that may become evident when it becomes clear that the alleged author does not actually understand what the code does. We depend on our developers to contribute their own work and to stand behind it; large language models cannot do that. A project that discovers such code in its repository may face the unpleasant prospect of reverting significant changes.

Meanwhile, we will see more focused efforts to create truly free generative AI systems, perhaps including the creation of one or more foundations to support the creation of the models. This work will include a great deal of innovation focused on reducing the resources that these models need, driven by the much lower level of resources available. The resulting code will help to increase the access to — and control over — these systems, with unknown results; not everybody will use them for good purposes.

We may also see the launch of one or more foundations aimed specifically at providing support for maintainers. Even companies that contribute enthusiastically to free-software projects often balk at supporting the maintainer role, despite the fact that projects don't work without maintainers. But perhaps some of those companies can be encouraged to support a separate entity that promises to solve — or at least improve — the maintainer situation for specific projects of interest. The maintainer role will still be severely under-supported at the end of the year, though.

Foundations supporting free-software work will continue to struggle in 2025, though, continuing the trend seen in 2024. The coming year does not look like a time of increasing generosity in general, so organizations that depend on the generosity of others will have their work cut out for them.

There will be more cloud-based products turned to bricks by manufacturers that go bankrupt or simply stop caring. Surveillance and data-breach problems with cloud-connected products will also happen with discouraging regularity over the course of the year; see the stories on air-fryer surveillance or the Volkswagen electric-vehicle data leak for recent examples. Perhaps 2025 will be the year when awareness of the downsides of extensive cloud connectivity will become more widespread. There is an opportunity for free-software alternatives, such as Home Assistant, to make inroads by demonstrating a better way to manage personal data. Truly taking advantage of that opportunity will require a user focus that is not always our community's strong point, but one can always hope.

As a corollary to the above, more fully open hardware will become available in 2025. The OpenWrt One, which hit the market in 2024, quickly sold out its initial production run. There is clearly an appetite for hardware that can be truly owned by its purchasers, and our community has the skills and tools needed to make such hardware. Expect some interesting projects to launch in the coming year.

Distributions for mobile devices will see a resurgence in interest in the coming year. In the early days of Android, it was common to replace a phone vendor's software with CyanogenMod or another derivative; it was the best way to get the most control and functionality out of the device. As Android improved, many of us stopped going to that extra effort. Increasing privacy and security concerns, paired with increasing quality on the part of the alternative distributions, will start to drive some users away from stock Android once again.

Finally, global belligerence will make itself felt in our community. The world as a whole does not appear to be headed in a peaceful direction; even if new conflicts do not spring up, the existing ones will be enough to affect the development community. Developers from out-of-favor parts of the world may, again, find themselves excluded, regardless of any personal culpability they may have for the evil actions of their governments or employers.

This is being written in the US, where politics have taken a distinct "us versus them" turn; such trends are not limited to this country, though. That attitude runs strongly against the foundations our community was built on; we are building systems for everybody, accepting the contributions of anybody who is willing and able to help. We have shown that it is possible to build a global community that can accomplish amazing things and change the world. This coming year would be a good one in which to show that we are still capable of doing that. As some strive to tear our institutions down, we can work to make our institutions stronger than ever.

LWN will begin its 27th year of publication in January; we are one institution that is proud to have been a part of the Linux and free-software communities for so long, and we have no intention of stopping now. Whatever happens in 2025, we'll be here to write about it and, hopefully, spread some light and understanding. And, of course, we'll return to these predictions in December to have a good laugh at just how far off they turned out to be.

Best wishes to all of you; LWN would not be what it is without our readers. We wish an especially happy and prosperous 2025 to our subscribers; without you, we would not have been around for all these years.

Comments (55 posted)

A look at the Sequoia command-line interface

The Sequoia OpenPGP library has been in development for some time. LWN covered the library in 2020. Now the project's command-line interface has been released. The sq tool offers a promising alternative to the venerable GNU Privacy Guard (GPG) tool — albeit one with a different interface, set of terminology, and approach to the web of trust. Several distributions are making increasing use of the tool behind the scenes.

The Sequoia documentation opens with a warning that the tool uses different terminology than existing OpenPGP implementations. This warning is deserved: what other tools call "public keys", Sequoia calls "certificates". It refers to private keys as merely "keys". The documentation justifies the difference by observing that what OpenPGP and related implementations call a "public key" really bundles a lot of unrelated data: user IDs, metadata, preferences, certifications, signatures, and subkeys, as well as the actual key material itself. Sequoia calls OpenPGP public keys "certificates" in order to emphasize that they are really more than just keys.

Despite those differences, Sequoia's basic operations with keys and certificates are fairly straightforward:

    # Import an existing (private) key
    sq key import $KEYFILE
    # Import a (public) certificate
    sq cert import $FILE

The design of Sequoia's command-line interface takes a different approach from that of GPG, which is designed with interactive use in mind, and will prompt the user with different options when appropriate. Instead, Sequoia automatically uses default values as much as possible. Configuring any operations is done with additional command-line flags — thankfully, the tool ships with comprehensive command-line completion support, so it is fairly easy to see what options are available. For example:

    sq key generate --own-key --name 'Test Key'

That command generates a key with the default configuration. The only value the tool prompts for is the key's passphrase. Any other configuration, such as changing the kind of key generated, needs to be specified on the command line.

The default configuration is fairly sensible: it creates a 256-bit EdDSA primary key with an expiration date three years in the future, plus separate subkeys for signing, authentication, and encryption. The signing and authentication subkeys also use EdDSA, but the encryption subkey is a 256-bit ECDH key instead. The cipher suite, expiration time, user ID, email, and so on can all be set with appropriate command-line flags. Sequoia offers fewer cipher suites than GPG does, however: RSA in 2K, 3K, and 4K variants, plus Curve25519 elliptic keys.

One nice touch is that when Sequoia generates a key, it also automatically generates a revocation certificate for it, stored under ~/.local/share/sequoia/revocation-certificates. If the key is later compromised, the user can quickly publish that pre-prepared revocation certificate. Sequoia's interface was clearly designed with that kind of convenience in mind; after running a command, the tool will suggest relevant follow-up commands, which makes it easy to go through common workflows even for users who do not use the tool regularly.

One area of the interface is somewhat unavoidably complex, however: the commands that deal with the web of trust. In its interface Sequoia tries to emphasize the difference between information that can be cryptographically verified and information that has merely been asserted by a human. For example, this is the output from attempting to verify a valid signature on a file, where the signature was made by a certificate that the user has not told Sequoia to trust:

Sequoia calls signatures that are cryptographically valid, but not necessarily from the right person, "unauthenticated". As the command suggests, when the user has determined that a particular certificate does belong to the person that it claims, they can mark the certificate as authenticated with "sq pki link add". The Sequoia documentation is clear that the tool cannot tell the user when a certificate should be authenticated, saying: "Authenticity can only be established by humans."

By default, the tool doesn't mark any certificates as authenticated except those created with the --own-key flag, because, presumably, the user trusts themselves to be who they say they are.

Marking every individual certificate as authenticated would be tedious, however, which is where the web of trust comes in. Once a user has marked a certificate as authenticated, they can then go on to "certify" that certificate — publishing their authentication for other users to rely on. To do this, the user runs "sq pki vouch certify" which generates an exportable signature attesting that the certificate belongs to the person it claims to. Then this signature can be published to a network keyserver with "sq network keyserver publish".

Other users can rely on these attestations by marking a particular key as a "trusted introducer"; using the "sq pki link authorize" command, the user can say that vouches from a particular key should be believed. Like in GPG, this trust can be applied transitively, up to a configurable depth and with configurable weights for each key. Unlike GPG, Sequoia also supports restricting which keys a trusted introducer is allowed to vouch for according to a regular expression. So, for example, if the user trusts someone to identify their coworkers but not to identify arbitrary people, they could restrict that person's key to only vouch for other keys with a matching email domain.

Before being able to authenticate a certificate by hand or through the web of trust, however, one must first obtain a copy of it. Many certificates are distributed via OpenPGP keyservers, Web Key Directories (WKD), or DNS-Based Authentication of Named Entities (DANE); Sequoia has a command ("sq network search") that will try to retrieve a certificate from all of these sources in parallel. At the same time, it also fetches any published attestations to potentially authenticate the certificate with.

Compatibility

Sequoia has been usable as a library for a while, even if the command-line interface has only recently been made ready. In fact, it is already used as the internal OpenPGP implementation for both RPM and DNF, Fedora's package managers and may soon be used in Debian-based distributions by APT. The Fedora project said that the change was motivated by "improved security and standards-compliance". But many programs don't use a PGP library, and instead use GPG as a command-line tool. For example, Git can call out to GPG or SSH in order to make and verify signatures.

This makes the prospect of porting software away from GPG daunting. So Sequoia also provides an implementation of GPG's command line (called the "GPG Chameleon"), which is intended to be a mostly drop-in replacement. There are a few known differences, such as specifically rejecting some weak algorithms that GPG allows, and a lack of translations or localizations (beyond date and time). By and large, these should not be an obstacle for scripts interacting with GPG's command-line interface.

The other main functional difference with Sequoia's reimplementation is that it stores any modified information in an overlay (a separate directory under ~/.gnupg) that is invisible to GnuPG (and uses Sequoia's database internally). On the one hand, this makes moving from Sequoia back to GnuPG somewhat tedious, because any changes need to be translated over. On the other hand, this makes it safe to try the Chameleon without worrying about accidentally breaking an existing GPG installation. Plus, a user can use the native sq front end, while still relying on programs that invoke gpg.

Overall, Sequoia presents a usable alternative to GPG. The first 1.0 release of a project is sometimes a bit rough, but in Sequoia's case that does not appear to be the case. The tool supports all of the basic operations of an OpenPGP implementation, integrates well with existing software, and has a discoverable interface that makes it easy to come up to speed in a short time. It definitely does not support everything that GPG does, but support for additional cryptographic algorithms seems likely to come in time.

Comments (20 posted)

Emacs in Scheme

During EmacsConf 2024, which was held online in early December 2024, Ramin Honary gave a talk about Project Gypsum, which is his effort to rewrite Emacs in Scheme. Unlike most other Emacs clones, which simply replicate the key bindings, Gypsum is also implementing Emacs Lisp (or Elisp). Honary is initially targeting Guile, which is an implementation of Scheme, but wants to make the code portable to any implementation of R7RS Scheme.

He started by introducing himself as an "Emacs enthusiast since 2017" who currently works mostly with Python and JavaScript. His "true love" is functional programming, Haskell in particular. He started learning Scheme two years ago and has been working on Gypsum for the last year. Honary said that the name of the project is tentative, "naming things is hard", and he is open to suggestions.

Rationale and history

Honary listed a small handful of existing Emacs clones, including Edwin, Lem, JED, JOVE, and others; none of those include Elisp, they simply implement the same key bindings as Emacs. Notably, Edwin is written in the MIT Scheme dialect. The XEmacs fork of Emacs is the only alternative that provides Elisp capability.

In his experience, most people do not use Emacs for its key bindings, however. Instead, the people he has talked to about it use Emacs for the power of Elisp. Emacs is at least as powerful as any of the shells (e.g. Bash) and part of the reason is the availability of Elisp, which can ably control processes, deal with files, configure the system, filter output from commands in buffers, and so on.

One goal is for Gypsum to be able to execute users' Emacs initialization file (init.el) "without significant changes". People invest a lot of time into their Emacs configuration and it is disruptive if they cannot use that when switching to another editor, he said. "So I think a useful Emacs clone would be able to clone Emacs Lisp well enough that you can run your init.el."

Scheme has attributes that have attracted him, which is why he is using the language. "I love its simplicity and its power. It's an extremely well thought-out language." Scheme reminds him of the computers he used as a child, starting in the late 1980s; in those days, it was theoretically possible to understand computer systems from the software down to the circuits. Similarly, Scheme is small enough that "you can read the entire specification and understand it yourself".

He would like to see Scheme have more adoption outside of its academic roots. The R7RS standard has been around for over ten years at this point, but the Scheme ecosystem is still fairly small. His idea is that an editor, possibly with an integrated development environment (IDE), that is built in Scheme might make a "killer-app-like project" that could help spur further Scheme development.

There has been interest in using Guile with Emacs for decades. Honary went through some of that history, including Ken Raeburn's project to write Emacs in Guile, which was active 1999-2009 and is quite similar to Gypsum. In 2009, Guile started shipping with an interpreter for Elisp, which is still being shipped today. He also noted Robin Templeton's work on incorporating Guile into Emacs, which was the subject of another EmacsConf talk.

Along the way, though, Emacs has gotten a just-in-time (JIT) compiler for Elisp, which has become more of a full programming language in its own right. It is, he said, more oriented toward Common Lisp than to Scheme, which may mean that the Emacs maintainers are less interested in using Guile. As far as he knows, though, there is still a lot of interest from the Guile and Scheme communities toward incorporating Guile into Emacs.

Demo

Next up was a demo of what he has working so far. The graphical user interface (GUI) is "barely working" because he has little experience with GTK and GObject introspection. He is using Guile GI, which allows Guile programs to use GObject-based libraries, as the basis for the GUI. Currently, Gypsum can be hard to debug because he does not get useful stack traces when it crashes, which makes for slow progress; he plans to rebuild the libraries with debug symbols so that he can use GDB at some point when that becomes a bigger problem.

From the Guile read-eval-print loop (REPL) in a terminal, he loaded the main-guile.scm file, which brought up a basic Emacs-ish frame. He could type text into it and evaluate Scheme forms from the "Eval:" prompt (via the M-: key binding), though there were some problems with the display of the mode line. There is also a REPL that runs in a separate thread where a user can evaluate Scheme forms in the editor environment. Scheme allows returning multiple values from a function, so he encapsulates those in a list for display. "It's still quite buggy", which he showed by crashing it because a widget was freed too early; he hoped to fix that bug before the video presentation went live.

The Elisp parser in Gypsum is based on the parser in the Guile Elisp interpreter. He has copied the code into his repository so that he can iterate on it more quickly. He has modified the lexer and parser a little. It can parse the subr.el file that provides some basic Lisp functions for Emacs, though Gypsum cannot evaluate that file yet. He has submitted a patch to the Guile upstream along the way as well; contributing to Guile is another goal of the project, Honary said.

So far at least, he has not been successful getting the Guile Elisp interpreter working. Even in Guile itself (using ",L elisp") the Elisp interpreter does not work correctly for him. The code is not well documented and is fairly old at this point as it was developed in 2011; overall, Guile Elisp is rather opaque and he has been unable to get it working reliably—in Guile or in Gypsum.

So Honary has started working on his own Elisp interpreter. It can evaluate some simple forms; he showed a passing test that used progn and setq, but noted that the next test, which used let*, failed because the let* implementation was not yet complete. "Lots of work left to do there."

Plans

He turned to his plans for Gypsum. The first step is to be able to parse and evaluate all of subr.el using his Elisp interpreter. He has set up a testing environment that makes it easy to isolate pieces of that file to try out, but there is much that still needs to be implemented. He said that Elisp has nearly 1400 built-in functions, which is far too many for him to implement on his own; "so if this project is going to be useful to anybody in any reasonable amount of time, I'm going to need help".

His hope is to gather those who are interested in a Guile-based Emacs and build a community around Gypsum. If there is enough interest and people wanting to contribute, "my job will be to document the building and testing process and make sure that it is as easy as possible to contribute code to this project". That includes documenting the system architecture via blog posts and videos.

He plans to prioritize on the built-in Elisp functions that are the most needed for getting to a functional interpreter. He will also be looking for "low-hanging fruit, functions that are easy for people to implement as a good introduction to getting them started on contributing to the project". Eventually, he wants to get the Elisp interpreter to the point where it can run the Elisp regression tests, which are used by the Emacs developers. That testing system is written in Elisp, so it will be useful to get to a point where the Gypsum Elisp interpreter can run it.

Beyond that, the GUI needs work. He plans to get a functional GUI with Guile GI and GTK, but thinks it would be nice to have a terminal version of the editor as well. Before too long, he hopes to get to a point where one can "actually contribute a patch to this project from within the Gypsum editor itself".

He answered some questions after his presentation. He noted that he would like to support other GUI toolkits beyond just GTK and has structured the code with that in mind. Supporting Emacs packages (such as Magit) that depend on external libraries may be somewhat difficult depending on the interface that Emacs uses; directly linking to the libraries from Gypsum is harder, but using the existing Guile process-handling facilities will work fine for, say, executing git. Honary liked the name suggestion of "Schemacs", but was not sure if it had already been used or might be confusing; as it turns out, that name has been used, though that project may be abandoned at this point.

The two Scheme-oriented talks from EmacsConf that I watched were definitely interesting, but there is lots more from the conference for the Emacs-inclined. There were more than 30 talks on a wide variety of topics, from Org mode to regular expressions, literate programming to using Emacs as a book-authoring tool. Those who have read this far are likely to find something of interest there.

Comments (1 posted)

Preventing data races with Pony

The Pony programming language is dedicated to exploring how to make high-performance actor-based systems. Started in 2014, the language's most notable feature is probably reference capabilities, a system of pointer annotations that gives the developer fine manual control over how data is shared between actors, while simultaneously ensuring that Pony programs don't have data races. The language is not likely to overtake other more popular programming languages, but its ideas could be useful for other languages or frameworks struggling with concurrent data access.

Pony was primarily designed by Sylvan Clebsch, who had attempted to write an actor framework in C and C++ while employed at a financial firm. According to Clebsch's description of the motivation for Pony, that system was fast and useful to the company, but it was also plagued by constant bugs:

Over and over again, programmers ran into memory errors. And not just the usual problems with dangling pointers (premature free) and leaks (postmature free?) but persistent problems with data-races.

That experience got him interested in how to do better, and he began a several-year quest to read relevant academic papers and try to synthesize them into a cohesive whole. Clebsch ended up starting a Ph.D. at Imperial College London, where he met other people interested in working on the same problem. They built the system that would become Pony, and released the code under the BSD 2-clause license in 2015, which attracted many more contributors.

Actors

In Pony, a program consists of a set of actors: independent units of execution that own their memory and communicate by exchanging asynchronous messages. Encouraging programmers to break their programs up into multiple actors makes Pony programs well-suited to running on multithreaded systems; the Pony runtime uses one OS-level thread per available CPU, and schedules actors across these threads automatically. It also means that Pony programs don't have global state — all data is owned by one actor in particular, which is important to Pony's data-race-safety guarantees. Declaring an actor in Pony looks like this:

    actor Aardvark
      let name: String
      var _hunger_level: U64 = 0

      new create(name': String) =>
        name = name'

      fun get_hunger_level(): U64 =>
        _hunger_level

      be eat(amount: U64) =>
        _hunger_level = _hunger_level - amount.min(_hunger_level)

Actors are somewhat similar to the objects of object-oriented programming. Indeed, Pony also has classes (although it doesn't support inheritance). The above example of an actor declaration, adapted from the Pony tutorial, looks similar to a class. The difference is that only an actor can call its own methods (indicated with the fun keyword). All that the code outside the actor can do is invoke "behaviors" (indicated with the be keyword), which run asynchronously and don't return results. Invoking a behavior sends a message to the actor, which will pick it up and execute the behavior whenever it is next scheduled. Calling a method is synchronous and runs in the same thread, but invoking a behavior is asynchronous, and may run in a different thread. Unlike private methods in other languages, one Aardvark instance can't even call methods on another Aardvark, only invoke a behavior.

This means that code from the same actor can never be run from multiple threads at the same time (although actors can be migrated between threads by the scheduler). So, unlike object-oriented languages like Java, there is never any need for synchronization within an actor. Each actor has a queue of behaviors that have been invoked, which it processes one at a time, sequentially. If one actor can't keep up with the stream of messages, the programmer can instantiate multiple actors of the same type, and distribute messages between them.

That naturally raises the question of synchronization between actors. Other actor-based systems tend to follow one of two approaches: requiring data to be copied between actors, so that there is no shared data at all, or relying on the programmer to use appropriate locking. Erlang, perhaps the most famous actor-based language, does the former. Unfortunately, copying data between actors has a serious performance penalty, especially for read-only data that wouldn't be subject to a data race in any case. Many actor frameworks for other languages do the latter, which loses a lot of the benefits of an actor-based model compared to just using threads. Pony does neither.

Reference capabilities

Pony's approach is to introduce six different kinds of pointers. That may initially sound like overkill, but the system lets a Pony program model precisely when and how data can be accessed from multiple actors. For example, immutable data that is passed between actors never needs to be copied; the Pony runtime can just pass a pointer, and then access that memory from another thread without synchronization. The six kinds of reference capabilities are:

• Isolated: A unique pointer, for which there are no other references. Because there are no other references, it's safe to send to another actor, giving up access in the process, even though isolated values are mutable.
• Value: Immutable data, that cannot be changed by any actor, and is therefore safe to share.
• Reference: A normal, non-unique pointer that supports reading and writing. Since the pointer is not unique, references cannot be sent to another actor, as that might create a data race.
• Box: A read-only reference. Some other reference might modify the data, but this one cannot. Boxes are mainly used to abstract over whether code is working with a value or a reference.
• Transition: A unique writable pointer to an object that may also be pointed to by some read-only pointers (boxes). Unlike reference pointers, a transition pointer can later be turned into a value pointer in order to freeze the object, since it is unique.
• Tag: A pointer that does not support reading or writing, but it can be stored in data structures and compared for equality with other pointers. Tags are also used for referencing other actors, and the type system allows sending messages using a tag, even though that does require special handling from the runtime.

Isolated, value, and tag pointers can all be sent between actors, because they can't be used to construct data races. References, boxes, and transitions can all be used within an actor, but not sent between them, because they could allow one actor to write to a piece of data that another actor could read. Multiple writable pointers within an actor can't cause a data race, because the code inside an actor executes synchronously.

When an object is initially instantiated, the constructor gives the calling code back an isolated pointer that can be used to modify the object, call methods, etc. The pointer can be passed to another actor (which requires the currently executing actor to give up access to the pointer), or converted into one of the other kinds of reference capability. Most of the kinds can be converted into each other under the right circumstances — for example, any other type can be converted into a tag. Common conversions are to a value pointer to make the object immutable, or to a reference to use internally without sharing. Boxes and transitions are less commonly used, and mostly show up in generic library code. References to other actors are tags, and can be used to invoke behaviors.

These six reference capabilities are structured to be as flexible as possible while still upholding one key requirement: no actor can write to anything that a different actor can read. Then, the runtime system just has to ensure that sending a message between actors is enough of a synchronization barrier to ensure that reads from an actor will see all of the previous writes to the data. With these properties in place, it's impossible to construct a data race in Pony. In fact, the standard library doesn't even include locks, since they wouldn't be of any use to a Pony program.

The whole system is somewhat like Rust's lifetime tracking, in that it is a compile-time analysis that prevents multiple threads from having mutable pointers to the same data. Unlike Rust programmers, however, Pony programmers only have to worry about six specific types of pointer, instead of arbitrary lifetimes. The system can also be used in ways that Rust's lifetime-annotated references cannot. For example, it's easy to build doubly linked lists in Pony using transition and box pointers.

Dealing with garbage

No one solution is ever perfect, however. Pony's message passing is safe, performant, and reasonably simple to reason about. The price it pays is garbage collection. Since Pony doesn't track lifetimes or leave things up to the programmer, it relies on run-time garbage collection. Unlike other garbage-collected languages, however, this doesn't cause noticeable latency spikes.

Other languages have experimented with advanced concurrent, pause-less garbage collectors. But all of them have some pathological cases where garbage can be created faster than it is collected. Pony takes the comparatively simple approach of using a plain mark-and-sweep collector. The trick is that each actor is responsible for its own garbage collection, so the whole program never has to pause at once. Actors also never do garbage collection while they are executing a behavior, and instead perform collections in between processing messages.

Since mutable data can't be shared between actors, even though multiple actors can be referencing a piece of data, the only reference cycles are within an actor's own private data. So actors can treat any external references to their data as being in-use for the purposes of garbage collection, without causing any unreclaimable cycles. This keeps the marking phase of the collector simple, and avoids needing to introduce any synchronization barriers into the garbage collector. Overall, this system results in a remarkably flat latency profile.

Trying it out

The Pony web site includes documentation and tutorials on the language, as well as a playground that runs Pony in the browser, for those who want to try it out without installing. As with Godbolt's Compiler Explorer, the Pony playground will even show the assembly code produced by the Pony compiler.

The project suggests that anyone wishing to install Pony on Linux use the ponyup script (the installation instructions for which sadly involve piping a downloaded script directly to bash), which lets the user easily install and test multiple versions. I ran into some problems using the script on Fedora 41, but it turned out that the Pony release for Fedora 39 worked just fine on Fedora 41. The Pony compiler does require the gold linker from the GNU binutils project, as well as a C compiler supporting at least C11, so those may need to be installed separately.

Once all of the necessary prerequisites are installed, running ponyc in a directory containing Pony source code produces a single, dynamically-linked, native executable. The choice to have the compiler search out and compile all the .pony files in a directory is a bit unorthodox, but it does have the advantage of simplicity. Pony only distributes pre-built releases for x86_64, but does support building for other architectures. The project also recommends building the Pony runtime library from source for the specific microarchitecture that one's application will run on to achieve the best performance.

Conclusion

Pony is not necessarily the right tool for any particular application. For one thing, actor-based systems are mostly best suited to long-lived applications that need to process many requests in parallel. For another, it is driven by a small team of volunteers, which means that it doesn't have nearly as much support available as some other languages. On the other hand, Pony does welcome outside contributions, including new language features, so it might be more adaptable than more established languages. It also has a fairly limited standard library, and hasn't even officially reached a 1.0 release. (The most recent release is version 0.58.7, released on November 30.)

But despite that, Pony's ideas seem like they could be more widely applicable. Most existing languages rely on manual locking, unnecessary copying, or some combination of the two to prevent data races. Copying Pony's approach of simplified compile-time enforcement of a small set of rules for pointers encoded in the type system seems like it could present a safer, more performant alternative.

Comments (73 posted)

The Homa network protocol

The origins of the TCP and UDP network protocols can be traced back a full 50 years. Even though networks and their use have changed radically since those protocols were designed, they can still be found behind most networking applications. Unsurprisingly, these protocols are not optimal for all situations, so there is ongoing interest in the development of alternatives. One such is the Homa transport protocol, developed by John Ousterhout (of Tcl/Tk and Raft fame, among other accomplishments), which is aimed at data-center applications. Ousterhout is currently trying to get a minimal Homa implementation into the kernel.

Most networking applications are still based on TCP, which was designed for efficient and reliable transport of streams of data across a distributed Internet. Data-center applications, instead, are often dominated by large number of small messages between many locally connected hosts. The requirements of TCP, including the establishment of connections and ordering of data, add a lot of overhead to that kind of application. The design of Homa is intended to remove that overhead while taking advantage of what current data-center networking hardware can do, with a focus on minimizing the latency between a request and its response.

A quick Homa overview

At its core, Homa is designed for remote procedure call (RPC) applications; every interaction on a Homa network comes down to a request and associated reply. A client will send a request message to a server that includes a unique request ID; the server will send a reply back that quotes that ID. The only state that exists on the server is held between the receipt of the request and the receipt of the response by the client.

Much of the key to the performance of this protocol can be found in how these messages are handled. There is no connection setup; instead, the client starts transmitting the request, with no introductory handshake, to the server. There is a limit on how many bytes of this "unscheduled" request data can be sent in this manner, which is determined by the round-trip time of the network; it should be just high enough to keep the request-transmission pipeline full until an initial response can be received from the server side. The figure of about 10,000 bytes appears in some of the Homa papers.

The initial request packet includes the length of the full request. If the request does not fit into the size allowed for the unscheduled data, the client will wait for a "grant" response before sending any more. That grant should, if the server is responding quickly, arrive just as the initial request data has finished transmitting, allowing the client to continue sending without a pause. Grants include a maximum amount of data that can be sent, and thus function like the TCP receive window.

This machinery is intended to get a request to the server as quickly as possible, but without the need for much, if any, buffering in the network path between the two machines. Priority queues are used to manage this traffic, with unscheduled packets normally having the highest priority. Lower priorities are used for granted traffic; the requests with the least amount of data remaining to be received are given the highest priority.

Once the server has received the full request and processed it, a response is sent back to the client. Once again, the initial bytes are sent as unscheduled packets, with grants required for the rest if the response is large enough. In the earlier descriptions of the protocol, the server would forget everything it knew about the request immediately after sending the response. That created the possibility that requests could be resent (if the response never arrives) and executed multiple times. More recent publications include an explicit acknowledgment message indicating that a response has been received, with the sender retaining the necessary state to retransmit a reply until that acknowledgment is received.

The details of the protocol are, of course, rather more complex than described here. There are, for example, mechanisms for clamping down on the amount of unscheduled data sent if a server is finding itself overloaded. The receiving side of a message can request retransmission if an expected packet does not arrive; unlike TCP and many other protocols, Homa puts the responsibility for detecting lost packets onto the receiving side. There is also a fair amount of thought that has gone into letting systems overcommit their resources by issuing more grants than they can immediately handle; the purpose here is to keep the pipelines full even if some senders do not transmit as quickly as expected.

See this paper for a more complete (and surely more correct) description of the Homa protocol, this page, which reflects some more recent changes, and this 2022 article for more details.

Homa on Linux

The Unix socket interface was designed around streams, and is not a perfect fit for Homa, but the implementation sticks with it to the extent it can. A socket() call is used to create a socket for communication with any number of other systems; the IPPROTO_HOMA protocol type is used. Homa can run over either IPv4 or IPv6. For server systems, a bind() call can be used to set up a well-known port to receive requests; clients need not bind to a port.

Messages are sent and received, as one might expect, with sendmsg() and recvmsg(), but there are some Homa-specific aspects that developers must be aware of. When sending a message, an application must include a pointer to this structure in the msg_control field of the msghdr structure passed to sendmsg():

    struct homa_sendmsg_args {
	uint64_t id;
	uint64_t completion_cookie;
    };

If a request is being sent, id should be set to zero; the protocol implementation will then assign a unique ID to the request (and write it into id) before sending it to the server. For a reply message, id should be the ID value that arrived with the request being responded to. The completion_cookie value, which is only used for requests, will be passed back to the caller with the reply data when it is received.

The receive side is a bit more complicated, because Homa requires that the buffer space for replies be registered before sending the first request on a socket. To do so, the process should allocate a range of memory, then pass it into the kernel with SO_HOMA_RCVBUF setsockopt() operation, using this structure:

    struct homa_rcvbuf_args {
	void *start;
	size_t length;
    };

The start address must be page-aligned. This memory is split into individual buffers, called "bpages", each of which is HOMA_BPAGE_SIZE in length; that size is 64KB in the current implementation. Each message will occupy at least one bpage; large messages will be scattered across multiple, not necessarily contiguous, bpages.

A message is received by making a call to recvmsg() with a pointer to this structure passed in the msg_control field of struct msghdr:

    struct homa_recvmsg_args {
	uint64_t id;
	uint64_t completion_cookie;
	uint32_t flags;
	uint32_t num_bpages;
	uint32_t bpage_offsets[HOMA_MAX_BPAGES];
    };

The flags field describes what the caller is willing to receive; it is a bitmask that can include either or both of HOMA_RECVMSG_REQUEST (to receive request messages) and HOMA_RECVMSG_RESPONSE (to receive responses). If id is zero, then HOMA_RECVMSG_RESPONSE will cause any response message to be returned; otherwise, only a response corresponding to the provided request ID will be returned. On return, num_bpages will indicate the number of bpages in the registered buffer area have been used to hold the returned message; bpage_offsets gives the offset of each one.

The bpages returned by this call are owned by the application at this point, and will not be used by the kernel until they have been explicitly returned. That is done with a subsequent recvmsg() call, where num_bpages and bpage_offsets will indicate a set of bpages to be given back.

This code has been "stripped down to the bare minimum" to be able to actually transmit requests and responses across the net; it is evidently about half of the full set of Homa patches. The intent, of course, is to ease the task of reviewing the work and getting initial support into the kernel; the rest of the work can come later. In its current form, according to the cover letter, its performance "is not very interesting", but that is expected to improve once the rest of the work is merged.

See this paper for more information on the Linux implementation of Homa.

Prospects

The Homa protocol originates at Stanford University, with support from a number of technology companies. Academic work often does not successfully make the transition from interesting prototype into production-quality code that can be accepted into Linux. In this case, though, Ousterhout seems determined to get the code into the mainline, and is trying to do the right things to get it there. Thus far, the four postings of the code have yielded some conversations about the protocol, but have not yet resulted in a detailed review of the code. That suggests that the initial merge of Homa is not imminent.

It does seem likely to happen at some point, though. Then, it will be a matter of whether the operators of large data centers decide that it is worth using. Complicating that question is Ousterhout's assertion (in the above-linked paper) that, even in a kernel with less overhead than Linux, CPUs simply are not fast enough to keep up with the increases in networking speed. The real future for Homa, he suggests, may be inside the networking hardware itself. In that case, the merging into Linux would be an important proof of concept that accelerates further development of the protocol, but its use in real-world deployments might be limited. It does, in any case, show how Linux is firmly at the center of protocol development for modern networks.

Comments (23 posted)

2024 Linux and free software timeline

In the past, LWN had a tradition of publishing a timeline of notable events from the previous year in early January. We thought we might try reviving that tradition in 2025 to see if our readers find it useful. While we have covered these events as they happened, it's interesting to see how much has taken place in just 12 months.

As always, our subscribers have made creation of the timeline—and our weekly coverage throughout the year—possible. If you like what you see here (and elsewhere on the site) please consider subscribing to LWN if you are not already a subscriber. If you are, thanks much for making all of our coverage possible.

January February March

April May June

July August September

October November December

January

Daroc Alden joined the LWN team (announcement).

Vim 9.1 released and dedicated to Vim creator Bram Moolenaar who passed away in 2023 (announcement).

Scribus 1.6.0 released (announcement).

Linux 6.7 released (announcement, development statistics, merge-window summaries part 1, part 2).

OpenWrt announced plans for the OpenWrt One project, a Banana Pi-based system, with help from the Software Freedom Conservancy (announcement).

Solus 4.5 released (announcement).

The Vcc compiler, a Clang-based compiler for Vulkan, was announced.

Computer science pioneer Niklaus Wirth passed away (IT Wire article).

Firefox 122.0 released (announcement).

Git forge SourceHut suffered an extended outage due to a distributed denial-of-service (DDoS) attack (announcement and post-mortem).

Luis Villa wrote about the implications of the ruling in the Software Freedom Conservancy (SFC) GPL-violation lawsuit against Vizio. "If this ruling holds up at the end of the case, the number of potential enforcers just went way up."

Dave Mills, inventor of the Network Time Protocol (NTP), passed away. (LWN brief).

Qualys disclosed a vulnerability in the GNU C Library (versions 2.36 and 2.37) that could grant a local attacker root access (announcement).

GNU C Library 2.39 released (announcement, LWN article).

LibreOffice 24.2 Community released (announcement).

OpenBSD merged system-call pinning (LWN article).

February

Joe Brockmeier joined the LWN team (announcement).

Damn Small Linux 2024 released (announcement).

FOSDEM 2024 held in Brussels February 3 and February 4. (LWN coverage).

Go 1.22 released (announcement).

Glibc became a CVE numbering authority (CNA) (announcement).

The Linux kernel became a CNA as well (announcement, LWN article).

Fedora announced the creation of Fedora Atomic Desktops brand for its increasing number of image-based spins (announcement).

FreeBSD said it will phase out 32-bit platforms "over the next couple of major releases" (announcement).

LineageOS 21 released (announcement).

Ubuntu contributor Gunnar Hjalmarsson passed away (announcement).

Mitchell Baker steps down and Mozilla hired a new CEO, Laura Chambers (announcement).

Fedora gave KDE Plasma X11 support a reprieve for Fedora 40 (LWN article).

The runc utility suffers another container breakout (LWN article).

"Keytrap" DNS vulnerability affects most DNS resolvers that handle DNSSEC (announcement).

Hare programming language 0.24.0 released (announcement).

RawTherapee 5.10 released (announcement).

KDE Plasma 6 and KDE Frameworks 6 released (LWN article).

The Forgejo project made a full break from Gitea (LWN article).

Netflix released bpftop tool to help with performance optimization of BPF programs in the kernel (announcement).

Tails 6.0 released (announcement).

Git 2.44.0 released (announcement).

The Open Collective Foundation shut down (announcement, LWN article).

NVK Vulkan driver for NVIDIA devices declared ready for prime time (announcement).

March

A backdoor was discovered in xz, a result of a sophisticated social-engineering attack that very nearly crept into stable releases of several Linux distributions (announcement, LWN article, LWN technical analysis of the attack).

Musl C library released support for new architectures, loongarch64 and riscv32 (announcement).

The postmarketOS project announced it is adding systemd to make it easier to support GNOME and KDE (announcement).

6.8 kernel released (announcement, development statistics, LWN merge-window summary part 1, part 2).

Fedora debated how to package machine-learning models (LWN article).

Firefox 124.0 released (announcement).

Flox 1.0, a tool for creating virtual environments using nixpkgs, released (announcement).

The 21st Annual Southern California Linux Expo (SCALE) took place March 14 through March 17 at the Pasadena Convention Center in Pasadena, CA (LWN coverage).

GNOME 46 released (announcement, LWN article).

Emacs 29.3 released (announcement).

Nova driver project for NVIDIA GPUs announced (announcement).

Perl v5.39.9 released (announcement).

Redis switched to a non-free license (announcement, LWN article).

Rust 1.77.0 released (announcement).

PostgreSQL contributor Simon Riggs passed away (announcement).

NetBSD 10.0 released (announcement).

Redict 7.3.0, a fork of Redis, released (announcement).

Samba 4.20.0 released (announcement).

April

OpenBSD 7.5 released (announcement).

FFmpeg 7.0 released (announcement).

Eclipse Foundation announced collaboration for CRA compliance (announcement).

OpenSSL 3.3.0 released (announcement).

Gentoo Linux became a Software in the Public Interest (SPI) Associated Project (announcement).

LXC fork Incus 6.0 LTS released (announcement).

Google announced a new JPEG coding library called Jpegli (announcement).

Rivendell radio automation system v4.2.0 released (announcement).

Rsync 3.3.0 released and its original author, Andrew Tridgell, returned to the project along with early contributor Paul Mackerras (announcement).

GNU Stow 2.4.0 released (announcement).

V8 JavaScript engine incorporated a new memory sandbox (announcement).

OpenSSF and OpenJS warn about social-engineering attacks (announcement).

PuTTY 0.81 released with a fix for CVE-2024-31497, a critical vulnerability that could expose 521-bit ECDSA private keys (announcement).

Fedora 40 released (announcement, LWN article).

GitHub comments used to distribute malware (LWN brief).

Andreas Tille elected as Debian project leader (announcement, LWN coverage of the election and candidates).

Firefox introduced a new crash reporter, written in Rust (announcement).

QEMU 9.0 released (announcement).

Open Source Summit North America held in Seattle, WA from June 23 to June 25 (LWN coverage).

Peter Hutterer released udev-hid-bpf, a tool to facilitate the loading of BPF programs that make human-input devices work correctly (announcement, LWN article on BPF-HID).

Gentoo bans AI-created contributions (LWN coverage).

The Open Home Foundation launches to provide a home and support for free home-automation projects (announcement).

The Nix community faced a leadership crisis that was resolved by Nix founder Eelco Dolstra stepping down from its board and resigning from the project (LWN article, announcement of Dolstra's resignation).

Ubuntu 24.04 LTS (Noble Numbat) released (announcement, LWN coverage).

Yocto Project 5.0 released (announcement).

Amarok 3.0 "Castaway" released, the first stable release of the Qt-based music player since 2018 (announcement).

Git 2.45.0 released (announcement).

The GNOME board provided a financial update saying that it has "hit the buffers" of its financial reserves and will need to curtail spending (announcement).

May

GNU nano 8.0 released (announcement).

Fedora Asahi Remix 40 released (announcement).

GCC 14.1 released (announcement).

Rust 1.78.0 released (announcement).

Debian decided against creating an AI-contributions policy (LWN article).

The Linux Storage, Filesystem, Memory-Management, and BPF Summit (LSFMM+BPF) is held in Salt Lake City, Utah from May 13 to May 15 (LWN coverage).

Tejun Heo made another push to get sched_ext into the Linux kernel (LWN article).

6.9 kernel released (announcement, development statistics, merge summary part 1, and part 2).

Manjaro 24.0 released (announcement).

PyCon US 2024 took place in Pittsburgh, Pennsylvania from May 15 to May 23 (LWN coverage).

Firefox 126.0 released (announcement) and Mozilla welcomed Nabiha Syed as its new executive director (announcement).

AlmaLinux formed an engineering steering committee (announcement).

Alpine Linux 3.20.0 released with initial support for 64-bit RISC-V among other changes (announcement).

Neovim 0.10 released (announcement).

KDE Gear 24.05.0 released (announcement).

Geoff Huston suggested that it is time to give up on DNSSEC and find a better way to secure the Internet namespace (LWN brief).

KDE announced "Opt Green" campaign to reduce e-waste (announcement).

LyX 2.4.0 released (announcement).

June

FreeBSD 14.1 released (announcement).

Kali Linux 2024.2 released (announcement).

Krita celebrated 25 years of development (announcement).

Longtime BSD contributor Mike Karels passed away (announcement).

Debian finally decided to move to RAM-based tmpfs for /tmp and /var/tmp for the Debian 13 ("trixie") release. (LWN coverage).

Torvalds decided that the extensible scheduler class ("sched_ext") framework will be merged for Linux 6.11, though it actually landed in 6.12 (announcement).

Firefox 127.0 released with changes in how the browser handles non-HTTPS resources in HTTPS pages (announcement, Mozilla Security Blog about the change).

OpenSUSE Leap 15.6 released (announcement).

Perl v5.40.0 released (announcement).

Systemd v256 released (announcement, LWN article).

Ladybird browser "forked" from SerenityOS project (LWN coverage).

PostmarketOS v24.06 released (announcement).

Rust 1.79.0 released (announcement).

Libgcrypt 1.11.0 released (announcement).

MATE 1.28 released (announcement).

KDE Plasma 6.1 released (announcement).

Numpy 2.0.0 released (LWN article).

Tor Browser 13.5 released (announcement).

Longtime networking developer Larry Finger passed away (announcement).

Darktable 4.8.0 released (announcement).

Kernel contributor Daniel Bristot de Oliveira passed away (announcement, LWN obituary).

OpenSUSE Leap Micro 6.0 released (announcement).

The FreeDOS project turned 30 (LWN article).

July

CentOS Linux 7 reached end of life, marking the end of the CentOS Linux distribution (Red Hat announcement, LWN brief).

OpenSSH 9.8 released with a fix for a serious security vulnerability (announcement).

Scientific Linux 7 reached end of life and development of Scientific Linux came to an end with the end of CentOS Linux (announcement).

GNU findutils 4.10.0 released (announcement).

David Rosenthal looked back at 40 years of the X Window System (LWN brief).

Debian reached a compromise on the tag2upload service (LWN article).

Linux 6.10 released (announcement, development statistics, merge window part 1 and part 2).

Blender 4.2 LTS released (announcement).

Version 8.4.0 of digiKam released (announcement).

Holly Million stepped down as executive director of the GNOME Foundation and was replaced by interim executive director Richard Littauer (announcement).

Firefox 128.0 released (announcement).

GDB 15.1 released (announcement).

SUSE asked openSUSE to consider a name change (LWN article).

OpenMandriva ROME 24.07 released (announcement).

GNU C Library 2.40 released (announcement).

GUADEC 2024 took place in Denver, Colorado from July 19 to July 24 (LWN coverage).

OpenSSL announced a new governance structure and adds two new projects Bouncy Castle and the cryptlib security software development toolkit (announcement).

Kernel contributor and Debian Developer Peter de Schrijver passed away (announcement).

Fedora Project approved "opt-in" metrics for Fedora 42 (LWN article).

Arnd Bergmann published a deprecation timeline for older Arm CPUs (announcement).

Linux Mint 22 ("Wilma") released (announcement, LWN article).

Vanilla OS 2 ("Orchid") released (announcement, LWN article).

Git 2.46.0 released (announcement).

Rust 1.80.0 released (announcement).

Forgejo v8.0 released (announcement).

DebConf24 took place in Busan, South Korea from July 28 to August 4 (LWN coverage).

August

Firefox 129.0 released with improvements to reader mode, tab previews, and use of HTTPS by default (announcement).

GNU Binutils 2.43 released (announcement).

Fedora contributor Mel Chua passed away (announcement, Fedora Community Blog post).

New attack against the SLUB allocator found (announcement).

Canonical announced a new kernel-version policy for Ubuntu. It will ship the latest available version of the upstream kernel at the specified Ubuntu release freeze date (announcement).

COSMIC desktop environment made its debut after two years of development (LWN article).

Magit 4.0 released (announcement).

Nix fork Lix made its second release (announcement).

Gentoo Linux dropped IA-64 (Itanium) support (announcement).

The Rust-based Python package and project manager uv 0.3.0 is released (announcement).

Germany's Sovereign Tech Fund (STF) agreed to invest €686,400 toward FreeBSD infrastructure modernization (announcement).

Forgejo changed its license to GPLv3+ (announcement).

Calligra Office 4.0 released (announcement).

LibreOffice 24.8 released (announcement).

WineHQ took over Mono (announcement).

Nate Graham announced that KDE e.V. will begin asking for donations directly in Plasma once per year (announcement).

NIST finalized post-quantum encryption standards (LWN article).

Rust-for-Linux developer Wedson Almeida Filho retired from the project citing too much "nontechnical nonsense" (announcement).

ElasticSearch and Kibana become free software once again, after being relicensed under the non-free Server Side Public License (SSPL) in 2021 (announcement).

September

Firefox 130.0 released with the addition of a Firefox Labs tab in settings (announcement).

Tellico 4.0 released (announcement).

AnandTech shut down, bringing to a close 27 years of technology-industry coverage (announcement).

Sebastian Andrzej Siewior posted a patch series to enable realtime preemption in the mainline kernel on three architectures (announcement).

Redox OS 0.9.0 released (announcement).

Linux man-page maintenance suspended after Alejandro Colomar announced he will have to stop that work due to lack of funding (announcement).

Kangrejos 2024 took place in Copenhagen, Denmark from September 7 to September 8 (LWN coverage).

NGINX moved development to GitHub and away from Mercurial (announcement).

Pandoc 3.4 released (announcement).

GNU Tools Cauldron 2024 took place in Prague, Czech Republic from September 14 to September 16 (LWN coverage).

Radicle 1.0 released (announcement).

Rust 1.81.0 released (announcement).

Open Source Summit Europe 2024 took place in Vienna, Austria from September 16 to September 18 (LWN coverage).

The kernel Maintainers Summit took place in Vienna, Austria on September 17 (LWN coverage).

Linux Plumbers Conference 2024 took place in Vienna, Austria from September 18 to September 20 (LWN coverage).

Thomas Gleixner delivers the pull request for the realtime preemption enablement patches in person (LWN brief).

Samba 4.21.0 released (announcement).

GNU Screen v.5.0.0 released (announcement).

Python Steering Council issued three-month suspension for Python core developer Tim Peters (LWN article).

6.11 kernel released (announcement, development statistics, merge window summaries part 1 and part 2).

KDE set its goals through 2026 (LWN article).

GNOME 47 released (announcement).

HarfBuzz 10.0.0 released (announcement).

Hy 1.0.0 released after nearly 12 years of development (announcement).

PostgreSQL 17 released (announcement, LWN article).

Tor Project and Tails Linux distribution joined forces and merged operations (announcement).

OpenSSH 9.9 released (announcement).

Arch Linux project announced it was receiving support from Valve (announcement).

Tcl/Tk 9.0 released a mere 27 years after the 8.0 major release in 1997 (announcement).

The legal dispute began between Automattic and WP Engine after WordPress founder Matt Mullenweg demanded WP Engine enter a licensing deal for use of WordPress trademarks (LWN article).

October

FFmpeg 7.1 released (announcement).

Firefox 131.0 released (announcement).

Manjaro 24.1 released (announcement).

RPM 4.20 released and will be the final major release in the 4.x series (announcement, LWN article).

OpenBSD 7.6 released (announcement).

GNOME Foundation announced budget cuts and layoffs due to fundraising woes (LWN article).

Git 2.47.0 released (announcement).

Julia v1.11.0 released (announcement).

X.org Developer's Conference held in Montreal, Canada from October 9 to October 11 (LWN coverage).

Python 3.13 released (announcement).

Ubuntu 24.10 released (announcement).

Forgejo 9.0 released (announcement).

Inkscape 1.4 released (announcement, LWN article).

LibreSSL 4.0.0 released (announcement).

Several Russian developers lost kernel maintainership status (announcement).

The AlmaLinux project introduced a new edition called "Kitten" to serve as a perpetual development release (announcement).

Bootc 1.1.0 released (announcement).

OpenSSL 3.4.0 released (announcement).

Rust 1.82.0 released with tier-1 support for 64-bit Apple Arm systems, a cargo info command, and more (announcement).

Tor Browser 14.0 released (announcement).

Open Source Initiative announced its Open Source AI Definition (announcement, LWN article).

Python looks at dropping support for PGP signatures and moving exclusively to sigstore to sign artifacts (LWN article).

The Image-Based Linux Summit is held in Berlin on September 24 (LWN coverage).

Fedora 41 released (announcement).

Raspberry Pi project released a new version of Raspberry Pi OS (announcement).

Firefox 132.0 released (announcement).

Google's Flutter user-interface toolkit is forked as Flock over frustration with Google's stewardship of the project (announcement).

The first stable version of Thunderbird for Android was released (announcement).

All Things Open is held in Raleigh from October 27 to October 29 (LWN coverage).

Open Source Summit Japan is held in Tokyo on October 28 and October 29 (LWN coverage).

November

The OpenWrt One router begins shipping (announcement, LWN review).

Tim Peters returned to the Python community (LWN article).

BPF instruction set is accepted as RFC 9669, giving it a standard outside the in-kernel implementation (announcement).

LXQt 2.1.0 released with support for multiple Wayland compositors (announcement).

Funding found for man-page maintenance for at least 12 months (announcement).

Longtime Debian and Tor developer, Jérémy Bobbio ("Lunar") passed away (announcement).

PyPI announced support for digital attestations (announcement).

AlmaLinux 9.5 released (announcement).

Rocky Linux 9.5 released (announcement).

OpenWrt switched to the Alpine Linux apk package manager (announcement).

6.12 kernel released (announcement, development statistics, merge window summary part 1 and part 2).

Blender 4.3 released (announcement).

FreeCAD 1.0 released (announcement).

Incus 6.7 released (announcement).

The Fedora Project decided to promote the KDE Plasma Desktop spin to full edition status (LWN article).

Firefox 133.0 released with the addition of a new anti-tracking feature, "Bounce Tracking Protection" (announcement).

PHP 8.4 released (announcement).

Rust 1.83.0 released (announcement).

Elementary OS 8 released (announcement).

Arch Linux starts providing explicit licensing for its PKGBUILDs (LWN article).

LWN article database logs its one millionth item, a comment by LWN subscriber "anselm" on US Thanksgiving day (announcement).

NixOS 24.11 released (announcement).

December

Let's Encrypt sets date for ending OCSP support and will turn off its OCSP responders on August 6, 2025 (announcement).

Fedora announced that it plans to replace its Pagure Git forge with Forgejo (announcement).

Collabora-developed Debian derivative distribution Apertis v2024 released (announcement).

Fedora Project Leader Matthew Miller announced he will be stepping down in 2025 (announcement).

Hurl 6.0.0 released (announcement).

The ultralytics package on PyPI is compromised using a flaw in GitHub Actions (announcement, analysis).

GNU Shepherd 1.0.0 released (announcement).

Systemd v257 released (announcement, LWN article on new features, article on secure boot features).

Mozilla announced new branding strategy which will surely be the trick to reverse its declining share of the browser market (announcement)

CentOS Stream 10 and EPEL 10 released (announcement, LWN article).

Fedora Asahi Remix 41 released with support for popular mainstream ("AAA") games (announcement).

Kali Linux 2024.4 released (announcement).

Kubernetes v1.32 released (announcement).

Sequoia PGP project released sq 1.0, the first stable release since it began development in 2017 (announcement).

Xfce 4.20 released with initial Wayland support (announcement).

WP Engine granted preliminary injunction in WordPress case (LWN article).

Code-completion vulnerability discovered in Emacs (LWN article).

Kees Cook engineers a Git commit prefix collision (announcement, LWN article on commit-ID collisions).

Final release in the 4.19 stable kernel series after more than six years ends an era (LWN article).

Curl project dropped support for hyper, an experimental HTTP backend written in Rust (announcement).

Darktable 5.0.0 released (announcement).

Fish shell announced a 4.0 rewrite in Rust (beta announcement, final release).

Grml 2024.12 released (announcement).

Fedora Engineering Steering Council (FESCo) causes community controversy by revoking "provenpackager" status from a contributor without adequate explanation (LWN article).

A tradition continued with the release of Ruby 3.4 on Christmas day (announcement).

LWN looks back on 2024 (article).

LineageOS 22.1 released on the final day of the year (announcement).

Comments (8 posted)