On Thu, Sep 11, 2025 at 09:13:28PM +0200, Nicolas Frattaroli wrote:
On Thursday, 11 September 2025 17:05:23 Central European Summer Time Sasha
Levin wrote:
On Thu, Sep 11, 2025 at 04:48:03PM +0200, Nicolas Frattaroli wrote:
>On Tuesday, 9 September 2025 18:32:14 Central European Summer Time Sasha Levin
wrote:
>it doesn't seem like Assisted-by is the right terminology here, as
>the code itself makes me believe it was written wholesale by your
>preferred LLM with minimal oversight, and then posted to the list.
>
>A non-exhaustive code review inline, as it quickly became clear
>this wasn't worth further time invested in reviewing.
Thanks for the review!
Indeed, Python isn't my language of choice: this script was a difficult (for
me) attempt at translating an equivalent bash based script that I already had
into python so it could fit into b4.
There's something to be said about these tools' habit of empowering
people to think they can judge the output adequately, but I don't
want to detract from the other point I'll try to make in this reply.
My intent was for this to start a discussion about this approach rather than
actually be merged into b4.
I know that, and you did get feedback on this approach already from
others, specifically that it did not solve the core issue that is
poorly utilised metadata and instead applies hammer to vaguely nail
shaped thing.
And your reaction was to call them personally biased against this
approach, and to loudly announce you would ignore any further
e-mails from them.
Now while I won't claim Laurent Pinchart isn't one of the louder
critics of your recent LLM evangelism, I can't really see a fault
in his reasoning: your insistence on finding an LLM solution to
every and any problem is papering over the real pain point,
which is that Link: should contain useful information, so that
you can click on the link and get the information and not have
to do a search (LLM assisted or not) for said information.
So the responses you expect to this patch should seemingly meet the
following two criteria:
1. we're not supposed to critique the implementation, as it's an RFC
and therefore should not get comments on anything but the general
approach,
2. we're not supposed to critique the general approach, because saying
that this solution is neither reliable nor efficient is a result
of personal bias against the underlying technology.
I don't condone the arguments based on energy usage because any use
of electricity in a grid that's not decarbonised will be open to
value judgements. For example, my personal non-workplace-endorsed
opinion is that electricity used on growing zucchini is wasted,
as they are low-nutrient snot pumpkins masquerading as cucumbers.
My main criticism on the approach end of things, if I am allowed
an opinion, is that this does not make Link: tags more meaningful,
nor does it solve the problem of automated tools adding sometimes
useless noise to something humans are supposed to be reading (which,
some may point out, your tool makes even worse.)
While bisecting, I often come across things where I'd love to be
able to immediately see what discussion preceded the problematic
patch with just one click and pageload between. Shoveling GPUs
into Sam Altman's gaping cheeks does not allow me to do that,
or at least not any better than a search on lore with dfn: would
already allow me to do.
I very much agree with your general observation:
1. I don't think that this script solves the underlying Link: issue.
2. It papers over the real problem
3. I don't think that today's LLMs can solve any fundamental issue we're facing
in kernel-land.
4. I am really happy (as Laurent said) to apply my big hammer to anything that
looks like a nail.
We've started[1] the workflows@ list (which is how I stumbled on this thread)
about 5-6 years ago when the concern from multiple maintainers was that we all
have our magical scripts, they are seriously ugly, and everyone are ashamed of
sharing them. So this list was an effort to get the ball rolling on folks
sharing some of those ugly workflows and scripts in an attempt to standardize
and improve our processes.
I've shared this very hacky b4-dig script as exactly that: I have a very ugly
bash script that addresses some of the issues Linus brought up around being
able to find more context for a given patch/mail. I use that script often, it
helps me spend less time on browsing lore (no, dfn: won't find you syzbot
reports or CI failures), and it just "works for me".
I'd love if we end up with a great solution for Link:, I'm not asking anyone to
stop working on that, nor am I claiming that this is a good long-term solution
for the problem. All this is is a utility script that fits my needs *TODAY*.
So no, I wasn't looking for criticism on workflows@ (this isn't even on lkml,
ksummit-discuss, or anything like that). I was looking to share a workflow
that I have and see if folks have any ideas, suggestions, or would potentially
want to do something like this on their own. I wasn't looking for an almost
religious "vim vs. emacs"-esque choire of "LLMS SUCK" or comments about Sam
Altman's rear end.
Maybe this is why folks are reluctant to share their ugly scripts?
[1] https://lwn.net/Articles/799134/ - "The session closed with the creation of
a new "workflows" mailing list on vger.kernel.org where developers can discuss
how they work and share their scripts".
--
Thanks,
Sasha
