'It's hard to find maintainers': Linus Torvalds ponders Linux's future
theregister.com
theregister.com
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 journey of WireGuard from inception to submitting it to the kernel, that's an entire process, involving many, many steps and employs an unlimited number of tools; meeting in person, email, VoIP, Slack and anything you can think of.
Conversations that turn into code are a vital part of kernel development, but I feel is less well known (after all, we just see code shuffling about git repos).
Each bit of code is possibly hours of work, represents many conversations, and yet, git cannot (and does not), preserve the history of how code reaches Linus' tree.
So, how can we improve this situation?
Document, document, document!!
I'd love to see someone like Greg Kroah-Hartman, David Miller, Stephen Rothwell et al document, extensively, how they do their work.
I'm talking about high resolution; screen captures, text, images, audio and anything else that we can preserve going forward, perhaps all neatly tucked away in a git repo and backed up many, many times.
Seriously, we're at risking of losing a core vital understanding of how people do their work, especially those who are core to the Kernel. Of course, people may develop new methods, but I feel the kernel is quite mature and the processes in theory are quite stable too (such as how Greg actually releases a stable kernel once a week).
Of course, not everything can be documented, older software gets older, and someone's favorite email client may not be transferable, but the general process can be.
So yes, this is something to think about and prepare for, otherwise it may hit the kernel quite hard.
More specifically, check out the work of Matt Ratto, who defended his 2003 dissertation on this exact topic: https://bit.ly/2YQL1yf
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 seen as letting the rope go in the middle of a heated tug-of-war, which needs to happen on a public stage more often).
The "in between the lines story" on Linux over the years looks like [they] have been thrust into a role of placating the miserable, instead of writing brilliant code (its happening outside of tech too).
As far as switching gears to salaried maintainers, OSS should start an ISP (core function) similar to AOL (maybe aspergers online) and be a HUB for accessing the fruits of their labor. It would be like bringing the earthlink/mindspring 110% support model back to life (a reputation for being stewards of all open tech, in addition to top notch support).
Just having an ad-free network as an option would be worth the price of admission.
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.)
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.
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 cultural makeover that most companies don’t survive, and won’t do unless they’re forced to. And maintaining starting culture is even more crucial for volunteer-driven projects than for corporate projects with very different incentives.
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.
FWIW that's already happening with the BPF subsystem https://github.com/libbpf/libbpf
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 and navigating a possibility space where the UI isn't built yet? (And I'm sure some kernel contributors would argue it's more _unusual_ than actively _worse_).
I know this paints me as old and out of touch. I know this. But I think it still applies. When I look at my interns, the good developers tend not to be the ones tripped up by onboarding to systems and workflows that aren't exactly like the trendy development tools or what they saw in school.
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 drive one is a small price to pay. But it's a barrier to entry for most young drivers because automatic transmissions are far, far more common. Besides, not only is the constant starting/stopping like a mail truck does usually hardest part of driving a manual, but isn't even fundamentally coupled to the act of delivering mail.
There's plenty of competent drivers who might be willing to deliver mail using an automatic (or developers to maintain the kernel on a platform with a decent UX), and that kind of process overhead isn't something that should just be waved away.
Edit: Changed accidentally repeated phrasing in middle paragraph
The Post example doesn't work in Europe or Africa post.
Software doesn't have to be so difficult and tedious to use, as has been demonstrated by a decade of u/x in the UI space. Nowadays, nobody would ever consider gordian knot for their video editing, and I don't blame them.
This idea that one must suffer to learn is as outmoded as alchemy. You don't need to take the good with the bad; learn from the bad and make more of it good. I lived though the old times, and they sucked!
Nowadays, if the developer doesn't give any thought to u/x, people won't give any thought to his creation, and rightly so. The days of cryptic incantations and tedious rituals are largely over.
This type of assertion is made in a lot of contexts, but I don't believe it holds true. I believe that there are a subset of people who are willing to learn a new skill. Of those people, there are very few who are willing to learn a new skill but won't because of some perceived barrier to learning it. The vast majority of that subset will learn the new skill despite the perceived barrier.
Of the people who aren't in the set of people who are willing to learn a new skill, there will be very few people who will be movitated to learn the new skill because the perceived barrier to learning it has changed in some way.
Is there an established open source project out there that originally used a mailing list or some other review software like gerrit, reviewboard, or phabricator, that transitioned to Github or Gitlab and actually increased the number of contributors and maintainers?
Plus I suspect the crowd capable of contributing meaningfully is quite comfortable with low level old school tech.
What? Aren't new collaborators way more likely to be younger and acquainted with Web-based tools like GitHub/GitLab?
> 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."
0: https://www.reddit.com/r/linux/comments/fx5e4v/im_greg_kroah...
I contacted the Ruby development team, and was told: "find something to improve, maybe do an optimization" with no further guidance. So, I moved on to other things.
But the question is, will it run Linux® ?
No, the bootloader is locked.
Microsoft has arrived and is rescuing linux
GrapheneOS (most secure AOSP variant) Vanadium browser Auditor (attestation.app)
Get in touch by commenting here, or GrapheneOS.org