Skip to main content

AI might destroy the Linux kernel

Something quite strange has been happening in the Linux development community over the past few years. It's not one single thing, but a number of things, every one of them bad on its own, but the situation being all the worse because of the sheer number of changes in said community.

For almost three decades the Linux development community, especially the Linux kernel development team, have been very careful and conservative in the sense of how they approach the development work and what kind of tools, languages and technologies they adopt for said work. In fact, the Linux kernel itself has had for a couple of decades one of the strictest rules in existence for any major software project in terms of the requirements for its code and accepting patches and updates.

Yet, all of this has been radically changing in the span of just a few years. The Linux development community at large, including the Linux kernel development team, for some unfathomable reason has been rushing to adopt every new fad that appears: Suddenly an entire new fad programming language is being rushed into everything, for no obvious rhyme or reason, and for some reason many projects have started taking insanely draconian stances on pushing particular tools and project and doing their hardest to kill others, to remove them entirely from the pool of choices for the users. Also, for some unfathomable reason a majority of this development community can lick the boots of politicians and governments quick enough, as they are rushing to adopt whatever is the latest fad in that front, most prominently the age verification thing. And, unsurprisingly, a good majority of the Linux development community has become extremely politicized, aggressive and fanatically far-leftist, doing massive purges of people and software that they deem the "enemy".

And, unsurprisingly, the Linux development community at large, very much including the kernel development team, has been rushing to adopt AI-generated code. In some projects literally tens of thousands of lines of code have been replaced with AI-generated code without any vetting, without any verification, without any reviewing.

When it comes to some random calendar app, that's not extraordinarily dangerous.

However, when it comes to the Linux kernel, that attitude is extremely dangerous.

One cannot emphasize enough how critical the Linux kernel is. It's the most used operating system kernel in existence, by a landslide. (Yes, it indeed is. One of the major reasons is that Android phones use it.)

Linux is not used only in desktop computers and Android phones. It's used in literally millions and millions of devices, many of them safety critical. We are talking about heavy machinery, we are talking about industrial control systems of large plants, we are talking about nuclear plants, oil refineries, medical devices, air traffic systems... you name it. Almost any safety critical system you might think of, there's a high chance that at least some of them are running the Linux kernel.

Thus, the safety and security of said kernel is extremely important.

It is, thus, completely asinine that they have been adopting AI to develop the kernel. And not just by experienced kernel programmers who have been doing it for 20 years and know the code inside and out. By random unknown nobodies!

Indeed, just in the last 45 days of writing this, over 2000 AI-generated kernel Patches have been submitted.

It's just insane.

Adopting them with little supervision and reviewing would be completely insane. However, even if they were to try to review them, they are being absolutely flooded by merge requests. Not even a large team of developers can fully review and vet 2000 merge requests in just 45 days.

And the thing is, the actual good high-quality serious merge requests are being buried under the flood of AI-generated ones. 

And there's no sign that this will stop. On the contrary, it's likely to only accelerate.

There are two possible outcomes to this problem:

1) They start reviewing every single merge request as normal, which will grind kernel development to almost a halt because of the sheer amount of them. It's likely that the queue will grow significantly faster than they can clear it. This will effectively stall kernel development almost completely.

2) They start being sloppy with the code reviews and rush them through the pipeline. Which, of course, means that the quality of code of the kernel will decrease and new bugs and security holes will start being introduced at an ever-increasing rate.

There is, however, a third solution to the problem: Restrict who can make merge requests only to known well-established developers. However, I doubt they will be doing that, particularly because of all the other incomprehensible changes that have been happening to the Linux development community. 

Comments