AI is creeping into the Linux kernel

1

AI is creeping into the Linux kernel - and official policy is needed ASAP
AI tools can help Linux maintainers, but they can also cause chaos. Here's what needs to be addressed - fast - before things get out of control.

3 Likes
2

So, "official policy" fits only the major distros? Red Hat, Ubuntu, SuSe, etc? Given that one of the core precepts of Linux is its open-source nature, and that anyone is free to create their own, does this mean a(nother?) division in the Linux ranks?

2 Likes
3

My stance will always be:

  • Nyet! to AI for repository maintenance

  • Absolutely! for "human-programmed rule-based" Expert-Systems

Basically, "Makefiles" are the embodiment of the latter of the two.

Why should we risk allowing systems evolve their own rules without human-vetting of those rules before they are applied, not knowing the extent of the "guard-rails" that have been applied or ignored?

There also needs to be a concensus from the Community at large, as to what constitute a miminum-required-set of such "guard-rails".

1 Like
4

I think that Satya Nadella's boasting about AI should be taken with a grain of salt. This is a company that is trying to ride investor enthusiasm for AI to raise capital: of course they're going to overstate its impact. Maybe I'm wrong, but I suspect much of the impactful code and development at MS is being handled by engineers and traditional tools (language servers, profilers, debuggers, etc).

And Sasha Levin's comparison between LLMs and compilers elides the fundamental differences between the two.

The article got off to a bad start for me because it presented both these statements without expanding on why neither of them are to be taken at face value.

At least the later parts of the article seem more grounded, e.g. something like AUTOSEL could be a productivity enhancer ... but AI-written code is probably not.

Then we get basically nothing, just speculation that someone might be doing something about a policy. Nothing about how this fits into the bigger picture of Linux kernel development and maintenance.

There's a throwaway line in the article which I think points to a much deeper priority:

We use a programming language that can almost be defined by its lack of any kind of safety, and, in some subsystem patches, are simply taken if no obvious problems exist, making us rather vulnerable to this.

The lack of modernity (in general) in the Linux kernel development is a far more important issue in my opinion. I know there's something of a split between the pro-rust vs the stainless steel camp; but overall the investment in other modern software development practise seems like a much more important topic than whether noobs are pushing AI slop onto the LKML.

So why are we reading about AI here? Because no one can look away. Journalists (if ZDNet claims to have those) are just as guilty of going "all in" on AI as investors, tech companies (and governments), and are taking their eyes off the ball of the truly important problems because of the "new shiny".

Maddening.

2 Likes
5

VERY scary!

With that kind of attitude, the ghost in the machine will emerge to bite us all!

For me LLMs are just a "higher order" of Lisp (list processing, simple condition matching), and I don't like "rules derived by nucleation" which are not documented, explained, weighted or prioritized!

4 Likes
6

I wouldn't be that concerned :slight_smile:

The language they are referring to is obviously C. What they mean is that as far as the language specification cares: perfectly valid code (that could be compiled and run) might leak memory, may access arrays 'out-of-bounds', or any other number of unsafe operations.

Reality isn't so black and white.

Modern C compilers will check many additional safety issues and by default issue "warnings". And a lot of projects while be built with "warnings as errors" i.e. they will fail to compile when the additional checks fails.

What some people argue - probably correctly - is that other languages (and Rust is getting the most support) have stricter safety requirements in the language itself and its tool set; i.e. some 'optional' checks are now requirements, and the checks performed are more robust.

For me, LLMs are more like a weirdly complicated way to heat the planet.

That said, I actually do hope to work more with ML/LLMs where their application is of clear benefit (e.g. medical technology, engineering solutions to sustainability, etc).

2 Likes
7

Stephen, am I wrong, or do you also get the vibe that there is a hint in that quote suggesting that the programmers may not even know the intent/purpose/function of the generated code, but accept/insert it into the base anyhow?

1 Like
8

I don't know if it's hinting at anything that serious; but I imagine the standards vary considerably depending on the maintainer due to their experience, time available, and so on.

One of the things that surprises me about kernel development is the lack of formality about testing. It really depends on the maintainer as to what they expect from a contributor.

1 Like
9

But isn't that why Linus took some hard stands and reversed some patches because they didn't meet his vetting requirements?

Isn't Linus "the" gatekeeper, which others have accepted as such ... and ... have any of the key contributors ... or heavily-vested Distros ... started to discuss any kind of continuity concensus plan for that "gatekeeper" role, for the likely eventuality of Linus' demise?

I was pretty sure the gate was not wide open. :slight_smile:

2 Likes
10

I guess everyone is a little bit fascinated by the 'benevolent dictator' myth that surrounds Linus and a kind of 'one man show' narrative ...

... but from where I sit (which is way outside); there's a lot of delegation of authority. He'd be looking at certain 'big ticket' items, but I don't think it's realistic that to say that Linus would be looking much at the patches submitted to the AMDGPU driver (which is part of the kernel).

As an example: I am subscribed to the list for the media subsystem (I was doing a little bit of work on v4l2loopback and thinking about whether it could be upstreamed). That mailing list gets about 100 messages a day. In 6 months, I don't recall seeing a single Torvald reply. By searching the list, I can see that he did reply to a patch in March this year. That's a very light touch - much of the decision making is handled by other maintainers.

3 Likes