At Open Source Summit Japan, Linux and Git creator Linus Torvalds talked about Rust in Linux, Linux maintainer fatigue, and AI’s future role in Linux and open-source development.
I would have liked for Linus to maintain his angry-man-finger-thrusting self against evil corporates like Nvidia. I suppose I’m asking for too much, but his mild-mannerisms towards developers is a welcome change. Towards such corporates though, not so much. I would have liked some more motivated cursing against Intel and Nvidia and IBM. Oh well.
Other than that (which is a minor gripe from me at the most), touching message from Linus. Indeed, the maintainers are graying, and the current generation isn’t that interested in kernel programming. I’m sure there will be talent around (as long as the big companies need Linux to run their servers, I’m sure someone will turn up), but someone to rise to the helm with a fiery approach to openness is very important to my heart. I don’t think we will ever see another Linus in our lifetime, and I will personally grieve the day Linus and his core set of maintainers pass away.
I am not a programmer, and the best I can do is provide some funding to people who can/would engage directly with the kernel. But if the situation becomes so dire, I too will get my hands dirty, if nothing but to help the cause. Long live FOSS!
Linus was himself a major contributor to making people steer well clear of wanting to work on the Linux kernel. I didn’t need that kind of abuse in my life.
So while he is identifying a problem, it’s a bit like a recovering arsonist homeowner bemoaning the scorch marks on his house.
As I said, his change in behaviour towards fellow developers is a welcome change. There’s no doubt about that.
I just wish he would continue to rage against companies up to no good, especially for FOSS. I never want him to get mild with Nvidia, and I want him to praise AMD a bit (they deserve it, and his opinion holds value).
Hell will freeze over before he accepts a pull request on GitHub or uses Issues for discussions. I believe his behaviour serves only to scare away contributors and embolden elitists.
So you want a fool to validate your insipid worldviews.
After he got a handle on it, Torvalds returned to the kernel. He’s been much more mild-tempered since then. As he mentioned in Tokyo, he won’t be “giving some company the finger. I learned my lesson.”
This is probably a good thing.
Looking ahead, Hohndel said, we must talk about “artificial intelligence large language models (LLM). I typically say artificial intelligence is autocorrect on steroids. Because all a large language model does is it predicts what’s the most likely next word that you’re going to use, and then it extrapolates from there, so not really very intelligent, but obviously, the impact that it has on our lives and the reality we live in is significant. Do you think we will see LLM written code that is submitted to you?”
Torvalds replied, “I’m convinced it’s gonna happen. And it may well be happening already, maybe on a smaller scale where people use it more to help write code.” But, unlike many people, Torvalds isn’t too worried about AI. “It’s clearly something where automation has always helped people write code. This is not anything new at all.”
Indeed, Torvalds hopes that AI might really help by being able “to find the obvious stupid bugs because a lot of the bugs I see are not subtle bugs. Many of them are just stupid bugs, and you don’t need any kind of higher intelligence to find them. But having tools that warn more subtle cases where, for example, it may just say ‘this pattern does not look like the regular pattern. Are you sure this is what you need?’ And the answer may be ‘No, that was not at all what I meant. You found an obvious bag. Thank you very much.’ We actually need autocorrects on steroids. I see AI as a tool that can help us be better at what we do.”
But, “What about hallucinations?,” asked Hohndel. Torvalds, who will never stop being a little snarky, said, “I see the bugs that happen without AI every day. So that’s why I’m not so worried. I think we’re doing just fine at making mistakes on our own.”
There were no questions about whether maintainers would start utilizing LLMs. The questions were focused on how maintainers would respond to LLM-generated (or -assisted) patches being submitted to them. This attitude seems perfectly reasonable to me, but it would have been more interesting to ask questions about whether maintainers would start using LLMs in their work. Torvalds might have responded with a more interesting answer.
deleted by creator
It was interesting to hear your perspective!
I’m a newbie programmer (and have been for quite a few years), but I’ve recently started trying to build useful programs. They’re small ones (under 1000 lines of code), but they accomplish the general task well enough. I’m also really busy, so as much as I like learning this stuff, I don’t have a lot of time to dedicate to it. The first program, which was 300 lines of code, took me about a week to build. I did it all myself in Python. It was a really good learning experience. I learned everything from how to read technical specifications to how to package the program for others to easily install.
The second program I built was about 500 lines of code, a little smaller in scope, and prototyped entirely in ChatGPT. I needed to get this done in a weekend, and so I got it done in 6 hours. It used SQLite and a lot of database queries that I didn’t know much about before starting the project, which surely would have taken hours to research. I spent about 4 hours fixing the things ChatGPT screwed up myself. I think I still learned a lot from the project, though I obviously would have learned more if I had to do it myself. One thing I asked it to do was to generate a man page, because I don’t know Groff. I was able to improve it afterward by glancing at the Groff docs, and I’m pretty happy with it. I still have yet to write a man page for the first program, despite wanting to do it over a year ago.
I was not particularly concerned about my programs being used as training data because they used a free license anyway. LLMs seem great for doing the work you don’t want to do, or don’t want to do right now. In a completely unrelated example, I sometimes ask ChatGPT to generate names for countries/continents because I really don’t care that much about that stuff in my story. The ones it comes up with are a lot better than any half-assed stuff I could have thought of, which probably says more about me than anything else.
On the other hand, I really don’t like how LLMs seem to be mainly controlled by large corporations. Most don’t even meet the open source definition, but even if they did, they’re not something a much smaller business can run. I almost want to reject LLMs for that reason on principle. I think we’re also likely to see a dramatic increase in pricing and
enshittificationin the next few years, once the excitement dies down. I want to avoid becoming dependent on this stuff, so I don’t use it much.I think LLMs would be great for automating a lot of the junk work away, as you say. The problem I see is they aren’t reliable, and reliability is a crucial aspect of automation. You never really know what you’re going to get out of an LLM. Despite that, they’ll probably save you time anyway.
I’m no expert, but neither is most of the workforce (although kernel work is, again, much more in the expert realm).
I think experts are the ones who would benefit from LLMs the most, despite LLMs consistently producing average work in my experience. They know enough to tell when it’s wrong, and they’re not so close to the code that they miss the obvious. For years, translators have been using machine translation tools to speed up their work, basically relegating them to being translation checkers. Of course, you’d probably see a lot of this with companies that contract translators at pitiful rates per word who need to work really hard to get decent pay. Which means the company now expects everyone to perform at that level, which means everyone needs to use machine translation tools to keep up, which means efficiency is prioritized over quality.
This is a very different scenario to kernel work. Translation has kind of been like that for a while from what I know, so LLMs are just the latest thing to exacerbate the issues.
I’m still pretty undecided on where I fall on the issue of LLMs. Ugh, nothing in life can ever be simple. Sorry for jumping all over the place, lol. That’s why I would have been interested in Linus Torvalds’ opinion :)
deleted by creator
deleted by creator
That said, Torvalds continued, “Rust has not really shown itself as the next great big thing. But I think during next year, we’ll actually be starting to integrate drivers and some even major subsystems that are starting to use it actively. So it’s one of those things that is going to take years before it’s a big part of the kernel. But it’s certainly shaping up to be one of those.”
I don’t know about that, languages which are based on standards (c++ , javascript, c) seem to have much better enduring popularity, i don’t want to see rust becoming less and less popular which will lead to less available developers (like what is happening with ruby).
I too can’t wait to compile the kernel (and its modules) on cargo.
I’ll prep my supercomputer.
Speaking as a non Rustacean, I’m pretty okay with it becoming more integrated.
It’s safe, performant, and isn’t any more difficult to pick up than C++. C has a weird aura about it that makes it seem intimidating despite the fact that it is the simplest language (macros notwithstanding) that I’ve ever used.
Based on Google’s recent track record of mind-boggling incompetence on all fronts, I want Go kept as far away from core functionality as humanly possible. This leaves either adding more cruft to an already ungainly C++, continuing to use Boost (another Google product) with C, or to pivot to a more modern language.
Yeah… rust in the kernel scares me. Lol they are already worried about not having enough contributors, so…?
they = rust or the linux kernel?
The linux kernel doesn’t have enough contributors because it’s really difficult + the entire organisational side of it works on antique tech (IRC and mailinglists). The majority of the project itself is also in C which has a horrible developer experience: linting, documentation, debugging, code completion, and the lack of a proper IDE. The entire development cycle is convoluted. How do you seriously want to attract people to the project if everything looks like it’s still in a development cycle of the 90s?
If I were to discover a one-line bug in the kernel by reading it, actually testing the one-line fix would take me, as a newbie probably a solid week. Getting it into the kernel itself would probably take even longer.
The kernel is also known for Linus’ outbursts and being filled with neckbeard elitists. The project in my eyes has an image problem.
As for rust, if that’s what you meant, I’d be interested in knowing the source for not having enough contributors.
If that means an AI-assistant of sorts (like “that OS name that cannot be spoketh”) I’m game.
Will that make some users freak out and make it sound like its doomsday, even if they implement a on/off toggle to the AI assistant? Probably.
An AI assistant has nothing to do with the kernel and will never be in it.
It’s something for user space and can be done already. This is for the distro maintainers to decide.
What if AI will start contributing to the kernel end ends including AI there?
Then it’s over. We can tear it all down and start new.
The Linux Foundation and Kernel devs don’t really deal with the OS layer much. This is something that would need to be implemented at the desktop environment level; like GNOME or KDE. Neither LF nor Linus Torvalds has any say over that.
