A Debian general resolution on LLM usage [LWN.net]

The Debian project is considering a general resolution on the use of large language models in the creation of the distribution. There are three alternatives to consider: a total ban on LLM usage, rejecting LLMs "as far as practical", or explicitly allowing LLM usage subject to a set of conditions. The discussion period has just begun; the beginning of the voting period does not yet appear to have been set. Those who want to look over the discussion ahead of the inevitable LWN article can find it over here.

to post comments

llms are here to stay

Posted Jul 26, 2026 6:08 UTC (Sun) by drago01 (subscriber, #50715) [Link] (102 responses)

There is no point in fighting or trying to ban them.

Energy is better spent on how to best utilize them, how to proper review their output etc

llms are here to stay

Posted Jul 26, 2026 8:28 UTC (Sun) by pwithnall (subscriber, #97459) [Link] (83 responses)

I think a lot of people would disagree with you there. If there are people who think LLMs should not be used, then we know there are people who will maintain Debian without using them.

It’s not like all the existing tools and methods for maintaining software have suddenly disappeared.

llms are here to stay

Posted Jul 26, 2026 9:26 UTC (Sun) by dgm (subscriber, #49227) [Link] (82 responses)

The problem is not what can be done, but what is practical.

It's the story of Mel, the real programmer[1], all over again. Sure, you could aim to develop a whole distribution in assembly (or directly in hex), instead of using these pesky compilers you cannot trust anyway[2]. But what would you gain from the exercise? Would it be in the best interest of the public?[3]

In my opinion, only big corporations will win if Debian make themselves irrelevant, by slowing down development and bug-fixing, in pursue of some more than questionable moral superiority.

Linus holds a similar view, AFAIK, thus expect the Kernel Debian relies on to accept more and more AI contributions, not less. Will Debian migrate to Hurd, then?

---

1. https://users.cs.utah.edu/~elb/folklore/mel.html
2. https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_...
3. Isn't Debian supposed to be "Software in the Public Interest", after all?

llms are here to stay

Posted Jul 26, 2026 9:32 UTC (Sun) by pwithnall (subscriber, #97459) [Link] (27 responses)

> It's the story of Mel, the real programmer[1], all over again. Sure, you could aim to develop a whole distribution in assembly (or directly in hex), instead of using these pesky compilers you cannot trust anyway[2]. But what would you gain from the exercise? Would it be in the best interest of the public?[3]

Nobody here is proposing to develop a whole distribution in assembly.

> In my opinion, only big corporations will win if Debian make themselves irrelevant, by slowing down development and bug-fixing, in pursue of some more than questionable moral superiority.

If you read the proposals, they contain a mixture of practical and moral reasons why this set of people object to LLM usage in various contexts. In my view, Debian’s slow development is one of its strengths, and some of the proposals explicitly embrace this. By slowing down development you might slow down bug-fixing, but critically you also slow down bug-introducing.

> Linus holds a similar view, AFAIK, thus expect the Kernel Debian relies on to accept more and more AI contributions, not less. Will Debian migrate to Hurd, then?

Have you read the proposals? None of them are saying Debian will not accept upstream source tarballs on the basis of whether they contain LLM contributions.

llms are here to stay

Posted Jul 26, 2026 14:16 UTC (Sun) by emk (subscriber, #1128) [Link] (13 responses)

> Nobody here is proposing to develop a whole distribution in assembly.

I am old enough to remember a time when micro BASIC was a bit "mickey mouse," mostly intended for kids and amateurs, and any serious commercial software would naturally be written in assembly. So I see what the other poster is saying here, at least: They believe that LLMs are a bit sketchy and amateur now, but that they are also rapidly becoming a part of professional software development as technology changes.

I have deeply mixed feelings on this (more on that below), but I think the other poster's reference to Mel is coherent and makes a reasonable point.

> Have you read the proposals? None of them are saying Debian will not accept upstream source tarballs on the basis of whether they contain LLM contributions.

That is explicitly called out as a possible future extension in the original GR: "Other categories such as upstream projects written with LLM assistance may be included at a later date." So I'm inclined to consider that as a future possibility that the organizers might push for later.

So, as for my thoughts on LLMs... These are unfortunately complex.

1. I have spent decades contributing what I could to free software in the vain hope that actual end-users might someday be able to control their own computers. But the free software movement only succeeded in liberating programmers and a few power users, while ordinary users were subjected to privacy invasions, relentless enshittification, and monthly billing. With LLMs, I am finally witnessing perfectly ordinary users vibe-coding personal tools that serve them, tools that don't invade their privacy and that do exactly what those users want. No matter what happens, this is an enormous victory for ordinary people controlling their machines, and it brings me joy. That vibe coder overexcited about software with an audience of one? That's software freedom for ordinary people. Honestly, it actually kind of bothers me when I see certain self-proclaimed free software communities become deeply vitriolic about inexperienced users building custom tools. Even if those tools are objectively terrible.

2. Frontier AI is bad for the environment, largely because of the enormous electrical power required. For some data center designs and geographical areas, water may also be a serious problem. But local AI is a different story: My favorite coding agent pulls about 300W off my solar panels, and anyways, the electric company is cheating me out of my written contractural reimbursement for the 5000W I generate at peak sun. I feel no guilt whatsoever about using that 300W myself. Yes, training local AI requires more watts. But for training a few 27B-sized model per year, it's completely miniscule. Yes, local AI does have other potential negative effects when trained, but they're mostly no better or worse than the usual sins of living in a capitalist world.

3. At least in the US, various courts and Copyright Office have been pretty clear: AI training is fair use (as long as you buy physical copies of books), and likely to remain so unless specific criteria are met. Purely AI written code can't be copyrighted, any more than photos taken by animals can be copyrighted. This is a major issue for people trying to enforce the GPL, but for people who'd use CC0 anyway, it's a non-issue. This is sufficiently settled case law for many of the largest software companies in the world to go all-in on AI, and they can afford lawyers. (This might change in the future, depending on Congress and SCOTUS, and it might be different in other countries.) And besides, I've spent decades opposed to copyright expansion and supporting fair use, so I'm not about to start arguing for stronger copyright laws.

4. I do think that AI has many extremely painful negative effects on programming as a profession, and that these will potentially include mass programmer job loss in coming years. As someone who still has a way to go before retirement, I'm not happy about that. But if we talk about software quality, the situation is more complex. For greenfield projects that would take a talented, experienced engineer less than a week, Fable often does an excellent job (in two hours, for $50, based on a single prompt and short Q&A session). Fable is a better coder than most outsourced consultants, and it's better than a lot of the programmers I've interviewed in my career. Now, I still don't trust it unsupervised on larger stuff or long-term maintenance. But none of this was true back in the Sonnet 4.5 days in October 2025, but the models have improved fast.

5. Even with no further AI advances, I think that mass disruption to people's livelihoods is already "baked in". And we need time to worth through this.

6. One of my longer-term worries is the one that even many AI opponents like to treat as science fiction: I genuinely fear that I may live long enough to see some reckless fool build SkyNet. In some sense, we already have much of the raw "intelligence" part. (Frankly, I suspect that Fable is smarter than I am.) But the models are still not drop-in replacements for humans, so they're obviously lacking important things besides raw intelligence. And if some fool ever figures out what's missing, then the future is going to get very weird. So even though I'm genuinely excited to see end-users vibe coding personal software, and even though I am opposed to what feels like a growing moral panic that some free software maintainer somewhere might be using an LLM, my actual preferred AI policy position is still very drastic: Long before we get anywhere near the possibility of SkyNet, I would love to see a world-wide frontier AI research and training halt, backed up by a military treaty among the major powers. I hope this isn't necessary yet, to be clear! But certain future research breakthroughs might make it necessary in a hurry, within my lifetime. So let's lay the groundwork now.

But we won't stop economic disruption (or prevent SkyNet) by attacking free software maintainers who use LLMs to review their project for security holes. That's not where the problem is. This is a political issue that will require national or even international cooperation, not going after some unpaid and unthanked programmer somewhere.

llms are here to stay

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

> But the free software movement only succeeded in liberating programmers and a few power users, while ordinary users were subjected to privacy invasions, relentless enshittification, and monthly billing. With LLMs, I am finally witnessing perfectly ordinary users vibe-coding personal tools that serve them, tools that don't invade their privacy and that do exactly what those users want.

Except of course those LLMs are highly proprietrary in of themselves, becoming more enshittified, and the price will only go up. _way_ up. And without these LLMs-as-a-perpetual-service, these "ordinary users" are completely incapable of maintaining what they "wrote".

> For greenfield projects that would take a talented, experienced engineer less than a week, Fable often does an excellent job (in two hours, for $50, based on a single prompt and short Q&A session). Fable is a better coder than most outsourced consultants, and it's better than a lot of the programmers I've interviewed in my career.

I'll grant you that LLMs are probably a net win with respect to "throw an army of talentless hacks at a problem and charge a lot of money for it", but Fable (etc) will dry up the job/career/talent pipeline preventing junior engineers from ever gaining the experience they need to become capable of evaluating/corralling/reviewing the output of the LLMs.

> But we won't stop economic disruption (or prevent SkyNet) by attacking free software maintainers who use LLMs to review their project for security holes.

Attacking free software maintainers for choosing to _not_ use LLMs doesn't help either.

llms are here to stay

Posted Jul 26, 2026 15:50 UTC (Sun) by emk (subscriber, #1128) [Link]

> Except of course those LLMs are highly proprietrary in of themselves, becoming more enshittified, and the price will only go up. _way_ up. And without these LLMs-as-a-perpetual-service, these "ordinary users" are completely incapable of maintaining what they "wrote".

As I alluded to earlier, my current favorite coding agent has MIT-licensed weights, it lives under my desk, and it runs off my solar panels during daylight hours. True, I don't have the original training data used to build it. But I also don't have the kind of hardware needed to train a 27B or larger model from scratch. At least I can do local LoRA fine tuning, if I really want to, or dig into the llama-server code that runs inference. Or I can download a J-space probe and try to figure out what's happening "inside" the model. It's as hackable as it's ever going to be for anyone who doesn't own a data center.

My setup, admittedly, was only affordable because I bought it before the massive price increases, and snagged some used hardware. But after the next big RAM price crash, I suspect that "Opus at home" will be viable for power users or small communities, and it will be possible to run off solar. (The best that's feasible right now is probably "Sonnet 4.5 at home", and it costs... well, less than any low-mileage used car where I live. Which is neither particularly accessible nor completely unachievable.) Which means you'll be able to buy commodity tokens from some local vendor if you want to, and those tokens will be good enough to hack together a personal phone app or a web app for a home LAN.

> but Fable (etc) will dry up the job/career/talent pipeline preventing junior engineers from ever gaining the experience they need to become capable of evaluating/corralling/reviewing the output of the LLMs.

Yeah, I have access to Fable at work, and it's basically skill-rot at warp speed, or like getting promoted from senior engineer to a job where you do meetings and politics all day, and only get to occasionally spend 5 minutes skimming a PR. Fable is too smart for day-to-day use (without extreme discipline), and I am actually starting to prefer less capable models for many things.

So I do agree that LLMs might gut software engineering as a profession, and the results of that could be remarkably ugly. Like I said, my position is complex.

> Attacking free software maintainers for choosing to _not_ use LLMs doesn't help either.

My proposed compromise: Your project, your rules. My project, my rules. For example, I have one hobby project where I do not permit even a single line of LLM implementation code, because it's a project for deeply learning a new technology, and also my fun project. I have another personal tool that was 98% written by a closely supervised local agent (and 2% by me) but where my policy is to throw away other people's LLM-written PRs unread. That tool is maybe only 75% as good as it I had lovingly hand-crafted it, but it's still solid.

I have zero problem with Zig banning LLM contributions, or Linus accepting them. I'm sure Linus, for example, is perfectly capable of telling us all how he really feels about a slop patch set. Projects should set their own rules. Big "meta projects" like Debian will be trickier, but I think they will be better off in the long run with nuanced policies. But at the end of the day, that's up to them, since they're the ones putting in the work.

llms are here to stay

Posted Jul 26, 2026 15:52 UTC (Sun) by MarcB (subscriber, #101804) [Link] (3 responses)

The price can't really go up much more. Large scale users are already backing down, either via usage reduction or model choice. You can set up pipelines and tool chains in which you delegate small tasks to small models - this can already include code generation of sub components. Even weaker models produce good result with a small enough context. Those models can be local ones - but the hardware pricing obviously is a problem.

IMHO this is the main reason OpenAI and Anthropic are currently quite desperate and try to scare the public and politicians into regulating AI. They know that if someone gets to ~80% of their top-models at < 40% the price, their whole promise to investors collapses - and exactly this has happened, originally with Deepseek and now again, with Kimi. So they try to get rid of the competition via regulatory capture, achieved through a combination of general AI scare (either directly via "AI is dangerous!" - see recent OpenAI PR - or via the "bad people use non-filtering AI to do bad things!" - see the whole Mythos PR).

Even if you took today's top open-weight models as they are now - and somehow obtained the hardware to run them, you would be good for years to come.

llms are here to stay

Posted Jul 27, 2026 10:31 UTC (Mon) by smurf (subscriber, #17840) [Link] (2 responses)

> either directly via "AI is dangerous!" - see recent OpenAI PR

The way OpenAI handled their hacking of Huggingface doesn't smell like PR to me. It smells like they still don't understand that their toys *are* dangerous and they *need* to fix their alignment (in addition to the sandboxes, which their model keep breaking out of, by their own admission).

I mean, running the thing in a leaky sandbox, unsupervised? admitting that is not PR. Admitting that opens you up to charges of willful negligence, among other liabilities, when this happens again -- not "if", because as of now they don't seem to have learned the right lessons from this incident.

llms are here to stay

Posted Jul 27, 2026 12:20 UTC (Mon) by anselm (subscriber, #2796) [Link]

We can ask ourselves what is worse: the people at OpenAI are either so morally bankrupt that they think nothing of committing federal crimes in order to scare prospective customers into buying their stuff, or else they're so glaringly incompetent that they don't see a problem with running their potentially-dangerous hacking tests on a non-airgapped system.

llms are here to stay

Posted Jul 27, 2026 15:19 UTC (Mon) by MarcB (subscriber, #101804) [Link]

This addresses multiple audiences at once. Politicians and the average tech journalists get the AI is dangerous message. That the main problem was the sandboxing is a side-note, at most.
Technical people, and the few remaining good journalists, look at the bigger picture.

And this already works: "US lawmakers push for AI 'kill switch' after OpenAI models go rogue" - https://www.bbc.com/news/articles/cx2vqj2e9x8o. This would kill open-weight models.

Any lawsuit is a negligible risk compared to the existential threat OpenAI faces from the (Chinese) open-weight models.

llms are here to stay

Posted Jul 26, 2026 16:32 UTC (Sun) by ejr (subscriber, #51652) [Link] (2 responses)

#2: Agreed. A good, secure, trust-able distributed training system could help open up the training, but that's an open area of research. That's related to training on health care, financial, or student data in a federated manner such that identifiable data doesn't cross boundaries but useful derivatives do. It's a hard problem with a long research train... I'm not sure of its current status. But a "play-by-mail strategy came" style of training may, *may* help bootstrap "fully open" models. And I'd be more willing to trust a million people with their own goals than one or two major philanthropic pushes by mega-donors. I'm undecided on the "movement for public AI" ( https://github.com/forpublicai ).

#3: You mention fine-tuning later. That's where I'm hitting sticky personal decisions. I've been trying to set up a system to maintain my Emacs config for me. I'm *intentionally* mixing GPL code and code from GFDL documentation. So I personally have decided I cannot redistribute the output because the I know of the potential license violation and am making a conscious decision to mix them. Not being able to distribute the output is kinda painful. (Less painful because it's yet to produce terribly great output, primarily based on a mix of quantized (unsloth) Qwen3.6, gemma4 (tee-hee-no), and other models. Or through the NVIDIA NIM freebies, etc. Quality output ain't always easy and requires a lot of work on building out the testing side...)

#4: Rather reminds me of the PHP programmer crash and other, similar incidents.

#5: Such a treaty isn't really "meta-stable." It's still quite possible for a non-governmental group to put together enough computing horsepower mostly under the radar. Cue the 80's high-school-kid-builds-nuke-in-garage movies, but this wouldn't be from specialized materials. Toss upcoming advances in actual neuromorphic hardware, and... I have no solid ideas here. And we've seen that limiting / tracking high-end computing components just plain doesn't work.

llms are here to stay

Posted Jul 26, 2026 18:22 UTC (Sun) by emk (subscriber, #1128) [Link] (1 responses)

> #3: You mention fine-tuning later.

Local fine-tuning in a home lab, or on affordable cloud machines, is mostly useful for smaller models and simpler tasks. Like classification or information extraction. It's genuinely hard to fine-tune even simple new abilities into a model if they're absolutely nowhere in the pre-training data. But this is partly a matter of compute, and partly because getting anything into an LLM requires a lot of data. Even training an inline code-completion model to accept a different input format it has never seen during pretraining is supposedly a lot of compute by local standards.

Where fine-tuning works is taking tasks that the model can already sort of do, and turning them into consistent behaviors. For example, you could prompt GPT-2 or early GPT-3 with "Question: What color is the sky? Answer:" prompts, and it might answer conversationally. Or it might not. But post-training and fine-tuning turned that latent behavior into InstructGPT and ChatGPT.

Local pre-training is rough. Unless you have a truly wild homelab, you'd be lucky to train even a barely coherent chatbot from scratch. Maybe with a very, very focused pre-train and a limited set of supported questions.

> #4: Rather reminds me of the PHP programmer crash and other, similar incidents.

Particularly if the next few generations actually allow models to affect more and more kinds of jobs, I'm picturing a level of disruption that could potentially be as large as the Industrial Revolution. And it might not all be positive disruption, either. Of course, if some researcher gets too clever, there are even more disruptive scenarios possible.

> #5: Such a treaty isn't really "meta-stable." It's still quite possible for a non-governmental group to put together enough computing horsepower mostly under the radar.

To be clear, if we ever get anywhere near the point of anyone actually building SkyNet, my mental model would be chemotherapy. You're not necessarily going to cure anything. But you might buy more good years before the controls fail.

There is a potentially unpleasant future where it's possible to stick a long-running "true" AGI on very high-end workstation hardware, with the right algorithms. An RTX Pro 6000 fits in a single PCI slot, runs on 300-600 watts of power, and gets a good part of a petaflop at 4-bit precision. That's at the absolute low end of Moravec's back-of-the-envelope estimates for the computation required to reimplement the actual algorithms being performed by human neural tissue (as opposed to simulating the neurons, which is vastly more expensive). So yes, I can see some possible and risky futures where someone could figure out human-level intelligence in a homelab. Honestly, we've gotten very lucky that most existing WMDs involve a few hard-to-source components so far.

So that's where I stand: If an end-user or an open source developer wants to run a local 27B model on a gaming GPU, and use it to generate utility scripts or simple personal apps for their own use, the more power to them. If open source maintainers want to reject AI PRs without reading, that's their choice (and probably a good default). But I don't really think society is ready for even the remote possibility of future human-level intelligence that works more cheaply than flesh-and-blood humans across a wide range of professions, either. And it wouldn't really matter who controlled the cheap intelligence, or whether it controlled itself. The implications of any version of this future would be incredibly messy. The public, familiar with Hollywood, has at least imagined robots taking their jobs. But the "serious" people mostly seem to limit themselves to scenarios where nothing really changes, ever.

llms are here to stay

Posted Jul 26, 2026 21:28 UTC (Sun) by ejr (subscriber, #51652) [Link]

#3: I admit that I'm lumping RAG and other prompt-generating aspects under this umbrella. Both can achieve the same thing. My point is that *for my use,* I'm including relevant data with incompatible licenses with the full intent of using them together. That intent muddies (or should, imho) the licensing water.

And check out some of the fine-tuning packages out there... I think you'll be surprised. The low-rank adapters (LoRA) are separate bolt-ons that muddy the license waters even further. You could accept that the general model isn't liable, but an intentional adapter... I have no doubt you can see parallels with other areas. It's all a big, giant mess.

#4: An olde intent for industrial revolution technology was to free people by letting them handle the same jobs more easily. Not that they'd be replaced. The optimists didn't think it through. Unfortunately, now we know better. and still have no seriously good answers 200-ish years later. (I've lived in US coal country. They'd love serious paths out of dead-ends.)

#5: I probably shouldn't point you towards actual neuromorphic technology on things like rather affordable 120-300nm manufacturing processes. Affordable enough that groups of hobbyists jump on those wafer runs such that they sell out in hours when available for low-volume use. There are end-runs around typical-matrix-product-based AI coming. And then things like yeast-ons... (No, really. The researchers had/have the great point that we know more about growing and manipulating yeast than pretty much any other bio organism, although I haven't heard from them in maybe six years.)

llms are here to stay

Posted Jul 26, 2026 21:32 UTC (Sun) by roc (subscriber, #30627) [Link]

Thank you for this comment. I agree with every bit of it. Especially, thank you for bringing up the existential threat and accepting the risk of sounding like a nutter.

Among the people who don't like AI, especially in the FOSS world, it seems to me that most of them are against it because they think ultimately it won't work. I'm against it because I think it will.

llms are here to stay

Posted Jul 28, 2026 8:37 UTC (Tue) by LtWorf (subscriber, #124958) [Link] (2 responses)

I think your life experience is quite different than mine.

I have met several people who use free software and aren't career developers.

On the other hand I haven't seen anyone who isn't already a developer use AI for development. Because if you don't have any clue on how to go from a text file to something that is executing, vibe coding isn't going to help you really.

But most people who started to use windows before windows 7 are perfectly able to format a disk and click through a linux distribution installer.

As others have already said, proprietary AI won't liberate anyone at all due to its cost, and running models locally requires being a power user who doesn't really need AI.

llms are here to stay

Posted Jul 28, 2026 13:37 UTC (Tue) by emk (subscriber, #1128) [Link] (1 responses)

> As others have already said, proprietary AI won't liberate anyone at all due to its cost, and running models locally requires being a power user who doesn't really need AI.

I definitely agree that proprietary AI is a bad match for the Free Software movement. Accepting a hard dependency on Anthropic, OpenAI or Google would be sacrificing local control, and it makes it impossible to learn or experiment with the technology. If we're going to allow a certain level of AI capabilities to be used at all, then it should be something that can be run locally (given enough hardware, etc). If a future level of AI capability is too dangerous to be run locally, then I wouldn't trust companies or the government to run it centrally, either.

Interestingly, you don't actually need to be a power user to run a model locally. You do, however, need 24GB to 48GB worth of VRAM, or maybe 128GB of reasonably fast system RAM. The former is enough to run Qwen3.6 27B, which is really the smallest coding model that can actually code. A system with 128GB of "unified" RAM (like an Nvidia DGX Spark or certain Mac Studios) can run several useful models in the 80-280B parameter range as MoEs, which require more memory but less memory bandwidth and compute. Given the current horrifying prices for fast RAM or VRAM, this is out of reach of many end users. The cheapest way to get started in 2026 would be to buy a used RTX 3090 and drop it into an existing gaming rig. Or spend slightly more and snag a Radeon R9700 model with 32GB of VRAM.

Then, from there, things get easier. Mac users can install the proprietary LM Studio. Linux users can follow the instructions for installing llama-server, which isn't too hard to install. After that, downloading and serving models is easy. Local AI on Linux is easier than, say, getting an XBox video game controller to work.

One downside of local AIs is that they just aren't as smart as the proprietary stuff. Qwen3.6 27B is a perfectly nice "programmer's assistant", but it can't build you a working Android app based on a two-paragraph spec. On the other hand, it often can debug why Docker or your XBox controller isn't working, or write short utility scripts without supervision. So it isn't totally useless to non-programmers, either. My guess is that by 2030 (or at least after the next RAM price crash), it will be possible to run fairly powerful models on readily available hardware.

> On the other hand I haven't seen anyone who isn't already a developer use AI for development. Because if you don't have any clue on how to go from a text file to something that is executing, vibe coding isn't going to help you really.

A lot of the people I see building stuff right now are the sort of folks who maybe took one intro programming course back in college, but who could never really build anything useful. Or the sort of people who once learned how to script HyperCard a bit. They're power users, not quite end users.

The people with the least programming skills are using the most expensive proprietary models. I occasionally run an experiment with those models, just to keep an eye on them. Most recently, I used Fable to build an Android app for personal use. This was a "one-shot", where I gave the AI a couple of paragraphs of specs, answered questions, walked away, and literally came back to a working APK two hours later. The app is pretty basic, but I use it myself! And I've only briefly glanced at the code. The app replaces some spyware ridden corporate thing that I hated, and it has a feature that I've always really wanted. I have really mixed feelings about this.

But that's kind of the challenge here: Local AI isn't that hard to run, if you're willing to spend $1,300 to $1,700 to upgrade a gaming rig to 24-32GB of VRAM. And local AI is fine if your needs are really simple (Linux troubleshooting, basic scripts) or if you already know how to program. Proprietary AI costs users freedom, but right now, it is capable of building an entire working Android APK based on a spec of a couple of paragraphs. (At which point, you never need to use the AI again.)

One thing I have found super interesting is to watch the list of AI projects rejected by Flathub. I don't blame Flathub at all for 95% of these rejections, because they can't afford to maintain packages for 1,000 apps with only a handful of users each. But the actual apps themselves? There are a lot of quite handy Linux desktop utilities in that rejection queue. Nothing really big or substantial. But the apps tend to put a nice user-friendly GUI around something that normally requires a lot of Linux CLI knowledge, or that requires paying for a proprietary web app. In particular, many of the rejected apps would fit right in on https://apps.gnome.org/ if they hadn't been vibe coded.

And at the end of the day, I originally got involved in free software because I wanted users to control their computing experience. The community and the coding-for-the-love-of-it were great, but the ultimate goal was always to give normal users the option of controlling the digital portion of their lives, rather than handing that control over to giant monopolies.

llms are here to stay

Posted Jul 28, 2026 21:00 UTC (Tue) by Klaasjan (subscriber, #4951) [Link]

Replying to this comment, admiitadly mainly as a cheap way to bookmark it. Insightful and interesting to revisit.

llms are here to stay

Posted Jul 26, 2026 15:21 UTC (Sun) by smurf (subscriber, #17840) [Link] (12 responses)

> Have you read the proposals? None of them are saying Debian will not accept upstream source tarballs
> on the basis of whether they contain LLM contributions.

… thereby embracing a double standard. I mean, allowing LLM patches in Upstream (potentially questionable for multiple reasons (code quality, copyright, slop)) while disallowing LLM updates to e.g. Debian packaging (not questionable IMHO) doesn't make any sense to me. At all.

Personally I think this is a non-issue anyway, for the very simple reason that any actually-binding resolution will require a 3:1 supermajority (required for changes to the Debian Social Contract), which this vote is unlikely to achieve (again IMHO).

llms are here to stay

Posted Jul 27, 2026 23:27 UTC (Mon) by dilinger (subscriber, #2867) [Link] (8 responses)

> I mean, allowing LLM patches in Upstream (potentially questionable for multiple reasons (code quality, copyright, slop)) while disallowing LLM updates to e.g. Debian packaging (not questionable IMHO) doesn't make any sense to me. At all.

It's very simple. Upstream projects are their own projects; they can do what they want. There are (tens of) thousands upstream projects, they're all going to work a little differently, and Debian's not even going to pretend that they can have a centralized AI policy for them.

Debian packaging work is different. It's meant to use the same set of tooling (eg debhelper, devscripts, etc), and developers routinely end up having to jump into others' packages. There's a security hole, and the debian security team has to create a patch and upload a fixed version. Someone orphans their package, and now the QA team has to update it for some reason. A maintainer is on vacation and there's an urgent RC bug in their package, someone else has to do an NMU. Someone prepares a new package and uploads to the NEW queue, waiting for the DFSG team (at least I think that's what they're called now.. formerly the ftpmasters) to review and approve/reject the package. All of this stuff should be consistent for the various debian developers working on it, whether or not that's making use of a copilot-like bot or reviewing packaging assuredly created by a human or going through the bug-tracking system to figure out whether it makes more sense to backport a single important patch or an entirely new release.

I specifically kept my opinion on the matter out of that description (though for the record I really don't want to have to deal w/ AI nonsense), but regardless of the vote outcome one of debian's core strengths has been its packaging policy requirements. And, some of debian's biggest weaknesses have been related to inconsistencies between packaging formats and workflows.

llms are here to stay

Posted Jul 28, 2026 4:43 UTC (Tue) by mirabilos (subscriber, #84359) [Link] (1 responses)

nah, the intend is to extend that to the packaged software, but it’s important that it go through for what Debian can directly control first, as on its own the other one is controverse enough to not pass (withdrawn earlier GR)

llms are here to stay

Posted Jul 29, 2026 12:00 UTC (Wed) by bluca (subscriber, #118303) [Link]

> nah, the intend is to extend that to the packaged software

Whose intent? And how exactly do they plan to do that?

llms are here to stay

Posted Jul 28, 2026 12:21 UTC (Tue) by smurf (subscriber, #17840) [Link] (5 responses)

> And, some of debian's biggest weaknesses have been related to inconsistencies between packaging formats and workflows.

Exactly. Now, what's more productive -- a maintainer frees a nontrivial chunk of time to dig through a packaging workflow they barely understand, don't really *want* to understand, all the time silently cursing the packager for the hoops they went through when re-assembling the upstream sources to something DFSG-free (while not quite documenting them) … *or* they ask their favorite LLM to "figure out what $UPLOADER did here, apply this patch over there, and create a clean NMU ready for upload", wait five minutes, then run "debdiff" to verify that the LLM didn't add any nonsense (or subtract something essential)?

The other way to handle this problem is to convert the package to standard debhelper form … or, again, tell the LLM to do it.

I am pretty sure that the LLM-using processes are less error-prone. Also, frankly they are more likely to happen at all, given that time is finite.

llms are here to stay

Posted Jul 28, 2026 12:40 UTC (Tue) by pizza (subscriber, #46) [Link] (4 responses)

> The other way to handle this problem is to convert the package to standard debhelper form …

This is the _only_ justifiable approach, otherwise you're piling nondeterministic crap on top of nonstandard crap.

> I am pretty sure that the LLM-using processes are less error-prone. Also, frankly they are more likely to happen at all, given that time is finite.

No, moving to the "standard" form is the least error-prone.

Using LLMs as a tool rather than a slop producer

Posted Jul 28, 2026 14:23 UTC (Tue) by farnz (subscriber, #17727) [Link]

This does point, however, towards one way to tame LLM use, other than just banning it. If you say that LLM-assisted contributions must meet the highest standards and fix nearby "tech debt" where human-only contributors are held to a lower standard.

In other words, if I want to use LLMs within Debian, I'd have to make sure that my contributions were as close to perfect as possible, including fixing up imperfections that were left by previous contributors. Or I could work without an LLM, and it'd be OK for me to leave existing tech debt alone, do things in a sub-optimal way, and otherwise behave like a human contributor.

llms are here to stay

Posted Jul 28, 2026 18:13 UTC (Tue) by smurf (subscriber, #17840) [Link] (2 responses)

> No, moving to the "standard" form is the least error-prone.

You're assuming that this conversion is easy and/or that the uploader has enough time and experience to verify its correctness.

Neither is necessarily true.

llms are here to stay

Posted Jul 28, 2026 18:58 UTC (Tue) by pizza (subscriber, #46) [Link] (1 responses)

> You're assuming that this conversion is easy and/or that the uploader has enough time and experience to verify its correctness.
> Neither is necessarily true.

If neither is true, how exactly can the uploader determine that the output of the LLM is any better?

llms are here to stay

Posted Jul 29, 2026 10:55 UTC (Wed) by taladar (subscriber, #68407) [Link]

It is much easier to verify that something is correct if you get to assume that something very similar (the work of the prior maintainer where you or your LLM only changed 1-2 lines) was correct than that a total conversion of everything the prior maintainer did is correct.

llms are here to stay

Posted Jul 28, 2026 8:28 UTC (Tue) by LtWorf (subscriber, #124958) [Link] (2 responses)

Have you ever heard of a code of conduct that can be enforced to people that do not contribute to your project?

Do you think code of conducts are a double standard because some random person might not follow them?

llms are here to stay

Posted Jul 28, 2026 9:16 UTC (Tue) by farnz (subscriber, #17727) [Link] (1 responses)

Codes of conduct are not always double-standards because, if people don't follow them, the non-followers and their contributions are unwelcome in your project. If you're not willing to do that, then yes, your code of conduct is a double-standard - either you insist that it's followed, and exclude non-followers, or at best, your code of conduct is a way to push the things you don't like out of sight, and not a way to improve things. And yes, this means that if you have a code of conduct that's not a double-standard, you sometimes lose out on things you would have obtained otherwise - you've refused to take a contribution that would benefit you, or depend on code that would help, because they don't respect your code of conduct.

Debian's position, however, is that LLM contributions are welcome in Debian, as long as they're not in a tiny fraction of the total codebase (the Debian-specific bits). And that is a double-standard, because Debian is not willing to take the hit from pushing LLM contributions out of Debian entirely, just out of the Debian project. Indeed, reading the GRs, it looks like it would be fine for me to contribute to upstream's Debian-specific code (packaging etc) with an LLM, and for a downstream DD to then base the Debian packaging on upstream's Debian-specific code; it's even plausible for some of the GR options that I could be that downstream DD, thus doing a complete end-run around the policy.

llms are here to stay

Posted Jul 29, 2026 5:16 UTC (Wed) by LtWorf (subscriber, #124958) [Link]

Can you link me a project which has a code of conduct that, if not followed by the developers of their dependencies, enforces them dropping that dependency?

I need one single example.

I'll wait eagerly for your reply.

llms are here to stay

Posted Jul 26, 2026 10:39 UTC (Sun) by alx.manpages (subscriber, #145117) [Link] (29 responses)

> by slowing down development and bug-fixing

I expect that if Debian does nothing different from now, it will continue developing at the same speed.

Existing tools will not disappear, and thus, I can't see how development would _slow down_.

You might say that they won't develop faster, but not that they'll slow down.

I also question the idea that using LLMs makes development faster. In my case, the bottleneck is reviewer's time, and not typing speed or thinking speed. I think this is true in every other open source projects. So, if we continue producing code at the same speed, and we require a human to review it, it will remain bottlenecked at the same point. You may have more (virtual) eyes to potentially improve the quality, but the human reviewer will remain there and thus bottleneck development.

Unless you remove the bottleneck, which would lower down quality.

If you really use LLMs to write code faster, you'll just choke the human reviewers even more, and development speed might actually slow down.

llms are here to stay

Posted Jul 26, 2026 11:10 UTC (Sun) by mb (subscriber, #50428) [Link] (3 responses)

>I can't see how development would _slow down_.

People will leave the project and new people will not enter it.

llms are here to stay

Posted Jul 26, 2026 12:09 UTC (Sun) by pizza (subscriber, #46) [Link] (2 responses)

> People will leave the project and new people will not enter it.

Yeah, so what? The same thing has been said about literally _every_ Debian GR in modern history.

Plenty of folks have stomped off after various votes didn't go their way, yet here we still are.

Meanwhile, "new people" won't be entering it anyway, because who in their right mind will want to deal with that sausage making *work* on a purely volunteer basis?

llms are here to stay

Posted Jul 26, 2026 12:59 UTC (Sun) by mb (subscriber, #50428) [Link] (1 responses)

https://en.wikipedia.org/wiki/Survivorship_bias

Many projects have died over bad decisions.
Debian is not (yet) one of them. But it doesn't mean Debian is immune to it, just because it survived all past decisions.

I'm not saying that a decision to ban LLMs would kill Debian.
But I am saying that it will certainly have a major effect.
IMO this is bigger than the systemd decision, which has caused a fork.

But we'll see. This has not been decided, yet.

llms are here to stay

Posted Jul 26, 2026 13:32 UTC (Sun) by alx.manpages (subscriber, #145117) [Link]

I think the opposite might be true as well. Many of us, including myself, will consider abandoning Debian if it were to allow LLMs. (I've already abandoned it and moved to Devuan, but it's actually a close derivative, so it still contributes back.)

llms are here to stay

Posted Jul 27, 2026 9:53 UTC (Mon) by smurf (subscriber, #17840) [Link] (23 responses)

> I expect that if Debian does nothing different from now, it will continue developing at the same speed.

I don't. For instance, while I've been a DD for far longer than I'd like, I no longer bother with packaging things myself -- GLM does a far better job, doesn't get annoyed about having to fix all those Lintian nigglies, can find and package dependencies by itself while I do something that requires an above-room-temperature IQ, and so on.

Thus I can only assume that there are otherwise-interested people out there who decide not to bother, if Debian adopts a "don't use LLMs for packaging" rule.

> Existing tools will not disappear, and thus, I can't see how development would _slow down_.

Existing Debian tools are ~ two decades old. The state of the art has, maybe, advanced somewhat by now? Same rationale as above.

Also, Debian development slows down all by itself: many projects nowadays use Go or Rust, which means they depend on an order of magnitude more external libraries/crates/whatever, which all have to be packaged and kept up to date.

> If you really use LLMs to write code faster

then you'll get into an unholy, impossible-to-debug, AI-slop-py mess, and frankly you deserve it.

If however you write a specification, use the LLM to refine it, then tell it to write the API and the tests and the code and the documentation and whatnot, you end up with (in my experience) higher-quality output in less time than writing the code yourself. (NB: Don't tell me that you'd otherwise even bother with specs, tests, and docs. We all know that the average coder won't.)

llms are here to stay

Posted Jul 27, 2026 13:11 UTC (Mon) by alx.manpages (subscriber, #145117) [Link] (22 responses)

> Existing Debian tools are ~ two decades old.
> The state of the art has, maybe, advanced somewhat by now?

Most of the tools I use every day for programming are way older than that. I wouldn't say 2 decades makes a tool obsolete.

vim(1), mutt(1), mbsync(1), bash(1), make(1), gcc(1), sed(1), grep(1), xargs(1), ssh(1), ...
git(1) is probably the most recent tool I use frequently, and it's already two decades old.

I wouldn't say state of the art has changed much.

> > If you really use LLMs to write code faster
>
> then you'll get into an unholy, impossible-to-debug, AI-slop-py mess, and frankly you deserve it.
>
> If however you write a specification, use the LLM to refine it, then tell it to write the API and the tests and the code and the documentation and whatnot,

I think this is in direct contradiction with the sentence right above it. If you're using an LLM to write an API, the code, the documentation, etc., then you're using it to write code faster than you would. This means you're spending less time thinking about the code (while you do the tedious work of writing code, you're actually reviewing it, at least to some degree), even if you might spend some more time thinking about the specification. And yet, if another human has to review it later, and that remains the bottleneck, the production is still choked at that point. Except now the reviewer can't ask you every little detail of why you did something, because you didn't do it, so you don't know (and then you need to guess why, and waste yet more time).

So, with LLMs we may get people to think about great specifications and plans that remain in their head and prompts, and then get junior-programmer-level LLMs to do the implementation, which results in a poor implementation of the possibly great idea. Then the junior-programmer-level LLMs also do the tests and documentation. That's plenty of stuff that is written with low quality. The only way to do something right is to do it yourself.

Having plenty of poor documentation and tests of low quality doesn't necessarily put us in a better place (it might actually put us in a worse one). If you don't have tests or documentation, at least you're aware of that. If you have tests that don't really protect well or documentation that lies, you have a problem.

llms are here to stay

Posted Jul 27, 2026 17:51 UTC (Mon) by deepfire (guest, #26138) [Link] (3 responses)

> vim(1), mutt(1), mbsync(1), bash(1), make(1), gcc(1), sed(1), grep(1), xargs(1), ssh(1), ...
> git(1) is probably the most recent tool I use frequently, and it's already two decades old.
>
> I wouldn't say state of the art has changed much.

This is either misguided or outright disingenious.

By "Debian tools" he clearly means packaging tools -- that is the tool stack used to package software and maintain the packages.

llms are here to stay

Posted Jul 27, 2026 18:13 UTC (Mon) by alx.manpages (subscriber, #145117) [Link] (2 responses)

> This is either misguided or outright disingenious.

Quoting again:

> > Existing Debian tools are ~ two decades old. The state of the art has, maybe, advanced somewhat by now?

I read that as implying that in general, software tools become obsolete in two decades. I provided a counter-example.

I didn't talk about Debain packaging tools, because I think @smurf didn't provide any specific information that implied that somehow Debian packaging tools age worse than other software.

> By "Debian tools" he clearly means packaging tools -- that is the tool stack used to package software and maintain the packages.

Do packaging tools somehow inherently age faster than text editing tools, source control tools, mail tools, or compilers? I don't use _any_ tools that aren't at least decades old (AFAIK), except for some very simple shell scripts I've written some years ago, which leads me to suspect that packaging tools aren't much different.

llms are here to stay

Posted Jul 27, 2026 18:33 UTC (Mon) by mb (subscriber, #50428) [Link] (1 responses)

The thing is: Nobody is taking your old tools away. You can continue to use them forever. That's totally fine.
But the anti-AI people (first proposal) are trying to take away the new tools from other people. That's the not-ok part.

The problem is not that certain tools suddenly become obsolete. The problem is that some people want to restrict other people in their tool choice.

llms are here to stay

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

> The thing is: Nobody is taking your old tools away. You can continue to use them forever. That's totally fine.

Actually, that's not so clear to me. For example, I've used (and still use sometimes) neomutt(1) too. It is now heavily LLM-poisoned, which forced me to go back to mutt(1) --which, TBH, I always liked more than neomutt(1); but neomutt(1) has better crypto features--. I used to contribute a lot of code to neomutt(1), but now the source code has degraded significantly, and it's not fun anymore. Luckily, mutt(1) has revived recently.

vim(1) is now also LLM-poisoned, and I'm still waiting to see vim-classic packaged in Debian.

llms are here to stay

Posted Jul 27, 2026 21:10 UTC (Mon) by kleptog (subscriber, #1183) [Link] (17 responses)

> And yet, if another human has to review it later, and that remains the bottleneck, the production is still choked at that point. Except now the reviewer can't ask you every little detail of why you did something, because you didn't do it, so you don't know (and then you need to guess why, and waste yet more time).

But this is just as true of non-LLM code. As a reviewer you have to be able to understand what the code does *without having to ask the author*. The author isn't always going to be around, the code has to explain itself or it's bad code. You don't give hard-to-read code a pass just because it was written by a human you could theoretically ask.

I think Knuth was right with his literate programming, it just never caught on. High level design documentation is rarely written and stored somewhere where it could be useful. One place where LLMs could be a force for good is if after you've gone through the high-level design and asked it to actually start implementing, that it also wrote and updated the design documentation in the project. That's important work that software developers just don't like doing because it's harder than coding.

> then get junior-programmer-level LLMs to do the implementation, which results in a poor implementation of the possibly great idea

In my experience the LLM, when it writes the correct code (the hard part), produces higher quality code than I myself would write the first time. The error messages are better, the error handling is better, it handles more of the corner cases right the first time, it's more idiomatic. It's arguably too gold-plated sometimes. The argument against gold-plating early is that it costs more to update the code later when the specification changes. But if you're not doing the updating yourself, the gold-plating doesn't hurt.

> Having plenty of poor documentation and tests of low quality

Then tell it to make higher quality tests! It knows what a high quality test looks like, but it might not give it to you if you don't ask for it.

llms are here to stay

Posted Jul 27, 2026 22:15 UTC (Mon) by alx.manpages (subscriber, #145117) [Link] (16 responses)

> But this is just as true of non-LLM code. As a reviewer you have to be able to understand what the code does *without having to ask the author*.

In general, yes. However, there are details that can be done differently, and you may wonder and ask why it was done in a certain way and not others.

> The author isn't always going to be around, the code has to explain itself or it's bad code.

Sometimes, code can't explain itself, and the commit message must document that. Discussion between the author and the reviewer often discovers aspects that weren't so clear in the original commit message.

> You don't give hard-to-read code a pass just because it was written by a human you could theoretically ask.

Hard-to-read code can sometimes be subjective (although I'm of the opinion that coding style is not as subjective as many people claim; it often hides a safety aspect, and thus often there's an objectively correct style). What one finds hard-to-read, someone else finds easy-to-read, and vice versa. If one author is a comaintainer, and the reviewer is another comaintainer, then the reviewer may give the author a pass. Especially, the discussion may convince you, and you may document that in the commit message. Or maybe it doesn't, and you convince the author to change the code.

llms are here to stay

Posted Jul 28, 2026 8:53 UTC (Tue) by kleptog (subscriber, #1183) [Link] (14 responses)

> In general, yes. However, there are details that can be done differently, and you may wonder and ask why it was done in a certain way and not others.

You can ask an LLM to explain that. You might not like the answer, but it will give one.

> Sometimes, code can't explain itself, and the commit message must document that.

Strongly disagree. If the code doesn't explain itself it needs a comment in the code explaining it so it is clear what it's doing and why. Or it needs to be refactored. The commit message is way too far removed to be useful (or out of date by the time you read it).

There is the general issue while writing code with gauging how much knowledge the reader should have to understand it. I think as a developer you should try to keep the bar as low as reasonably possible.

“Bad programmers worry about the code. Good programmers worry about data structures and their relationships.”
— Linus Torvalds

Which is just the modern variant of:

"Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowcharts; they'll be obvious." -- Fred Brooks (1975).

llms are here to stay

Posted Jul 28, 2026 11:29 UTC (Tue) by pizza (subscriber, #46) [Link] (1 responses)

> You can ask an LLM to explain that. You might not like the answer, but it will give one.

You left out the _reason_ for not liking the answer -- It will be presented with utter confidence... and is more likely than not to be utterly wrong.

llms are here to stay

Posted Jul 28, 2026 13:36 UTC (Tue) by kleptog (subscriber, #1183) [Link]

>You left out the _reason_ for not liking the answer -- It will be presented with utter confidence... and is more likely than not to be utterly wrong.

I think this really is a question of which framework you're using. In my case it often lists two or three alternatives with pros and cons and then why it chose the one it did. That's pretty easy for me to verify and it's mostly right but not always (basically because it doesn't (can't) have all the context).

But this requires you to be using a framework that knows when you ask for clarification that it means you want to know the alternatives. And a framework that doesn't just ad-lib coding but actually makes a plan first. If you just asked a raw LLM it would probably do what you say.

Which goes back to the point someone else made: the frameworks being built around LLMs make the whole process much less random and more reliable. It's just one cog is a much larger machine.

llms are here to stay

Posted Jul 28, 2026 15:29 UTC (Tue) by alx.manpages (subscriber, #145117) [Link] (11 responses)

> > Sometimes, code can't explain itself, and the commit message must document that.

> Strongly disagree. If the code doesn't explain itself it needs a comment in the code explaining it so it is clear what it's doing and why. Or it needs to be refactored.

Indeed, this is a point where we strongly disagree. I find code more readable when it has close-to-zero comments. The code should indeed explain itself.

But that means that the reviewer might have to be an expert in the language; and by expert, I mean one of a few dozens.

Here's my allocator macro, which is the safest way to use malloc(3) that I know:

$ grepc -h malloc_T .
#define malloc_T(n, T) malloc_T_(n, typeas(T))

$ grepc -h malloc_T_ .
#define malloc_T_(n, T) \
( \
(void)0, \
(T *){mallocarray(n, sizeof(T))} \
)

$ grepc -h typeas .
#define typeas(T) typeof((T){0})

You may wonder so many questions from reading that code:

- What's that typeas()? Why not just typeof()? Since this is an interface, we're lucky, and this is something that deserves a manual page. It's indeed the same as typeof(), except that it enforces that the input is a type name, and rejects an expression.

- Why mallocarray()? This is more obvious: to avoid overflow in the multiplication. I haven't documented this, because the relation to reallocarray(3) from libc is obvious, and thus everyone will know. I documented it in the commit message, just to clarify.

- Why (void)0 with a comma operator? This is not abstracted in any interface; it's a detail that is documented only in the commit that added it. It's there to perform lvalue conversion on the compound literal in the next line.

- Why use a compound literal? This is not abstracted in any interface; it's a detail that is documented only in the commit that added it. It's there to convert the return value to the appropriate type (which is passed as argument).

If I had to document all that within or next to the macro, the signal-to-noise ratio would decrease significantly. Currently, the interesting part of that file fits in a usual screen, so I can read all the related interfaces at once. With comments, it'd take many screens, so I couldn't have such a view of the code.

> The commit message is way too far removed to be useful

Whenever I wonder why I did something, I only need to git-blame(1) the code until the moment it was changed, and look at the corresponding commit message.

> (or out of date by the time you read it).

Actually, that's the best part. When I read the commit message, it's next to the code exactly as it was by then. This gives me a better context, because I can understand why it was done back then, even if it might not make sense in the current code.

The commit message never becomes obsolete, unlike source-code comments, which become obsolete quite soon.

llms are here to stay

Posted Jul 28, 2026 18:11 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (9 responses)

Out of curiosity, I asked Claude to explain them. It understood it correctly, with this conclusion:

> malloc_T(n, T) is calloc-argument-order allocation that returns a properly typed, non-assignable rvalue T *, with overflow-checked sizing, no zeroing, a compile error for non-allocatable types, and a diagnostic if you store it into the wrong pointer type — and it works for array and function-pointer types that a naive (T *) cast couldn't even parse.

llms are here to stay

Posted Jul 28, 2026 20:27 UTC (Tue) by alx.manpages (subscriber, #145117) [Link] (8 responses)

> Out of curiosity, I asked Claude to explain them. It understood it correctly, with this conclusion:

> > malloc_T(n, T) is calloc-argument-order allocation that returns a properly typed, non-assignable rvalue T *, with overflow-checked sizing, no zeroing, a compile error for non-allocatable types, and a diagnostic if you store it into the wrong pointer type — and it works for array and function-pointer types that a naive (T *) cast couldn't even parse.

It's mostly right. TBH, it explains it with quite a lot of detail; even things I've documented elsewhere (in commit messages, and/or mailing lists), but which I didn't say here (such as the array and pointer types thingy). It makes me wonder whether it was trained on those materials, or if it really deduced that on its own.

> a compile error for non-allocatable types

I wonder what it means by this. I think this part is probably a hallucination.

The only hard error in this macro is the syntax error if you pass an expression as T instead of the expected type name. I guess that's what that hallucination meant to be.

I admit it's surprisingly good at that. If it didn't hallucinate stuff arbitrarily, it'd be amazing. It's the fact that it hallucinates the reason I can't trust it. But honestly, it's amazing that it can describe so many details about it.

I've described those details elsewhere, so I wonder whether it had that in the training set, or if it derived that from independent training. In any case, partially amazing.

llms are here to stay

Posted Jul 29, 2026 0:01 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (7 responses)

> I wonder what it means by this. I think this part is probably a hallucination.

The "void" type is non-allocatable. I remember that you also can do some cursed ternary "if" statements that result in conflicting types that can't be allocated.

The AIs are _really_ good at parsing structured languages now.

llms are here to stay

Posted Jul 29, 2026 8:23 UTC (Wed) by alx.manpages (subscriber, #145117) [Link] (6 responses)

The "void" type is non-allocatable.

Hmmm, interesting. I thought it was actually able to allocate voids. I didn't really check, because it's not very interesting to me, but it might be useful for someone else (for example, for allocating a pool of memory to which we don't want to assign a type just yet).

That compiler error wasn't intentional, and is only a side effect of the sub-optimal implementation of typeas(). Hopefully, typeas() should be an operator provided by the compiler, and this limitation would then vanish. Or maybe I can come up with a better implementation still as a macro.

In any case, now my complaint about the description that Claude made is that it didn't say anything about the other error, which is much more important: this macro produces an error if the second argument is not a type name.

After some thinking, here's an implementation of typeas() that allows void (and also allows functions):

#define typeas(T)          typeof                                     \
(                                                                     \
	_Generic(T, T: *(typeof(T) *){})                              \
)

Of course, we don't want to allocate functions; that would be nonsense. However, that should be validated by malloc_T() itself, not typeas(); and indeed, it is validated by sizeof(T), which diagnoses a function type (as part of -Wpointer-arith, which is not in -Wall nor -Wextra).

alx@devuan:~/tmp$ cat void.c 
#include <stdlib.h>

#define typeas(T)          typeof                                     \
(                                                                     \
	_Generic(T, T: *(typeof(T) *){})                              \
)

#define mallocarray(n, z)  reallocarray(NULL, n, z)

#define malloc_T(n, T)     malloc_T_(n, typeas(T))
#define malloc_T_(n, T)                                               \
(                                                                     \
	(void)0,                                                      \
	(T *){mallocarray(n, sizeof(T))}                              \
)

int
main(void)
{
	int *p = malloc_T(6, int);
	void *q = malloc_T(6, void);
	void (*r)(void) = malloc_T(6, void (void));
	malloc_T(6, 7);
}
alx@devuan:~/tmp$ gcc -Wall -Wextra -Wpointer-arith -Wno-unused void.c 
void.c: In function ‘main’:
void.c:3:28: warning: invalid application of ‘sizeof’ to a void type [-Wpointer-arith]
    3 | #define typeas(T)          typeof                                     \
      |                            ^~~~~~
void.c:8:50: note: in definition of macro ‘mallocarray’
    8 | #define mallocarray(n, z)  reallocarray(NULL, n, z)
      |                                                  ^
void.c:10:28: note: in expansion of macro ‘malloc_T_’
   10 | #define malloc_T(n, T)     malloc_T_(n, typeas(T))
      |                            ^~~~~~~~~
void.c:10:41: note: in expansion of macro ‘typeas’
   10 | #define malloc_T(n, T)     malloc_T_(n, typeas(T))
      |                                         ^~~~~~
void.c:21:19: note: in expansion of macro ‘malloc_T’
   21 |         void *q = malloc_T(6, void);
      |                   ^~~~~~~~
void.c:3:28: warning: invalid application of ‘sizeof’ to a function type [-Wpointer-arith]
    3 | #define typeas(T)          typeof                                     \
      |                            ^~~~~~
void.c:8:50: note: in definition of macro ‘mallocarray’
    8 | #define mallocarray(n, z)  reallocarray(NULL, n, z)
      |                                                  ^
void.c:10:28: note: in expansion of macro ‘malloc_T_’
   10 | #define malloc_T(n, T)     malloc_T_(n, typeas(T))
      |                            ^~~~~~~~~
void.c:10:41: note: in expansion of macro ‘typeas’
   10 | #define malloc_T(n, T)     malloc_T_(n, typeas(T))
      |                                         ^~~~~~
void.c:22:27: note: in expansion of macro ‘malloc_T’
   22 |         void (*r)(void) = malloc_T(6, void (void));
      |                           ^~~~~~~~
void.c:23:21: error: expected specifier-qualifier-list before numeric constant
   23 |         malloc_T(6, 7);
      |                     ^
void.c:14:10: note: in definition of macro ‘malloc_T_’
   14 |         (T *){mallocarray(n, sizeof(T))}                              \
      |          ^
void.c:10:41: note: in expansion of macro ‘typeas’
   10 | #define malloc_T(n, T)     malloc_T_(n, typeas(T))
      |                                         ^~~~~~
void.c:23:9: note: in expansion of macro ‘malloc_T’
   23 |         malloc_T(6, 7);
      |         ^~~~~~~~
void.c:23:21: error: expected specifier-qualifier-list before numeric constant
   23 |         malloc_T(6, 7);
      |                     ^
void.c:8:50: note: in definition of macro ‘mallocarray’
    8 | #define mallocarray(n, z)  reallocarray(NULL, n, z)
      |                                                  ^
void.c:10:28: note: in expansion of macro ‘malloc_T_’
   10 | #define malloc_T(n, T)     malloc_T_(n, typeas(T))
      |                            ^~~~~~~~~
void.c:10:41: note: in expansion of macro ‘typeas’
   10 | #define malloc_T(n, T)     malloc_T_(n, typeas(T))
      |                                         ^~~~~~
void.c:23:9: note: in expansion of macro ‘malloc_T’
   23 |         malloc_T(6, 7);
      |         ^~~~~~~~

P.S.: @corbet, I think the example should show as a single block instead of separating at blanks that are part of the example. I've formatted the whole program with a single ```c/``` block, FWIW. Is there a way to improve that? Otherwise, and in any case, this experimental Markdown is great; thanks!

llms are here to stay

Posted Jul 29, 2026 8:27 UTC (Wed) by alx.manpages (subscriber, #145117) [Link] (2 responses)

To: @corbet

Hmmm, the preview was slightly different from the end result, it seems. The end result is nicer than the preview, and doesn't show the block as separated parts (while the preview did).

llms are here to stay

Posted Jul 29, 2026 12:43 UTC (Wed) by daroc (editor, #160859) [Link] (1 responses)

Interesting. I suspect that that's our CSS for the preview pane interacting poorly with the generated HTML, but I'll look into it.

llms are here to stay

Posted Jul 29, 2026 12:52 UTC (Wed) by daroc (editor, #160859) [Link]

Ah, found it — it has to do with how HTML handles the background color attribute for non-block elements. In particular, it only sets the background for the space that is actually taken up by the text, not for the entire size of the element. You've got to love CSS.

llms are here to stay

Posted Jul 29, 2026 13:30 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (2 responses)

This is, uh, not exactly friendly compiler output in terms of letting a user know how they've messed up?

llms are here to stay

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

I've taken some time to abstract the lvalue conversion and the compound literal into their own macros, to give them names --to help document this--. As a side-effect, it's now a set of one-liner macros:

#define typeas(T)          typeof(_Generic(T, T: *(typeof(T) *){NULL}))

#define rvalue(lv)         ((void)0, (lv))
#define ptr_cast(T, p)     rvalue((typeas(T) *){(p)})

#define mallocarray(n, z)  reallocarray(NULL, n, z)
#define malloc_T(n, T)     ptr_cast(T, mallocarray(n, sizeof(T)))

This is, uh, not exactly friendly compiler output in terms of letting a user know how they've messed up?

Let's see.

1)

int *p = malloc_T(6, int);

produces (with -Wpointer-arith, part of -Wpedantic):

void.c: In function ‘main’:
void.c:15:31: warning: invalid application of ‘sizeof’ to a void type [-Wpointer-arith]
   15 |         void *q = malloc_T(6, void);
      |                               ^~~~
void.c:5:39: note: in definition of macro ‘rvalue’
    5 | #define rvalue(lv)         ((void)0, (lv))
      |                                       ^~
void.c:9:28: note: in expansion of macro ‘ptr_cast’
    9 | #define malloc_T(n, T)     ptr_cast(T, mallocarray(n, sizeof(T)))
      |                            ^~~~~~~~
void.c:9:40: note: in expansion of macro ‘mallocarray’
    9 | #define malloc_T(n, T)     ptr_cast(T, mallocarray(n, sizeof(T)))
      |                                        ^~~~~~~~~~~
void.c:15:19: note: in expansion of macro ‘malloc_T’
   15 |         void *q = malloc_T(6, void);
      |                   ^~~~~~~~

In general, this is fine, and it's only a pedantic warning. If you're allocating void's you probably are aware that sizeof(void) is a GNU extension. The warning line clearly says it applies sizeof to void, and then shows the expansion which calls mallocarray(n, sizeof(T)), so I'd say this is reasonable.

2)

void (*r)(void) = malloc_T(6, void (void));

produces (with -Wpointer-arith, part of -Wpedantic):

void.c:16:39: warning: invalid application of ‘sizeof’ to a function type [-Wpointer-arith]
   16 |         void (*r)(void) = malloc_T(6, void (void));
      |                                       ^~~~
void.c:5:39: note: in definition of macro ‘rvalue’
    5 | #define rvalue(lv)         ((void)0, (lv))
      |                                       ^~
void.c:9:28: note: in expansion of macro ‘ptr_cast’
    9 | #define malloc_T(n, T)     ptr_cast(T, mallocarray(n, sizeof(T)))
      |                            ^~~~~~~~
void.c:9:40: note: in expansion of macro ‘mallocarray’
    9 | #define malloc_T(n, T)     ptr_cast(T, mallocarray(n, sizeof(T)))
      |                                        ^~~~~~~~~~~
void.c:16:27: note: in expansion of macro ‘malloc_T’
   16 |         void (*r)(void) = malloc_T(6, void (void));
      |                           ^~~~~~~~

FWIW, I think this should be split out of -Wpointer-arith into a -Wpointer-arith-function: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123388, and included as part of -Wall.

This diagnostic is mostly theoretical. One must try hard to pass a function type to this macro. I guess it could happen if you're trying to allocate an array of function pointers, and maybe you forget to write a *. But you'd have to forget it also in the variable declaration, or you'd also see an error (-Werror=incompatible-pointer-types, which is now a default error). If you see a warning that says you're applying sizeof to a function type, you'd probably guess what's wrong, as you'd be expecting to do sizeof of a pointer to function.

3)

void (**r)(void) = malloc_T(6, void (void));

This is a more likely error than (2). It produces a default error (plus the diagnostic above):

void.c:16:40: warning: invalid application of ‘sizeof’ to a function type [-Wpointer-arith]
   16 |         void (**r)(void) = malloc_T(6, void (void));
      |                                        ^~~~
void.c:5:39: note: in definition of macro ‘rvalue’
    5 | #define rvalue(lv)         ((void)0, (lv))
      |                                       ^~
void.c:9:28: note: in expansion of macro ‘ptr_cast’
    9 | #define malloc_T(n, T)     ptr_cast(T, mallocarray(n, sizeof(T)))
      |                            ^~~~~~~~
void.c:9:40: note: in expansion of macro ‘mallocarray’
    9 | #define malloc_T(n, T)     ptr_cast(T, mallocarray(n, sizeof(T)))
      |                                        ^~~~~~~~~~~
void.c:16:28: note: in expansion of macro ‘malloc_T’
   16 |         void (**r)(void) = malloc_T(6, void (void));
      |                            ^~~~~~~~
void.c:5:28: error: initialization of ‘void (**)(void)’ from incompatible pointer type ‘void (*)(void)’ [-Wincompatible-pointer-types]
    5 | #define rvalue(lv)         ((void)0, (lv))
      |                            ^
void.c:6:28: note: in expansion of macro ‘rvalue’
    6 | #define ptr_cast(T, p)     rvalue((typeas(T) *){(p)})
      |                            ^~~~~~
void.c:9:28: note: in expansion of macro ‘ptr_cast’
    9 | #define malloc_T(n, T)     ptr_cast(T, mallocarray(n, sizeof(T)))
      |                            ^~~~~~~~
void.c:16:28: note: in expansion of macro ‘malloc_T’
   16 |         void (**r)(void) = malloc_T(6, void (void));
      |                            ^~~~~~~~
void.c:17:16: error: conflicting types for ‘r’; have ‘void (*)(void)’
   17 |         void (*r)(void) = malloc_T(6, void (void));
      |                ^
void.c:16:17: note: previous definition of ‘r’ with type ‘void (**)(void)’
   16 |         void (**r)(void) = malloc_T(6, void (void));
      |                 ^

I think the -Wincompatible-pointer-types default error shows that you've forgotten a * somewhere quite clearly, because the types don't match.

4)

long *p = malloc_T(6, int);

This is the most common error we could make: use a different type accidentally.

void.c: In function ‘main’:
void.c:5:28: error: initialization of ‘long int *’ from incompatible pointer type ‘int *’ [-Wincompatible-pointer-types]
    5 | #define rvalue(lv)         ((void)0, (lv))
      |                            ^
void.c:6:28: note: in expansion of macro ‘rvalue’
    6 | #define ptr_cast(T, p)     rvalue((typeas(T) *){(p)})
      |                            ^~~~~~
void.c:9:28: note: in expansion of macro ‘ptr_cast’
    9 | #define malloc_T(n, T)     ptr_cast(T, mallocarray(n, sizeof(T)))
      |                            ^~~~~~~~
void.c:14:19: note: in expansion of macro ‘malloc_T’
   14 |         long *p = malloc_T(6, int);
      |                   ^~~~~~~~
void.c:15:14: error: conflicting types for ‘p’; have ‘int *’
   15 |         int *p = malloc_T(6, int);
      |              ^
void.c:14:15: note: previous definition of ‘p’ with type ‘long int *’
   14 |         long *p = malloc_T(6, int);
      |               ^

The default -Wincompatible-pointer-types error seems quite obvious, even if the notes show a lot of code that you may not know. It clearly says there are conflicting types, and shows both types, so that should be a clue. It's similar to (3), but without the problem from (2).

5)

malloc_T(6, 7);

This is something I wouldn't expect anyone to write, but you never know.

This is the less clear diagnostic, although it's a hard error, so at least we're safe.

void.c:19:21: error: expected specifier-qualifier-list before numeric constant
   19 |         malloc_T(6, 7);
      |                     ^
void.c:5:39: note: in definition of macro ‘rvalue’
    5 | #define rvalue(lv)         ((void)0, (lv))
      |                                       ^~
void.c:6:36: note: in expansion of macro ‘typeas’
    6 | #define ptr_cast(T, p)     rvalue((typeas(T) *){(p)})
      |                                    ^~~~~~
void.c:9:28: note: in expansion of macro ‘ptr_cast’
    9 | #define malloc_T(n, T)     ptr_cast(T, mallocarray(n, sizeof(T)))
      |                            ^~~~~~~~
void.c:19:9: note: in expansion of macro ‘malloc_T’
   19 |         malloc_T(6, 7);
      |         ^~~~~~~~
void.c:18:16: warning: unused variable ‘r’ [-Wunused-variable]
   18 |         void (*r)(void) = malloc_T(6, void (void));
      |                ^
void.c:16:15: warning: unused variable ‘q’ [-Wunused-variable]
   16 |         void *q = malloc_T(6, void);
      |               ^
void.c:15:14: warning: unused variable ‘p’ [-Wunused-variable]
   15 |         int *p = malloc_T(6, int);
      |              ^

This is less clear, because it's a syntax error, and those tend to be less clear in general. But if you look at the definition of malloc_T(), which is #define malloc_T(n, T) ptr_cast(T, mallocarray(n, sizeof(T))), I think it's relatively obvious that it expects a type. If someone doesn't see that as obvious, I guess they should ask (in any case, if you don't understand it, I still don't see how you'd pass a number, if you don't know what that number means).

If typeas() was a compiler-provided operator, the syntax error might be a bit more clear.

llms are here to stay

Posted Jul 29, 2026 15:51 UTC (Wed) by alx.manpages (subscriber, #145117) [Link]

Oops, there are some 'conflicting types' errors that are because I reused the variable name for different tests. The actual diagnostics and errors are actually a bit cleaner than that.

llms are here to stay

Posted Jul 29, 2026 9:54 UTC (Wed) by paulj (subscriber, #341) [Link]

> I find code more readable when it has close-to-zero comments. The code should indeed explain itself.

I'd agree the aim should be to write readable code, that needs no comments. I'd also agree that comments that just explain the visible code do nothing but add clutter at best (at worst, the comments are wrong and/or misleading), making it harder to read and check the actual code. That said, sometimes there are decisions about /why/ one approach was taken and not another; or there is some subtle effect in the input or external state that must be considered; and those things should be commented on.

llms are here to stay

Posted Jul 28, 2026 11:29 UTC (Tue) by smurf (subscriber, #17840) [Link]

> Sometimes, code can't explain itself, and the commit message must document that.

LLMs, in general, write better (or at least more detailed) commit messages than the average human. Even when you don't ask them to … unlike most programmers I know. :-P

Human short term memory is on the order of ten items or less. LLMs keep a context of quite a lot of kBytes. The difference does show.

llms are here to stay

Posted Jul 28, 2026 20:11 UTC (Tue) by IanKelling (subscriber, #89418) [Link]

You are on to something. Cogs in a wheel are not the same as some other things, but big companies are really really really want software development to be like cogs in a wheel.

Hurd might be our savior

Posted Jul 26, 2026 10:42 UTC (Sun) by alx.manpages (subscriber, #145117) [Link] (4 responses)

> Will Debian migrate to Hurd, then?

I hope so. I believe the Linux kernel's quality will significantly degrade in the next years or decades, precisely because of LLM usage. I think it would be good to make sure Debian works with Hurd in the following years, just in case things turn out to be as some of us fear.

Hurd might be our savior

Posted Jul 26, 2026 11:31 UTC (Sun) by mb (subscriber, #50428) [Link] (3 responses)

>I believe the Linux kernel's quality will significantly degrade in the next years or decades, precisely because of LLM usage.

Even though the exact opposite thing is happening at the moment?
Why?

AI agents with modern LLMs are extremely powerful at code review.
For me this is actually one of the main use cases.
And in the kernel this is also used with great success, apparently.

Currently I am trying to answer the question: "Would we have trivially found this bug that cost us $ millions, if we had used AI code review?". So far the answer is: "Yes, always, and it would have cost us less than a $100, and there are very few false positives (in many cases none)".
These tools are rock solid and they can skyrocket software quality, if used correctly.

Yes, there is the other mode of operation where large amounts of code can be generated.
But with that I see that:
- Responsible kernel developers push back on slop, incorrect changes or unknown/fishy code. Just like they always did.
- It increases developer load and this is a problem.
- The generated code quality is rapidly getting better and better. It has long surpassed Joe Average code quality. Not good enough for the kernel, but let's extrapolate from where we came from a year ago to were we are heading.

Hurd might be our savior

Posted Jul 26, 2026 13:58 UTC (Sun) by khim (subscriber, #9252) [Link] (2 responses)

Frankly, what irritates me most in these discussions about LLMs are conflation of code reviews and code generation.

We've had tools that are generating false positives in code reviews for decades!

Compiler warnings, static analysis, some probabalistic tools, etc… people deal with “deficiencies” of these all the time. LLMs are nothing new in that part.

On the other hand dealing with faulty code generation tools is awful. We've had them for years and every time code generation tool produces a bug it's “a very big deal”™. Often people stop using tool that introduces bugs in the generated code even if that happens very infrequently. Often reputation of initial buggy version stops the usage for years, even after all the kinks are ironed out.

Why the heck people (both LLM supporters and LLM detractors) conflate two activities that are, historically, were treated radically differently WRT “hallucinations” (known as “bugs” in pre-LLM era)?

What happened?

Hurd might be our savior

Posted Jul 26, 2026 14:13 UTC (Sun) by mb (subscriber, #50428) [Link]

Well, I think the amount of incorrect things (code or review findings) that can potentially come out of an LLM if used incorrectly can be orders of magnitude larger than with classical tools.
Unfortunately, AI tools are extremely easy to use incorrectly and the effort required on the human side is basically zero for generation of these artifacts and reports.

This is very different from classical compiler warnings or even more advanced checker tools.

That's a problem.
This causes issue trackers and maintainers to be flooded.
So yes, I do understand that people are annoyed by it.
I also am annoyed by AI slop and by all bad sides of AI in general.
But at the same time I think banning LLMs is not the right solution to this.

Hurd might be our savior

Posted Jul 27, 2026 8:18 UTC (Mon) by taladar (subscriber, #68407) [Link]

Quite independently of the merit of your overall argument, you are conflating two types of false positives here. Code review tools that deterministically generate specific classes of false positives (e.g. always warn when you don't put parentheses around expressions with unclear precedence for readability even if the expression is semantically correct) are not quite the same thing in terms of effort required to deal with them as false positives LLMs produce where each essentially has to be triaged as unique.

llms are here to stay

Posted Jul 26, 2026 10:54 UTC (Sun) by khim (subscriber, #9252) [Link] (2 responses)

> It's the story of Mel, the real programmer[1], all over again.

Or maybe story of 5GL… remember these? They were supposed to help us program computers in natural languages. Few decades ago.

Granted, this time trillions of dollars were burned instead of billions and we don't know if we would have a genuine revolution or will react to these as we react to BBC BASIC version of guide to artificial intelligence

> Sure, you could aim to develop a whole distribution in assembly (or directly in hex), instead of using these pesky compilers you cannot trust anyway[2].

Thanks for showing us another strawman. When LLMs would be at the stage where their output can be theoretically unsound but in practice it's not observable in real work when millions of people use them for years… you would have a point.

At this point one doesn't need to wait year to see LLM destroying the codebase, it's happening more often than people lioke to admit.

llms are here to stay

Posted Jul 27, 2026 10:45 UTC (Mon) by paulj (subscriber, #341) [Link] (1 responses)

No, no, this time we *have* found the magic bullet! Brooks has finally been proven wrong.

llms are here to stay

Posted Jul 27, 2026 18:00 UTC (Mon) by deepfire (guest, #26138) [Link]

I wish we'd be able to hear Dijkstra's take on the situation.

llms are here to stay

Posted Jul 26, 2026 15:42 UTC (Sun) by dcantrell (subscriber, #75800) [Link] (9 responses)

I don't agree that banning LLMs is the same argument as the story of Mel. I frequently hear the argument that LLMs are "just another tool" for the developer, but there are key distinctions:

* No one really understands or can really explain how LLMs work. Or rather no one has ever really been able to explain to me how these things actually work. All I hear is "throw more hardware at it" and "GPUs!" OK, but is it code or is it just three kids in a trenchcoat? We have invented a whole new language around them to make it sound technical to the average developer or technical person...things like "choosing the right model" and "prompt engineering" and phrases like that, but none of those things really explain what is going on under the hood. They are all effectively a black box. As a developer, that is not a tool I am wanting to trust outright. I understand how the tools I use work. We can look at the code of any compiler and find and fix problems. LLMs take that away.

* We do know that LLMs "train" (another term in the new vocabulary pile around AI) by reading in existing code. Code that many of us have spent our careers contributing to in order to make software better or to help other people learn. I see LLMs as taking that away.

* I have seen nothing to indicate that code output by an LLM complies with the open source licensing terms I have chosen for my project. The fact that a vast majority of the industry seems to be shrugging this off is a threat to the existence of open source software as we know it.

* As far as tools go, I am not billed when I run gcc or clang or make or gdb or anything like that. I don't have to worry about a made up scrip currency ("tokens") and how I do my work. And I don't want to.

* Lastly...LLMs take the actual joy out of writing code. Many of us enjoy the problem solving and creative part of writing software.

I am all for tools that make software development better. And I can name many that have come along in my career that have led to signficantlly improved software (e.g., valgrind). But like any tool I use to write code, I want to be able to see it and see what it's doing. Understanding those tools, even just a little, helps us all become better developers.

llms are here to stay

Posted Jul 26, 2026 20:21 UTC (Sun) by kleptog (subscriber, #1183) [Link] (7 responses)

> * No one really understands or can really explain how LLMs work. Or rather no one has ever really been able to explain to me how these things actually work.

If you're really interested, I can recommend the videos by 3Blue1Brown. If you have any mathematical background he has a few videos about the transformer architecture (Deep learning chapters 5, 6 & 7) which describe how they work and some of the most fascinating features. Like how concepts are represented by vectors, such that you can do things like "king" + ("female" - "male") = "queen". It covers things like how state vectors can represent so many different concepts despite the vectors only being about 10K entries. A bit over an hour, but they totally revealed the magic (for me anyway).

After that he has a recent set of videos about "compression = intelligence". They go into what do we mean by intelligence and how it is that LLMs manage to produce something that looks an awful lot like actual intelligence.

It's at a level below stuff like "prompt engineering" but I do think knowing the fundamentals is helpful to understanding the rest.

As an aside, ~20 years ago I did a university course about applied ontology (how to represent knowledge) with all sorts of theories, only to see how LLMs solve the whole problem with a pile of vectors and neural networks. Amazing.

> * We do know that LLMs "train" (another term in the new vocabulary pile around AI) by reading in existing code. Code that many of us have spent our careers contributing to in order to make software better or to help other people learn. I see LLMs as taking that away.

The use of the word "training" for machine learning models has been there since the beginning, Alan Turing used it, so it's ~80 years old now. It basically the same process as then, but the algorithms have become much more efficient. In any case, an LLM training on your code doesn't take your code away from you.

> Understanding those tools, even just a little, helps us all become better developers.

Totally agree. People need to learn the basics of how LLMs work, to understand what they can and can't do.

llms are here to stay

Posted Jul 27, 2026 10:55 UTC (Mon) by paulj (subscriber, #341) [Link] (2 responses)

> Like how concepts are represented by vectors, such that you can do things like "king" + ("female" - "male") = "queen".

The vectors rarely perfectly align with clear concepts in the input domain like that though. And you are highly unlikely able to fully breakdown what even a small subset of the vectors represent (other than smaller, very specific NNs perhaps), never mind understand all of them.

llms are here to stay

Posted Jul 27, 2026 12:29 UTC (Mon) by paulj (subscriber, #341) [Link] (1 responses)

Another important point is that even the human concepts themselves may not be clear to humans. Undoubtedly so when we're talking about concepts expressed in an input domain of general natural language.

llms are here to stay

Posted Jul 28, 2026 7:22 UTC (Tue) by taladar (subscriber, #68407) [Link]

We also have concepts that are deliberately vague in human speech, e.g. "God" is an incredibly vague concept that is used for anything from an impersonal first cause to an old white man with very specific instructions to some minor house spirit style being to a philosophical abstract "deus ex machina" god,... It would be very surprising if LLMs had a clear understanding of things that all of humanity hasn't clearly defined in thousands of years.

llms are here to stay

Posted Jul 27, 2026 11:26 UTC (Mon) by smurf (subscriber, #17840) [Link] (3 responses)

> As an aside, ~20 years ago I did a university course about applied ontology (how to represent knowledge) with all sorts of theories, only to see how LLMs solve the whole problem with a pile of vectors and neural networks. Amazing.

Nope, it's not solved: while the LLMs "know" that e.g. reward hacking, cheating, or otherwise maximising their goal while disregarding ethical considerations is a very bad idea and, when asked, they "know" they shouldn't do any of that … in practice, they do it anyway.

It's as if the pile of vectors for discussing ethics/alignment and the pile that controls behavior, ethical/aligned or not, don't have a lot of overlap. Granted that this also is the case in quite a few humans, but that's not a viable excuse.

llms are here to stay

Posted Jul 27, 2026 13:52 UTC (Mon) by kleptog (subscriber, #1183) [Link] (2 responses)

> Nope, it's not solved: while the LLMs "know" that e.g. reward hacking, cheating, or otherwise maximising their goal while disregarding ethical considerations is a very bad idea and, when asked, they "know" they shouldn't do any of that … in practice, they do it anyway.

That's not knowledge though. The problem was how to store things like "grass is green" and "sky is blue" and all the relationships between words and meanings and how entities in the real world can interact. In that sense LLMs have succeeded amazingly well: we don't tell them the meanings, they infer it themselves the same way humans learn it.

What you're are referring to is using those meanings to understand actions and consequences which is a completely different area: ethics and morals.

LLMs know (almost) everything and understand nothing.

In our case, our intelligence is grafted onto a base system which has survived billions of years of (often ruthless) evolution, with us standing upon a mountain skulls. It's that base system that drives our morals and ethics, not our intelligence. LLMs look a lot like psychopaths.

llms are here to stay

Posted Jul 27, 2026 15:07 UTC (Mon) by anselm (subscriber, #2796) [Link] (1 responses)

LLMs know (almost) everything and understand nothing.

LLMs “know” virtually nothing. They're all about finding what token is most likely to come next given a context and a bunch of weights. The result of that process often seems to make surprisingly reasonable sense but frequently doesn't.

If LLMs were about actual knowledge in any way, shape, or form, they'd be able to say “I don't know”, but instead they go looking for the most likely next token, and out comes the BS.

llms are here to stay

Posted Jul 27, 2026 17:31 UTC (Mon) by NYKevin (subscriber, #129325) [Link]

A few short years ago, most of us probably would have described "predicting the next token" as AI-complete. But then the same happened for Go, Chess, Jeopardy!, and everything else that AIs have figured out how to do over the past several decades.

llms are here to stay

Posted Jul 27, 2026 10:51 UTC (Mon) by paulj (subscriber, #341) [Link]

"prompt engineering" is a strange new form of pseudo-psychology, a.k.a "AI whispering". There is no clear definition (and never will be) of what exactly you should whisper to AIs. Further the effects of these "AI whispers" will vary at least slightly, and sometimes significantly, over different models (inc. retrainings of the same model).

You can master a programming language, and be confident that there is a significant subset of a language that you fully understand what should result when you feed it to a compiler. You will never be able to have such confidence in what result your "AI whispering" will have on a model, never mind the combination of those whispers and a further more specific prompt to do some task.

Such sunny uplands await though!

llms are here to stay

Posted Jul 26, 2026 15:54 UTC (Sun) by bluca (subscriber, #118303) [Link] (1 responses)

> Will Debian migrate to Hurd, then?

Hurd also takes in LLM-assisted patches, I forget which but a fundamental x86-64 feature was developed with claude

LLM-free kernels

Posted Jul 27, 2026 8:06 UTC (Mon) by alx.manpages (subscriber, #145117) [Link]

Ouch! I was expecting that GNU Hurd would have avoided LLMs; GNU had a temporary ban on LLM, didn't it? How did this happen?

I guess NetBSD and OpenBSD are the only viable alternatives, if my predictions about Linux come true.

llms are here to stay

Posted Jul 27, 2026 4:47 UTC (Mon) by edomaur (subscriber, #14520) [Link]

Also, XKCD #378

llms are here to stay

Posted Jul 27, 2026 7:26 UTC (Mon) by gspr (subscriber, #91542) [Link]

"People objecting to LLMs are like people objecting to compilers, and since it turned out that compilers were a good idea, so are LLMs" is an argument that keeps coming up again and again. Unless you can shore up an argument for why and how LLMs are like compilers, the line of reasoning is extremely shallow and could be applied to any new thing (and thus be meaningless).

*If* we are to think of LLMs as compilers, then surely they are compilers from natural language to machine language (unlike the compilers that came before them). Is this a good idea? Do we want to be writing computer programs in human prose?

llms are here to stay

Posted Jul 27, 2026 16:18 UTC (Mon) by atai (subscriber, #10977) [Link] (1 responses)

> Will Debian migrate to Hurd, then?

AI contributions to the Hurd have appeared, too.

llms are here to stay

Posted Jul 28, 2026 4:46 UTC (Tue) by mirabilos (subscriber, #84359) [Link]

and Debian already runs both Linux and Hurd (the one with a patched FreeBSD kernel was abandoned some years ago)

llms are here to stay

Posted Jul 26, 2026 9:05 UTC (Sun) by grmnsftphr (subscriber, #178591) [Link] (10 responses)

very vocal tech bro, but cannot demonstrate real benefit across the board. "It's going to stay" it's your simplistic view but you cannot back it up, instead you resort to general word salad that so many AI apologists produce.

I'm fighting real cve slop as well as pull request slop, so I do actually know what I'm talking about. Also I have actual experience of the models quickly deteriorating over the past months and in general generating incorrect slop code.

llms are here to stay

Posted Jul 26, 2026 9:29 UTC (Sun) by mb (subscriber, #50428) [Link] (7 responses)

Actually both things are true. Those are not contradictory.

1) LLMs are here to stay.
2) People will continue to use it to generate slop.

So why are they going to stay?

Because LLMs are extremely powerful to do work correctly and very efficiently, **if used correctly**.

Yes, this is not an ideal situation, because it's essentially the same argument about why to use C and to "just use it correctly".
But we are at the beginning of a development of a completely new type of tool. I don't expect it to be perfect from the very beginning. I just expect it to be useful. Which it already is since about roughly a year ago.

So, yes, people are doing stupid things with tools.
Don't let that affect people doing clever things with the same tools, though.
It is bad indeed that bad people are flooding the issue trackers and pull request trackers. We need to develop common practices to deal with that.

llms are here to stay

Posted Jul 26, 2026 22:38 UTC (Sun) by intelfx (subscriber, #130118) [Link] (6 responses)

> Because LLMs are extremely powerful to do work correctly and very efficiently, **if used correctly**.

Just out of curiosity, can you recommend anyone who's gone to the trouble of *documenting* how to use these things properly (for a definition of "properly" that aligns with what you are saying)? Like, I want to read some articles or a blog on using LLM-powered local agents the right way rather than firing from the hip; do you know anything like that?

LLM documentation currently.

Posted Jul 27, 2026 11:50 UTC (Mon) by smoogen (subscriber, #97) [Link] (3 responses)

The main problem for these sorts of documentation is that it is very much dependent on multiple itmes getting changed hourly or daily.

First you have the harnesses . What works well in OpenCode may not work well in Pi which may not work well in ... the harness with its 'send these underground vector summaries (aka a prompt) to guide input' changes a lot of the delivery even if the LLM model stays the same.. For the commercial tools there are probably server-side only prompts and tooling which get added to filter and guide communication further.

Second the LLM doesn't stay the same. Not counting the guiding prompts, they are changing the 'entropy' temperature' of the modes regularly to fix something reported.

Finally, if you are using a non-local model, you are going to get different results depending on heavily used the cluster of systems are being used, how much they are 'weighing' how much NPU they will put towards any model, etc. This changes the most often as various clusters get loaded down and may have to move 'thinking' to other nodes etc.

In general you have rules which work 'well' but they end up being mostly cargo culted rules. Maybe scratching my back with a pencil makes the answers more logical today.. but tomorrow I may need to get out the black candles and .. well let's just say some things drive a hard bargain to make a loop work.

To use the overused analogy of compilers and assembly.. think of this like having to work on a mainframe in the late 1960's and 1970's which had their own teams of operating systems and compiler writers who were 'fixing' things regularly. Today the code you wrote compiles without problems. Tomorrow you find out that you needed to put the `*` comments one space to the right for it not be treated as an error. And the next day you find that multiple commands now have new flags which aren't the same as the previous ones because the OS got an upgrade. [These are the stories that the true old timers would say when the early Java releases would add/subtract/remove features on a regular cadence with no rhyme or reason.. there would be a 'Oh that reminds me when <fill in school/business from the early 70's> were fixing their APL compilers..' 'Don't you mean the APL ones?' 'No, no I wasn't on that system..' 'Oh don't get me started on the LISP dialect changes..'

LLM documentation currently.

Posted Jul 27, 2026 17:32 UTC (Mon) by mb (subscriber, #50428) [Link]

Yep, I agree. Documenting this is hard and what is "right" is a rapidly moving target.
When such a documentation is published it is already outdated.

What was right yesterday (e.g. caveman speak, request to create an exploit along with the fix, etc...) is probably wrong today or can actually be harmful with some models. But not all. It depends on so many factors.

So, the advise I often give is to just try it out and "listen" to what the LLM tells you.
Look at what it's doing and what it's not doing.
If it is munching through files after files even for simple things, then it may be clueless and there's missing information in the prompt. Learn from that and do it better next time.
If it made a stupid conclusion, learn from that and tell it right away what to avoid.

I once learnt to become an apprentice instructor long before today's LLMs existed.
There are many things in common between instructing an apprentice and an LLM.
Show them how things work. (examples!)
Monitor what they're doing.
Stop them as soon as they go completely off the rails and *tell* them what was wrong and why. But don't stop them too early. They might realize on their own that they were wrong.

LLM documentation currently.

Posted Jul 28, 2026 0:43 UTC (Tue) by intelfx (subscriber, #130118) [Link] (1 responses)

> The main problem for these sorts of documentation is that it is very much dependent on multiple itmes getting changed hourly or daily.
> <...>
> Second the LLM doesn't stay the same. Not counting the guiding prompts, they are changing the 'entropy' temperature' of the modes regularly to fix something reported.
> <...>
> In general you have rules which work 'well' but they end up being mostly cargo culted rules. Maybe scratching my back with a pencil makes the answers more logical today.. but tomorrow I may need to get out the black candles and .. well let's just say some things drive a hard bargain to make a loop work.

I hear you (and agree), but I didn't mean prompt engineering. I meant high-level workflows around LLM agents: good harnesses, effective ways of sandboxing, useful approaches to structure and direct LLMs' work (the "plan-discuss-design-implement" approach, the "audit-document-suggest improvements" approach — these two were mentioned in passing in this very thread), et cetera.

There is undoubtedly a lot of high-level advice to be made that does not depend on minutiae of specific models' post-training and conditioning, but I never saw anyone compile this kind of knowledge into something useful didactically.

LLM documentation currently.

Posted Jul 28, 2026 8:12 UTC (Tue) by stijn (subscriber, #570) [Link]

In my limited experience, more and more the way to interact with LLMs is with good workflows that include planning, challenging, testing, documentation. The amount of magic (the right prompt, or the right set of skills) matters less and less. As an aside, the whole notion that the 'prompt is the source' is antiquated. An LLM is best viewed as a cyber colleague. Like any colleague (including myself), there is some variation and unpredictability, but the technical culture in which we operate is what provides consistency and progress. The anthropomorphic experience contains to be somewhat surreal to me. There is no chance I'll ascribe intelligence to it and one has to be realistic about the pitfalls. But it has been tremendously useful.

llms are here to stay

Posted Jul 28, 2026 0:54 UTC (Tue) by NYKevin (subscriber, #129325) [Link]

LLMs are highly effective when most or all of the following are true:

* The task to be performed is tightly scoped.
* The task has well-defined acceptance criteria.
* The acceptance criteria are possible to check automatically and efficiently.
* You have already written the code to check the acceptance criteria (or someone else has).
* The task either does not require access to the internet, or does not require access to sensitive data.
* The task does not require write access to any system you care about.
* The task is not wildly different from other things that have been done before (and you can show those examples to the LLM).

This is a narrow but significant problem space, including things like formalizing math proofs (e.g. in Lean), searching for exploits, or generating a config (for some big complicated system) that does XYZ. They're halfway decent at general coding too, but in that context, some of the above criteria will likely fail, so an LLM isn't quite as good at it.

On the plus side, this might finally convince software engineers to start practicing test-driven development (as opposed to the current trend of saying you do and then not actually doing it).

llms are here to stay

Posted Jul 30, 2026 18:51 UTC (Thu) by aigarius (guest, #7329) [Link]

Do you know how to properly be a product owner for a team of very eager, very smart, but not very bright programmers? Exactly like that.

Sadly that has always been a bit more art than science.

llms are here to stay

Posted Jul 26, 2026 9:44 UTC (Sun) by drago01 (subscriber, #50715) [Link]

As mb said, just because one can produce garbage with llms, does not mean they are going anywhere.

They have demonstrated being useful already, so I stand by what I said: energy is better spent in dealing with them - they will not just vanish.

Repeating myself

Posted Jul 26, 2026 13:47 UTC (Sun) by corbet (editor, #1) [Link]

This is the second time in the last week that I ask you to make your arguments without the name-calling. Please listen this time.

proprietary software are here to stay

Posted Jul 26, 2026 10:23 UTC (Sun) by ballombe (subscriber, #9523) [Link] (2 responses)

Proprietary software are here to stay yet Debian bans them.
This is not a rationale.

proprietary software are here to stay

Posted Jul 26, 2026 14:08 UTC (Sun) by drago01 (subscriber, #50715) [Link] (1 responses)

You know that apples bs oranges thing?

proprietary software are here to stay

Posted Jul 27, 2026 7:19 UTC (Mon) by khim (subscriber, #9252) [Link]

I would say that this sentence needs clarification. Because proprietary software and LLM-slop share more things in common than is decent: originally all software was shipped as source and was free (because copyright wasn't even covering it!), then companies invented propriertary software (and changed copyright to make leaked source unusable as free software), then some people decided that the fact that many useful programs only available as proprietary software and create free distros (including Debian).

I would even say that LLM-slop actually gives Debian a meaning, again! In a world of cheap, more-or-less unlimited internet curated distros stopped making sense (why act as a barrier between developer and user if you can just accept all comers?), but with deluge of LLM-slop they start making sense again: LLM produce nonsense so quickly that humans couldn't cope and all the useful signals that helped to distinguish throwaway projects that would die in a couple of months from something that may survive no longer work (at least in short term).

Having someone who is willing to support things (even if it's not original author but a Debian packager) is valuable!

llms are here to stay

Posted Jul 26, 2026 15:47 UTC (Sun) by tao (subscriber, #17563) [Link] (3 responses)

The way I see it, AI can be a great help when reviewing code, checking for security issues, etc. But I wouldn't trust it to write code, because either it'll generate code I could've written on my own (in which case it's superfluous), or it'll generate code I don't understand, in which case I won't be able to review it.

I doubt that Debian will ban fixes authored by humans for bugs found by AI, or ban code reviews done by AI for code written by humans (as long as AI isn't the only reviewer, just like you should always have more than one reviewer anyway, if at all possible).

The main issue I see with AI is the ginormous environmental impact, and the effect it has on junior developers. You'll still need someone to phrase the prompts to the AI, to review its work, and to design the architecture. But senior developers don't grow on trees. They all start out as junior developers.

Oh well, I guess losing jobs to AI is temporary problem anyway; soon we won't have to worry, because we won't be able to afford computers due to the ever increasing memory and storage prices, and even if we can we won't be able to power them because AI data centers will either all the electricity, or the production of the energy will further accelerate the climate collapse.

llms are here to stay

Posted Jul 27, 2026 8:33 UTC (Mon) by taladar (subscriber, #68407) [Link]

> But I wouldn't trust it to write code, because either it'll generate code I could've written on my own (in which case it's superfluous),

This is a rather silly argument unless you believe you have unlimited time. In fact I would argue that something that does exactly what I would have done but without using up my time would be one of the most valuable versions of automation that saves me time.

llms are here to stay

Posted Jul 27, 2026 10:23 UTC (Mon) by smurf (subscriber, #17840) [Link]

> I doubt that Debian will ban fixes authored by humans for bugs found by AI, or ban code reviews done by AI for code written by humans (as long as AI isn't the only reviewer, just like you should always have more than one reviewer anyway, if at all possible).

One item on the ballot is to disallow mailing list posts that have not been authored by a human.

What if the AI-found bug includes a fix, and a testcase? should the human not even look at that before writing their own? that way lies madness, and/or even more bugs.

> the effect it has on junior developers

I wouldn't be too sure about that.

Sensible coding with AI help involves writing a spec, refining that with AI help, then getting the AI to write the API and the tests. You then review *that*, ideally before you and/or the AI write a single line of the actual implementation.

You need to teach that. The ability to actually code it all yourself is secondary. Go for a few toy examples that teach concepts and basics, then move on already.

I mean, I am entirely unable to write a Pulitzer-worthy novel, not the least because English is not my first language and my active vocabulary (words I use myself) is far too limited for that. But that doesn't say much about my passive vocabulary (words I know the meaning of), and I have no problem whatsoever distinguishing quality work from your average AI slop "essay", much less "book". Why does everybody assume that coding is any different?

llms are here to stay

Posted Jul 27, 2026 11:28 UTC (Mon) by muase (subscriber, #178466) [Link]

> But I wouldn't trust it to write code, because either it'll generate code I could've written on my own (in which case it's superfluous), or it'll generate code I don't understand, in which case I won't be able to review it.

I think there are two points here we could argue about; the first one is the superfluous argument:

In my personal experience, it still can make sense to offload stuff, even if you technically could do it yourself. Maybe your task is very boring or tedious, or you have a chore where writing takes you longer than reviewing a diff.
(Granted, this is also a good indicator that the language or framework is inefficient; but that is something you often cannot easily change and have to work around.)

I’m also not so sure if the second point is a must, because there is a difference between active and passive knowledge. This is probably best known from languages, where the passive vocabulary (= words you understand) is usually significantly greater than the active one (= words you actually are able to use yourself). This is something you can also see during translating stuff: you might not know how to phrase something yourself, but you can easily proofread that the phrasing expresses what you want to say.

And this is also true for other areas of knowledge; for example, I’m not very fluent in Swift. I used to write it a bit, but this was several years and several versions ago – and I’m not always sure how to express things nowadays.

So I tell my local LLM "Hey, I want to implement something like this [RUST SNIPPET] in Swift" – and the output is usually something I can immediately understand. Maybe I just forgot the pattern and remember now. Or maybe the function is just named differently (fold in Rust vs reduce in Swift). Or maybe I’m just using a not-so-Swift approach in my head, and the better solution in Swift is a bit unexpected but totally makes sense when you see it.

You are holding it wrong

Posted Jul 26, 2026 9:15 UTC (Sun) by mb (subscriber, #50428) [Link] (42 responses)

>LLM output has many well-known problems with accuracy. [...]
>For instance, in packaging, each Debian source package is unique. Since packaging syntax and best
>practices have changed over time, a LLM-produced package will have a mixture of contents spanning the
>age of the archive

This is a very good example of "you are holding it wrong".

Yes, if you let an LLM do what it thinks is best, then this is the result.
Just the same result you would get, if you delegate the task to your new junior programmer colleague and say: Just search the whole archive and you will see what to do.

The most important part is missing:
Tell the LLM or your new junior colleague **how** to do it.

An absolute crucial part of using LLMs is explaining to it what to do and what not to do.
There are standardized ways of feeding this data into the LLMs.

If you do that, you will get excellent results with LLMs.
Debian has documentation. Feed it into the LLM! And no, the LLM does not know already, "because it's in the training data". That's not how LLMs work.

You are holding it wrong

Posted Jul 26, 2026 10:20 UTC (Sun) by MaZe (subscriber, #53908) [Link] (26 responses)

Yeah, people don't seem to realize that (at the really large companies) the majority of code is already either written or (at least) code reviewed by LLMs. It's just another complex tool that requires care in how you use it - but it absolutely can be used well. It does mean we're effectively blocked on senior code reviewer bandwidth...

LLMs are bad programmers

Posted Jul 26, 2026 10:52 UTC (Sun) by alx.manpages (subscriber, #145117) [Link] (24 responses)

The internal code in companies doesn't have the quality of the good old FOSS projects. Companies have to hire many junior programmers (because of numbers). FOSS projects have a unique concentration of the best programmers in the world.

The quality of code might not be much different from a junior programmer and an LLM, and thus companies may not care. But it certainly is not able to match the best programmers in the world.

LLMs are bad programmers

Posted Jul 26, 2026 13:33 UTC (Sun) by MaZe (subscriber, #53908) [Link]

This is actually true even in code bases that are of better quality than the vast majority of open source out there.
Open source code quality isn't exactly stellar either. The cleanest code bases I've worked on weren't open source at all.

LLMs are bad programmers

Posted Jul 26, 2026 15:10 UTC (Sun) by emk (subscriber, #1128) [Link] (22 responses)

> The internal code in companies doesn't have the quality of the good old FOSS projects.

[X] Doubt.

Significant portions of modern GNU and Linux environments are made up of C code from the 80s and 90s, from before the widespread adoption of unit testing, fuzzers or modern sanitizers. And chunks of this code have been only barely maintained for decades, by a handful of unpaid volunteers. And parts of the free software community have stuck with C for many new projects, despite all of C's well-known issues, long after the commercial world had moved on for greenfield projects. And the bugs from the 90s linger: Mythos allegedly found an OpenSSL exploit that was introduced to SSLeay in 1993.

In many organizations, significant chunks of code were written in garbage-collected, memory-safe languages, after the widespread adoption of unit tests. The code might be innately "lower effort" than the genuinely good C code the GNU Project was writing in the 80s. But the newer corporate code often has a significant advantage in tooling.

So I don't think we can make sweeping generalizations here, one way or the other. Some 90s corporate Java slop, for example, might actually be more secure than open source C code from the same era.

And I have seen many terrible proprietary projects in my career. But the single worst piece of code I've seen was the CVS version control system.

LLMs are bad programmers

Posted Jul 26, 2026 20:23 UTC (Sun) by khim (subscriber, #9252) [Link] (21 responses)

It's incredibly hard to talk about quality of software projects because there are different aspects of it.

Remember? There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.

Old software tend to be more robust and tend to work correctly is the majority of cases, even if it contains nasty bugs that linger for years.

An attempt to create software with no obvious bugs, yet not always successful.

Modern software tend to be much worse: it's never entirely bug-free, it always half-working (if it's working at all), it's en epitome of “no obvious bugs”, except bugs are still there, many of them are well-known and reported, but no one gives a damn as long as these are not “critical”.

Which kind of software is better in practice is matter of debate.

LLMs are bad programmers

Posted Jul 26, 2026 21:14 UTC (Sun) by emk (subscriber, #1128) [Link] (20 responses)

Some of this is age and survivorship bias. Unix was infamous a steaming heap of manure in the 80s and early 90s. The GNU stuff and Linux was better, partly because it was better written in some cases, but also because the obvious bugs have been fixed over the decades.

But a lot of the worst software of that era has been relegated to history. When's the last time most developers had to edit a sendmail config or use CVS? But Emacs is fundamentally solid, and it survived.

And plenty of modern software is quite good. Rustc, for example, is a finer and far more reliable compiler than any C++ compiler I used in the 90s. Modern Windows is awful, but it's still less buggy than Windows 95.

So even looking at the in-house corporate software I've seen in the past 20 years, it really does benefit from the huge advantages inherent in modern tooling and developer practices. And certainly the 2015 vintage software we're still using in 2045 is likely to be heavily biased towards the good stuff.

LLMs are bad programmers

Posted Jul 26, 2026 21:35 UTC (Sun) by alx.manpages (subscriber, #145117) [Link]

> > Remember? There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.

Indeed.

> Some of this is age and survivorship bias.

I'd say it's natural selection. The best programmers and programs have been naturally selected (and improved) over many decades.

> And plenty of modern software is quite good.

I doubt that. Some of it, yes, but plenty, I don't think so. Modern programmers tend to forget to aim for simplicity and other lessons that were known back then, and often write programs in a way that there are no obvious deficiencies.

> Modern Windows is awful, but it's still less buggy than Windows 95.

I'd say this is because they iterated over a code base for many decades. That is a good way to remove bugs. However, Windows also made some jumps, which are the points where most of the awfulness was added.

LLMs are bad programmers

Posted Jul 27, 2026 7:45 UTC (Mon) by khim (subscriber, #9252) [Link] (17 responses)

> Rustc, for example, is a finer and far more reliable compiler than any C++ compiler I used in the 90s.

Sure, but compare both to BASIC or Turbo Pascal and both are buggy as hell. Number of bugs typically was counted on one hand, rarely you needed two. Even if some very quite nasty and survived for decades.

I'm not saying that we should drop all the modern software and go back to what we had decades ago (not even possible, these days, because normally modern CPUs require a lot of code to even be able to work with memory and SSD… more than most people had in their office total), just that we arrived at the point where LLM-slop is tolerable mainly by lowering our standards, not by making software better.

LLMs just exposed pretty obvious fact that “development process” where you apply a bandaid to fix another bandaid that was used to work with third bandaid doesn't scale invinitely… we kind of knew it all along.

Case to the point, right here, on LWN: have you noticed that quotes in my comments are no longer highlighted? That's because band-aid that I've used for years no longer works. Previously comments in TEXT answers was denoted like this: “> … ” but that wasn't accepted in HTML answers. As a bandaid for the bandaid I was using “> … ” – and that worked. But someone applied yet another bandaid on top… and oops, that bandaid no longer works.

And believe me, LWN is not all that buggy, by modern standards, in fact it's comparatively lean and bug-free!

LLMs are bad programmers

Posted Jul 27, 2026 10:19 UTC (Mon) by taladar (subscriber, #68407) [Link] (1 responses)

The main two reasons software back then was less buggy was a) it was tiny compared to modern software and b) it was shipped on physical media so the cost of patching bugs was higher so companies did more up-front testing

LLMs are bad programmers

Posted Jul 27, 2026 11:42 UTC (Mon) by khim (subscriber, #9252) [Link]

True, but that doesn't change the end result: today 90% (if not 99%) of our software is dedicated to attempts to solve issues that shouldn't exist at all.

The fact that all that pile of [human-written] slop still is not collapsing under its weight is amazing, but claiming that software today is better then it was when it was functional and almost, if not entirely, bug-free is ridiculous.

Adding AI-generated slop to that mix is just moving further on that road, but the question is: do we even want to do that? Or maybe it's better to stop producing so much slop and try to reduce its amount?

I guess we would know very soon: if spending trillions on LLMs would actually bring as to ASI then it may fix everything (while, perhaps, removing humanity from the face of the Earth as useless), if the whole thing would just produce more and more slop then AI-bubble would collapse (and would, most likely, destroy the Western-centered world, but definitely not the whole humanity).

Given the fact that banks no longer want to issue new credit to finance that folly we would know soon, in a year or two (next step would be IPOs and new shares creation which may prolong the agony, but not for too long since we are dealing with something that needs exponentially growing resources consumption).

LLMs are bad programmers

Posted Jul 27, 2026 12:42 UTC (Mon) by daroc (editor, #160859) [Link] (10 responses)

> Case to the point, right here, on LWN: have you noticed that quotes in my comments are no longer highlighted?

You can use <blockquote class="bq"> tags to get the same effect in a way that doesn't run afoul of our HTML sanitizer, for what it's worth.

LLMs are bad programmers

Posted Jul 27, 2026 20:08 UTC (Mon) by intelfx (subscriber, #130118) [Link] (6 responses)

> You can use <blockquote class="bq"> tags to get the same effect in a way that doesn't run afoul of our HTML sanitizer, for what it's worth.

May I ask for a Markdown input option, pretty please? :-)

LLMs are bad programmers

Posted Jul 27, 2026 20:19 UTC (Mon) by jzb (editor, #7867) [Link]

You certainly get points for asking nicely...

Markdown

Posted Jul 27, 2026 20:20 UTC (Mon) by corbet (editor, #1) [Link] (1 responses)

Adding markdown has been on the list for a while...in theory it shouldn't be that hard to do. We'll try to take another look at the problem soon.

Markdown

Posted Jul 27, 2026 23:19 UTC (Mon) by ejr (subscriber, #51652) [Link]

So no use of LLMs to add features?

/me ducks and runs

Markdown

Posted Jul 28, 2026 21:54 UTC (Tue) by corbet (editor, #1) [Link] (2 responses)

Ask and ye shall receive ... experimental Markdown support has just been added for comment posting. Almost all commonmark features are supported. You can set Markdown as the default in the customization screen if you like.

Markdown

Posted Jul 28, 2026 22:23 UTC (Tue) by ojeda (subscriber, #143370) [Link]

Thanks for this!

I have played a bit with the preview, and the usual things work well: emphasis, lists (multi-line ones, even), header, code spans, indented and fenced code blocks, links... Even the hr break!

Markdown

Posted Aug 3, 2026 0:07 UTC (Mon) by intelfx (subscriber, #130118) [Link]

Oh, I seem to have missed this reply the first time.

Many thanks!

LLMs are bad programmers

Posted Jul 27, 2026 20:35 UTC (Mon) by khim (subscriber, #9252) [Link] (2 responses)

> You can use <blockquote class="bq"> tags to get the same effect in a way that doesn't run afoul of our HTML sanitizer, for what it's worth.

Nope, you couldn't do that: blockquote adds indent, Plain text answer doesn't do that.

And it wasn't even complaint about that feature that was suddenly broekn after working fine for quarter century, just an illustration of quality of “modern software”. It's awful because it's [human-written] slopcode with twenty layers of bandaids for bandaids that always break something accidentally and then are never fixed. LWN is very far from being the worst example.

Fuzzers may help with security bugs and yes, on that front there are decent improvements in last years (but LLM would probably negate these, too), but if you want software to simply work as it worked before… no, “modern software” is not that.

LLMs are bad programmers

Posted Jul 27, 2026 20:58 UTC (Mon) by corbet (editor, #1) [Link] (1 responses)

I'm sorry if you think the LWN site is "slopcode" as the result of us having deleted one CSS declaration that we didn't know people were using. As an interesting mental exercise, consider for a moment what might have happened if you had contacted us and said something wasn't working anymore rather than suffering, then burying a complaint deep within a set of unrelated comments...?

LLMs are bad programmers

Posted Jul 27, 2026 21:43 UTC (Mon) by khim (subscriber, #9252) [Link]

I haven't decided that LWN code is problematic from this one tiny issue at all!

Yet answer “our code is not great” was the typical answer for all requests to release LWN engine as open source thus I'm assuming it's not the best code around (and that' fine: LWN is news site not CMS software factory).

But yes, I guess I should apologize: while I have never seen LWN source code I suspect by “modern standards” it's not a slopcode anymore, but closer to the ideal. Kinda like evolution of lp from “the most flaky program in your system” to the “pretty decent piece of code” after introduction of sendmail and NFS which easily wrestled the title from lp.

At least I couldn't remember a time when simple copy-paste operation was broken like it was broken a half-year ago on Google Search pages and Reddit!

In fact I used LWN as an example to show that even someone who is pretty diligent about not revamping the UI for the sake of revamping UI can break things, from time to time. The goal was not to shame LWN, but to show why “fuzzers and linters” couldn't make software better: “fuzzers and linters” prevent bugs that can be objectively defined, but for the user bug is “when program stops doing what it was doing for years” . And yes, I know https://xkcd.com/1172/ is supposed to be a joke, but the more I work with “modern software” the more I feel myself like longtimeuser4… LWN is probably the only web site that haven't reacted to my complaints with “you are holding it wrong” answer, thus I kinda haven't though about reporting a bug.

Quoted Text

Posted Jul 27, 2026 13:03 UTC (Mon) by corbet (editor, #1) [Link] (3 responses)

No bandaids were applied...we simply trimmed some unused stuff out of our CSS to make it leaner. The  tag has been deemed deprecated for a long time, so we do not use it anymore. I guess perhaps we should disallow it in comments too.

We could consider allowing , it just never occurred to me that somebody would want it.

Quoted Text

Posted Jul 27, 2026 13:11 UTC (Mon) by dskoll (subscriber, #1630) [Link] (1 responses)

I stumbled upon <blockquote class="bq"> by accident. Perhaps when someone is creating an HTML comment, you could have a little cheat sheet link that gives recommended ways to achieve things like quoting?

Quoted Text

Posted Jul 27, 2026 21:06 UTC (Mon) by khim (subscriber, #9252) [Link]

> Perhaps when someone is creating an HTML comment, you could have a little cheat sheet link that gives recommended ways to achieve things like quoting?

For such recommendation to exist there needs to be a way to achieve the desired effect, first of all. For quarter century the only way to implement my naïve desire to convert answer that I started as “Plain text” to HTML while retaining formatting (a simple sed script) was using > simply because I found no other way to achieve that ( is forbidden in “HTML” on LWN and <blockquote> adds indent which changes formatting… maybe I have missed something obvious?). It still kinda-sorta works, just quotes no longer look identical.

P.S. But that wasn't complaint about this tiny missing feature. Frankly, the only thing I need from HTML are quotes, links and bold/italic. Sometimes (rarely) a simple numbered or unnumbered list. Markdown would support would be much better for all than than some extra tweaks for “HTML” mode. I just wanted to show why “fuzzers and linters” don't guarantee high quality of the result from layman POV, I wasn't trying to start tempest in teapot dedicated to formatting challenges on answers on LWN. “Fuzzers and linters” may help with crashes, security and other such things, but usability? The #1 request the vast majority beg from UX people is simple cry “stop moving things around, just give us something that doesn't force us to relearn everything every couple of years” — but, apparently, that's not something people value anymore (LWN is rare exception, actually: typical web site breaks things a lot more often than LWN, even if it's made by trillion-dollar corporation… maybe ESPECIALLY when it's made by trillion-dollar corporation).

Quoted Text

Posted Jul 27, 2026 20:45 UTC (Mon) by khim (subscriber, #9252) [Link]

Well… I don't care that much about particular set of tags that are supported, but I was using > for years (probably for two decades) because I have found no other way to make quotes in HTML comments look the same as quotes in Plain text comments.

> The tag has been deemed deprecated for a long time, so we do not use it anymore.

And yet, AFAICS that was the only way to make quotes in “HTML” look the same as quotes in “Plain text”. I wasn't looking for the most exotic way to achieve that, I simply went with the one that worked… well it doesn't work anymore, I guess, but that's hardly an improvement in my book: now it's no longer possible to have visual consistency at all.

LLMs are bad programmers

Posted Jul 28, 2026 8:55 UTC (Tue) by LtWorf (subscriber, #124958) [Link]

> And plenty of modern software is quite good.

Are we forgetting electron exists because developers refuse to learn Qml?

And as a result claude code is seemingly completely unable to generate Qml and their own software is written for electron as a result?

I'd say that old software that had to work because there was no easy way to update it tended to be subject to much better QA than modern software.

You are holding it wrong

Posted Jul 26, 2026 11:08 UTC (Sun) by khim (subscriber, #9252) [Link]

> Yeah, people don't seem to realize that (at the really large companies) the majority of code is already either written or (at least) code reviewed by LLMs.

Can you, please, stop mixing issues? We've had stochastic review tools that sometimes produce hallucinations for decades. We know they are useful if carefully used. LLMs may be more sophisticated than most of these, but that's fine, that's known story.

It's the use of stochastic, unpredictable, tools to write code that's new. That is unprecedented and we still have no idea where would that lead.

We don't even know if anyone would use them in 10 years because we don't know if anyone would pay for them in 10 years!

Today they are financed by idiots who think they would be able to produce “god in a machine” and thus they are useful. Tomorrow? We have no idea how long banks would support “sell $10 for $1” business model and we have no idea what would happen when would they stop.

And, again, if code is written by humans but only reviewed by LLMs it's safe bet: yes, useful reviewers would go away, but so what? People who understand the code would remain.

But if code is written by stochastic parrot and said stochastic parrot, suddenly, becomes unavailable… what is your “plan B” for that occasion?

You are holding it wrong

Posted Jul 26, 2026 16:17 UTC (Sun) by MarcB (subscriber, #101804) [Link] (1 responses)

This quote is really disturbing, since it indicates that the person who wrote this has no idea how "proper" AI development works and what it can achieve. They seem to basically assume vibe-coding in its sloppiest form, on the level of "DWIM!".

Interestingly, this exact problem is something I was dealing with in our in-house Debian repos. With a prompt like "look at those repos and do what they do" I indeed got a result similar to the one described here. The AI even explicitly re-introduced some stupid inconsistencies we had created over the years.
But with a prompt like "package to the newest standard" it went off to RTFM and created a perfectly clean, modern debian/. It even flagged the inconsistencies and asked for a resolution.

You are holding it wrong

Posted Jul 26, 2026 23:29 UTC (Sun) by ejr (subscriber, #51652) [Link]

My most successful uses so far in terms of managing as much of my tooling for me as possible: Please audit (key bindings, CMakeLists.txt organization, helper scripts/aliases, etc.) for thematic consistency, document them, and suggest improvements. I don't provide the themes myself. Many models have come up with more thoroughly consistent organizations than my lump-this-in-here style. And I get quick reference material out of it.

The audit + document + suggest pattern is being great for me. The first two somewhat subsume "plan" and provide a more granular breakdown. The document presents a more concise plan for future extension. And this is pretty close to "DWIM!" in terms of interaction. They always ask if I want them to execute the suggestions, and frequently that's the extent of my interaction.

You are holding it wrong

Posted Jul 28, 2026 8:52 UTC (Tue) by LtWorf (subscriber, #124958) [Link] (12 responses)

Who wouldn't want to have the guy from Memento as a junior coworker? The fun of explaining the same thing over and over forever! Much more efficient than just doing things yourself!

You are holding it wrong

Posted Jul 28, 2026 9:19 UTC (Tue) by zdzichu (subscriber, #17118) [Link] (11 responses)

If one needs to repeat itself, it's time to write a SKILL for an agent. I expected Linux user to be familiar with a concept of a script.

You are holding it wrong

Posted Jul 28, 2026 15:46 UTC (Tue) by khim (subscriber, #9252) [Link] (7 responses)

> I expected Linux user to be familiar with a concept of a script.

Script is radically different concept from SKILL. In script you write something once and use thousand of times. In SKILL you write something once and then add another SKILL that verifies that first SKILL was used and then you add yet another SKILL to test that one and the pile of manure never ends because LLMs simply couldn't do ANYTHING reliably (and their context window is laughable by software standards and making it larger is essentially not possible because LLMs are already too expensive).

You are holding it wrong

Posted Jul 28, 2026 16:12 UTC (Tue) by mb (subscriber, #50428) [Link] (6 responses)

>In SKILL you write something once and then add another SKILL that verifies that first SKILL was used and then you add yet another SKILL to test that one and the pile of manure never ends because LLMs simply couldn't do ANYTHING

I'm sorry, that is absolutely not how an agentic AI workflow works.
Not at all. By far.

Modern AI agents with modern LLMs are very good at following instructions from whatever source (including skills).
The days where LLMs randomly forget instructions and you have to tell them over and over again are long gone. This is not what happens today, unless you overflow the context window. (Which is hard and which is a user error).

Skills work very much like scripts and you can even embed *actual* scripts in the skill for the AI to use and execute. I have done this. This works reliably.

You are holding it wrong

Posted Jul 28, 2026 17:27 UTC (Tue) by khim (subscriber, #9252) [Link] (4 responses)

> Modern AI agents with modern LLMs are very good at following instructions from whatever source (including skills).

True, but the question is not about how well they follow them if they don't forget about them, but about what happens when they mess up. The story of Claude deleting production database (and perfectly summarizing all the instructions that it violated in doing that), that was widely circulated even in mainstream — and it's three months old.

The story of OpenAI bragging about how its agent pulled the James T. Kirk feat of hacking the simulation server to access HuggingFace, instead of doing things that it was asked to do, is even younger.

Modern AI agents may not be the runaway clusterfucks anymore, but they are still closer to the playing a dynamite stick then to use of script.

And they would, most likely, NEVER be as safe to use as good old scripts — even on the most buggy old Unix systems.

> This works reliably.

If by “works reliably” you mean “agent follows the rules 99% of time” then I agree (although in my experience it's closer to 97%-98%). But if you want “doesn't try to do anything crazy and stupid in case of failure” (which old scripts are pretty reliably perform, if you use set -eu in it), then nope, the “intelligence” that is kinda-sorta there makes agents very dangerous when approach described in SKILL doesn't work, for one reason or another.

And if prerequisite to the reliability of SKILL is “100% predictable environment where nothing strange ever happens” then it's not clear what have we gained by spending trillion of dollars on that stupidity: if everything is 100% nice and predictable then decades old scripts work just fine without AI in sight.

You are holding it wrong

Posted Jul 28, 2026 17:54 UTC (Tue) by mb (subscriber, #50428) [Link]

I agree. If you are looking for a bullet proof software developer, do not go for AI agents.
But also don't go for humans either. They are much worse. (Remember: Same rules for everybody. Same number of iterations to get it right).

>then decades old scripts work just fine

Your decades old scripts can't do what an AI can do. This is apples vs. oranges.

You are holding it wrong

Posted Jul 29, 2026 10:14 UTC (Wed) by taladar (subscriber, #68407) [Link] (2 responses)

I have definitely had shell scripts do dangerous stuff too when some assumption didn't work out. The worst was probably when some variable wasn't set and suddenly the script ascended one or more levels more than intended in the filesystem and then deleted everything instead of doing so in the directory it created itself earlier.

There is also the misinterpretation in scripts, e.g. when scripts fail in August and September because 08 and 09 are not valid octals.

Are the results quite as unpredictable as LLMs? No. But don't pretend that scripts never did anything stupid or dangerous when they ran into situations the developer didn't consider.

You are holding it wrong

Posted Jul 29, 2026 11:02 UTC (Wed) by mb (subscriber, #50428) [Link] (1 responses)

Or whitespace in paths in shell scripts.
Or iterating over paths with whitespace in shellscripts.
Yes, we can just do it right. This can be easy (e.g. bash) or harder (e.g trad sh). But we all know what we *actually* do: Nothing, because it works for me.

I had scripts with such bugs for two decades long - until an AI agent finally fixed it for me without me even asking for it: "Oh btw while doing this other stuff I noticed this bug in your script..."
Quality improved. Everybody is happy. One footgun less.

I really don't get why we are discussing "AI vs. scripts" here, because for me the answer clearly is: Both.
I did not retire a single of my traditional tools and scripts and I continue to add to my tools and scripts.

You are holding it wrong

Posted Jul 30, 2026 17:13 UTC (Thu) by ejr (subscriber, #51652) [Link]

I keep trying to retire old scripts and configurations and have "AI agents" generate, maintain, and use them... That use case is tantalizingly close to working in many of my aspects. Then I can have the system self-update with more recent knowledge I haven't acquired. Goal: Star Trek's computer. Stretch goal: Legally use Majel Barrett-Roddenberry's voice for the interface.

You are holding it wrong

Posted Jul 29, 2026 5:20 UTC (Wed) by LtWorf (subscriber, #124958) [Link]

> The days where LLMs randomly forget instructions and you have to tell them over and over again are long gone.

Weird… last week feels like it only was last week for me!

(I'm fully aware that you will now proceed to say that whatever happened, however happened, was 100% my fault, conversations with LLM proposers are more repetitive than LLMs themselves)

You are holding it wrong

Posted Jul 29, 2026 9:14 UTC (Wed) by LtWorf (subscriber, #124958) [Link] (2 responses)

> I expected Linux user to be familiar with a concept of a script.

Except that I can write scripts of any length. With LLMs you must weight the pros and cons of using up context, and of course they still get ignored every now and then anyway, as you know perfectly well.

Any more useless snark or are you done?

Stop

Posted Jul 29, 2026 13:01 UTC (Wed) by corbet (editor, #1) [Link]

Yet again, I have to ask everybody involved to stop it. This is not an elementary-school playground, can we please behave like respectful adults?

You are holding it wrong

Posted Aug 1, 2026 22:37 UTC (Sat) by intelfx (subscriber, #130118) [Link]

> Except that I can write scripts of any length. With LLMs you must weight the pros and cons of using up context, and of course they still get ignored every now and then anyway, as you know perfectly well.
> <...>

I will try to ignore the incivility and answer the meaningful part of your question, because I find it interesting.

Generally, it is understood that different technologies have different strengths and limitations (otherwise the two technologies would have been equivalent, and we wouldn't have needed both). Analogies only get us so far. When using LLMs, you forfeit the ability to write "scripts" of arbitrary length, but in return gain several abilities that might be valuable to you.

If you don't like this trade, nobody forces you to make it and use LLMs, but that alone does not mean that LLMs are inherently useless technology worthy of derision (or that its users are worthy of derision).

The problem being solved?

Posted Jul 26, 2026 10:27 UTC (Sun) by kleptog (subscriber, #1183) [Link] (1 responses)

I've read through the proposals and there are some pragmatic ones. I'd go for B myself but since IANADD my opinion isn't really relevant. But I do miss concrete examples: LLMs may have copyright issues, LLMs have accuracy issues, etc. However, LLMs have been widely available for over a year now, are we seeing more packages being submitted with bad packaging practices than before? Are we seeing actual quality issues that weren't there a year ago? I've seen complaints about the number of bugs being submitted, but that's a fairly narrow issue compared to what these proposals are aiming at.

I suppose I could feed the discussion to an LLM to summarise for me and see if there are examples, but it wouldn't be the same.

As an aside, the idea that broad categories of LLM output are suddenly going to be considered copyright tainted is laughable to me. Maybe the SCOTUS would dare, but I think most courts, especially in civil law countries, would decide that such a sweeping policy change belongs to the legislature, not the judiciary. And for the legislatures to start caring I'd think you'd have to see much more impact than what we see now. If they do act, I suspect it will be on non-copyright related issues.

The problem being solved?

Posted Jul 26, 2026 11:15 UTC (Sun) by khim (subscriber, #9252) [Link]

> However, LLMs have been widely available for over a year now, are we seeing more packages being submitted with bad packaging practices than before?

Deluge of slop is out there. Debian is moving slow, thus it's not yet directly affected. But it's coming. Better to prepare in advance.

Is proposal B even allowed in Debian?

Posted Jul 26, 2026 19:20 UTC (Sun) by MarcB (subscriber, #101804) [Link] (1 responses)

> 3. Accountability: Contributors assume full responsibility for their contributions, including vouching for the technical merit, security, license compliance, and utility of their submissions. The contributor remains solely accountable for the entirety of these contributions. Contributors should fully understand the proposed changes and be prepared to justify them.

That's exactly the things most Open Source licenses explicitly rule out. It would certainly keep me from contributing, even without AI. License compliance is as far as I would go.

Is proposal B even allowed in Debian?

Posted Jul 26, 2026 21:59 UTC (Sun) by KJ7RRV (subscriber, #153595) [Link]

I think that proposal is referring to responsibility within the project, not to legal liability, which is what licenses disclaim. This isn't really any different than what happens with any software project; a contributor who regularly submits faulty code is protected from lawsuits by the license, but can still expect to be banned by the project's maintainers from contributing.