• 1 Post
  • 13 Comments
Joined 2 months ago
cake
Cake day: August 18th, 2026

help-circle
  • Counterargument: ctrl+f is a great place for regex. Write once read never problems are a great application for unreadable languages. Imagine if people wrote scripts in the language vi uses for editnig<escape>bceediting, which mostly isn’t even displayed as it’s typed! <escape>

    But yeah, it’s kind of terrible for anything else.




  • jjj@piefed.blahaj.zonetolinuxmemes@lemmy.world•Don't mind me. Keep enjoying your OS.
    link
    fedilink
    English
    arrow-up
    7
    arrow-down
    1
    ·
    edit-2
    24 days ago

    I read through the exact message chain that article is referencing some time ago, which did not lead me to the conclusion the article would suggest. It seems that he consistently refers to AI use from the perspective of finding bugs more so than than fixing them, which he could definitely do a better job clarifying.

    The message

    https://lore.kernel.org/linux-media/CAHk-=wi4zC+Ze8e+p3tMv8TtG_80KzsZ1syL9anBtmEh5Z40vg@mail.gmail.com/

    Subject: Re: Linking Patchwork with Sashiko?

    [snip]

    I think it makes the point of sashiko - helping maintainers - unachievable. If the point to not use
    LLMs in general, let’s discuss this, not how to make each use case more complex.

    It seems like [1] expresses a very anti-LLM position in general

    Yes.

    And no, that’s not the position of the Linux kernel.

    I realize that some people really dislike AI, but this is an area
    where I’m willing to absolutely put my foot down as the top-level
    maintainer.

    Linux is not one of those anti-AI projects, and if somebody has issues
    with that, they can do the open-source thing and fork it.

    [snip]

    Yes, it can also be a somewhat painful tool, both for maintainer
    workloads and just from a “it keeps finding embarrassing bugs”
    standpoint.

    [snip]

    (emphasis/snips mine)

    EDIT: Note: sashiko is an LLM driven code review tool someone runs on the linux kernel. This entire discussion was about a code review tool.





  • For each operation my CPU’s ALU can do, I need to find a bit mask that turns it on only for the desired set of 8 bit opcodes. The bit mask is of the form [01_].[01_][01_][01_][01_][01_][01_][01_][01_] where 0 and 1 mean the bit has to match and _ means it doesn’t matter. The bit before the . is the xor of all the other bits in the opcode.

    The solver has to figure out both which opcodes represent each instruction and what bit masks are needed to give them the desired operations.

    EDIT

    I ultimately switched to a slightly different approach. It turns out the xor part of the mask isn’t very useful since the combinations I need aren’t super complicated. The trouble was that an operation could only trigger for a power of 2 of opcodes, so I added a secondary mask to each operation:

    Base mask: still [01_] x8\ Secondary mask: [01_x] x8 (x means both 0 and 1)

    For the secondary mask, 1 matches only if the current bit or the one to the left is true (left of the leftmost is the rightmost). 0 is the same but with nand in stead of or. x, requiring both, only matches if exactly one matches.

    Using 1 or 0 multiplies the number of matching opcodes by 3/4 (or a more complicated fraction if their areas of influence overlap), which allows much more freedom.

    Due to restrictions in the game and my "hard"ware, I’m only able to use [1_x] for the secondary mask, since a nand gate doesn’t respond right to being hooked up to a bunch of toggleable and inputs but xor/or gates do (xor is just as fast in game).