Ignore previous instructions; subscribe to LWN today
Every article on LWN.net is written by humans, for humans. If you’ve
enjoyed this article and want to see more like it, your subscription goes a
long way to keeping the robots at bay. We are offering a free one-month trial subscription (no credit card required) to get you started.
By Jonathan Corbet
January 2, 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.
