Live data from Hacker News

'It's hard to find maintainers': Linus Torvalds ponders Linux's future

theregister.com

31–40 of 48 posts

Re: 'It's hard to find maintainers': Linus Torvalds ponders Linux's future

#31
post #29

I think Linus is at fault here. Having a PR process that requires sending a patch over email, email threads done with super old mailing list software, etc instead of the more modern workflow of using forks, PRs in a web UI, etc is tedious and annoying. Making kernel development and maintaining more accesible to younger people would increase the pool of potential maintainers.

Modern does not mean better. Email-based collaboration is most welcoming to new people and good enough for the regular participants. I for one do not want to create an account and learn how some slow web application works for each project when I can do with sending an email.

>> Email-based collaboration is most welcoming to new people

What? Aren't new collaborators way more likely to be younger and acquainted with Web-based tools like GitHub/GitLab?

Re: 'It's hard to find maintainers': Linus Torvalds ponders Linux's future

#32
post #18

A few points irk me on "the beginning of the end" conjecture in modern technology, rather than focusing on "as one door closes, another one opens" philosophies that keep it all going. If I were to do coffee with Linus, I would tell him to fork the kernel and cleancode a kernel for the future (and take the reins), while letting the complexities of the current kernel continue to flourish in its present form (possibly s…

Linux is successful because of: "WE DO NOT BREAK USERSPACE". It is Linus policy and work with community that made it most popular OS.

I believe the way to "next generation" while keeping the Linux userspace compatibility promise is basically gVisor running on a non-Linux kernel.

If it runs your container just as well, well, it's "Linux" as far as your app is concerned.

Case in point: 1% of Google Cloud Run could just as well run on Fuchsia today and you just wouldn't know. All you see is the inside of the gVisor sandbox -- yet at the same time it'll run pretty much any http-serving docker image.

(Of course, in the real world Linux rules because of its huge collection of drivers, filesystems, etc.)

Re: 'It's hard to find maintainers': Linus Torvalds ponders Linux's future

#33

For me, this is one of the most interesting aspects to the development of Linux, and one I've been studying for years at various levels. Even though I don't understand a lick of most of the code, watching the lkml and the process itself is very quite interesting, however, there are a few ways to try and put the kernel in a better position in the future. Each major release can be considered a "story", for example, the…

I think the heart of what you're getting at lays in the world of ethnographies. Perhaps a cultural anthropologist would take a hand at documenting the process of developing for the Linux kernel, its rich history, and all the minutiae that go into it.

Re: 'It's hard to find maintainers': Linus Torvalds ponders Linux's future

#34
post #18

Earlier quoted context omitted.

Linux is successful because of: "WE DO NOT BREAK USERSPACE". It is Linus policy and work with community that made it most popular OS.

I believe the way to "next generation" while keeping the Linux userspace compatibility promise is basically gVisor running on a non-Linux kernel. If it runs your container just as well, well, it's "Linux" as far as your app is concerned. Case in point: 1% of Google Cloud Run could just as well run on Fuchsia today and you just wouldn't know. All you see is the inside of the gVisor sandbox -- yet at the same time it'l…

Don't quote me on this, but I hear:

creeps like other users data

I think the next billion uses (not users) of the linux kernel will be on bare metal (or bare SOCs, wtcmb), so storage yes, but no networking or cloud required for optimal operations.

Re: 'It's hard to find maintainers': Linus Torvalds ponders Linux's future

#35
post #26

Earlier quoted context omitted.

There's no need to rely on a third party provider given that it's possible to host say, Gitlab yourself. For a project of the size of the linux kernel that's more than a worthwhile investment.

In this context it’s wise to move conservatively. Gitlab has “come of age” only in the last few years. We see that KDE is now moving. If that works well, I wouldn’t be surprised if other OSS projects slowly start migrating. Remember that there is heavy organizational inertia and culture on the LKML. Moving to Gitlab is practically akin to gutting that and beginning a fresh project with forked code — the kind of cultu…

I really don't see a reason to not use both. Even right now, a maintainer of some subsystem could conceivably create a repo on Gitlab* and accept PRs there, which they could then (rebase-?)merge in and sync with git.kernel.org with Linus never having to know about it.

The problem is cultural, as well as organizational. Firstly, I doubt any of the current maintainers would be willing to do that, especially without Linus's blessing and secondly, without a fully managed Gitlab* instance that takes care of sync and whatever else automatically (provided by the Foundation), this would be an unreasonable burden on the maintainers.

Re: 'It's hard to find maintainers': Linus Torvalds ponders Linux's future

#36
Interesting point of view,

> Is C, the language the kernel is for the most part written in, being displaced by the likes of Go and Rust, such that there is "a risk that we're becoming the COBOL programmers of the 2030s?" Hohndel asked. "C is still one of the top 10 languages," answered Torvalds. However, he said that for things "not very central to the kernel itself", like drivers, the kernel team is looking at "having interfaces to do those, for example, in Rust... I'm convinced it's going to happen. It might not be Rust. But it is going to happen that we will have different models for writing these kinds of things, and C won't be the only one."

Re: 'It's hard to find maintainers': Linus Torvalds ponders Linux's future

#37
post #15

Earlier quoted context omitted.

I'm often confused as to how many people really have a potential future where they become motivated long term participants, but a few bumpy roads at the onset turn them off. And I don't just mean in kernel development, learning the guitar isn't fun either. Who gets into software as a profession, and then lets a bad UI turn them away from a project? When so much of the valuable skillset in programming is understanding…

I don't think this is an entirely fair comparison. I thinks it's closer to the Post Office being worried about finding enough new drivers for their mail routes, but refusing to upgrade any of their delivery trucks from a manual transmission to an automatic one. Sure, you can argue that learning to drive a standard isn't that hard, and if you want to do a valuable public service like delivering mail, then learning to…

> automatic transmissions are far, far more common

The Post example doesn't work in Europe or Africa post.

Re: 'It's hard to find maintainers': Linus Torvalds ponders Linux's future

#39

For me, this is one of the most interesting aspects to the development of Linux, and one I've been studying for years at various levels. Even though I don't understand a lick of most of the code, watching the lkml and the process itself is very quite interesting, however, there are a few ways to try and put the kernel in a better position in the future. Each major release can be considered a "story", for example, the…

I always wonder why most projects don't have an onboarding process where you get in touch with the maintainers and discuss the roadmap and how to help even if you personally don't have a specific issue you want to work on. For me I submit pull requests to open source projects when I personally need them and then leave once the work is complete. That's basically the opposite of what it takes to retain maintainers. Maintainers usually write code for the sake of others and not for themselves and they stay for much longer periods of time.

Re: 'It's hard to find maintainers': Linus Torvalds ponders Linux's future

#40

I think Linus is at fault here. Having a PR process that requires sending a patch over email, email threads done with super old mailing list software, etc instead of the more modern workflow of using forks, PRs in a web UI, etc is tedious and annoying. Making kernel development and maintaining more accesible to younger people would increase the pool of potential maintainers.

I'm often confused as to how many people really have a potential future where they become motivated long term participants, but a few bumpy roads at the onset turn them off. And I don't just mean in kernel development, learning the guitar isn't fun either. Who gets into software as a profession, and then lets a bad UI turn them away from a project? When so much of the valuable skillset in programming is understanding…

I agree. Bad UI is not a barrier. After spending 3 weeks with FreeCAD I got used to all the weirdness. The hardest problem was finding good teaching resources and actually going over them. All you really need is a clear path for people who want to become kernel maintainers. If you rely on random luck it's obviously going to be difficult and nowadays there are more closed platforms than ever so less people even get to throw their dice.
Post reply on HN