Re: [PATCH] docs: remove Assisted-by references

[Troy Benjegerdes <hozer@hozed.org>]

On Mon, Oct 26, 2026 at 03:53:48PM -0400, Joshua Peisach wrote:
> On Mon Oct 26, 2026 at 3:39 PM EDT, Linus Torvalds wrote:
> > On Mon, 26 Oct 2026 at 09:04, <lyude@redhat.com> wrote:
> > > 
> > > On Wed, 2026-10-21 at 16:07 +0000, Troy Benjegerdes wrote:
> > > >
> > > > It *is* possible to make a deterministic LLM, and this is why I think
> > > > it
> > > > is critical to my personal future to have an LLM that can actually be
> > > > understood by a human instead of a random number generator casino
> > > > that
> > > > sometimes puts "4" in your private key.
> > > 
> > > I hate to break it to you but that is literally not how large language
> > > models work.
> > 
> > More importantly than that - the whole "deterministic" part is a total
> > red herring.
> > 
> > We shouldn't even reply to that idiotic argument.
> > 
> It's not idiotic. Would it be considered non-deterministic for a human
> to intentionally add a line of code causing a kernel panic for no
> reason at all? Or an LLM telling me to jump off a bridge?
> 
> When it comes to human development, people *know* what they are putting
> in. An LLM does not think about the words it is spitting out.
> > Why? Nobody is arguing that we should stop take human patches because
> > "they aren't deterministic".
> > 
> 
> Except humans want to actually contribute to the kernel, not make their
> slavemaster happy.
> 
> > So anybody who thinks we shouldn't use LLM as tools because of that
> > reason is just being dishonest. It's just a disguise for "I don't like
> > AI". It's not an argument, it's a complete strawman.
> > 
> > We have had non-deterministic tools in the past. One trivial example
> > of that is just different compiler versions that have slightly
> > different instruction weights or just different rules. Even when they
> > are individually deterministic the end result is effectively that
> > different people will get different results.
> > 
> > And not all tools have even been individually deterministic - actual
> > real non-deterministic behavior exists in non-LLM tools either becasue
> > they have timing issues or are explicitly using random numbers as a
> > way to get their results: Monte Carlo simulations is a very real
> > thing.
> > 
> > And yes, non-determinism adds a wrinkle to things and it's something
> > that needs to be taken into account (and people often add things like
> > explicit seeds to avoid it when they need explicit determinism from
> > otherwise non-deterministic algorithms). So non-determinism is
> > something that should be weighed as a factor against what else the
> > tools brings you.
> > 
> > But it's not actually an argument against LLM's.
> > 
> >               Linus
> 
> Well said. But also, we won't be able to "submit bug reports to LLMs"
> like for years people have submitted bug reports to compilers.
> 
> -Josh
> 

Submitting bug reports to LLMs is something we can and should aspire to
do, and maybe one of these LLMs will have sufficient context window and
processing power to take all of what we've written here as a prompt to 
build and demonstrate a deterministic code generation tool where the
code produced by the tool and the entire process that produced it back 
to the underlying training data can be fully disclosed and discussed.

I'd challenge anyone that believes that "LLMs don't work like that" to 
try running code generation with temperature=0, and let us know, what
happens?

Just because pretty much any commercial machine that uses IEEE derived
floating point and parallel execution can't practically produce the same
answer from the same inputs does not mean it's not possible. It just 
means no one has yet put in the engineering effort.

Good engineering with monte-carlo models or other tools that depend on
a random number "seed" seems to involve multiple runs, with different 
seeds, and when you are working on a something involving human life
safety or otherwise have to satisfy some regulator or reviewer that the
simulation work you did is repeatable, is specify something about how
many runs you did, with what codebases, and how much divergence did you
get from different runs and different seeds.

You see this with weather models, where an ensemble of models is used to
map and quantify the uncertainty in the projected path of a hurricane.

We can and should apply the same rigor to kernel engineering, and keep
an awareness of what models produce what kind of code, if for no other
reason than to provide some additional forensic data if or when we
discover the first evidence of an intentional LLM generated zero-day
that slipped by human review.

- Troy