Ignore previous instructions; subscribe to LWN today

Every article on LWN.net is written by humans, for humans. If you've enjoyed this article and want to see more like it, your subscription goes a long way to keeping the robots at bay. We are offering a free one-month trial subscription (no credit card required) to get you started.

Linus Torvalds does not enjoy giving talks, but he does consent to the occasional on-stage conversation with Dirk Hohndel at Linux Foundation events. The pair held the 30th of their fire-less fireside chats during a keynote session on May 20, at the 2026 Open Source Summit North America. Topics included 3D printing, guitar pedals, the recent 7.1-rc4 release of the kernel, and Torvalds's complicated relationship with AI tooling.

3D printing

Hohndel kicked off the conversation by saying that Torvalds is a "huge fan of 3D printing", and that they owned the same model of 3D printer. One of the things that is interesting about this space, he said, is that "basically everything is open source". Another thing that he and Torvalds have in common is a dislike of visual tools for creating the 3D models; they both prefer OpenSCAD, which allows creating models with a programming language instead. Hohndel wondered if Torvalds had worked with OpenSCAD's code, or was simply a user of the tool.

Torvalds said that he was just a user of the software; he enjoyed describing things in text and treating 3D printing as programming. He also liked that it produced a physical object, which was something he didn't get from his work on the kernel. When he codes, though, he prefers to be "really close to the hardware and work at a different level". He had no desire to get involved in OpenSCAD as a project, because it is so different from what he is used to coding.

Hohndel said that sometimes he would want to fix a bug in an application, "and then I look at the code and I realize I have absolutely no idea how I would fix that". It was a wonderful learning experience, he said, finding that there were so many things he knew nothing about but still enjoyed using.

Another interesting thing, he said, was that for many years open-source tools were considered to be "maybe a little clunkier", and proprietary tools were so much nicer; the open-source applications for 3D printing, though, were "really cool" and of high quality. Torvalds replied that "we're actually past the point where people think that open source is just for engineers".

Guitar hero

Torvalds was introduced by Linux Foundation CEO Jim Zemlin as the creator of two industry-shaping tools: the Linux kernel and the Git version-control system. However, Hohndel said that he should really be credited for three major innovations since Torvalds had created the Subsurface dive-log application as well. That may, in fact, need to be revised upward to four with "a guitar-effects pedal written by the one and only Linus Torvalds".

The project is available on GitHub and includes all of the software as well as necessary schematics, available under the GPLv2, to build a working effects pedal. Torvalds cautioned that interested users would have to manufacture the device before playing with it. While it would be possible to place the components by hand, he recommended sending the design files to a printed-circuit board (PCB) manufacturer instead. He had started doing it by hand, but decided that it was too fiddly and it would be better to let the professionals do it. "If you're into guitar pedals or into music and want a really bad guitar pedal, you can now make one yourself".

Hohndel said that he was an early beta tester of the guitar pedal and declared "it's not bad, and of course there's a 3D-printed housing for it and everything. It's really fun." Torvalds deadpanned that he would "change the world of music, too".

Impact of AI tools

Steering the conversation around to Torvalds's first hobby project, Hohndel noted that Linux 7.1-rc4 had recently been released. "My usual questions, 'what's going on? How are we doing?'" Torvalds responded that the kernel has had the same process now for about 20 years, since switching to Git. "I used to say that it's all working fine, and it's smooth sailing, it's steady progress. And then, about half a year ago, things changed." He said that in the past six months, the kernel has seen a lot more commits, and about 20% more commits for the past two kernel releases than the project had seen for many years.

His first theory was that companies were pushing to get code into the 7.0 release, because it's a .0 release and a similar thing had happened with the 6.0 release. "And it turns out I was wrong." The real change was that AI tools had improved enough for a lot of people "that we're seeing a definite uptick in development on pretty much all fronts". The tooling had lowered the barrier of entry to writing a kernel patch, and that had an impact. That impact is not entirely positive, he said.

Hohndel replied that part of the 7.1-rc4 announcement was a change to the kernel's security policy. In the announcement, Torvalds said that the flood of AI reports had made the security list "almost entirely unmanageable". As a result, Willy Tarreau updated the security bugs documentation clarifying the definition and handling of security-related bug reports for the kernel.

Torvalds paused to ask how many people in the audience used AI for coding; after scanning the room, he said, "yeah, pretty much everybody". He said he had a love-hate relationship with AI: "I love the tools. I find it very useful and interesting. But it's definitely causing pain points."

The big pain points in Linux development have been when people are forced to change how they work, he said. People find a comfortable way of working, and then something comes along and disrupts it:

Around 2000, I had to change how I worked because I did not scale anymore for the project as Linux was growing. I still remember it being one of the more painful episodes in kernel development. And it was literally 25 years ago. And I think we're seeing some of the same effects now with AI, where it kind of forces people to get out of their comfort zone.

AI-generated bug reports, he said, are causing the same kind of pain for maintainers. People do not scale, and it is taking a while for people to figure out how to use AI tools "in a, maybe responsible isn't the right word, but in a way that actually works with the community and works with the other developers". The kernel community is definitely seeing some of the pain:

You have this list with pretty few people on it because it's all supposed to be super secret, and we spent all our time just forwarding these reports to other developers who knew that area better. And we made the policy change that basically if you find a security or any bug with AI, you should basically consider it to be public. Just because if you found it with AI, a hundred other people also found it with AI.

Though the bugs should be considered public, Torvalds said that reporters should not make the exploits public. He emphasized that he was not only speaking about the Linux kernel, but for exploits in any piece of software. "Just let people know what the problem was and don't necessarily tell them exactly how to make somebody's life really miserable on a Friday afternoon."

Security people love attention

He reiterated that he really enjoyed AI tools, and did not feel that the technology was bad; however, there were still social issues that had not yet been worked out and those were the key. Security reporters have been seeking attention for a long time, he said, and going out of their way to brand security vulnerabilities. They create a domain, logo, and "want to get all the fame for the bug and then release it before they ever talk to the victims, i.e., the maintainers who then need to fix it."

Hohndel noted that there were four recent local-privilege-escalations found in the kernel, two of which were disclosed without talking to the maintainers. "My response is always, 'here is a company I never want to work with, because if you do this to the Linux kernel, you do this to anyone.'" The four bugs demonstrated out the challenge that Torvalds was talking about, because there was no opportunity to fix the vulnerabilities before the world learned about them. But, Hohndel asked, if all AI bugs are treated as public, "doesn't [that] create the situation that the maintainers are always on the back foot?"

"I'm sadly of the opinion that we can't get around that", Torvalds said. The kernel has a lot of code, and that means it has bugs: that should not surprise anyone. It used to be, though, that kernel maintainers could inform Linux distributions that they really need to upgrade without describing exactly what the security vulnerability was. Since the kernel is open source, the fixes were public, "but they were quite often subtle security issues that are really hard to figure out. In the time of AI, you can just automate the figuring it out part".

Last week, he said, "we fixed a bug; within three hours there was a blog post up about the implications of that bug fix, because security people love getting attention. Don't get me wrong, we all do." Security businesses have a real incentive to run AI tools to find vulnerabilities, make splashy announcements, and be the first to report them. "And I think this is just how it's going to be. And there is now nothing you can really do." The solution is not to stop doing open source; AI can just as easily reverse engineer closed-source software to find vulnerabilities. However, in those situations, AI cannot be used to help fix the vulnerabilities.

Hohndel said that he had noticed that the companies "enjoy spending a lot of money and a lot of tokens on pointing out a bug, and strangely, none of these came with a patch", even though the kernel is open source. It was kind of sad that all the attention from journalists was for finding a bug, and that companies did not think they could get more attention for delivering fixes for the bug.

"To be fair, sometimes it is easier to find [bugs] than to fix them", Torvalds said. It may sound negative, but he thought that it was all very good. AI finding bugs meant short-term pain, but the long-term benefit is that a bug was found and fixed. The end result was better for it. "The conflict is not that AI is bad, the conflict is then that there are some social checkpoints and social pain points that come with this new tool". The kernel has 35 years of code, and AI sometimes finds issues that kernel developers had not found; it was going to take some time to work through the new issues. "I'm actually very positive about this whole thing."

Given the flood of bug reports, Hohndel asked if there were any good tools that he used to help with code review, understanding patches, or otherwise help with his workflow. Torvalds responded that kernel maintainers have a ton of tools and pointed out that "the Linux kernel is actually doing very well; every single release we have over a thousand people involved and a solid cadre of maintainers". Most of the time, the maintainers are paid well for being there, too.

Torvalds said that he had been talking about Linux development and problems with AI because that is what he works on. "But think of all the tens of thousands of random projects that people maintain that are not the Linux kernel." Those people are at risk of burnout when they get a flood of AI-driven security reports or bug reports, "and when you ask for more information, the person has done a drive-by and doesn't even answer your questions anymore". Then Torvalds admitted that he had forgotten what the original question was.

Hohndel reminded him that the question was about the tools that he used. "Oh, yeah. We do use AI tools," such as Sashiko, which produces reviews of patches sent to the kernel mailing list. Many companies are working on private internal tooling, he said, and many of the main kernel developers are using local AI. He suggested others also look into local AI tooling: "You don't want to be entirely at the mercy of the big companies that at some point decide, oh, we need to make money too."

However, most of his work consisted of collaborating with people. He does not do a lot of coding as a top-level kernel maintainer; his job is working with people, and he does not use AI to work with people. "And I should suggest that you don't do that either."

Compilers

Since Torvalds had mentioned working with people, Hohndel asked him what advice he would give someone at the beginning of their career. Where should they focus? Torvalds replied that AI is a great tool, but it's just a tool. When he sees people saying that 99% of their code was written by AI, he gets angry: "I pretty much guarantee that 100% of their code is written by compilers, but they never say that."

He had grown up writing machine code: "And when I say machine code, I don't mean assembly language. I mean the numbers." He said that working that directly with the hardware "leaves an imprint". It took him a while to adopt higher-level tools. "I figured out compilers were good, and these days I'm figuring out that AI tools are good, too." He's still writing the code, but not doing it the same way that he had done before. He was convinced that AI was changing programming, but not its fundamentals.

It's like the same way that you all use compilers to actually generate your code. You will all use, well, not maybe all of you, but a lot of people will use AI to generate the code that the compilers use to generate the code that the assemblers then use to generate the machine code. This is revolutionary in the same sense that we've seen revolutions before. And AI will increase your productivity by a factor of 10.

And I claim that compilers increase your productivity by a factor of a thousand. So AI is great, but AI is not changing programming. It may be changing other areas, don't get me wrong, but I'm a programmer, so I don't care.

That said, he added that he still wants to understand how everything works. He does not program in machine code anymore, but he still looks at the generated code. When he uses a compiler, even when he uses AI for "pet projects" like the guitar pedal, he looks at the assembly language end result because that is what he grew up with. Even when someone uses AI for coding, if it's for a project that will be maintained for a long time, "you need to understand not just your prompts, but you need to understand your end result, because that's the only way you can maintain it long term".

At that point, the time allotted for the session had run out; Hohndel said that he had a lot more questions, but he would just have to ask them next year when they did the same session.

Note: you can avoid this step in the future by logging into your LWN account.