Re: Automatic reports boosted by AI create burden on maintainers

On Thu, Apr 30, 2026 at 1:37 AM Roberto A. Foglietta
<[email protected]> wrote:
>
> On Wed, 29 Apr 2026 at 16:21, Tim Tassonis <[email protected]> wrote:
> >
> >
> >
> > On 4/28/26 21:06, Roberto A. Foglietta wrote:
> > > Hi,
> > >
> > > The Linux kernel maintainers (notably Jakub Kicinski for the
> > > networking side) submitted a pull request deleting about 138,161 lines
> > > of code: ISDN support, old network drivers, ATM, ISA/PCMCIA ethernet,
> > > and other legacy subsystems that are effectively unmaintained. Linus
> > > has said this is partly because the maintenance cost is now dominated
> > > by AI‑generated bug reports and “false‑positive” security scans over
> > > these dormant code paths.
> > > Instead of fixing or hardening decades‑old drivers, the calculus
> > > flipped: removing the code eliminates the attack surface for AI‑based
> > > scanners entirely, and maintainers can stop triaging hallucinated
> > > bugs.
>
> This above isn't something that I wrote but copy and paste news, the
> news is online in many other ways written:
>
> https://www.phoronix.com/news/Linux-7.1-Removes-Old-Net
>
> >
> > Well, it's the only sensible choice, if there is no actual way of
> > actually reproducing a bug due to nobody having the actual hardware, why
> > bother?
>
> TT, what you wrote above isn't true, the hardware is legacy and the
> bug might be reproducible (or not) but there are too many bugs and not
> enough maintainers testers to verify all the alerts and then report
> false positives or fix them. Whatever, this is the exact definition of
> technical debt.
>
> >
> > Oh God, how I hate this AI bullshit.
>
> The problem is not the AI, which found too many possible bugs humans
> cannot fix. The problem is that even if the AI would be used to fix
> those bugs, the outcome would be worse than the current code base. And
> someone should be accountable for committing those changes.
>
> My example about ctime vs ctime_r as already explained is just a
> trivial case in which relatively small human effort can fix AI
> security false positives for the potential benefits of having a more
> portable busybox with a negligible increase in size. Thus, "AI
> bullshit" is positive.

Don't force your project's vision to others. BusyBox was not written
with security as the first priority. The first priority is small size.
While your reasoning with ctime vs. ctime_r looks valid, a better
attitude of writing your patch is to allow builders the choice. This
is why BusyBox comes with menuconfig and lots of CONFIG_* options!

So, how about wrapping the ctime_r function into something like
bb_ctime and allow the option to use either ctime or ctime_r?
_______________________________________________
busybox mailing list
[email protected]
https://lists.busybox.net/mailman/listinfo/busybox