Debating the role of large language models in the kernel community [LWN.net]

By Jonathan Corbet
July 21, 2026

Like many development communities, the kernel community has been struggling to determine how large language models (LLMs) will be used in its development process. The news has been dominated recently by a strongly worded missive from Linus Torvalds on the subject, but the discussion has been rather more wide-ranging and nuanced than that. Topics that have been considered recently include the LLM attribution requirement, code-review tools, dependence on proprietary tools, and whether there is a place for concerns about the ethics of LLMs.

Reconsidering Assisted-by

The kernel community's guidance regarding LLM-generated code was added to the kernel, at the end of 2025 for the 7.0 release, after long discussions in the Linux Foundation's Technical Advisory Board (TAB) and on the mailing lists. The coding-assistants.rst file states that, when a code submission has been partially or entirely generated by an LLM, the patch should carry an Assisted-by tag in this format:

    Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]

The purpose of this tag was to document the use of an LLM, and to alert reviewers and maintainers to that fact. It also contains the name of the specific tool used. That information was deemed potentially useful in case a specific LLM turns out to have a tendency toward specific bugs or ends up in copyright-related trouble; it would make it possible for developers to review patches generated by the problematic model and, possibly, modify or remove them.

Since then, this tag has not won over all developers. As of 7.2-rc4, over 1,200 commits carry Assisted-by tags. There is, however, clearly a significant stream of machine-generated patches that do not carry that tag; sometimes that is a result of ignorance of the rules, but other times the origin of the code is, seemingly, being deliberately obscured. As a result, the tag's usefulness as an indicator of LLM involvement is unclear at best. Meanwhile, some developers see placing the names of specific LLMs into the kernel's development history as a form of advertising. All told, many wonder whether the tag adds any value at all.

This discussion came to the fore at the beginning of July when Christian Brauner suggested removing the tag or, at least, removing the name of the specific model used:

I acknowledge that my stance is even more radical: imho we would just stop it with any disclosure requirements completely. It's useless imho. We already see that other than core contributors most people don't care and will just not disclose their usage of AI. I think this is entirely pointless and worse it brings in undefined legal status as well. It's not like recent events of pulling certain models from the face of the earth have made this any less concerning.
But fine, if we want to do this can we please just dumb it down to
    Assisted-by: LLM

Jeff Layton later followed this up with a separate patch removing the attribution requirement entirely. Some developers were clearly in favor of that; networking maintainer Jakub Kicinski let it be known that he simply removes those tags from patches he applies, essentially undermining the previous decision made by the TAB and the community. Others have not taken that step, but expressed little love for the tag.

There are developers, though, who would like to see its use continue. Greg Kroah-Hartman described it as a signal that an LLM was involved in the creation of a patch, and that the result should be reviewed more closely. Lorenzo Stoakes characterized the current policy as being "about empowering maintainers to push back". This contingent would like to see the Assisted-by requirement stay in force, perhaps with better enforcement if possible.

In the end, there appeared to be enough support for keeping the tag to prevent its outright removal, but nobody was willing to defend requiring disclosure of the specific tool used. So the consensus seemed to be to go with Brauner's initial suggestion, perhaps with a more focused changelog. A new revision has not yet appeared, though, and it may well be that a final decision on this policy will not be made until the Maintainers Summit in October.

Dependence and sustainability

While the use of LLMs to write code is clearly on the increase in the community, LLMs are still much more widely used for the review of patches rather than their creation. The Sashiko review tool, in particular, has seen extensive adoption by many subsystems, and maintainers increasingly expect developers to respond to the reviews it emits. But these tools depend heavily on the willingness of corporations to fund their use, which drives a couple of concerns: will that generosity continue in the future, and will the community become so dependent on those tools that a future rugpull could substantially hurt the development process?

Roman Gushchin, the most active developer behind Sashiko, raised this concern in his proposal for a Maintainers Summit discussion:

Several kernel engineers and maintainers have rightfully expressed concerns about relying on infrastructure provided by a single company without clear formal guarantees. It would be great to discuss what a more sustainable model could realistically look like and how we might get there.

I have also brought this issue up in the community more than once. Two decades ago, the community's reliance on BitKeeper led to a major shock when access to that proprietary tool was suddenly withdrawn. Depending on another proprietary tool now risks a similar shock, and this time the community may not be able to depend on Torvalds creating a replacement over a long weekend.

Many of the responses to this question have leaned on the idea that, while LLM-based tools help the community to be more productive, there is no real risk of becoming dependent on them. Sasha Levin, for example, said: "if AI suddenly goes away tomorrow it'll suck for me, but I'll just go back to writing my tools manually like I did before". The earlier part of that email, though, read:

In the past year or two I was able to rewrite most of my ugly scripts, automate so many of the processes I used to do manually, and just improve so many quality of life items thanks to AI. Look even at the CVE process that was created last year: so much of the infrastructure used to drive it was created with AI.

Or consider the words of another long-time kernel developer, Dave Chinner, in an entirely different conversation:

I have learnt how to drive LLMs well enough that I don't need to write code anymore. The LLM functions as my code editor that is capable of extremely fancy DWIM predictive text insertion. For someone who hates the process of typing out code, this has been a revelation.

The authors of words like that may not feel dependent on these tools, but they have nonetheless clearly given LLM-based tools a major role in how they get their work done.

Ted Ts'o said that Sashiko finds problems that human reviewers might not notice, but that it is not a substitute for human review: "I agree that if reviewers stop doing this, we would be in a world of hurt". He also said, in a different discussion, that "one of the things that really excites me about Sashiko is that it reduces my workload". How maintainers will respond to LLM-based reviews in the long term remains to be seen, but it seems almost certain that they will take advantage of that workload reduction and stop looking for the sorts of problems that tools like Sashiko tend to find anyway. It is hard to imagine that the skills needed to do that kind of review would not atrophy over the long term in such a scenario.

If LLM-based review tools are with us for the long term, the loss of those skills might be no more tragic than the loss of low-level assembly skills. They just will not be needed anymore, and humans can focus on more strategic and long-term-maintenance issues. But if those review tools disappear as the pipeline of money behind the LLM industry constricts, development communities could find themselves regretting that skill loss. Compilers cannot be taken away from us; massive, data-center-based LLMs can. Even if the tools do not disappear entirely, they may become unavailable to developers who do not work for large companies that can pay the bills for their use.

There are some developers looking into ways of running tools like Sashiko locally, using open-weight models; Mauro Carvalho Chehab and Takashi Iwai have mentioned such efforts. According to Iwai, the results are not yet the same: "Yes, there are definitely many false-positives, and they don't always follow the recent changes. Also they cover much less changes than Sashiko". But, presumably, these efforts will make progress over time, reducing the level of dependency on the resources supplied by companies.

Email from Sashiko

To what extent should contributors be required to use — or, at least, to interact with — LLM-based tools? The 2026 Media Summit, held in May, discussed the use of Sashiko for media patches. Some of the outcome of that discussion can be seen in this email from Chehab (the maintainer of the media subsystem), who said that a separate email list had been set up to receive Sashiko emails to keep them off the main media mailing list. He also said that there is a desire for individual contributors to be able to opt out of receiving Sashiko reviews of their patches. That led to a rather lengthy discussion.

Gushchin responded that an opt-out capability seemed like a strange request, like asking to be able to opt out of unit tests. Chehab agreed with him, saying that community etiquette called for always copying the author on replies, but that there are members of the community who see things differently. Laurent Pinchart answered that etiquette called for an explicit request before signing somebody up for a new mailing list. When Gushchin asked whether even a "critical issue" found by Sashiko should not be sent to a patch author, Pinchart responded: "I expect maintainers who want to act on sashiko reviews to triage and verify them first before bothering authors".

It is fair to say that the idea of expecting maintainers to review Sashiko's reviews before sending them to contributors was not entirely popular with maintainers. Ts'o refused that duty and said, instead, that he feels no need to accept patches from contributors who refuse to look at Sashiko reviews. Ihor Solodrai said that it is the contributor's job to make a patch good enough to be merged and, in the current environment, that includes addressing bugs found by LLM-based tools. Gushchin pointed out that attackers are using these tools even if contributors reject them. James Bottomley added that "the contributor doesn't get to approve the tools the maintainer uses to assess and apply patches".

Pinchart pushed back, though, saying that, since maintainers are forcing the change toward these tools, it is up to them to use the time the tools are saving to triage the reviews instead. To require dealing with Sashiko, he said, is to "force contributors to constantly justify their value against a machine that is known to produce a non-negligible quantity of nonsense". Having to respond to unchecked reviews from LLMs, he said, is equivalent to maintainers being forced to read LLM-generated patches from contributors who have not checked them. He also referred back to the Media-Summit discussion about sending machine-generated reviews to newer developers:

This came from a consideration on the impact of false positives and other hallucinations on junior developers. They may have the best context of the work, but they are also most at risk of not questioning the validity of the reviews.

A related area of concern, raised by a number of developers (including Gushchin in his proposal for the Maintainers Summit) is that of pre-existing issues. As Sashiko reviews a patch, it also finds bugs that already exist in the code being changed. Surprisingly, it would seem that the current kernel code base still contains no shortage of errors. Nobody seems to think that these bugs should not be reported, but many see them as noise that the developer of the patch being reviewed should not have to work through. It would be nice, certainly, if the developer would fix all of those bugs, but it is generally not considered reasonable to require developers to do that extra work.

As Torvalds noted, the tendency of some maintainers to expect contributors to fix unrelated problems has been a pain point in the past. It doesn't work, and should not be done with bugs found by LLMs either. He had a somewhat eye-opening suggestion that, perhaps, an LLM could create its own fixes for at least some of those bugs and maintain a tree of its own patches. "That would seem to be the obvious 'next step' from just doing patch review. Trivial patches that the AI has high confidence in, and we have high confidence in the group running the AI". There was no immediate clamor of support for that idea. Instead, developers talked mostly about trying to somehow maintain a separate list of pre-existing bugs that need attention when somebody has the time to do so.

Forking and ethics

Returning to the media discussion; Gushchin had responded to the request for a per-developer opt-out capability by describing the request as "a very anti-LLM position in general" and something that would defeat the purpose of helping maintainers. That led to the Torvalds response reported on around the world:

Linux is not one of those anti-AI projects, and if somebody has issues with that, they can do the open-source thing and fork it.
Or just walk away.
AI is a tool, just like other tools we use. And it's clearly a useful one.

Lyude Paul's response to Torvalds is worth reading in its entirety. She points out that many developers need their paychecks and are not in a position either to fork the kernel or to walk away from it. Developers are currently under heavy pressure to use LLM-based tools, to the detriment of the quality of the code produced:

Many, many of our employers are explicitly trying to force these tools on people with the expected result being a magical 10x productivity boost that just isn't compatible with oversight. It is being used in a LOT of workplaces as an excuse to throw any notion of actual review or code quality out the window. While we've been dealing with slop for decades in the kernel already: I think it is very worthwhile to point out that a tool that dramatically lowers the bar required to generate huge amounts of sniff-test passing slop is in fact, not like other tools.

For developers who are working to maintain the quality of the kernel's code, Paul said, guidelines on LLM use within the kernel may be the only tool those developers have to push back safely on their employers.

This pressure from employers has also arguably had the result of making many developers unwilling to argue publicly against their use, leaving Pinchart as one of the few willing to do so. He made his position clear on the topic: "I consider that, today, there's no ethical justification for the use of generative AI in FOSS development". Torvalds was quick to shut down any discussion along those lines: "So keep your ethics where they belong - in your personal life. Don't try to enforce your ethics on others".

This position is worth reflecting upon for a moment. Developers will, given a chance, describe a number of ethical misgivings about these tools. They will talk about the industry's decision to ignore copyright and the possibility that LLM output violates copyrights. They may mention the environmental costs of untold gigawatts of computing power being directed toward these models, or the effects of data-center construction on the communities around them. Developers may express concerns about how these models are controlled by oligarchs, or about the systemic economic risk posed by the huge portion of the economy being pulled into this industry. They might even spare a moment to commiserate with web-site operators who are struggling to contend with scraping by bot networks.

Whether or not one agrees (or cares) about these concerns, there is no doubt that they exist. But, according to Torvalds, that entire discussion is off limits; the only aspect of the problem that can be talked about is "technical reasons" and whether the tools are useful. Clearly, the kernel community is not in a position to fix any of those problems. It is also clear that the community cannot pretend that these tools do not exist. But neither can the community pretend that the ethical issues around LLM use do not exist, at least, not without the risk of alienating the developers who do care about these things.

As anybody who has made it to the end of this overly long article will have long since realized, there are a lot of open questions regarding the use of LLM technology in the kernel community. Many developers and maintainers are clearly quite supportive of that use, and it seems clear that the role of LLMs in kernel development is set to grow. This community has muddled through numerous debates over the years about its direction and, yes, about its ethics. The result has generally been a stronger and larger community going forward. Hopefully, the community will find ways to reach that sort of outcome this time as well.

Index entries for this article
Kernel	Development tools/Large language models

to post comments

LLM cost

Posted Jul 21, 2026 15:09 UTC (Tue) by ballombe (subscriber, #9523) [Link] (11 responses)

The question is how Linus plans to pay for all the kernel developers LLM cost.

LLM cost

Posted Jul 21, 2026 15:35 UTC (Tue) by burki99 (subscriber, #17149) [Link] (10 responses)

Why should Linus pay this? He doesn't pay the electricity or the cost of internet access of those currently working on the kernel, so why should the (optional) use of LLMs be any different?

LLM cost

Posted Jul 21, 2026 17:57 UTC (Tue) by ballombe (subscriber, #9523) [Link] (9 responses)

Linus started by writing an unix-like OS that ran on commodity i486 hardware. That suddenly allowed a lot of people to become kernel hackers.
What Linus is saying is that now LLM are not optional to participate. So either you can pay for LLM or you are out.

LLM cost

Posted Jul 21, 2026 18:21 UTC (Tue) by burki99 (subscriber, #17149) [Link]

Can you give a citation for "What Linus is saying is that now LLM are not optional to participate."?

LLM cost

Posted Jul 21, 2026 18:47 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

In 1999 I was paying about $1 per hour for Internet access, just for scale.

LLM cost

Posted Jul 21, 2026 19:31 UTC (Tue) by alx.manpages (subscriber, #145117) [Link]

> So either you can pay for LLM or you are out.

From what I've understood, there's no obligation to use LLMs for contributing. It's only allowed. It would be very weird to ban contributions that don't use an LLM.

LLM cost

Posted Jul 21, 2026 20:18 UTC (Tue) by malmedal (subscriber, #56172) [Link] (4 responses)

> So either you can pay for LLM or you are out.

What happened was that some people got very very angry because they got Sashiko reviews for free, nobody was asked to pay for anything.

LLM cost

Posted Jul 23, 2026 9:04 UTC (Thu) by LtWorf (subscriber, #124958) [Link] (3 responses)

And those reviews they got for free were saying their patch was bad because of a bunch of pre existing bugs that had nothing to do with them, but they are somehow accountable for them now.

LLM cost

Posted Jul 23, 2026 9:41 UTC (Thu) by taladar (subscriber, #68407) [Link] (1 responses)

To be honest not fixing bugs extremely close to code you worked on even though you are aware of them to the point where they are in the patch context or the same functions is just as weird as leaving dozens of compiler warnings unfixed to me.

LLM cost

Posted Jul 24, 2026 15:37 UTC (Fri) by marcH (subscriber, #57642) [Link]

> To be honest not fixing bugs extremely close to code you worked on even though you are aware of them to the point where they are in the patch context or the same functions is just as weird as ...

Totally agree. Unfortunately, everyone has a different definition of "extremely close". There is no simple solution to this problem, never will be.

LLM cost

Posted Jul 23, 2026 9:46 UTC (Thu) by malmedal (subscriber, #56172) [Link]

That's an entirely different claim, though Linus did in fact address this one as well.

LLM cost

Posted Jul 22, 2026 8:57 UTC (Wed) by garyvdm (subscriber, #82325) [Link]

You have miss-read what he said.

He DIDN'T say everyone has to use a LLM.

He said you can't block contributions made with the assistance of a LLM.

Ethics of immense new energy demands of AI

Posted Jul 21, 2026 16:10 UTC (Tue) by paulj (subscriber, #341) [Link] (23 responses)

> " keep your ethics where they belong - in your personal life."

I mean, AI is gobbling up energy like no tomorrow, and creating huge economic incentives for the richest companies in the world to burn loads of extra hydro-carbons to sate the desire to expand AI ever further. In Ireland we are seeing AI-driven DC growth consume ever more power - we're at circa 25% of our entire grid generation now (predicted to hit 30% or so in next year or so)! Our government will require new DCs to have their own generation, but that will be largely gas-backed - HCs.

There is a *huge* moral and ethical component to that!

The tech industry has gone from trying to make DCs somewhat net-0 (however token, or however flawed offsetting may or may not be), to pretty much not giving a fsck anymore and expanding HC-energy use massively.

Let's burn down the planet for AI. Will that be our legacy?

Ethics of immense new energy demands of AI

Posted Jul 21, 2026 16:32 UTC (Tue) by bluca (subscriber, #118303) [Link] (22 responses)

That is all true, however what you are describing are the consequences of runaway capitalism, not AI. Climate change did not start when chatgpt was published. It will not stop if all LLMs magically disappeared tomorrow morning either.

Ethics of immense new energy demands of AI

Posted Jul 21, 2026 16:50 UTC (Tue) by collinfunk (subscriber, #169873) [Link]

Well, the alternatives to capitalism don't seem much better environmentally. See (or I guess don't see would be better in this case) the Aral Sea.

Ethics of immense new energy demands of AI

Posted Jul 22, 2026 8:47 UTC (Wed) by paulj (subscriber, #341) [Link] (11 responses)

You're not wrong, of course. On the other hand, why not generalise further? It's not just capitalism, it's humans generally. It's not just humans, it's the fizzling of entropy through the universe generally (so far as we now).

Alternatively, people are responsible for the choices they make. Some people's decisions have more consequences than others, but we all collectively decide together. We have agency, and we choose our path. Even within constraining systems such as capitalism, we have choices.

On your other point, LLMs are not responsible for the HCs burned that got us to this point. However, at this point where we need to reduce HC use drastically, LLMs are most certainly _adding_ a significant impetus to burning a lot more HCs (certainly in my country).

"It's just capitalism" is a cop-out. As is "But LLMs didn't cause climate change".

Ethics of immense new energy demands of AI

Posted Jul 22, 2026 9:17 UTC (Wed) by bluca (subscriber, #118303) [Link] (10 responses)

> It's not just capitalism, it's humans generally. It's not just humans, it's the fizzling of entropy through the universe generally (so far as we now).

Actually, no, I'm pretty sure it's capitalism. Humans as a species lived for about ~250k years without setting everything on fire for the benefit of a select few.

> "It's just capitalism" is a cop-out. As is "But LLMs didn't cause climate change".

It's not, it's refocusing: you don't solve climate change by shouting at workers who use LLMs. You solve climate change by joining a trade union, and by supporting your local flavour of the green party. There's nothing anarco-capitalists love more than workers squabbling among themselves about minutiae, as it distracts from doing the only thing that we know for sure works to knock them down a notch or two: organized labour.

Ethics of immense new energy demands of AI

Posted Jul 22, 2026 10:23 UTC (Wed) by alx.manpages (subscriber, #145117) [Link] (9 responses)

> Actually, no, I'm pretty sure it's capitalism.

The communist China eradicated sparrows almost a century ago.
The Romans eradicated many forests where they conquered, notably including Great Britain, two millenniums ago.

> Humans as a species lived for about ~250k years without setting everything on fire for the benefit of a select few.

Population has grown exponentially in these years, with more than half of the humans that have ever existed being alive at the moment. This means that whatever effects those old populations could cause were minimal, simply because they were too few.

Also, they didn't have the ability to destroy that they have now.

I attribute this to partial intelligence. Humans tend to overestimate their intelligence and believe they are aware of all the possible positive and negative consequences of their acts, which is obviously not true, and thus they do things they wouldn't do if they were aware of their consequences.

An example is people that kill birds because they eat their food (see China as the ultimate example, but this happens every day in most of the world, including my village), without taking into account that they also eat pests.

Another example is governments approving the chopping of a forest to place of solar panels, considering that the solar panels will help reduce CO2 from the reduced HC consumption. Except they didn't take into account the CO2 that the forest would consume, and they also didn't take into account that the forest also reduces temperatures, and thus people will have to use AC more, and thus increase energy consumption, so in the end probably HC consumption will stay the same, and CO2 will have a net increase.

There are just too many examples.

In the end, this is stupidity hidden by limited intelligence. We've had it for millenniums.

Of course, capitalism is stupid. But stupidity isn't limited to capitalism.

Ethics of immense new energy demands of AI

Posted Jul 22, 2026 18:57 UTC (Wed) by nhippi (subscriber, #34640) [Link] (5 responses)

> Another example is governments approving the chopping of a forest to place of solar panels, considering that the solar panels will help reduce CO2 from the reduced HC consumption. Except they didn't take into account the CO2 that the forest would consume

I mean I hate forest razing as much as any sensible person, especially as there are so much better places to put solar (solar car parks should be mandatory...). But the forests are not really that much of carbon sink.

1 hectar of forest will store 0.3 to 2.5 tons of co2 per year

1 hectar of solar panels will reduce yearly CO2 emissions by 200-400 tons per year

This may seem counterintuitive that forests full of green don't absorb more CO2, but you have to remember forests make life possible for huge amounts of animals, bacteria and fungi.

Ethics of immense new energy demands of AI

Posted Jul 22, 2026 19:23 UTC (Wed) by rschroev (subscriber, #4164) [Link] (3 responses)

You don't mention the carbon already stored in the forest. If you chop a forest, all that carbon potentially gets released into the atmosphere all at once. I don't have the numbers though. Do you have a source for the numbers you quote? I'd like to read up on that.

Ethics of immense new energy demands of AI

Posted Jul 22, 2026 20:37 UTC (Wed) by alx.manpages (subscriber, #145117) [Link] (1 responses)

Those numbers are easy.

2 carbons weight 24 UAM, and CO2 weigths 40 UAM.
So, per each 24 tons of carbon you release 40 tons of CO2

According to <https://en.wikipedia.org/wiki/Forest>, there are 172 tons of carbon per hectare of average forest. Thus, you release 172*40/24=286 tons of CO2 per hectare (when you burn it).

Ethics of immense new energy demands of AI

Posted Jul 23, 2026 0:11 UTC (Thu) by alx.manpages (subscriber, #145117) [Link]

Oh, the numbers were easy, but yet I got them wrong. I calculated C2O instead of CO2. :)

One carbon weights 12 UAM, and one CO2 weigths 44 UAM.
12 tons of carbon result in 44 tons of CO2.

Thus, from 172 tons of trees per ha, 172*44/12=630 tons of CO2 per ha released when the wood is burnt.

Of the Carbon storage of forests

Posted Jul 23, 2026 7:08 UTC (Thu) by nhippi (subscriber, #34640) [Link]

> You don't mention the carbon already stored in the forest. If you chop a forest, all that carbon potentially gets released into the atmosphere all at once.

Intentionally - unless the forest was protected natural reserve, it was going to be chopped down and burned anyways. Either immediately as bioenergy. Or later in waste furnance when ikea carboard packaging is disposed, or much later when the ikea furniture breaks down and is disposed.

Assuming a natural fully grown forest, the co2 sequestion rate is essentially how much topsoil it accumulates yearly. The co2 stored in tree trunks will be reused, either by humans or by xylophagous fungus.

> Do you have a source for the numbers you quote? I'd like to read up on that.

This is becoming incredibly off-topic and I hope the LWN editors forgive me :D

Re forest sequestation rates: I don't remember where I found the numbers but IPCC numbers are a good starter. Note that they list rates for afforestration / reforestration over short term of time. Hence a forest grown to full height the numbers would be smaller:

https://archive.ipcc.ch/ipccreports/sres/land_use/index.p...

Re solar co2 savings: It was napkin math based on 1MW solar park occupying 2 hectars, and producing 1000-2000MWh annually depending on location. For example global solar atlas will give you numbers per location: https://globalsolaratlas.info/map?c=55.553495,16.820068,6...

Split that with half for a hectar (500-1000MWh), and mupltiply with co2 emissions of a kWh of gas produced electricity (0.5kG per kwh, number from IPCC) (250 to 500 tons). Finally used the stetson-harrison method to round down to 200-400 tons to account for emissions related to solar panel / inverter etc lifecycle.

Ethics of immense new energy demands of AI

Posted Jul 22, 2026 20:16 UTC (Wed) by alx.manpages (subscriber, #145117) [Link]

How about the temperature difference? Forests are massive heat sinks.

Ethics of immense new energy demands of AI

Posted Jul 23, 2026 8:14 UTC (Thu) by taladar (subscriber, #68407) [Link] (2 responses)

Impressive how "communist China" did something before China was even communist.

Ethics of immense new energy demands of AI

Posted Jul 23, 2026 8:21 UTC (Thu) by alx.manpages (subscriber, #145117) [Link] (1 responses)

<https://en.wikipedia.org/wiki/Four_Pests_campaign>

I guess you confused "almost a century ago" with "a century ago"?

To me, 70 years ago falls within "almost a century ago".

Ethics of immense new energy demands of AI

Posted Jul 23, 2026 9:38 UTC (Thu) by taladar (subscriber, #68407) [Link]

No, I generally don't consider the late 50s and early 60s "almost a century ago", probably because that would mean I would have to consider my parents "almost older than a century".

Ethics of immense new energy demands of AI

Posted Jul 22, 2026 12:43 UTC (Wed) by rschroev (subscriber, #4164) [Link] (8 responses)

We've come at a point in time where we need massive decreases of greenhouse gas emissions, and at the same time the training and use of LLMs is instead causing massive increases. That is a massive problem and I don't understand how this doesn't cause large public outrage.

Ethics of immense new energy demands of AI

Posted Jul 22, 2026 17:30 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (7 responses)

If you want to make a CO2 argument, then it might not work like you think it does. A single human is vastly more polluting than an LLM.

It takes at least 2 decades of heavy resource investment to raise a kernel developer. Imagine the CO2 savings if they are replaced by an LLM!

Ethics of immense new energy demands of AI

Posted Jul 22, 2026 17:43 UTC (Wed) by mb (subscriber, #50428) [Link]

You forgot to multiply that by the general-population-kernel-hacker-factor.
On average, you have to raise like 1 million children to get one kernel hacker.
What an inefficient process and what a waste of resources!

Ethics of immense new energy demands of AI

Posted Jul 22, 2026 19:19 UTC (Wed) by rschroev (subscriber, #4164) [Link] (1 responses)

Faster development is not more important than having a habitable planet.

Ethics of immense new energy demands of AI

Posted Jul 22, 2026 19:34 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

But imagine the savings if we repurpose kernel developers to do something more productive, like sweeping streets or picking up trash for recycling!

But in all seriousness, money is a pretty good proxy for CO2. If $4000 for an LLM replaces a $200000 year developer, then it's very hard to justify hiring more developers.

Ethics of immense new energy demands of AI

Posted Jul 23, 2026 0:20 UTC (Thu) by alx.manpages (subscriber, #145117) [Link] (1 responses)

> A single human is vastly more polluting than an LLM.

I doubt this.

A human doesn't need to pollute at all for living (food, mainly). I try to buy food from local producers, which not only minimize pollution, but even reverse it in some cases.

And about the computing resources used for learning to program, those resources are often directly used for producing desired effects on code, so they're already accounted for something else. The marginal cost of using a programmer is negligible. The marginal cost of using an LLM is huge.

This argument reminds me of the sparrow eradication in the communist China. It's the same kind of ignorance of small side effects.

Ethics of immense new energy demands of AI

Posted Jul 23, 2026 5:28 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

It's not even a debatable argument. A human kernel developer is VASTLY more polluting than even the biggest LLM working 24/7.

If you can make the same amount of work in the kernel with fewer people, it's a win. Or more realistically, same number of people will do more work.

If you want to look at resources, LLMs don't need 20 years of education while doing nothing, they need a fraction of space for housing, they don't need transportation, and so on.

Ethics of immense new energy demands of AI

Posted Jul 23, 2026 4:20 UTC (Thu) by mirabilos (subscriber, #84359) [Link] (1 responses)

Of course the pro-LLM crowd will use eugenicist argumentation…

… why am I not surprised.

(Turned notifications of replies off.)

Ethics of immense new energy demands of AI

Posted Jul 23, 2026 5:21 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

WTF?!?

How the hell did you come to that conclusion?

So ethics don't apply professionally?

Posted Jul 21, 2026 17:49 UTC (Tue) by pizza (subscriber, #46) [Link] (7 responses)

> "So keep your ethics where they belong - in your personal life. Don't try to enforce your ethics on others"

What a bone-headed ludicrous thing to say.

By that standard, folks whose literal job is scamming elderly/vulnerable folks are perfectly fine, as long as they don't try to scam their own family and friends when off the clock?

So ethics don't apply professionally?

Posted Jul 21, 2026 18:56 UTC (Tue) by rgushchin (subscriber, #115257) [Link]

To be clear: I named the position expressed in https://sfconservancy.org/llm-gen-ai/llm-backed-generativ...
as "a very anti-LLM position in general", not the request from Laurent.

So ethics don't apply professionally?

Posted Jul 21, 2026 18:56 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

Linus' philosophy has always been that it's fine to use Linux to build baby-chomping machines as long as you contribute the source back.

The idea is that in the long run, the benefits of having a free kernel outweigh the disadvantages of "bad actors" having access to a free kernel. You can disagree with that, but it _is_ a valid self-consistent ethical position.

So ethics don't apply professionally?

Posted Jul 21, 2026 20:32 UTC (Tue) by pizza (subscriber, #46) [Link] (1 responses)

> Linus' philosophy has always been that it's fine to use Linux to build baby-chomping machines as long as you contribute the source back

...But is it fine to use baby-chomping machines to build Linux?

So ethics don't apply professionally?

Posted Jul 21, 2026 20:50 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Apparently, yes. Although it might be impractical and unreliable in the long run (see: BitKeeper). Linux developers also accept patches from closed-source (and very expensive) static analyzers like Coverity that are not available for the general public.

So ethics don't apply professionally?

Posted Jul 25, 2026 1:36 UTC (Sat) by chuckwolber (✭ supporter ✭, #138181) [Link]

> The idea is that in the long run, the benefits of having a free kernel outweigh the disadvantages of "bad actors" having access to a free kernel. You can disagree with that, but it _is_ a valid self-consistent ethical position.

That is _not_ the idea.

The idea is that no formal rule can deterministically anticipate the impact of all possible future context. You may indeed be able to contrive some pretty grotesque examples [*], but that does nothing to help establish a formal system that can be cleanly applied to _all_ possible situations.

All ethical systems leak in the face of context. Until this point is resolved, systems of morality fall into the "hard" category that requires individual struggle. Go study it and make a novel contribution if you feel that strongly about it.

I am sure we would all love to struggle a little less with questions of morality. But until that happens, no one is fit to prejudge another person's use of the Linux kernel, and Linus is smart to stay out of it.

* Can we please stop invoking children and defenseless animals into our ethical arguments?

So ethics don't apply professionally?

Posted Jul 22, 2026 23:56 UTC (Wed) by Phantom_Hoover (subscriber, #167627) [Link] (1 responses)

Yes, if you cut that sentence out and treat it as a maxim for life, you can easily reductio ad absurdum. If you read it in the context it was actually said, it looks much more like the far more reasonable ‘don’t turn my kernel into a new front in whatever ethical struggle seems so important to you’.

So ethics don't apply professionally?

Posted Jul 23, 2026 22:17 UTC (Thu) by IanKelling (subscriber, #89418) [Link]

> don’t turn my kernel into a new front

We didn't start the fire! (this is a song reference)

A technical concern with code generation

Posted Jul 21, 2026 20:46 UTC (Tue) by ebiederm (subscriber, #35028) [Link] (5 responses)

From time to time the code generated by an LLM is essentially cut & pasted from it's original source. If that code is from code that is from a GPL incompatible license, such as the original BSD license or solaris license that opens everyone who uses the Linux kernel up to a SCO like lawsuit but on firmer legal ground.

It is a technical and or legal problem that the big LLMs do not remember the license of code they are built from.

If this works anything like security exploits, the profiteers will wait until enough examples of violating copyright exist and wide spread enough that they can make a healthy profit out of a lawsuit.

A technical concern with code generation

Posted Jul 21, 2026 21:07 UTC (Tue) by mb (subscriber, #50428) [Link] (4 responses)

>From time to time the code generated by an LLM is essentially cut & pasted from it's original source.

Can you give one actual example of that happening?

A technical concern with code generation

Posted Jul 21, 2026 22:08 UTC (Tue) by airlied (subscriber, #9104) [Link]

and then add one where the generated code was in any way compatible with the project it was being submitted to.

A technical concern with code generation

Posted Jul 22, 2026 0:16 UTC (Wed) by csamuel (✭ supporter ✭, #2624) [Link] (2 responses)

This appears to have happened to the OCAML folks in this PR: https://github.com/ocaml/ocaml/pull/14369

> According to the copyright headers, all the new source files in this PR have been written by Mark Shinwell (@mshinwell), or maybe are directly derived from his work. This seems plausible (a lot of it seems heavily inspired by the DWARF support in the oxcaml repository, which I suppose has been written by Mark indeed), but is it actually the case? (If your work is so heavily derived from Mark's work, maybe it would make sense to credit him in the PR description, or in the webpage you created specifically to advertise for this work?)

and:

> > (If your work is so heavily derived from Mark's work, maybe it would make sense to credit him in the PR description, or in the webpage you created specifically to advertise for this work?)
>
> The webpage credits another author:
>
> > Native binary debugging for OCaml (written by Claude!)
>
> @joelreymont, could you please explain where you obtained the code in this PR?

To which they replied:

> It’s not where I obtained this PR but how.
>
> Claude Sonnet 4.5 (Claude Code) wrote most of it with ChatGPT 5 (Codex) reviewing and Claude addressing issues in each review. Codex wrote the last 10% or so when Claude kept getting stuck.
>
> I did not write a single line of code but carefully shepherded AI over the course of several days and kept it on the straight and narrow.

Followed up later with the classic line:

> > Here's my question: why did the files that you submitted name Mark Shinwell as the author?
>
> Beats me. AI decided to do so and I didn't question it.

A technical concern with code generation

Posted Jul 22, 2026 6:43 UTC (Wed) by kleptog (subscriber, #1183) [Link]

So in this case at it preserved the copyright notices, so all is fine, right?

In any case, it think it's far more likely Claude simply downloaded the source from the internet and used it, than that the source is somehow incorporated into the model itself.

I can see there being a general prompt instruction that if the LLM downloads source from elsewhere it preserves the notices.

A technical concern with code generation

Posted Jul 22, 2026 16:40 UTC (Wed) by mb (subscriber, #50428) [Link]

That is not an example of an AI reproducing copyrighted copies from its trained memory.
In this case the AI has explicitly been prompted to take a look at the original code:

> I did ask AI to look at the OxCaml implementation in the beginning.

That's a very different thing.
Of course an AI agent will take over code from somewhere, if it's being prompted to do read that code into its context window and then produce code. It is *supposed* to emit similar/copied code in that case.

Absolute insanity

Posted Jul 22, 2026 0:26 UTC (Wed) by roguelazer (subscriber, #101286) [Link] (9 responses)

"keep your ethics where they belong - in your personal life" is possibly one of the most philosophically-insane phrases I've ever heard. That's... not how ethics work? Even the most wildly-libertarian tech bros wouldn't argue that they exist in some magical ethics-free zone.

I get that what Linus is saying is that he doesn't care about the world and he doesn't want to be made to feel bad by other people who do, but what a wild way to say it!

It's so disappointing that free software, a space of full of people working collaboratively for the betterment of humankind, has been taken over so thoroughly by forces who are willing to sacrifice absolutely anything to avoid typing.

The more I read of this thread the more inclined I am to buy the argument that even a moderate amount of LLM use results in some kind of permanent brain damage.

Absolute insanity

Posted Jul 22, 2026 7:20 UTC (Wed) by sur5r (subscriber, #61490) [Link] (2 responses)

This, so much this. This is very sad to read.

With a quote like that, one wonders whether Linus is aspiring to become the next Musk-Trump-Zuckerberg-like fascist...

And here we see: FOSS is not apolitical and it doesn't live outside ethics.

Absolute insanity

Posted Jul 22, 2026 10:47 UTC (Wed) by pbonzini (subscriber, #60935) [Link] (1 responses)

Free software is very political. On the other hand the concept of open source was created to replace the politics with a more corporate-friendly calculus.

Absolute insanity

Posted Jul 23, 2026 8:22 UTC (Thu) by taladar (subscriber, #68407) [Link]

I would classify "corporate-friendly" as a political position too.

Absolute insanity

Posted Jul 22, 2026 8:39 UTC (Wed) by taladar (subscriber, #68407) [Link] (4 responses)

What he is saying that he might as well shut the entire Linux project down if every single kernel developer got to ban everything they disagreed with ethically for the entire project. Americans would ban contributions from Russia and China and vice versa. Companies would ban contributions from anti-capitalists and those would ban contributions from large corporations that also include departments that do something they don't like. Pacifists would ban contributions from any company involved in the military supply chain. Christians would ban contributions from atheists and religions in general would ban contributions from members of other religions. Sexist men would ban contributions from women and radical feminists would ban contributions from men. Homophobes would ban contributions from gay people, transphobes contributions from trans people. Racists would ban contributions from people of other races.

Do you see how this would be a problem for a huge project like Linux?

Absolute insanity

Posted Jul 22, 2026 10:29 UTC (Wed) by alx.manpages (subscriber, #145117) [Link] (1 responses)

Or maybe it's that the companies that fund the Linux Foundation --which pays Linus 1+ M$/year (last time I checked)-- have a strong interest in AI, and thus Linus is interested in keeping that, regardless of whether the world burns as a consequence.

Money doesn't change people, but it shows how people really are.

Absolute insanity

Posted Jul 22, 2026 11:20 UTC (Wed) by fenncruz (subscriber, #81417) [Link]

Or maybe it's just different people have different opinions.

Absolute insanity

Posted Jul 22, 2026 12:19 UTC (Wed) by roc (subscriber, #30627) [Link]

Your examples are over the top --- even if they had the power to do so, I guess most people don't actually want to ban contributions from out-groups. I'm a Christian and I certainly wouldn't ban contributions from atheists or other religions. (It would be unfair, unkind, stupid, impractical, and self-defeating.)

But you can imagine more realistic examples which are more compelling. For example, I think a lot of people (including me) would like to see a ban contributions from slaves if we became aware that someone was compelling slaves to contribute to Linux. And if you think current LLMs are inherently tainted because they are the product of copyright violation on a vast scale, I think it makes sense to push for banning LLM-generated contributions on ethical grounds as well as the grounds that the submitter doesn't have the rights to the code. For the sake of the commons it's prudent to restrain ourselves from advocating for too many ethical rules, or indeed things will become unworkable, but that doesn't mean the correct number of ethical rules is zero.

Linus' vegan example is interesting. If you believe that eating meat is morally unacceptable then you may choose not to advocate for a broad meat-eating ban --- it simply may be impudent and counterproductive --- but I think it still certainly makes sense to try to convince people to stop eating meat.

Absolute insanity

Posted Jul 22, 2026 14:56 UTC (Wed) by tux3 (subscriber, #101245) [Link]

If a kernel developer refuses contributions on those criteria, the code of conduct will probably have a pretty clear stance on that question. The kernel is already in the business of enforcing ethics. This includes rejecting contributions for behavior that is harmful, inappropriate, threatening, or offensive, if I'm reading this document right.

As divisive as AI ethics is as a discussion topic, it's not like the rest of your list is any less heavy. It took a while to stop ignoring the problem, and the end result is a policy that's entirely about non-technical reasons you can't refuse or must refuse work from a contributor.

Ignoring the problem doesn't seem like the best way to reduce those tensions.

Absolute insanity

Posted Jul 22, 2026 13:19 UTC (Wed) by ballombe (subscriber, #9523) [Link]

Any system designed to maximize user engagement is addictive...

Ethical and legal questions introduced by LLM's

Posted Jul 22, 2026 10:38 UTC (Wed) by shinyzenith (subscriber, #184473) [Link] (9 responses)

Given that LLM's are trained on stolen data, I believe it's unethical and legally questionable to use it in a GPL licensed project!
I am strongly against folks posting AI generated patches no matter how you like to dress it up as "assisted".

These tools lead to significant cognitive decline along with massive energy consumption. We as a community should stand against them.

The kernel has survived and thrived for decades without AI, I'm sure we can pull through this phase in preparation for when the bubble eventually pops.

Ethical and legal questions introduced by LLM's

Posted Jul 22, 2026 12:13 UTC (Wed) by rbranco (subscriber, #129813) [Link]

> The kernel has survived and thrived for decades without AI, I'm sure we can pull through this phase in preparation for when the bubble eventually pops.

When the bubble pops AI will actually get more interesting with cheaper hardware to run open-weight models on distributed inference.

There's no putting the genie back in the bottle... LLMs came here to stay.

Ethical and legal questions introduced by LLM's

Posted Jul 23, 2026 16:00 UTC (Thu) by bluca (subscriber, #118303) [Link] (6 responses)

> Given that LLM's are trained on stolen data

They are not. In the US, all relevant cases so far say that training models falls under fair use (https://www.theguardian.com/technology/2025/jun/25/anthro...), and in the EU the AI Act and the Copyright Directive explicitly amended copyright rules to allow training models on publicly available materials, in derogation to copyright protections.

Ethical and legal questions introduced by LLM's

Posted Jul 23, 2026 16:30 UTC (Thu) by pizza (subscriber, #46) [Link] (5 responses)

> They are not. In the US, all relevant cases so far say that training models falls under fair use

_Training_ models is fair use... if you legally obtained the material to do so.

Scanning every physical book in a library and feeding that into your model is okay.

Downloading eleventy-gigabyte torrents of books and feeding that into your model is not okay.

Ethical and legal questions introduced by LLM's

Posted Jul 23, 2026 19:44 UTC (Thu) by bluca (subscriber, #118303) [Link] (4 responses)

> _Training_ models is fair use...

Yes (in the US), but that's not what the person I replied to said, hence the needed clarification.

> Downloading eleventy-gigabyte torrents of books and feeding that into your model is not okay.

Absolutely, and they are getting their arses handed to them in court for that specific issue, and rightly so

Ethical and legal questions introduced by LLM's

Posted Jul 23, 2026 21:09 UTC (Thu) by shinyzenith (subscriber, #184473) [Link] (3 responses)

Thanks for the clarification on US and EU laws.

> Absolutely, and they are getting their arses handed to them in court for that specific issue, and rightly so

I'd absolutely disagree with this. If they were indeed getting their arses handed to them we'd be seeing much larger repercussions.

Open to having my mind changed. Please let me know if I am wrong.

Ethical and legal questions introduced by LLM's

Posted Jul 23, 2026 21:17 UTC (Thu) by bluca (subscriber, #118303) [Link] (2 responses)

They are losing in court(s) and being forced to pay compensation for pirating stuff https://www.bbc.co.uk/news/articles/c5y4jpg922qo

Ethical and legal questions introduced by LLM's

Posted Jul 23, 2026 21:19 UTC (Thu) by shinyzenith (subscriber, #184473) [Link] (1 responses)

I've read this article before and it's not close to how much they *should* be paying given that they have downloaded the entire internet illegally.
My initial point of stolen data also stands because we know for sure they did NOT get legal consent from all stakeholders (again proven by the link you shared).

Paying after the fact doesn't mean you didn't steal.

Ethical and legal questions introduced by LLM's

Posted Jul 23, 2026 21:46 UTC (Thu) by bluca (subscriber, #118303) [Link]

They have not downloaded the internet illegally. That's because downloading the internet is perfectly legal, and in fact the entire point of it. They have _torrented_ some works that are not otherwise publicly available, but that need to be acquired to be consumed, and that's why they are rightly getting massive fines.

There is no legal requirement to get "legal consent from all stakeholders" to download publicly available data and use it to train models, and the law (in Europe) and caselaw (in the US) makes this abundantly clear.

Ethical and legal questions introduced by LLM's

Posted Jul 25, 2026 7:47 UTC (Sat) by chuckwolber (✭ supporter ✭, #138181) [Link]

> Given that LLM's are trained on stolen data, I believe it's unethical and legally questionable to use it in a GPL licensed project!

The neural net between my ears was trained by a number of copyrighted textbooks. Am I using stolen data when I apply that knowledge to write code?

Thanks for a comprehensive write-up

Posted Jul 22, 2026 10:50 UTC (Wed) by salimma (subscriber, #34460) [Link]

I was following this development on and off - work deadlines and then much needed vacation got in the way - and did not realize it got this bad.

I guess as someone in the distro space who has ethical qualms myself and am also forced to use LLMs ... this makes me more inclined to limit any interaction with the kernel to the bare minimum needed by $dayjob and not a minute more.

The comparison with Bitkeeper is inapt

Posted Jul 22, 2026 12:23 UTC (Wed) by roc (subscriber, #30627) [Link]

Using LLMs to produce and review code is unlike Bitkeeper because it's not difficult to just stop using them. (Assuming peoples' skills haven't suffered LLM-induced atrophy --- definitely don't let that happen.) Source control is a much deeper dependency.

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 22, 2026 13:33 UTC (Wed) by jpeisach (subscriber, #181966) [Link] (46 responses)

First:

> The coding-assistants.rst file states that, when a code submission has been partially or entirely generated by an LLM, the patch should carry an Assisted-by tag in this format:

If it's **entirely** generated by an LLM, then they don't deserve to be called an "author". They didn't author anything. The LLM did. They aren't any better than a script kiddie.

> There is, however, clearly a significant stream of machine-generated patches that do not carry that tag; sometimes that is a result of ignorance of the rules, but other times the origin of the code is, seemingly, being deliberately obscured.

What about people like me who don't use LLMs and have been trying to get into kernel development? I don't want my contributions being seen as "probably just hiding behind a LLM" because I'm contributing to a pretty old driver.

> Sasha Levin, for example, said: "if AI suddenly goes away tomorrow it'll suck for me, but I'll just go back to writing my tools manually like I did before".

Ok, but at this rate AI isn't going anywhere, so anyone using it is just making themselves dumber and less practiced for if or when access to an LLM is lost.

> I have learnt how to drive LLMs well enough that I don't need to write code anymore. The LLM functions as my code editor that is capable of extremely fancy DWIM predictive text insertion. For someone who hates the process of typing out code, this has been a revelation.

Good for you. But I like typing out code. That's probably my favorite part of programming and computing in general - the process of actually *doing* the thing, the search through comments and functions to find what you need to do - please don't push this off of people.

Also, sacrificing the process of "typing out code" to an LLM, I'm sure is less of an issue to someone who already has a stable job and able to make a living. For the current job market (and maybe future ones too), and people who are desperately looking for work, that looks a lot like one less position that can be filled by an employer.

> If LLM-based review tools are with us for the long term, the loss of those skills might be no more tragic than the loss of low-level assembly skills.

Well, with compilers, these skills are able to be abstracted. But a human is still doing the code. But if an LLM is doing both coding *and* review, then the skills of *everything* get lost entirely.

Re: Sashiko emails. I think the contributor should be looking at test results and following up with review anyway, regardless of a human or a LLM. It's still feedback and review nonetheless. Just as long as it isn't sending so much feedback and nonsense that it scares off new contributors.

> "So keep your ethics where they belong - in your personal life. Don't try to enforce your ethics on others".

I'm not going to bother replying to the thread, but with all due respect to Linus, "don't try to enforce your ethics on others". Says the person who is basically the project dictator. When it comes to things like coding standards, project organization, etc. - isn't that all done and guided by Linus's ethics?

Also: "in your personal life"; well, it's going to get personal. LLMs generate heat and use a lot of energy, and currently the people in charge seem to not care. And nobody is doing the "here is what you should actually use AI for" and "here is how you optimize your usage to be as efficient as possible". Rather, I imagine people (myself included sometimes) can just dump a bunch of code, say "please fix", and let it do its thing. It's overkill.

But aside from "overkill", the planet will obviously continue warming, and we aren't going to know the effects of LLMs on the environmental until we get the research done (which, things are progressing faster than that), or when it is done and we are already too late, because, "oops! Turns out LLMs accelerated greenhouse gas emissions! Now the effects of global warming will be even worse and it will take more time for the world to recover!". So, it is coming.

This isn't ethics of like "do I put a space in between the `if` and the (?", or "do I still maintain this driver?", or "do we allow employees from companies to contribute to the kernel?", it is, "should people be using a technology that is overkill, threatening the jobs of developers, and heating the planet?" (Sorry to do a "it's not X, it's Y", but I really don't see any other way to phrase it).

People will do what they want. If they want to use LLM, fine, but don't force it on everyone. That's what I think was happening anyway. But the discussion is still something to think about. I disagree with Pinchart's claim that "FOSS should not use AI, period", which is a separate conversation, but I also disagree that because of the ethics, nobody should use it.

But at the same time, outright dismissing the concerns is not good. Realistically, nobody will fork the kernel for their "no AI" project. It's a waste of time.

And for those who want to ignore the AI conversation, while it may not impact you, think of the future generations. I'm 18 and a half. These developers may be in their 40s or older, but why should I have to suffer because they chose not to help my life?

Writing code yourself

Posted Jul 22, 2026 14:23 UTC (Wed) by chris_se (subscriber, #99706) [Link] (1 responses)

> > I have learnt how to drive LLMs well enough that I don't need to write code anymore. The LLM functions as my code editor that is capable of extremely fancy DWIM predictive text insertion. For someone who hates the process of typing out code, this has been a revelation.
>
> Good for you. But I like typing out code. That's probably my favorite part of programming and computing in general - the process of actually *doing* the thing, the search through comments and functions to find what you need to do - please don't push this off of people.

This is actually my main (non-ethics-based) gripe about LLMs for code generation: what drew me to computers is the fact that they are very deterministic machines and that if you know the rules they work by, you can get them to do exactly what you want. Some rules might be hidden, but discovering and understanding these hidden rules is part of the fun.

I've tried talking to LLMs, and they feel a lot like talking to a fake-nice salesperson that mostly does what I want, but often has subtle and not so subtle ways to undermine my intent. I don't want to spend the rest of my life talking to used-car salespeople -- LLMs are the opposite of fun for me. If LLMs at some point become the only way of writing code, I'll cease to be a software developer, because using LLMs to write code feels awful and hugely demotivating to me.

(Not saying that LLMs can't have other uses, but generating code is not one I personally find appealing.)

Writing code yourself

Posted Jul 22, 2026 14:31 UTC (Wed) by dskoll (subscriber, #1630) [Link]

If LLMs at some point become the only way of writing code, I'll cease to be a software developer, because using LLMs to write code feels awful and hugely demotivating to me.

I retired from the software development profession in 2023, and I think my timing was impeccable because I missed the whole LLM surge. I still work on hobby projects and I don't use LLMs at all. That's fine because I write the software on my timetable and I write it mostly by myself, so nobody can tell me what to do.

If I hadn't retired in 2023, I suspect that by now, I'd either be miserable or working in a non-software-development job. Yes, AI is "just a tool", but some tools can make things objectively less enjoyable. (Ask anyone forced to use Jira...)

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 22, 2026 21:40 UTC (Wed) by kleptog (subscriber, #1183) [Link] (4 responses)

> Ok, but at this rate AI isn't going anywhere, so anyone using it is just making themselves dumber and less practiced for if or when access to an LLM is lost.

Anyone using spell checkers is making themselves worse at spelling.

Anyone using calculators is making themselves worse at arithmetic.

Anyone using GPS is making themselves worse at reading maps.

Anyone using a gun for hunting is making themselves worse at using bows and arrows.

We make tools to make our lives easier, and there are always trade offs.

> That's probably my favorite part of programming and computing in general - the process of actually *doing* the thing, the search through comments and functions to find what you need to do - please don't push this off of people.

Well good for you. I also like the process of programming but I've been doing this for decades now and I'm glad don't have to spend a lot of time churning out the Nth variation of some code to get data from A, manipulate it and send it to B. A large chunk of what I do is not innovative at all so LLMs mean I can spend less time on that and more on the actual interesting parts.

> And for those who want to ignore the AI conversation, while it may not impact you, think of the future generations. I'm 18 and a half. These developers may be in their 40s or older, but why should I have to suffer because they chose not to help my life?

I sympathise, but this is the wrong target IMO. A single trip by a car uses way more than a large number of AI prompts. And this is the so-manyth bubble I've seen in my lifetime, I can't really get excited about it. As long as people keep using fossil fuels for driving and heating and manufacturing, the effects of LLM use are marginal.

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 22, 2026 22:21 UTC (Wed) by dskoll (subscriber, #1630) [Link] (2 responses)

Anyone using spell checkers is making themselves worse at spelling.

Anyone using calculators is making themselves worse at arithmetic.

Anyone using GPS is making themselves worse at reading maps.

While I'm not sure about #1, I think you are right about 2 and 3. Specifically with respect to 2, that's the reason schools don't let young kids use calculators when they are supposed to be learning basic arithmetic.

But I think there's a fundamental difference. LLMs take over creative work, not just routine work, for some definition of "creative". Even if you don't think LLMs are actually creative, they are used in places to replace work that is definitely creative, such as making video, photos or software.

If we outsource physical work to machines, our muscles atrophy. If we outsource thinking to machines, our brains will atrophy. (Calculators and GPS don't count as "thinking", but I think LLMs do, at least to some extent.)

As someone who feels that creativity is an important part of what gives my life meaning, I hate to outsource that to an LLM. I can't control what others do, but I will never use LLMs to write software or for any other creative endeavour. And I feel very sorry for young software developers who are effectively being forced to use LLMs even if they don't want to. (Not saying the Linux kernel community is doing this, but a lot of employers are.)

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 23, 2026 8:50 UTC (Thu) by taladar (subscriber, #68407) [Link] (1 responses)

I don't feel writing the 100th CRUD pattern copy in a year is particularly creative work. There is plenty of software that isn't exactly creative at all and more "we keep writing this again because we haven't quite figured out how to turn it into a library".

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 23, 2026 14:12 UTC (Thu) by dskoll (subscriber, #1630) [Link]

Every creative job involves some tedium. You can't write a novel without understanding the nitty-gritty of grammar and sentence construction.

Trying to eliminate all tedium from our lives is pretty dangerous. It leads to impatience, short attention spans, and the evils we've realized flow from social media addiction. I think the everyday parts of creative endeavors are just as much brain-training as the more creative parts because they teach persistence and patience. Though of course, you should research if a reusable library is available before you go and write something from scratch!

IMO, the pervasive use of LLMs in software development is going to produce a generation of software developers with ADHD and who don't really understand what they are doing. (Again, not specifically Linux kernel developers, but in general. Most software development shops don't have as rigorous a process as the kernel.)

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 23, 2026 8:17 UTC (Thu) by farnz (subscriber, #17727) [Link]

Go back far enough, and you find Socrates saying that anyone who reads and writes is making themselves worse at remembering things and at understanding things.

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 23, 2026 0:12 UTC (Thu) by dgc (subscriber, #6611) [Link] (38 responses)

> > I have learnt how to drive LLMs well enough that I don't need to write code anymore.
> > The LLM functions as my code editor that is capable of extremely fancy DWIM predictive
> > text insertion. For someone who hates the process of typing out code, this has been a revelation.
>
>Good for you. But I like typing out code. That's probably my favorite part of programming and
> computing in general - the process of actually *doing* the thing, the search through comments
> and functions to find what you need to do - please don't push this off of people.

Good for you. You can write code however you want, and I won't care on bit.

The fact is, I'm not a "programmer" who "writes code". I'm an engineer who uses tools to solve problems and create new things. For a software engineer, "writing code" is a necessary evil - it's part of the job.

However, as an engineer, I am always trying to improve my processes and tools. I will always try to use the best tool for the job. When a better tool than the one I am using comes along, I'll learn to use it to get my work done faster/better/easier/cheaper.

For example: I build and race cars as a hobby. I use the appropriate tools when solving engineering problems for that, too. My workshop has a lathe, a mill, a CNC mill, a drill press, a CNC plasma cutter table, a bandsaw, a 30 ton press, multiple cold metal benders, MIG and TIG welders, welding tables, half a dozen angle grinders, multiple pedestal grinders, a couple of dozen air-powered tools for different things (hammers, scalers, die grinders, etc), and so on. These are all tools needed to do specific jobs efficiently and effectively.

I use the best tool I can afford to get the job done. I can cut and shape metal with an angle grinder, but it is slow. Yes, it's cheap, and that's how I've cut metal for a long time. A year ago, I bought a small CNC plasma table. I can now cut out the same piece of metal drawn from a cardboard template in about 1/10th the time it takes with a grinder. It's so much faster than manually cutting metal that I can't ever see myself going back to the old method, because I get a better product with less waste in 1/10th the time using the plasma table. And if I have to make a dozen pieces, I just press a button and I've got all the pieces in about 1/50th of the time than doing via manual process.

So, yes, I can make all the parts I need using a grinder and manual process, but all the time I spend doing this rather than using the plasma table is time I'm not spending -improving my cars-. i.e. my goal is to make my race cars faster, not *use a grinder to make parts*.

Why is this relevant? Like cutting out parts manually by hand with a grinder, writing code manually by hand is -slow-. The goal is to have robust, reliable working software in the hands of users, not to "write code". Yes, I can "write code", and have for the last ~35 years of my life, but "writing code" has never been the end goal. The end goal has always been to deliver new and/or improved functionality to users.

As such, I've always considered writing code to be painful because it is so much slower than my thinking speed. I'll solve a problem in my head in a few minutes, then it can take -days or weeks- for me to write the patchset that realises the solution. This is why I (and the rest of the world) use for "off the shelf" software libraries as much as possible - fast, cheap and gets the job done. (xkcd reference is an exercise for the reader!)

But what happens when that custom, one-off solution can be done as fast as using the (increasingly problematic) off-the-shelve software solution? The economics of the situation change, as does the impact on the engineering process.

This is what LLMs provide: they can speed up the implementation to the point where finding the design level solution is the bottleneck in the process. i.e. with an LLM, I can implement a solution as fast as I can think, rather than as fast as I can type. This is important, because the scope of problems I'm typically trying to solve result in thousands of lines of code change. LLMs allow me to change my processes for the better, similar to using a CNC plasma table in the workshop.

So, when it comes to "writing code" with an LLM, I'm reviewing every single hunk of code that is -predicted- by the LLM, and correcting it immediately. Remember: LLMs predict (like a soothsayer), they don't "generate" or "write". Hence what I'm doing is correcting predictions (i.e. closing the feedback loop) at the time the predictions are made, rather than letting prediction errors build and superimpose (i.e. what vibe coding does). It's not uncommon to take 5-10 review iterations per patch to get the code to how -I would write it-, but the difference is that this takes a few minutes at most, the code compiles first go, and it generally works first go, too.

Compared to me manually typing out the code, (apart from speed), it generally takes me several iterations just to get anything moderately complex to compile (e.g stupid typos). Then the code is full of stupid bugs from stupid typos, "fingers don't type what the brain is thinking" logic fubars or just off-by-one-because-I-didn't-think-about-it stuff like "<" rather than "<=".

These sorts of bugs are inherent in the exercise of manual coding, and won't get caught until the code is tested. Even then, there is a good chance that testing won't find them and they slip through into production.

Hence our software engineering process has a hard dependency on our testing catching all the stupid implementation bugs, as well as all the other implementation and design bugs that might occur. We all know that testing won't prove the absence of bugs, and the inability for testing to find all bugs is one of the reasons why modern software, in general, sucks. Further, from a process POV, these stupid implementation bugs result in testing taking longer because we're always dealing with random unexpected crashes, panics and weird behaviour.

IMO, having to rely on testing to catch this class of "coding" bugs points to how poor our traditional software development tools really are.

LLMs don't make these silly coding mistakes.

I've found that "Pair Programming" with an LLM has eliminated this entire class of code bugs from my engineering workflow. It's not just that the LLM is a faster way to write code, it eliminates many of the downstream issues that result from non-obvious coding mistakes, especially in C code. Not having to reproduce and debug multiple different random crashes makes the code-test-fix part of the implementation phase of the SDLC go much, much faster.

But the LLM provides more than that - I won't start "coding" until I've built a workable design and broken it down into individual change-per-patch tasks. I do this entirely in the LLM, generating design and architecture documentation as I go. The documentation falls out of the process of using the LLM for analysis and verifying proposed solutions. I use the LLM as a analysis and verification tool at the high level, speaking to it as a peer, using natural language, until I have a solid solution to the the problem that neither I nor the LLM can poke holes in. The design documentation just falls out of this process automatically.

It is at the higher levels of abstraction (i.e. architecture/design) where LLMs are weak. They can't predict through more than a couple of layers of abstraction, whereas I can easily think through a dozen or more layers and make connections to completely unrelated aspects of the system design and architecture. However, once the LLM is made aware of such a connection, it will do a great job of analysis and finding potential issues. If you only interact with the LLM as if it is an untrustable machine, or purely as a replacement for "programming", then you are not making use of the vast capabilities they provide us with.

If you have a robust solution in the form of a design document, then it is relatively trivial to translate that to almost any common programming language - all you need to know is how to program in that language. With an LLM, I don't need to care about the implementation language. I don't need to be a python expert, a yaml expert, a C expert, a rust expert, a shell expert, a CI expert, etc. With LLMs, the software implementation language of the solution just doesn't matter any more - what is important is that the engineer running the LLM understands the problem and has built a robust solution at the design level.

LLMs are not replacing "writing code". They are replacing the translation of software design language into the implementation language. LLMs also help build and document that design language description; they work really well when you integrate them with a traditional waterfall SDLC model approach to problem solving. Engineering processes (i.e. SDLCs) are what build
complex, robust, reliable software systems, and IMO LLMs are the best tool currently available for optimising away large chunks of this (human error prone) process.

If you have a solid design, there is no reason at all for there to be bugs in the implementation. LLMs go a long way to providing us with the capability of performing bug-free design to implementation language translation. If LLMs keep improving at the rate they currently are, then soon we are going to be able to remove this error prone manual implementation (i.e. "programming") step from our SDLC entirely.

Whether you like it or not, LLMs are the biggest disruptive change that has ever occurred in the software industry. They aren't going away any time soon....

-Dave.

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 23, 2026 0:26 UTC (Thu) by alx.manpages (subscriber, #145117) [Link] (2 responses)

> LLMs don't make these silly coding mistakes.

I have a very different experience, it seems.

Every now and then, some contributor sends me patches created with an LLM, and they're full of silly mistakes. The funniest ones are when it gets it right in one line, and two lines below it makes a silly mistake when doing the same exact thing, and in a way that even a stupid human wouldn't.

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 23, 2026 0:36 UTC (Thu) by pizza (subscriber, #46) [Link] (1 responses)

> Every now and then, some contributor sends me patches created with an LLM, and they're full of silly mistakes. The funniest ones are when it gets it right in one line, and two lines below it makes a silly mistake when doing the same exact thing, and in a way that even a stupid human wouldn't.

This is an everyday occurance for me now.

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 23, 2026 7:49 UTC (Thu) by alx.manpages (subscriber, #145117) [Link]

To clarify, most LLM-generated patches that I receive have these silly mistakes. It's just that most patches that I receive don't derive from LLMs, as the project policy disallows that, and most people are following it.

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 23, 2026 0:29 UTC (Thu) by dskoll (subscriber, #1630) [Link] (23 responses)

I'm an engineer who uses tools to solve problems and create new things. For a software engineer, "writing code" is a necessary evil - it's part of the job.

I've always been a bit skeptical about applying the term "engineer" to a software developer, for the simple reason that I don't think software development really is engineering.

In my opinion, having studied electrical engineering but worked mostly in software development, the software development industry does not have the same kind of processes in place that traditional engineering does, and it's much less cut and dried. I think there's a lot more creativity and even artistry in making good software than there is in designing a circuit or a chemical process or an HVAC system. (In civil engineering, all of the creativity and artistry is in the architecture field.)

That is why some people, myself included, don't like using LLMs. I and others feel it takes away the creativity and artistry from the process and (for me, anyway) sucks all the joy out of it.

I build and race cars as a hobby.

If an LLM-powered robot could do most of what you do, would you still find your hobby as enjoyable?

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 23, 2026 5:24 UTC (Thu) by dgc (subscriber, #6611) [Link] (22 responses)

> > I build and race cars as a hobby.
>
> If an LLM-powered robot could do most of what you do, would you still find your hobby as enjoyable?

Ok, I think might not have grasped the context of the example I gave.

In the example, I pointed out how using a CNC robot (CNC = Computer Numerical Control) has made my hobby better and more enjoyable because I don't have to do noisy, dirty, somewhat dangerous and sometimes tedious manual work as much anymore.

I don't know how the articulated arm of the CNC plasma cutter robot works. It doesn't matter to me one little bit if the computer behind it is using LLMs - all I care about is that it turns my drawing into a matching piece of metal faster and better than I can. That's what it was advertised to do, that's what I bought it to do, and all I care about is that it does what it is supposed to do.

Does that answer your question?

As for creativity vs engineering and LLMs? My creativity is apparent when I'm trying to understand a complex problem and gain unique insight that provides a neat and clean solution. After that, anyone can write the code once they know the solution that needs to be implemented. However, it takes creative thinking to go outside the box and come up with a novel technique, algorithm, structure, etc that solves the problem in the first place.

So neither engineering process nor LLMs are robbing me of any of my creativity or artistry - I hang my medals from the problems I have solved, not the tools I use or the code I wrote to implement those solutions.

-Dave.

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 23, 2026 11:43 UTC (Thu) by pizza (subscriber, #46) [Link] (13 responses)

> Ok, I think might not have grasped the context of the example I gave.

This goes both ways; you may not have grasped the context of the responses.

Would you still enjoy "building" those cars if you are, instead of doing the design and fabrication and assembly yourself, you are directing robots to do all of that for you? In that context, can you even claim that you are "building" the car at all, as opposed to simply "getting someone else to build a car to your specifications"

Similarly, would you still enjoy racing cars as a hobby if, instead of you doing the actual driving, you are directing a robot that does the driving for you?

Because that's what you're advocating in the context of other folks' hobbies [/professions]

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 23, 2026 13:37 UTC (Thu) by paulj (subscriber, #341) [Link] (12 responses)

I had a very similar discussion with my AI-besotted colleague. About how much more efficient it makes coding for them. (note: to my eyes, it has merely allowed that colleague - who was not very strong on coding before - to now be able to produce code where they could not before; except of course the quality is often very poor, and said colleague lacks the coding ability to even detect the problems). And gushing how much better things would be, and how I should take it up (note: I have used local AI before - my own findings are it is good for finding outlines / constructions that you didn't know about, particularly in using APIs / frameworks, which you then take forward yourself, i.e. as a somewhat context aware search engine; but that if you go much further with it, it produces code with many little and not so little errors, and you end up spending more time finding and fixing those than you would if you just wrote it yourself, so I just stopped with it there really). And he made similar points that we've heard here about how tools and automation has made traditional carpentry obsolete.

My counter-example to him was to ask him what he would rather be, a master carpenter who used his own skill and creativity to produce amazing pieces of work - demand for which still exists today, and is well remunerated (even if niche); or to be a factory worker standing at some kind of CNC machine feeding in the sheets of fibre-board for the machine to cut?

I would rather be the (aspiring) master carpenter. I don't care how efficient the computer tools are that nominally allow the factory workers to be much more productive than me. I am sure the master carpenter is a lot more satisfied. We have in our family a couple of the masterpieces that my great-grandad - a furniture maker - made. Cabinets and chairs with wonderful inlays and amazing decorative carvings, objects that are not just still useful, but amazing to behold and will (hopefully) still be in another 100+ years. No AI-whisperer will ever produce stuff like that. (And just read all those "AGENT.md" and other markdown documents for AIs that people have to write - it's a strange mix of psychology and and sooth-saying - and people really want /that/ to be their life's work?!!!).

AI-whisperer, mindless factory work, or master carpenter... I guess we all just have to choose our paths.

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 23, 2026 18:48 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (11 responses)

I like masterful carpentry and bespoke hardware as much as everyone else.

But I'd rather be a production engineer who makes furniture easily accessible for _everyone_ rather than just the richest people. IKEA is one of companies that I deeply respect.

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 24, 2026 8:42 UTC (Fri) by paulj (subscriber, #341) [Link] (10 responses)

Back in the era where my great-grandfather (and many others) were master carpenters producing amazing furniture, far *more* middle-class families were able to afford amazing furniture. Older furniture, that once was common in the homes of all middle-class families, is now sought after. That furniture then was largely made by craftsmen meant there was *far more* good, strong, furniture around - and the pieces that were looked after survive to this day.

Now, there was also a larger class of destitute people and near-destitute working-poor, who could barely afford any kind of furniture and what they did have would generally have been very roughly worked. However, that's not directly related to the fact that the educated classes - professionals, but not per se rich - as a matter of routine furnished their houses with items of *far* greater quality (and often 1 or 2 very high quality "show" pieces, e.g. for the receiving room, to impress visitors) than what similar professionals are able to afford today.

Perhaps you want to argue that having a large class of skilled craftsmen, able to produce such high quality items, is somehow connected to a society in which a great many are poor. But... then.. your argument would also apply to today's world, where (in the west) we are reverting back to a large class of near-destitute-poor (1 or 2 pay cheques away from financial ruin), who own very little, and owe very much to a wealthy rentier class. There'd be so many subjective and speculative aspects to that discussion it's not really worth having. However, I'll just put my stake my in the ground that I don't believe it's true that having lots of skilled labour must imply many can not afford basic items like furniture - I think the opposite is true, lots of skilled labour involved in making things means more high-quality goods, less crud (like always-wobbly, never-going-to-last, ugly, chip-board, cheap flatpak furniture); and that the proportion of destitution and poverty in a society is mostly an orthogonal question.

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 24, 2026 9:27 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

> Back in the era where my great-grandfather (and many others) were master carpenters producing amazing furniture, far *more* middle-class families were able to afford amazing furniture.

This is just a case of survivor bias. The vast majority of carpentry was average and did not survive to this day. And a lot of good carpentry survived because it used to be a major purchase to show off the status of the family.

IKEA and modern construction techniques caused the market to compress. Now the cheapest furniture that _anyone_ can afford is perfectly adequate and works well. Almost all of my moveable furniture is from IKEA and some items have survived for 20 years without any issues. It's light, sturdy, and I happen to like its style.

Will my IKEA furniture be treasured in 70 years? Unlikely. And that's the point. It's not a luxury item, it's functional goods that improve lives.

I can really appreciate it. I grew up in the USSR where the apex of furniture design was creaky chairs and uneven foldable tables.

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 24, 2026 9:35 UTC (Fri) by malmedal (subscriber, #56172) [Link] (8 responses)

> Back in the era where my great-grandfather (and many others) were master carpenters producing amazing furniture, far *more* middle-class families were able to afford amazing furniture.

How about you specify the exact time-period, country and region this supposedly happened?

Oh, and also specify the planet, because on planet Earth the middle-class is a post-WWII phenomenon which was enabled by mass production, not master craftsmen, starting in the US and spreading from there.

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 24, 2026 10:00 UTC (Fri) by paulj (subscriber, #341) [Link] (7 responses)

I don't actually know exactly when, but my great grand-dad would have been working in the late 19th Century. In western Europe.

That middle-class is some kind of post-WWII American thing is... just wrong. There most definitely was a professional or mercantile, educated middle-class in Europe pre-WWII and pre-WWI. Not as large, proportionally today (i.e., there was a much larger working-poor class - as I already wrote), but it was there.

I suspect you may have a somewhat US-centric view of things, but industrialisation - which brought significant urbanisation and greater professional/mercantile middle-classes - occurred earlier at scale in western Europe than in the USA (as a whole) perhaps. Visit any of the major centres of the industrialisation era in the like of the Celtic Isles (London, Glasgow, Belfast, etc.) or the mercantilist parts (which benefited themselves from industrialisation, but had already significant mercantile classes /long/ before) like Amsterdam and you will find plenty of (what we would recognise today as) middle-class housing from the early 20th C and even the late 19th C. I.e., rows of houses in urban setting that would have been occupied by lower-middle-class and middle-class professional and mercantilist families.

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 24, 2026 10:48 UTC (Fri) by malmedal (subscriber, #56172) [Link] (6 responses)

> That middle-class is some kind of post-WWII American thing is... just wrong.

No, it was an entirely new thing. Not that somebody always are in the middle, that's just math. But the way society went from being a pyramid where people at the top had power to a rhombus(diamond) shape where the middle class is politically and economically important, that was unprecedented.

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 24, 2026 11:14 UTC (Fri) by paulj (subscriber, #341) [Link] (5 responses)

This occurred before WWII, at least in the parts of Europe I'm familiar with.

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 24, 2026 12:24 UTC (Fri) by malmedal (subscriber, #56172) [Link] (4 responses)

I think you'll be surprised if you dig into the actual statistics. For instance pre-war Netherlands may superficially look like that, but much of their prosperity came from colonial extraction, unlike the US where the value was overwhelmingly created inside the country.

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 24, 2026 12:53 UTC (Fri) by paulj (subscriber, #341) [Link] (3 responses)

I'm not surprised at all. I referred above to some of the wealth predating industrialisation and being mercantilist in nature. An oblique reference at least to trade in colonially-sourced goods.

Also, I am baffled that you think the USA is an example of a state that did *not* gain its wealth from colonial extraction. I might have to print that comment out and frame it. It's just so wrong in so so many ways.

anyway.. well OT now.

Off-topic indeed

Posted Jul 24, 2026 13:48 UTC (Fri) by corbet (editor, #1) [Link]

I think the time has come to wind down this sub-thread, thanks.

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 24, 2026 15:04 UTC (Fri) by malmedal (subscriber, #56172) [Link] (1 responses)

> I might have to print that comment out and frame it.

Maybe put some efford into reading it?

To reiterate my position, the modern concept of "middle class" does not come from "master craftsmen" selling to each other. This cannot work.

Instead what happened was that after WWII, factories switched from producing weapons to civilian goods. This led to a long economic boom and society changed from being pyramid shaped with most people being poor at the bottom, to a diamond shaped where most people found themselves comfortable in the middle.

This was entirely different than the dynamic seen earlier with various mercantilist colonial schemes.

The US colonial adventures where not economically significant at this time. The value was overwhelmingly coming from inside the country itself.

Instead of doing extraction the US provided generous aid with e.g. the Marshall Plan.

While this behaviour did not last forever, it did happen, and was hugely significant.

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 24, 2026 16:01 UTC (Fri) by daroc (editor, #160859) [Link]

I think this thread has started to wander off-topic; there are many other places to learn about the historical development of our modern class system.

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 23, 2026 14:56 UTC (Thu) by dskoll (subscriber, #1630) [Link] (7 responses)

No, I meant would you still enjoy building cars if all you had to do was prompt an AI to do it on your behalf, and not do anything else other than perhaps looking at the results and tweaking the prompt? Because that's where we're heading with software development.

However, it takes creative thinking to go outside the box and come up with a novel technique, algorithm, structure, etc that solves the problem in the first place.

Again, that's where LLMs in software development are heading. I don't think people come up with algorithms or data structures when they use an LLM to write software. They simply prompt it with what they want the end result to be, and the LLM takes care of the algorithms, data structures, etc. all the way down to spitting out the final code.

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 24, 2026 9:23 UTC (Fri) by taladar (subscriber, #68407) [Link] (5 responses)

I would really like to know what kind of programming you do where you think you are coming up with new data structures on a daily, weekly, monthly or even annual basis. Most programmers do very little but reuse existing data structures for the entirety of their careers. Sure, in some primitive languages like C you might have to re-implement that data structure countless times but that doesn't mean you came up with it.

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 24, 2026 11:13 UTC (Fri) by Wol (subscriber, #4433) [Link] (1 responses)

> I would really like to know what kind of programming you do where you think you are coming up with new data structures on a daily, weekly, monthly or even annual basis.

I do it all the time, but I think we are taking "data structure" to mean two completely different things.

You clearly mean "array" or "linked list" or whatever the container-du-jour is.

I mean "a trailer has a journey start, a capacity, an origin, a destination, ..." and then choose whatever data container just happens to be appropriate for the contents.

Same words, different viewpoint, completely different meaning.

Cheers,
Wol

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 24, 2026 11:23 UTC (Fri) by taladar (subscriber, #68407) [Link]

Sure, technically every product or sum type could count as a new data structure but in terms of programming being interesting because you get to write those I don't really feel they count.

Maybe something like a list that also has some hashmap of direct access pointers or similar things would be a good middle ground that is still interesting enough to count as mentally stimulating but not quite the strict college course "data structure" that only gets created by a small number of people and reused by everyone else.

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 24, 2026 12:00 UTC (Fri) by mbunkus (subscriber, #87248) [Link]

I read Diane's comment more like "let the LLM take care of selecting which algorithms to use, how to organize data into data structures" etc — not coming up with new algorithms herself.

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 24, 2026 12:23 UTC (Fri) by dskoll (subscriber, #1630) [Link]

My response was to the person who said humans come up with the algorithms and data structures and the LLMs just spit out code. I don't think that's true. I think the LLMs produce the algorithms and data structures too, for the reason you allude to: Most software doesn't require novel algorithms or data structures.

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 25, 2026 15:04 UTC (Sat) by alx.manpages (subscriber, #145117) [Link]

I write very simple C code, with very few and simple data structures, where the most common one is just C strings. I don't invent new data structures, because the simple ones work just fine.

However, I do invent new functions for dealing with strings continuously. I've been researching and improving the <string.h> set of functions with safety and simplicity as a goal, for the last 5 years or so, in programs dealing with /etc/shadow and related databases, and I expect I will continue doing this for many years to come, because there are many details that still need to be polished.

It's very entertaining, and I feel like doing puzzles when I do it. I did it for free before getting paid to do it, so you can guess I enjoy it.

I can't understand those who claim to hate typing code, or who feel it's not productive. Typing speed is far from being my bottleneck. Even when I have to do huge refractors, typing speed is not my bottleneck. And thinking about how to do it is also not my bottleneck.

My bottleneck is reviewer time. I often have two people reviewing my code, and their time is the scarcest resource, by a large margin. And by large, I mean we have a queue where some patches were written 2 years ago, with the average patch written maybe 1 year ago.

LLMs wouldn't help with that, because we still need a human fully understanding the code and giving an okay. LLMs could in theory improve the quality (by finding bugs not spotted by those reviewers), but certainly not decrease the review time, because the understanding of the human must still be there (or we'd be blindly trusting the LLM).

However, given that the lifetime of my patches (the time since I first write them until they're merged) is around 1~2 years, the number of bugs tends to be quite small: I have plenty of time to re-think them, and re-test them, and spot the few bugs that may happen, even before the review starts.

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 25, 2026 10:58 UTC (Sat) by mathstuf (subscriber, #69389) [Link]

> I don't think people come up with algorithms or data structures when they use an LLM to write software. They simply prompt it with what they want the end result to be, and the LLM takes care of the algorithms, data structures, etc. all the way down to spitting out the final code.

I think there's a spectrum. Yes, some people are using LLMs (and agent harnesses) to make "promptware" where all they do is request something, maybe with some restrictions, and accept the results. Others (like myself) use it occasionally to help get over a "writer's block" to help stop staring at a blank page. I know the problem, the shape of the solution, but it's kind of a Cunningham's Law situation: it's easier to find motivation (for some) to tweak something that is close than to start from scratch.

I still have my own (high) quality controls that the code needs to meet before I toss it out there (I suspect dgc has a similar bar). Though I have used it to help make changes in unfamiliar languages (Swift and Golang) where I can spot check the behavior but am completely out of my depth on conventions and whether the change is idiomatic (and disclose such if/when they become PRs; an example: https://github.com/openai/tart/pull/1279).

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 23, 2026 0:34 UTC (Thu) by pizza (subscriber, #46) [Link] (6 responses)

Something I have to correct you on:

> LLMs don't make these silly coding mistakes.

They don't make "silly typo" mistakes; they instead massively amplify them; confidently build large edifices on top of whatever silly typos were made in their training material.

...Today I had to deal with LLM producing, back-to-back, two diametrically opposed outputs (effectively an "A = !A" situation) it justified with *identical* citations. Both were completely wrong because their source of "truth" was itself wrong.

Writing code is the easy part. Verifying the correct code was written is much harder. Doing that verification without the benefit of "I spent a lot of time with the spec in the process of writing the code" self-training... goes another magnitude beyond that.

> If you have a solid design, there is no reason at all for there to be bugs in the implementation.

That leading "If" is carrying so much weight it might as well be a spherical cow for its semblance to reality.

> Whether you like it or not, LLMs are the biggest disruptive change that has ever occurred in the software industry. They aren't going away any time soon....

I'm quite confident that the twilight of my career will consist of making a large pile of money as a consultant brought in to clean up after rampant LLM use.

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 23, 2026 6:14 UTC (Thu) by dgc (subscriber, #6611) [Link] (4 responses)

> > LLMs don't make these silly coding mistakes.
>
>They don't make "silly typo" mistakes; they instead massively amplify them; confidently build
> large edifices on top of whatever silly typos were made in their training material.

Then, IMO, you are using them incorrectly. I -never- let the LLM code do what it wants to do. I review every line of code it produces as it produces it, and correct it -immediately-. I do not let them build stuff themselves, I use them to build exactly what I want to build, and I use them to do this because it is much faster than using vim or emacs to type the code.

I keep the LLM under tight control; if it gets into a situation like this:

> ...Today I had to deal with LLM producing, back-to-back, two diametrically opposed outputs
> (effectively an "A = !A" situation) it justified with *identical* citations. Both were completely
> wrong because their source of "truth" was itself wrong.

at any stage (design, analysis, coding, etc), then I immediately stop it and tell what it should be doing, confirm that it has understood what it should be doing, and move on to the next part of the problem.

Yes, LLMs do get stuck, they do propose ludicrous things, they do hallucinate. But that doesn't make them a bad tool - just not a perfect one. Hence it's on the tool user to catch and correct these deviations before they become a problem, just like it is on senior engineers to catch and correct mistakes made by eager young junior engineers before they become a problem...

It should be obvious by now I am not advocating that "LLMs are perfect, we should just go vibe code everything" - the process I use is the *exact opposite*. I do not trust the output of the magic prediction machine any more than I trust what a fortune teller tells me about my future. However, I am of the opinion that what LLMs bring to the software engineering toolkit is sufficiently important to spend some of my time trying to help people learn how to use LLMs effectively rather than just shout "get off my lawn" at them all day.

-Dave.

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 23, 2026 11:33 UTC (Thu) by pizza (subscriber, #46) [Link] (3 responses)

> Then, IMO, you are using them incorrectly. I -never- let the LLM code do what it wants to do. I review every line of code it produces as it produces it, and correct it -immediately-.

Good for you. Pray tell, how do you get *EVERYONE ELSE* to do that?

> at any stage (design, analysis, coding, etc), then I immediately stop it and tell what it should be doing, confirm that it has understood what it should be doing, and move on to the next part of the problem.

You attitude supposes that *you* are the one (directly) directing an LLM, as opposed to having to you review patches produced by someone else's use of an LLM.

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 26, 2026 13:02 UTC (Sun) by dgc (subscriber, #6611) [Link] (2 responses)

> > Then, IMO, you are using them incorrectly. I -never- let the LLM code
> > do what it wants to do. I review every line of code it produces as it
> > produces it, and correct it -immediately-.
>
> Good for you. Pray tell, how do you get *EVERYONE ELSE* to do that?

Same way as we change any other poor engineering practice for the better: education and peer pressure.

Be a leader: try teaching people how to use LLMs properly within existing OSS project frameworks. We need more leaders who want to change things for the better, and less people who simply shout "get off my lawn" whenever change comes along.

-Dave.

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 26, 2026 15:14 UTC (Sun) by pizza (subscriber, #46) [Link] (1 responses)

> Same way as we change any other poor engineering practice for the better: education and peer pressure.
> Be a leader: try teaching people how to use LLMs properly within existing OSS project frameworks

In other words, your solution is... "work even harder, still for free"?

That sort of "leadership" is why we're in this mess to begin with.

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 26, 2026 15:41 UTC (Sun) by pizza (subscriber, #46) [Link]

>> Be a leader: try teaching people how to use LLMs properly within existing OSS project frameworks
> In other words, your solution is... "work even harder, still for free"?
> That sort of "leadership" is why we're in this mess to begin with.

Just to be clear, while I wrote "work even harder" it was from the perspective of F/OSS maintainers, but it goes both ways.

We have been "trying teaching" all along. It. Does. Not. Work.

Succeessful "teaching" requires that the recipient is willing (and able) to learn, which in turn requires them to put actual effort into what they are doing. Quite franky, the vast, vast majority of LLM "coders" are emphatically *NOT* willing (or able) to do this, and maintainers are sick of trying.

Many thoughts - let people do what they want, but hold people accountable for their work - but also keep the ethics.

Posted Jul 25, 2026 11:00 UTC (Sat) by mathstuf (subscriber, #69389) [Link]

> I'm quite confident that the twilight of my career will consist of making a large pile of money as a consultant brought in to clean up after rampant LLM use.

One team has already started: https://odra.dev/slopfix/

Then maybe the job isn't for you?

Posted Jul 23, 2026 14:37 UTC (Thu) by jpeisach (subscriber, #181966) [Link] (3 responses)

> For a software engineer, "writing code" is a necessary evil - it's part of the job.

Even if parts of code is repetitive, the variable names, the context you're using it for, hooking it up to your application, testing, is all unique. And trying to do things the "right way" by looking at other abstractions and figuring out "what can I do that isn't overkill"?

Here is how I first started programming. It was a Minecraft mod. I followed YouTube tutorials and made a (crappy-textured but working) mod.

At that point, you are writing code, and you got to control what the code does. And you saw how it changed things. If I wanted to make, lets say, a pickaxe break bedrock (which, you actually can if you give the pickaxe enough strength), you change the value of the float or whatever handles it.

Want another item? Awesome - you can make your own instance of an item class, extend all the properties, do whatever you want, and you get to hook it back in to the main game by registering it, and boom, you got it.

That was not a waste of my time. That was FUN.

Coding is a mix of problem solving with creativity. You can do what you want. Why would you want to get rid of the problem solving? I guess if you are vibe coding, you are problem solving, but you lose the experience of understanding what is happening. Believe me, I have reviewed kernel patches, nothing major, but unless you type them out, test them, read documentation, look at other examples and make a good judgement on "yes, this is how it should work", then you still don't understand the codebase and the reasoning for why each line of code was written that way.

Is it possible we are just heading to more abstraction? Absolutely. But I'm not sure if I'm ready for it yet. And I don't know if it will take away jobs and the fun I have in it.

Okay, another example. Lets go back to the basic hello world. You get to create a function, call a method, compile something, and wow, you printed something to the terminal. Cool!

Later, I can iter over a buffer or array. Honestly, iteration in general is cool. And again, there are so many ways it can be applied!

I know I'm speaking to someone who is twice, possibly thrice my age or older, but if you don't enjoy "writing code", the actual "doing", then why be a software engineer?

It's like being a lifeguard at a pool, but you don't like having to swim.

Then maybe the job isn't for you?

Posted Jul 23, 2026 20:57 UTC (Thu) by kleptog (subscriber, #1183) [Link]

> I know I'm speaking to someone who is twice, possibly thrice my age or older, but if you don't enjoy "writing code", the actual "doing", then why be a software engineer?

Because I like making the lives of other people easier. The users are the people doing the actual work that earns money for the business. Whatever makes them happier makes me happier. If that means fixing bugs, I fix bugs. If that means building a feature that means they save a hour of time per week doing brain-dead clicking, then I build that. If it means making bash script to deploy a change to a few hundred servers I do that. I like sitting with the users brainstorming about the kinds of things they'd like to be able to do and think how I can make that happen.

Coding is merely the means to an end. And if an LLM can deal with some of the boring coding crap, then I'm going to use it. And it teaches new new stuff: sometimes it comes up with solutions using useful functions I'd never heard of. It's also really good at answering questions of the form "what is the name of the function that does X".

I guess I don't really count as a "software engineer" but that's ok. Titles don't interest me.

> It's like being a lifeguard at a pool, but you don't like having to swim.

If you enjoy seeing people having a great time swimming safely at a pool, I don't see why you have to like swimming yourself.

Then maybe the job isn't for you?

Posted Jul 23, 2026 21:04 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

> if you don't enjoy "writing code", the actual "doing", then why be a software engineer?

There are contexts where I enjoy writing code, but a lot of the code I write for work doesn't fall into that category - it's pretty much a mechanical recapitulation of a specification. In that context the satisfaction comes from having designed and written the specification in the first place, and writing the code is the least interesting or intellectually stimulating part of the process.

Then maybe the job isn't for you?

Posted Jul 25, 2026 11:09 UTC (Sat) by mathstuf (subscriber, #69389) [Link]

> I know I'm speaking to someone who is twice, possibly thrice my age or older, but if you don't enjoy "writing code", the actual "doing", then why be a software engineer?

There are many aspects to a coding and not everyone enjoys the same parts. Me? I like software process and build systems and can discuss them at length. Others? Just GCC and a Makefile and they're satisfied. Some like slinging buffers and triangles in OpenGL; I do not particularly like doing so. Both involve "writing code", but without each here, a project is likely only finding a very narrow user base (which is also fine, but don't then wonder why no one is picking up your `gcc -o prog *.c`-build-system-using project on Windows; same with your "builds nothing everywhere" project).

Opportunities beyond bugs for LLM review

Posted Jul 23, 2026 4:09 UTC (Thu) by irogers (subscriber, #121692) [Link]

There can be substantial delay from a contributor sending a patch to a human (reviewer or maintainer) being involved. Sashiko is very heavily focused on finding bugs, which is great! Whilst humans flag bugs, they also flag stylistic issues, use of old deprecated APIs, etc. These may be more typical reviews compared to finding bugs.

A common piece of feedback can be to cut up a patch series into smaller commits. I wrote a prompt to automate this and while to get it landed I could make it a subsystem only prompt, I think there's a broader applicability to the prompt that could benefit patches across Linux:
https://github.com/masoncl/review-prompts/pull/73
It is written in a way to hopefully avoid needless intermediate or broken patch states.

I suspect other such common behaviors from reviewers/maintainers could also be turned into prompts. This would avoid nagging on the mailing list, but also hopefully make the first review from a human more productive. The prompts could in turn help people understand coding and patch standards, which further tooling could build upon.

"If companies withdraw LLMs"

Posted Jul 23, 2026 12:20 UTC (Thu) by SLi (subscriber, #53131) [Link] (1 responses)

I find the concern of the companies withdrawing access to LLMs a strange concern. Apparently people are still living in the era when LLMs were supposed to be something that only huge corporations can ever dream of. Today, anyone can run on their own hardware LLMs that, sure, lag behind the flagship models, but they're advancing at the same or more rapid pace than the flagship models (the gap is not getting wider).

LLMs are more replaceable than people because they don't remember the context, they reacquire it every time.

"If companies withdraw LLMs"

Posted Jul 23, 2026 12:51 UTC (Thu) by pizza (subscriber, #46) [Link]

> I find the concern of the companies withdrawing access to LLMs a strange concern.

It's not "access to LLMs in general", it's "access to services that provide effectively unlimited access to high-end LLMs that you've based your entire automated workflow around". Losing that, even on just an individual basis (eg due to geopolitical BS), will be quite disruptive in the short-to-medium term..

> Today, anyone can run on their own hardware LLMs that, sure, lag behind the flagship models

The models that can run "on their own hardware" lag in both capability *and* performance. Nevermind that "run on your own hardware" requires a significant investment in said hardware that most kernel contributors are probably not able to afford on their own, especially in the forseeable future.

> LLMs are more replaceable than people because they don't remember the context, they reacquire it every time.

That puts aside that one LLM to the next will need careful (ie time-consuming) prompt/context tuning to achieve similar results.. and even then only for models in the same rough generation+capability bucket. No amount of prompt tuning will make a "can run on consumer hardware" model can make up for the capability gap, and it doesn't take a lot of false positive/negatives before a tool gets relegated into "not reliable enough" dustbin.

Trying to figure out the bigger picture ...

Posted Jul 23, 2026 16:32 UTC (Thu) by karim (subscriber, #114) [Link] (2 responses)

Maybe this is obvious for others, but I have a feeling that there are existential issues at play here for many of the developers involved that are likely unlike anything we've seen in the software development field before.

When open source started to become mainstream in the early 2000s there was a lot of hyperventilation from established players in the industry. At the time *we* (the open source community) were the ones doing the disruption. And we did it with smiles on our faces: we were changing the world for, what *we* felt like was, the better. But we did upend the established norms and, to an extent, the business models and livelihoods of many people out there. Today no one asks if open source is a legitimate way of doing things. It's standard business practice.

This time around disruption is coming for us and how we did things. ... and the hyperventilation is industry-wide, us included ... And, business model and livelihood disruptions are at play. We can certainly debate the "how", but it feels like if you chart it far enough down the line then code generation within the software development process is likely going to also become "standard business practice" (or already has ...)

I won't pretend having any responses or solutions. But this is what comes to mind when reading about this debate.

Trying to figure out the bigger picture ...

Posted Jul 23, 2026 17:49 UTC (Thu) by jpeisach (subscriber, #181966) [Link] (1 responses)

> Maybe this is obvious for others

Well it clearly isn't. Some existing devs will take it up anyway. Which IMO, why even be a dev if you don't like what you're doing? And why force us to change our ways because you don't like what we do?

Trying to figure out the bigger picture ...

Posted Jul 25, 2026 11:15 UTC (Sat) by mathstuf (subscriber, #69389) [Link]

> And why force us to change our ways because you don't like what we do?

"No one" is "forcing" you. The market landscape is changing. Consider the carriage driver's job prospects when cars came out. No one "forced" them to drive a car instead of horses, but the *demand* for such things dried up.

> why even be a dev if you don't like what you're doing?

Many people do not like some aspects of their jobs. I suspect a non-trivial fraction dislikes *all* aspects of their jobs. But opting out of a job means opting out of a lot of other things as well, so the drudgeries get overridden.

A few thoughts

Posted Jul 23, 2026 22:07 UTC (Thu) by IanKelling (subscriber, #89418) [Link]

I found the article very informative. One takeaway for me is that the need for free/libre LLMs is growing. Perhaps the kernel community could at least adopt a policy which aims to elevate those as they come into existence and become known.

More random thoughts,

Posted Jul 24, 2026 0:20 UTC (Fri) by IanKelling (subscriber, #89418) [Link] (2 responses)

Hard not to point out, "Don't try to enforce your ethics on others", says the only person who's implemented a ban from .ru email addresses for any major free software project likely largely because of that person's ethics. (The lawyer written justifying document has failed pretty hard at convincing the rest of the free software community). And the license of the software we are talking about most certainly all about ethics. Not everyone is going to agree about ethics and the power of one person's ethical convictions often hold greater sway, but there has to be some room for people to make an argument and convince others, or not. There is an incentive built in to the argument that "these are useful" to both censor and fight the censorship, because if it reduces 10% of work, but you spend 10% of your time debating ethics, the argument is lost. A lot of ethical complexity will go away when using free/libre LLMs, so if we consider them to be the goal, that will help with the debate. Among other things, we'll be able to say how much computation requires to train any specific free llm.

More random thoughts,

Posted Jul 24, 2026 8:22 UTC (Fri) by bluca (subscriber, #118303) [Link]

> the only person who's implemented a ban from .ru email addresses for any major free software project likely largely because of that person's ethics

Except of course that didn't happen, what happened is that entities tied to Putin's criminal war machine were banned as they are (rightly) sanctioned by many governments in the world, including Europeans and Americans. And rightly so - fuck Putin and his criminal and genocidal war of aggression against Ukraine

> The lawyer written justifying document has failed pretty hard at convincing the rest of the free software community

Also untrue, projects that matter do not accept contributions from sanctioned entities either. Of course random developers in their random pet projects will hardly pay attention to these matters, but that's understandable and doesn't matter much in the grand scheme of things

More random thoughts,

Posted Jul 24, 2026 9:31 UTC (Fri) by taladar (subscriber, #68407) [Link]

Apart from the point that sanctions are government actions that major projects merely comply with because they are legally required to there is also nothing inconsistent about the view "my projects get to enforce my ethics but I don't care about making them a battleground for every individual contributor's ethics".

Long article?

Posted Jul 24, 2026 15:45 UTC (Fri) by marcH (subscriber, #57642) [Link] (1 responses)

> As anybody who has made it to the end of this overly long article will have long since realized,...

Long but I without any "fat" I could see. As always, thanks for the incredibly good reporting. Saves so much time! Almost like... some AI wrote it? :->

Long article?

Posted Jul 24, 2026 15:59 UTC (Fri) by daroc (editor, #160859) [Link]

No, I'm afraid you're not getting rid of us that easily. :)

LWN is still a human-only operation ... although I wouldn't be terribly surprised if Jon turns out to be a terminator sent from the future to ensure the kernel remains well-documented, given how much work he puts in.

Off Limits

Posted Jul 25, 2026 8:10 UTC (Sat) by chuckwolber (✭ supporter ✭, #138181) [Link]

> But, according to Torvalds, that entire discussion is off limits; the only aspect of the problem that can be talked about is ""technical reasons"" and whether the tools are useful.

I recognize that Linus used the literal words, "So this is where the discussion ends.", but I do not interpret that as establishing an invariant. Staking out an ethical position without full context is fraught with danger, and that is how I interpret Linus' follow-on statement, "If you don't have technical reasons, you don't have reasons.".

A technical position is only possible once you can establish full context. This is how courts of law work, and why legislation is so darn difficult.

So I really see this as an admonition to take the ethical conversation to an appropriate venue and to come back once the full context has been established. In other words - go have the discussion, but go have it with people who _want_ to have that discussion, and are motivated to put it on firm ground.

Gather the evidence and establish your point, but stop attempting to write the new textbook chapter on the kernel list.

Then, and _only_ then, bring the established ethical concern back to the kernel community. I am certain the kernel community will do the right thing once sufficient clarity has been established.

It always has.