Welcome to 2023

The community will see a spike in AI-generated material in the coming year. Machine-learning systems can now crank out both code and text that can look convincing. It seems unavoidable that people will use them to generate patches, documentation, mailing-list polemics, forum answers, and more. It could become difficult to tell how much human-generated content a given submission contains.

Perhaps this flood of content will prove beneficial — it could increase our development pace, bring about better documentation, and provide improved help to our users. But that outcome does not seem highly likely in the near future. Instead, we're likely to see code submissions from "developers" who do not understand what they are posting; this code could contain no end of bugs and, potentially, license violations. Cut-and-paste programming has long been a problem throughout this industry. It is far from clear that automating the cutting and pasting is going to improve the situation.

AI-generated text has its own challenges. Our mailing lists and forum sites do not lack for people trying to appear authoritative on subjects they do not really understand; how many more will show up when it is easy to get a machine-learning system to produce plausible text with little effort? Even the most ardent believers in the "last post wins" approach to mailing-list discussions will get tired and shut up eventually; automated systems have no such limits. How long until we have a discussion on, say, init systems that is sustained entirely by bots?

As a community we are going to have to come up with defenses against abuses of this sort. It would be good to start in 2023.

New kernel functionality written in Rust will be proposed for inclusion into the mainline. While the initial support for Rust kernel code landed in the 6.1 kernel, it was far short of what is needed to add any interesting functionality to the kernel. As the support infrastructure is built up in coming releases, though, it will become possible to write a useful module that can be built for a mainline kernel. A number of interesting modules exist now and others are in the works; they just need the kernel to provide the APIs they depend on.

Pushing a module written in Rust for the mainline seems almost certain to spark a significant discussion. While many kernel developers are enthusiastic about the potential of Rust, there are others who are, at best, unconvinced. This latter group has gone quiet in recent times, presumably waiting to see how things play out. After all, as Linus Torvalds has said, the current Rust code is an experiment; if that experiment does not go well, the code can be taken out again.

The merging of a Rust module that people will actually use will be a tipping point, though. Once this code is merged, taking it back out would create the most obvious sort of regression; that, of course, is something that the kernel community goes far out of its way to avoid. So the merging of user-visible functionality written in Rust will mark the point where the Rust code can no longer just be torn out of the kernel; it will be a statement that the experiment has succeeded.

Anybody who is still unsure of the benefit of Rust support in the kernel will have to speak out before that happens, and some of them surely will. Reaching a consensus may take some time, to put it lightly. So, while it seems likely that this discussion will begin in 2023, it is far less likely that any user-visible functionality written in Rust will actually be merged this year.

It will be a make-or-break year for distributed social networking. The events at Twitter have highlighted the hazards of relying on centralized, proprietary platforms, and have put the spotlight on alternatives like Mastodon. This may just be the opportunity that was needed to restore some of the early vision of the net and give us all better control over our communications.

A flood of new users is also going to expose all of the weaknesses, vulnerabilities, and scalability problems in the current solutions, though. Putting up an instance running Mastodon is easy enough; managing that instance in the face of an onslaught of users, not all of whom have good intentions, is rather less so. There is going to have to be a lot of fast hacking and development of social norms if all of this is going to work.

Perhaps the outcome will be a future where we can communicate and collaborate without the need for massive corporations and erratic billionaires as intermediaries. Or maybe the open and distributed alternatives will prove unable to rise to the challenge quickly enough. People have a remarkable ability to shrug and return to abusive relationships, no matter how badly they have been burned in the past. The sad truth is that things may well play out that way this time too.

It will be the year of the immutable distribution. The classic Linux distribution follows in the footsteps of the Unix systems that came before; a suitably privileged user can change any aspect of the system at any time. For a few years now, though, we have seen movement away from that model toward a system that is, at least in part, immutable. Android is arguably the most prominent example of an immutable system; the Android core can only be changed by way of an update and reboot — and the previous version is still present in case the need arises.

Distributions like Fedora's Silverblue have been exploring the immutable space as well. The upcoming SUSE Adaptable Linux Platform (ALP) is based on an immutable core, as is the just-released, Ubuntu-based Vanilla OS system. It seems likely that others will follow, perhaps using the blueprint that was laid out at the 2022 Image-Based Linux Summit. By the end of the year, there may be a number of immutable alternatives available to play with — and to use for real work.

A distribution with an immutable core offers a higher level of security, since a malicious process or inattentive administrator is unable to corrupt the base system. It provides a stable, consistent base on which applications, often in the form of containers, can be run. Immutable systems naturally lend themselves to fallback schemes that can make recovery from a failed update easy to the point of being transparent. It's not surprising that this approach is attracting interest.

An immutable system makes a lot of sense for cloud deployments, where changes after an image is launched are unwelcome at best. They seem to work well for Android devices, where users are unable to (and generally don't want to) change the core system in the first place. It remains to be seen whether immutability will prove attractive on desktop systems where, arguably, a larger number of users want to be able to tinker with things and may not be interested in running a platform that makes life easier for vendors of proprietary software.

Let the year begin

LWN completes its first quarter-century at the end of January; what a long, strange trip it's been since we put out our first weekly edition in 1998. Thanks to you, our subscribers, we're still at it, which is a good thing, since the Linux and free-software communities are far from done. We'll still be here at the end of 2023, when the time will come to look back at these predictions and have a good laugh. In between now and then, we're looking forward to covering our community from within; to say that it will be interesting is the safest prediction of all.