Linus Torvalds Muses About Maintainer Gray Hairs, Next 'King of Linux' (zdnet.com) 45
An anonymous reader quotes a report from ZDNet, written by Steven Vaughan-Nichols: In a candid keynote chat at the Linux Foundation's Open Source Summit Europe, Linux creator Linus Torvalds shared his thoughts on kernel development, the integration of Rust, and the future of open source. Dirk Hohndel, Verizon's Open Source Program Office head and Torvalds friend, moderated their conversation about the Linux ecosystem. Torvalds emphasized that kernel releases, like the recent 6.11 version, are intentionally not exciting. "For almost 15 years, we've had a very good regular cadence of releases," he explained. With releases every nine weeks, this regularity aims for timeliness and reliability rather than flashy new features. The Linux creator noted that while drivers still make up the bulk of changes, core kernel development continues to evolve. "I'm still surprised that we're doing very core development," Torvalds said, mentioning ongoing work in virtual file systems and memory management. [...]
Shifting back to another contentious subject -- maintainer burnout and succession planning -- Hohndel observed that "maintainers are aging. Strangely, some of us have, you know, not quite as much or the right hair color anymore." (Torvalds interjected that "gray is the right color.") Hohndel continued, "So the question that I always ask myself: Is it about time to talk about there being a mini-Linus?" Torvalds turned the question around. True, the Linux maintainers are getting older and people do burn out and go away. "But that's kind of normal. What is not normal is that people actually stay around for decades. That's the unusual thing, and I think that's a good sign." At the same time, Torvalds admitted, it can be intimidating for a younger developer to join the Linux kernel team "when you see all these people who have been around for decades, but at the same time, we have many new developers. Some of those new developers come in, and three years later, they are top maintainers."
Hohndel noted that "to be the king of Linux, the main maintainer, you have to have a lot of experience. And the backup right now is Greg KH (Greg Kroah-Hartman, maintainer of the stable Linux kernel), who is about the same age as we are and has even less hair." True, Torvalds responded, "But the thing is, Greg hasn't always been Greg. Before Greg, there's been Andrew {Morton) and Alan (Cox). After Greg, there will be Shannon and Steve. The real issue is you have to have a person or a group of people that the development community can trust, and part of trust is fundamentally about having been around for long enough that people know how you work, but long enough does not mean to be 30 years." Hohndel made one last comment: "What I'm trying to say is, you've been doing this for 33 years. I don't want to be morbid, but I think in 33 years, you may no longer be doing this?" Torvalds, making motions as though he was using a walker, replied, "I would love to still do this conference with you." The report notes the contention around the integration of Rust, highlighted by the recent departure of Rust for Linux maintainer Wedson Filho. Despite resistance from some devs who prefer C and are skeptical of Rust, Torvalds remains optimistic about Rust's future in the kernel.
He said: "Rust is a very different thing, and there are a lot of people who are used to the C model. They don't like the differences, but that's OK. In the kernel itself, absolutely nobody understands everything. I don't. I rely heavily on maintainers of various subsystems. I think the same can be true of Rust and C. I think it's one of our strengths in the kernel that we can specialize. Clearly, some people just don't like the notion of Rust and having Rust encroach on their area. But we've only been doing Rust for a couple of years, so it's way too early to say Rust is a failure."
Meanwhile, Torvalds confirmed that the long-anticipated real-time Linux (RTLinux) project will finally be integrated into the kernel with the upcoming release of Linux 6.12.
Shifting back to another contentious subject -- maintainer burnout and succession planning -- Hohndel observed that "maintainers are aging. Strangely, some of us have, you know, not quite as much or the right hair color anymore." (Torvalds interjected that "gray is the right color.") Hohndel continued, "So the question that I always ask myself: Is it about time to talk about there being a mini-Linus?" Torvalds turned the question around. True, the Linux maintainers are getting older and people do burn out and go away. "But that's kind of normal. What is not normal is that people actually stay around for decades. That's the unusual thing, and I think that's a good sign." At the same time, Torvalds admitted, it can be intimidating for a younger developer to join the Linux kernel team "when you see all these people who have been around for decades, but at the same time, we have many new developers. Some of those new developers come in, and three years later, they are top maintainers."
Hohndel noted that "to be the king of Linux, the main maintainer, you have to have a lot of experience. And the backup right now is Greg KH (Greg Kroah-Hartman, maintainer of the stable Linux kernel), who is about the same age as we are and has even less hair." True, Torvalds responded, "But the thing is, Greg hasn't always been Greg. Before Greg, there's been Andrew {Morton) and Alan (Cox). After Greg, there will be Shannon and Steve. The real issue is you have to have a person or a group of people that the development community can trust, and part of trust is fundamentally about having been around for long enough that people know how you work, but long enough does not mean to be 30 years." Hohndel made one last comment: "What I'm trying to say is, you've been doing this for 33 years. I don't want to be morbid, but I think in 33 years, you may no longer be doing this?" Torvalds, making motions as though he was using a walker, replied, "I would love to still do this conference with you." The report notes the contention around the integration of Rust, highlighted by the recent departure of Rust for Linux maintainer Wedson Filho. Despite resistance from some devs who prefer C and are skeptical of Rust, Torvalds remains optimistic about Rust's future in the kernel.
He said: "Rust is a very different thing, and there are a lot of people who are used to the C model. They don't like the differences, but that's OK. In the kernel itself, absolutely nobody understands everything. I don't. I rely heavily on maintainers of various subsystems. I think the same can be true of Rust and C. I think it's one of our strengths in the kernel that we can specialize. Clearly, some people just don't like the notion of Rust and having Rust encroach on their area. But we've only been doing Rust for a couple of years, so it's way too early to say Rust is a failure."
Meanwhile, Torvalds confirmed that the long-anticipated real-time Linux (RTLinux) project will finally be integrated into the kernel with the upcoming release of Linux 6.12.
as long as... (Score:4, Insightful)
As long as we can keep the systemd people as far from the future of linux as possible, I think whoever steps in as the next Linus will be not horrible.
Re: (Score:3, Insightful)
Re: (Score:2, Interesting)
By systemd people, do you mean the folks who work full time producing linux distros that utilize systemd? aka the vast majority of professional linux programmers? It's been years. We have systemd. Everyone has systemd. You can use other things if you don't want systemd (deuvan, gentoo w/openrc), but this continued cult-hatred for "systemd people" is completely weird to me. How many decades will it take before folks stop being salty about having to learn a new way of doing things.
I dunno. How many decades until you fix the stupid thing? How many decades until "apt get remove pulseaudio" stops being the way to fix 90% of sound problems? When can I expect Wayland to stop locking up whenever I try to run some opengl stuff on it? And so on...
Re: as long as... (Score:2, Insightful)
It is not systemd per se, it is NetworkManager and journald and pulseaudiod and systemd-boot and other stuff.
Systems has become relatively good despite its quirks and major these-bugs-are-features such as the config look like ini files, most of the options work like ini but in a few major cases (eg Exec*) does not function like ini files so parsing from/to machine format like JSON requires a special parser.
The biggest problem is that all of what Poettering builds ignore established protocols for configuring
Re: as long as... (Score:5, Insightful)
Re: as long as... (Score:2)
Re: as long as... (Score:4, Interesting)
Funnily enough, many of the systemd haters I met absolutely love Apple's launchd, which is the main inspiration for systemd.
I too use Gentoo, but migrated to systemd, precisely because it currently allows for a lot more stuff than openrc.
More stuff:
mailserver.target , which launches all necessary for mailserver.
nas.target
I can't do that with runlevels.
+ cgroup, namespaces, syscall filters...
Re: (Score:2)
Re: (Score:1)
So what if a component of mailserver.target doesn't run? Why do you want your server to go into rescue mode without networking in cases when systemd units fail?
And yes, with runlevels you could easily do that, just put all the calls into /etc/init.d/mailserver and call it a day.
If the cgroup stuff would work properly that is and not crash silently because Poettering and co decides that they wanted to remove cgroupv1 feature (that's a thing that happened) and then blame everyone for not reading the git repo
Re: (Score:2)
> So what if a component of mailserver.target doesn't run?
If a component fails, the target fails, however the multi-user target runs fine, because it isn't tied to the mail target.
So the system is functional, ready to be fixed (remotely if needed)
Getting systemd to drop into rescue mode requires something way more catastrophic.
> put all the calls into /etc/init.d/mailserver and call it a day.
I prefer using WantedBy in .service instead of Wants in .target. Personal preference.
The cgroup 1/2 migration
Re: (Score:1)
"Catastrophic" meaning network or any mount not working or a network link not coming up.
Re: (Score:2)
If you put your mount in fstab, and it fails, there is no way for the init system to know whether the OS is capable of functioning at all. You can add "nofail" to the fstab entry, making the system boot anyway. For me, this is a good safety net so that services don't run accidentally with lost persistent data/config. .mount points. then if a mount fails, only those that depend on that mount are failed, and the rest of OS works.
Otherwise you can make services depent on nofail
I haven't addressed network, beca
Re: (Score:1)
But nobody runs Linux on a desktop/laptop, it makes up 1% of the Linux population. Again, systemd MAY make sense on the server IF it had been better implemented so you could actually manage it with Ansible, but Poettering . NetworkManager and co instantly gets turned off by ANY server distro.
And Poettering literally says "why do you want us to keep state" when it comes to these discussions and other developers of the systemd project likewise "just use dbus" - now you need me to run yet another service that
Re: (Score:2)
It's not that weird that people were upset. Think of this this way. They once had a choice on what to run for init and one day the biggest, fattest initd "won" and was used in nearly every distro. And even important system packages (like udevd) were rolled up in with systemd releases.
I don't actually care. I have plenty of RAM and systemd hardly ever kills my desktop system. Getting the right logs from journalctl was an unnecessary learning curve, it felt a little like the first time I hard to learn how to
Re: (Score:2)
It's not a cult hatred. It's a fundamental misunderstanding of how computers work, how to diagnose problems, and generally how people use computers - on the part of the systemd folks.
It's extremely straightforward: computers work in a linear fashion, sometimes multiprocess. When a computer starts, or a service starts, or a service fails, etc. it does so in a linear fashion with dependencies.
By making the mechanisms surrounding how services do these things more complicated, you increase the potential for fai
Domain bigotry? (Score:1)
For some domains/niches people say systemd is better than alternatives. One Size Doesn't Fit All. Each domain is different.
Re: (Score:2)
Re: (Score:1)
While developing systemd, Lennart wasn't a rogue hacker hellbent on destroying Linux, he was a developer on Red Hat's payroll, employed to work on that. Now he's on Microsoft's payroll. So the chances that someone like him to get "king of Linux" are awfully high.
Re: (Score:2)
Mr. Poettering is an userland developer, not a kernel developer. His chances to get anywhere close to Linus' position are extremely slim, even if we disregard his reputation.
There it is (Score:2)
Clearly, some people just don't like the notion of Rust and having Rust encroach on their area.
Diplomatic way of saying their irrational. Exactly what I expected. Linux really can't afford to lose this guy: he gets it right every time.
no (Score:5, Interesting)
When Rust was introduced, it was for stuff like drivers. Go make your Rust driver like everyone else's and we're fine with that. Turns out, even that request is too much for some Rust developers because the API that exists is not "Rusty enough" or whatever. There was a controversy when some Rust graphics driver couldn't be made to fit the AMD GPU driver API.
Anyway, it's not irrational to not want responsibility for something you don't understand. Everything rolls up to existing maintainers, and if the Rust people can't stay involved enough to do the work to an acceptable level they are not welcome. In the video that was shared by the rage-quitting Rust developer, the existing developer said hey, we're not going to give you information and then not promise that information will stay correct forever. Which is completely correct, Linux has always said there is no stable internal API. If Rust wants to replace huge chunks of the existing code, then (a) the Rust people should figure their shit out and submit patches like every other kernel developer without asking more competent people to hold their hands and (b) the Rust people should stay intimately involved so when a breaking change is made in C they immediately fix the problem in Rust. They cannot expect to "Rustify" some C code and then ride off into the sunset leaving other people to deal with their mess.
yes (Score:2, Insightful)
Who do you imagine you're speaking for?
Did Linus cite reckless Rust developers as the issue? Nope.
Linus knew it would be this way when he gave his blessing to accept the first alternative to C in Linux history, and he's not discouraged by it. You can parrot all the excuses you've heard as much as you like for the entirely predictable and irrational reactions we've all seen. So go somewhere and seethe about it; we're all fortunate that a far wiser person gets to call these shots.
Re: (Score:2)
"promise that information will stay correct forever."
No one requested this. Everyone accepted that the internal APIs are dynamic. The request was for documenting changes as the changes were made *which is something even the people making the changes need if they were doing a competent job*.
Re: There it is (Score:2)
*they're
Re: (Score:2)
I predict Rustix will enjoy tens, possibly hundreds of users.
Re: (Score:2)
Re: (Score:1)
Here in Soviet Russia, Rustix uses you.
Re: (Score:2)
I predict it will be finished some time around GNU Hurd's second release.
Re: (Score:1)
Diplomatic way of saying their irrational.
Kind of like how he was (is?) about C++. He spent a few decades building a community with a certain attitude and a good part of that attitude was that C is supreme and everyone else is an idiot. He may have changed his mind, but it's not surprising the attitude remains.
Re:There it is (Score:4, Informative)
You got him wrong. There is no indication that he thinks C is the ultimate, perfect, impeccable gift of G-d to humanity.
He only thinks that C++ is not suitable for Linux kernel development, and didn't keep his thoughts on this matter private.
Re: (Score:2)
It's quite rational to not want Rust to "encroach" on your area. An "area" should be developed in one language. Either C, or Rust, but not both. Else you get maintainers who might not have 100 percent grasp at what happens in the area, and that would be very bad. Even if it doesn't happen, due to the maintainer being an expert in both C and Rust, you get developers who can't understand, let alone modify, a part of the code in that area. This would also be very bad.
"to be the main maintainer, ...." (Score:5, Interesting)
I don't think you actually need experience to be the main maintainer. It should be primarily a management role. That is to say, other smart people should be doing the technical work and decisions, and one person should be making sure that work is happening as well as it can.
The best manager I ever had was non-technical. He was really skilled at listening to people. He would ask just the right questions. Calm down the right people. Fire-up the right people. Help us reach consensus and compromise. Unblock people. Play interference between annoying higher-ups or other teams. And he listened to us, commiserated with us, empathized with us. He helped us be the best version of ourselves we could be. All that without knowing how to code. He knew enough to understand the concepts, to be involved in discussions, but he didn't need to "make the decision". He just needed to enable us to make it ourselves.
Maybe that's too out-there for most people to accept. But it's perfectly possible, especially in an environment like a community-driven OSS project, where our only limitations are self-imposed.
Re: (Score:1)
Bottle that person and clone millions of 'em!
Re: (Score:2)
I don't think you actually need experience to be the main maintainer. It should be primarily a management role.
Apple thought the same thing when they brought that Pepsi exec in to run the business. The name was John Sculley. It did not exactly turn out very well.
Re: (Score:2)
CEO is a little bit different than kernel maintainer :-) CEOs aren't managers, they're sort of doing 5 different jobs at once. Having technical skill does help. But also not necessary. John Chambers was an MBA who worked in sales at IBM, and he went on to grow Cisco into one of the biggest companies in the world.
Re: (Score:2)
I don't think you actually need experience to be the main maintainer. It should be primarily a management role.
I think the kernel maintainer should be balls deep in kernel code already. I'm assuming that person has the final say on what code goes into the kernel, so they should have a solid technical understanding of the whole thing. Perhaps there's a role for a non-technical manager in the kernel project to handle the issues you describe; this would also help the maintainer focus on the technical side. A bit like COO vs. CTO.
Oh, Wow! (Score:5, Insightful)
Some of us have been checking in on RTLinux for two decades.
It's yuge that 6.12 will merge it.
Kudos to the team.
King? (Score:2)
Wasn't he the Benevolent Dictator for Life?
How about God-Emperor as the successor's title?
Or something geeky and apropos, like Process Zero?
I wonder (Score:2)
What will happen when Torvalds is gone. Will there be a Rupert Murdoch-style fight for the pieces of what he built? Will the ecosystem survive? Just how big *is* his role in holding things together?
The next "king"? (Score:3)