Cancer?
Cancer?
Posted Jan 31, 2025 15:38 UTC (Fri) by LtWorf (subscriber, #124958)In reply to: Cancer? by npws
Parent article: Resistance to Rust abstractions for DMA mapping
So while the world will keep on going just fine, the kernel project (or any other project) might not, if it loses a few important contributors.
Posted Jan 31, 2025 15:58 UTC (Fri)
by corbet (editor, #1)
[Link] (13 responses)
Posted Jan 31, 2025 17:41 UTC (Fri)
by dralley (subscriber, #143766)
[Link] (5 responses)
Linus himself has talked about how many patches come in as one-offs, and how it's a challenge to find the kind of people who will spend years learning, building trust and contributing to a degree that they could potentially become a maintainer or authority of some kind.
Posted Feb 7, 2025 10:39 UTC (Fri)
by taladar (subscriber, #68407)
[Link] (4 responses)
Posted Feb 7, 2025 13:15 UTC (Fri)
by pizza (subscriber, #46)
[Link] (3 responses)
Posted Feb 7, 2025 14:54 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (2 responses)
But companies have motivation (or rather the people within them do). If the kernel community actively demotivate outsiders - paid or not - that's a bad thing.
What's the difference between the kernel community de-motivating contributors, and a company de-motivating customers? NOTHING. Both are actively shrinking the pool of people willing to do business with them, and both are actively hastening their own demise.
Whether I'm paid or not has nothing to with whether I have a bad experience or not. And if I have that bad experience, next time I'm asked to go back there I will actively resist. If I'm paid and my boss has to pull rank, that puts him off and makes him less likely to want to deal with them too.
Even - or especially! - if they're paid to do so, you do not want to give the people the motivation to NOT come back.
Cheers,
Posted Feb 7, 2025 15:24 UTC (Fri)
by pizza (subscriber, #46)
[Link] (1 responses)
I'm sorry, I didn't make my point clear.
Companies pay folks to contribute stuff, but once that "stuff" is contributed (eg add a new driver or a fix for an existing driver) from their employer's perspective, there is no longer any need for those folks to continue engaging with the kernel as a whole, so they are tasked with doing other things instead. Voila, drive-by contribution.
While those individuals _could_ continue to do other things with the Linux, but that would have to come from their off-the-clock time, and unlike $dayjob where you do what you're told, on one's own time there are innumerable other things you could do. Such as being with with their families or going outside, ie "anything other than spending even more hours staring at a computer screen performing unpaid, hard, thankless *work*)
In order to gain the level of expertise and experience necessary to rise up to the level of a subsystem maintainer, one has to spend literally *years* getting your hands dirty on Linux's internals on a more-than-full-time basis. Very few folks have the opportunity to do so.
Posted Feb 7, 2025 16:35 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
And you don't seem to have understood mine.
If my boss tells me to do something I find unpleasant, I will not want to repeat the experience! And in jurisdictions where "hire and fire" is not the norm, my boss will find it very hard to make me do it again. "Give it to someone else!". Payment has NOTHING to do with it.
And if the boss can't find people willing to interact with the kernel community, that could be another reason why so many companies ship outdated kernels with their gear - it's not that they don't want to ship updated stuff, it's that they can't find staff willing to go through the grief of upstreaming the stuff they need ...
(People of that calibre are likely people that could just walk if they so desired ...)
Cheers,
Posted Feb 1, 2025 18:24 UTC (Sat)
by koverstreet (✭ supporter ✭, #4296)
[Link] (6 responses)
That takes easily a decade of dedicated work to really do well, and we've been feeling the lack of it in filesystem and mm land - remember Linus saying "nobody understands mm" - mm has also fared poorly with retaining people with key knowledge...
And as Rust is rising fewer and fewer people are taking the time to get really good at C; understandably, since that also easily takes a decade...
It's easily to look at headline numbers and say "everything is great", but if you dig deeper I think we've got some real challenges ahead.
Posted Feb 1, 2025 22:37 UTC (Sat)
by smurf (subscriber, #17840)
[Link] (3 responses)
Rust won't save you from learning much of that of course, but it puts nice shiny padlocks onto those trapdoors which you can't overlook – you get compiler errors when you do – and aren't supposed to open (i.e. you don't get to use "unsafe").
I do wonder how much of some people's reluctance to learn Rust can be attributed to the Sunk Cost fallacy …
Posted Feb 1, 2025 22:48 UTC (Sat)
by pizza (subscriber, #46)
[Link] (2 responses)
You are describing the *what*, but what matters even more (from a maintainer's perspective) is the *why*.
> Rust won't save you from learning much of that of course,
Rust helps express the *what* far more formally, but it won't tell you *why* this approach was taken. That level of understanding tends to come with the acquisition of scars.
Posted Feb 1, 2025 23:14 UTC (Sat)
by koverstreet (✭ supporter ✭, #4296)
[Link]
The problem of insufficient, inadequate and imprecise human communication will remain out of reach for a bit longer :)
But anything that helps with the tedium does free up cycles for those "higher minded" issues, and besides I expect that better and more expressive type systems will help somewhat with the "why" issue as well, just because we'll have names for things that are more typically open coded today. C is not ideal for generic programming.
Posted Feb 3, 2025 8:47 UTC (Mon)
by smurf (subscriber, #17840)
[Link]
That's right at first glance, *but* when I can address the "what" in code, adding a comment that describes the "why" along with it is at least conceivable.
In C however you can't even express the "what" parts of your restrictions, so *that* ends up in documentation (we hope) and the "why" tends to fall by the wayside.
Posted Feb 5, 2025 18:35 UTC (Wed)
by ljsloz (subscriber, #158382)
[Link] (1 responses)
Who specifically are you thinking of? Because I'm an mm (co-maintainer) AND a relatively 'new' person (at least professionally) and I've not found this to be the case at all.
(For the sake of the topic - I have written a 1,300 page book on mm, documentation on esoteric mm locking, constantly refactor code to make it easier to understand/refactor/extend, added a whole userland vma testing framework to be able to very very quickly exercise/test behaviour there - so hey - I'm maybe one of the biggest proponents of providing mm knowledge out there who has walked-the-walk on that).
On the rust front, I'm also a huge proponent of it, as are many mm people, I for one have some real credibility here as I've reviewed the rust mm wrapper series at length and put a great deal of effort in explaining mm internals, discussing and promoting that series.
Supporting rust in mm isn't mutually exclusive with people in mm having deeper knowledge...!
Also that Linus quote seems to me to be quite obviously tongue-in-cheek right?
Posted Feb 6, 2025 2:44 UTC (Thu)
by koverstreet (✭ supporter ✭, #4296)
[Link]
Thanks for the work!
For people, Ric van Riel left for awhile (though I see he's back!), Johannes Weiner seems to be moving into management, there's been cycling in slab/slub (Vlastimil has been great to work with recently, though).
I've worked in a lot of areas of the kernel - block and filesystems the most - and mm has consistently been a pain point. It's very central, and yet it's been hard to get a lot of things done in a lot of areas because there hasn't seemed to be clear responsibility, and there's been a ton of "project focused" activity that left giant messes that have taken other people years to grapple with - hugepages and memcg being the big ones. Swap's been a mess, compaction frequently pops up as a likely culprit in heisenbugs that aren't getting resolved - oh, and I see a lot of bug reports where zram is implicated (so again, who's responsible? distros are turning this stuff on, but it's not stable).
My biggest pet peeves have just been getting sufficient introspection to debug e.g. reclaim issues resulting in a lot of nitpicky infighting; we can't debug issues when we can't see what's going on, and yet high level maintainers dismiss any movement as "that'll make the logs too spammy". Ouch. And again, lack of anyone with a clear long term proactive vision and responsibility.
Posted Feb 16, 2025 10:55 UTC (Sun)
by sammythesnake (guest, #17693)
[Link] (5 responses)
That is certainly something to be hoped for, and for some is a motivating consideration behind pushing R4L, even a stated aim, but I think the far stronger motivation is the fact that Rust has very definite advantages over C as a language to implement kernel functionality in.
IMVHO (as somebody who has written zero Rust code, zero Kernel code, and maybe 150 lines of C code ever, "VH" gets some emphasis here!) I see so many reasons *not* to use C when there's any alternative that I'm frankly perplexed at the resistance some have to Rust.
Rust certainly has imperfections (as a bystander, even I can name a few) but anything that makes whole classes of bugs all but impossible is a no-brainer to me without something *major* to push back the other way.
The current controversy saddens me greatly - the R4L people aren't asking the current maintainer to do anything extra to support their work, and yet he's applying a veto on the basis that he doesn't want to do extra work. Frustrating indeed.
It seems to me that the correct way to manage this is for the R4L wrappers to go into mainline via a separate tree that Linus can pull from without other subsystem maintainers having to worry about them at all. In an ideal world, people working on the C code these wrappers talk to would cooperate and maybe even assist, but at the very least they shouldn't use their position to mess up stuff that doesn't hurt them.
There seems value here to the maxim "Lead, follow, or get out of the way"...
Posted Feb 16, 2025 13:23 UTC (Sun)
by LtWorf (subscriber, #124958)
[Link] (4 responses)
As for rust in general, there's a number of reason to still be using C now:
* can build and run for a lot more devices
Posted Feb 16, 2025 19:05 UTC (Sun)
by smurf (subscriber, #17840)
[Link] (3 responses)
Arguably it's not.
It just looks easier. C definitely has fewer syntax rules and fewer restrictions than Rust.
The problem is that those rules and restrictions *do* exist in (kernel) C, it's just that the compiler doesn't help enforce them, let alone emit helpful (no scare quotes – Rust is reasonably good in that regard) error messages.
Instead you get to learn the rules by experience and/or reading the sources of whatever code you call, code review that hopefully finds some of the more egregious problems, debugging crashed kernels, followup patches that fix your mistakes, and so on.
Speaking of code review. There's only so much mental bandwidth. Making sure that the code in question obeys the locking rules du jour, doesn't have use-after-free problems, and so on, means less focus on the actual logic.
Posted Feb 17, 2025 6:09 UTC (Mon)
by LtWorf (subscriber, #124958)
[Link] (2 responses)
The awkward moment when you reply before reading what you're replying to, and you miss the line: "As for rust in general, there's a number of reason to still be using C now:".
You're basically arguing that python is harder because it has more hidden gotchas.
Is assembly easy since it's completely explicit then? Should we be using assembly directly? Should you have read my comment before replying to it?
(for me it's no, no, yes)
Posted Feb 17, 2025 7:38 UTC (Mon)
by smurf (subscriber, #17840)
[Link] (1 responses)
For the record, I didn't miss that line at all. I merely disagree, rather vehemently in fact, with your "C is easier" point. Because it definitely isn't. Not by the time you need to use nontrivial interfaces … like the rest of the Linux kernel, which I assume is still the context of this discussion.
C (and even more so, assembly) is not at all explicit in the sense that the interfaces to existing code are full of implied assumptions you need to adhere to, otherwise your code is buggy and will crash on you (or randomly corrupt your users' RAM, who knows). By contrast, in well-written Rust interfaces most of those cannot-be-stated-in-C-much-less-assembler assumptions are right there and the *compiler* will *tell* you if you violate them.
Posted Feb 17, 2025 8:12 UTC (Mon)
by LtWorf (subscriber, #124958)
[Link]
You keep talking about kernel and it was referred to user space. Since I even spoke about distributing and dependencies, which are very different on the kernel… That's because the comment I was replying to was wondering why would anyone still use C in general.
The 6.13 kernel had 254 first-time contributors — an entirely typical number. The kernel community may have problems, especially when it comes to maintainers, but it is not "lacking new contributors".
New contributors
New contributors
New contributors
New contributors
New contributors
Wol
New contributors
New contributors
Wol
New contributors
New contributors
New contributors
New contributors
New contributors
New contributors
New contributors
Cancer?
Cancer?
* C is a well established language and it's easy to get stuff into distributions
* A lot of dependencies won't have bindings or equivalent for rust
* C is easier
Cancer?
Cancer?
Cancer?
Cancer?