Spending significant time adapting core kernel code or developing a safe Rust abstraction for DMA, only to be summarily shut down by a single gatekeeper who cites "not wanting multiple languages" is demotivating. It's especially incongruent given that others have championed Rust in the kernel, and Linux has begun hosting Rust modules.
If the project leadership — i.e. Linus — truly wants Rust integrated, that stance needs to be firmly established as policy rather than left up to maintainers who can veto work they personally dislike. Otherwise, contributors end up in a limbo where they invest weeks or months, navigate the intricacies of the kernel's development model, and then find out a single personality is enough to block them. Even if that personality has valid technical reasons, the lack of a centralized, consistent direction on Rust's role causes friction.
Hector's decision to leave is understandable: either you have an official green light to push Rust forward or you don't. Half measures invite exactly this kind of conflict. And expecting one massive rewrite or an all‐encompassing patch is unrealistic. Integration into something as large and historically C‐centric as Linux must be iterative and carefully built out. If one top‐level developer says "no Rust", while others push "Rust for safety", that is a sign that the project's governance lacks clarity on this point.
Hector's departure highlights how messy these half signals can get, and if I were him, I'd also want to see an unambiguous stance on Rust — otherwise, it's not worth investing the time just to beg that your code, no matter how well engineered, might be turned down by personal preference.
_ph_ 29 days ago [-]
I think initially Linus stance of encouraging Rust drivers as an experiment to see how they turn out was a right decisions. There should be some experience before doing long term commitments to a new technology.
But since then a lot of experience was made and I got the notion that the Rust drivers were quite a success.
And now we are at a point where proceeding further does need a decision by Linus, especially as one of the kernel maintainers is actively blocking further work.
hulitu 29 days ago [-]
> Spending significant time adapting core kernel code or developing a safe Rust abstraction for DMA, only to be summarily shut down by a single gatekeeper who cites "not wanting multiple languages" is demotivating
Christoph Hellwig is one of the oldest subsystem maintainer.
Maybe the Rust developer shall have a more careful behaviour. Nobody wants to break core kernel code.
Ygg2 29 days ago [-]
> Christoph Hellwig is one of the oldest subsystem maintainer.
Also it's not his domain, from Marcan's Reddit response Greg is one in charge of maintaining this area.
So this is drive by reviewing.
ActorNightly 30 days ago [-]
[flagged]
codys 29 days ago [-]
This is a fundamental misunderstanding of the structure of the linux kernel, the nature of kernels in general, and the ways one performs automated verification of computer code.
Automated verification (including as done by rust in it's compiler) does not involve anything popularly known as AI, and automated verification as it exists today is more complete for rust than for any other system (because no other widely used language today places the information needed for verification into the language itself, which results rust code being widely analyzable for safety).
Human validation is insufficient and error prone, which is why automated verification of code is something developers have been seeking and working on for a long time (before rust, even).
Having "explicit" (manual?) memory management is not a benefit to enabling verification either by humans or by machines. Neither is using a low level language which does not specify enough detail in the type system to perform verification.
Kernel modules aren't that special. One can put a _lot_ of code in them, that can do effectively anything (other than early boot bits, because they aren't loaded yet). Kernel modules exist for distribution reasons, and do not define any strict boundary.
If we're talking about out-of-tree kernel modules, those are not something the tend to exist for a long time. The only real examples today of long lived out-of-tree modules are zfs (filesystem) and nvidia (gpu driver). These only exist out-of-tree because of licensing and secrecy. This is because getting code in-tree generally helps keep code up to date with less effort from everyone involved: the people already making in-tree changes can see how certain APIs are being used and if those in-tree folks are more familiar with the API they can/may improve the now-merged code. And the formerly out-of-tree folks don't have to run their own release process, don't have to deal with constant compatibility issues as kernel APIs change, etc.
ActorNightly 28 days ago [-]
>Human validation is insufficient and error prone,
Basically, if you assume thats impossible for humans to be correct, or that its impossible to write correct memory safe C code, you start down the path that leads to things like Java, Haskell, and now Rust. And then when nobody takes you seriously, you wonder why - well, its because you are telling people who know how to write correct and memory safe C code that we are insufficient and error prone
>Kernel modules aren't that special.
By definition, they interface with the core kernel code. They are not core kernel code
foota 29 days ago [-]
This doesn't make sense to me, why is a manual language that requires validation better than a language that enforces some safety on its own?
ActorNightly 28 days ago [-]
Because it forces the developer to think about what is being written at every step of the way, instead of relying on language features that are by far not complete in terms of providing memory safety.
liamwire 29 days ago [-]
Naive take would be that it adds abstraction that you need to keep checked, in addition to the kernel code itself. Not making a value statement at all on the level of impact that actually has in practice.
0dayz 29 days ago [-]
I don't get this what so ever, is there memory allocation bugs in GC languages such as Java?
Even if that is the case Rust specifically is design not to be GC.
Ontop of that you csn do manual memory management if you want in Rust afaik.
ActorNightly 27 days ago [-]
Rust with manual memory management is just more cumbersome than C
0dayz 25 days ago [-]
That's shifting the goal post.
Ergonomically I don't know a single language that is both trying to make you write secure and correct code without sacrificing ergonomics.
Closest is most likely Ada.
slanterns 29 days ago [-]
The patch is just a binding / abstraction of DMA for writing Rust drivers.
AndyKelley 29 days ago [-]
I've been saying this for years now: the rust4linux folks are putting so much effort into trying to upstream their work, seems like they should instead put that effort into maintaining a fork. Arguably it would be less hours spent porting than arguing with humans. Certainly more pleasant!
Then one of two things will happen:
* Rust will prove its worth and their fork will be the better operating system. Distros will start switching to it one by one due to its increased performance and stability, and they will have dethroned Linus and become gods of the new world.
* The project will die because the C programmers will outcompete it with good ol' C, and all their talk about safety doesn't pan out in the real world.
If I were the rust4linux leadership, I'd roll those dice.
Sounds like Hector Martin is doing exactly that, burning the bridge along the way. Good luck! I think it's the right move (minus the bridge burning).
gpm 29 days ago [-]
I think you're discounting the very real damage that would be done by Linux a project controlled by Linus and a community being replaced by Linux a project controlled by Google/Samsung/Redhat/Microsoft. I'm afraid that this is what is going to happen with the Linus tree effectively rejecting rust drivers by subjecting anyone attempting to upstream rust code to persistent bullying, but I don't want it to happen.
actinium226 29 days ago [-]
> I think you're discounting the very real damage that would be done by [Linux a project controlled by Linus and a community] being replaced by [Linux a project controlled by Google/Samsung/Redhat/Microsoft.]
(Brackets added for clarity)
Isn't the current Linux already Linus + communities + companies?
More to the point, any two such projects would quickly diverge. Once a particular piece of Linux is reimplemented in Rust, if the C version adds a feature it is no longer as simple as applying a patch to keep in sync.
gpm 29 days ago [-]
> Isn't the current Linux already Linus + communities + companies?
Absolutely. To that point the companies I listed are the ones that I'm aware of employing kernel developers who work specifically on rust in linux.
The control of the project is in Linus's/community hands though, not corporate ones, and I think that's a good thing.
> More to the point, any two such projects would quickly diverge. Once a particular piece of Linux is reimplemented in Rust, if the C version adds a feature it is no longer as simple as applying a patch to keep in sync.
I don't think so. Linux is a huge modular system, and no one is really interested in rewriting the core components of it at this point. Nor maintaining their own copies of components that some other company is responsible for (like graphics drivers). Until and unless it became the dominant fork I'd expect that they'd keep merging in the mainline branch and updating their things as necessary.
This is already how projects like Android work.
hitekker 29 days ago [-]
> subject upstream rust code to persistent bullying
I don’t remember seeing this bullying accusation in your original comment. Was it edited in?
Regardless, the “bullying” happened on both sides. Hector Martin started the social media brigading and quit when he couldn’t get his personal enemy suspended for CoC violations. Jonathan Corbet wrote a letter naming and shaming maintainers, in the guise of a report.
All in all, I agree with the GP. Most of the arguments against (even temporary) forking feel like excuses for a lack of will and a maybe even a lack of ability. The space is open for a fork.
gpm 29 days ago [-]
I may have edited the phrasing within a minute or two of posting, couldn't say. I haven't edited the comment in the 14 hours since then, and the sentiment was in the original.
(I have edited this comment on the other hand, first to explicitly disagree with various statements in the above, then to delete those disagreements since I don't really want to get baited into an argument)
dbcjv7vhxj 28 days ago [-]
Why do people think rejecting rust drivers is a bad thing? It's a fucking c project.
apatheticonion 29 days ago [-]
Does Linux have the ability to load drivers dynamically (like Windows)? Is there a reason why developers don't develop drivers outside of the kernel and have users simply install them post-install?
zinekeller 29 days ago [-]
Yes, it technically does (kernel modules), but the difference between Linux and NT is that Microsoft guarantees (as much as possible) that its ABIs are stable whereas Linux explicitly does not preserve backwards compatibility in the kernel (only the userspace is the stable interface).
It seems like a huge technical factor holding back a stable ABI is the C compiler itself. Binaries changing between compiler versions and changing with different compiler flags.
So while your code can be written such that it appears to respect the interface of an external library, the underlying binary representation might not line up correctly.
If there is agreement that modularity is good for the kernel but technical limitations prevent that from being a reality - surely the solution is to improve C's interoperability first?
---
I'm not a kernel developer and am probably naive here, but on the surface it feels like offering a stable driver ABI is one possible solution to the rust-in-linux controversy that has lead to so many people exiting kernel development.
I'd imagine if projects like Asahi could simply offer out-of-tree drivers, they wouldn't need to maintain a kernel fork (at least not for drivers) or negotiate with core maintainers (which I understand is stressful).
Might also make it easier for vendors like Qualcomm/Samsung/Nvidia to distribute drivers out-of-tree, perhaps reducing the need for long running Linux forks and allowing devices to update to modern Linux kernels.
As a novice hacker, I'd imagine the ability to reuse proprietary driver blobs would allow distros to be created targeting hardware that was otherwise impossible to access as drivers were hidden behind custom kernel forks (e.g. install mainline Fedora on a Samsung phone, taking the GPU driver from the Samsung build of Android - or OpenWRT on an Android powered portable 5g modem).
spacechild1 29 days ago [-]
> It seems like a huge technical factor holding back a stable ABI is the C compiler itself.
Not really. Every OS has a stable C ABI, otherwise there would be no stable OS API functions and no application plugin APIs. The actual reason seems to be that they simply do not want to commit to a stable ABI/API so they are free to make breaking changes and remove outdated APIs. Fair enough, but don't blame it on the compiler!
Additionally, there is politics in play here. Not the politics that is normally discussed outside of HN, but the politics of having companies (at least) release the detailed specifications of their hardware. I cannot really state authoritatively what the Linux developers think on this side, but Linus brandishing his middle finger to Nvidia (https://youtu.be/MShbP3OpASA?si=GJ1_0B81b7bFY_iZ&t=2890) says a lot of things.
sgerenser 29 days ago [-]
It can, but Linux does not have a stable driver ABI. Whoever wrote the out-of-tree drivers would have to constantly update them whenever there was a breaking change to the kernel, which I understand is relatively common.
apatheticonion 29 days ago [-]
That's interesting. Dumb question but why doesn't Linux aim for a stable driver ABI? Does it impede delivery speed?
I think nvidia uses out-of-tree drivers that are dynamically loaded - does that mean that nvidia drivers are tied to specific kernel versions?
nvidia uses "DKMS" to rebuild itself for each running kernel.
Closed source modules like nvidia frequently have a kernel-independent proprietary piece and a kernel-specific (open source) ABI piece. Whenever you upgrade your kernel, DKMS will re-build the kernel-specific shim and re-link the proprietary blob. The result is a .ko tailor made for your running kernel, even though most of the code is in a kernel-independent blob.
DrillShopper 29 days ago [-]
It looks like nVidia is open to moving their open driver (which requires a card that as a GSP) upstream [1] but with Rust being killed from the Linux kernel that's probably dead.
There is a reason why in-tree drivers are preferred, and that's because the Linux driver interface and API changes with kernel API changes. The API is considered unstable in the sense that is it not unchanging.
A driver written for one release of Linux may not work with the next release as the API changes.
GabrielTFS 29 days ago [-]
To my knowledge, out-of-tree drivers are quite inconvenient to maintain compared to in-tree drivers, due to the kernel's unstable API (a driver that works on a given version of the kernel likely only works on that single version unless it has lots of ifdefs to handle all the other versions).
(Not in rust, but it's mostly assembly anyways so I'm not sure rust provides much. There is https://github.com/briansmith/ring in rust, not sure if it's sponsored by anyone)
jeanlucas 29 days ago [-]
[flagged]
eqvinox 29 days ago [-]
> Sounds like Hector Martin is doing exactly that, burning the bridge along the way. Good luck! I think it's the right move (minus the bridge burning).
Unfortunately, what Hector Martin was actually doing is producing rather spectacular flame on LKML and Mastodon. And he isn't representative of other Rust developers either, at least one has voiced their disagreement with him: https://lore.kernel.org/rust-for-linux/Z6OzgBYZNJPr_ZD1@phen...
I agree maintaining a fork would've been a more productive use of Hector's time, but that's not what has been happening and I see no reason to believe it is what will be happening from now on. From my own experience, personalities like Hector quit after not getting their way, rather than looking for other constructive options.
nicce 29 days ago [-]
> Now I'm left with the unlikely explanation that
you just like thundering in as the cavalry, fashionably late, maximally
destructive, because it entertains the masses on fedi or reddit or
wherever. I have no idea what you're trying to achieve here, I really
don't get it, but I am for sure fed up dealing with the fallout.
That is a perfect description on what has been happening over the years.
saghm 29 days ago [-]
Even if they made a fork and made it super great from a technical perspective, it still would face an uphill battle from the perspective of adoption. The amount of work to get people to switch over would be enormous, and the fact that there's at least some willingness on the part of Linux to adopt Rust in places makes me skeptical that there really would be less work to try to compete. I'd be thrilled if you're right though!
nialv7 29 days ago [-]
Projects don't just live or die purely on technical merits. There are so many examples across history of this.
msgilligan 29 days ago [-]
I think a fork with a mission to aggressively rewrite the kernel into Rust would be a great experiment. Lessons learned could be applied to the more mainstream C/Rust kernel(s).
It's not a fork of Linux but a ground up effort to write a kernel in Rust. Still they're trying to make it compatible with Linux/BSD
snvzz 29 days ago [-]
Rust aside, it uses a microkernel, multiserver architecture.
And, of course, drivers run in userspace and interact with the system through a clearly defined API.
Other systems like this include Robigalia, Lions OS and Genode.
They would likely quickly overtake Linux if they got 1% of the resources Linux receives.
snvzz 29 days ago [-]
Correction, where I said Robigalia I meant Managarm.
Robigalia is also an effort, but one that hasn't been touched in nearly a decade.
mmooss 29 days ago [-]
Who would use a kernel that is essentially the mainline kernel with more Rust? Would Debian or Red Hat use it? Maybe some very hard-core Rust hobbyists, but otherwise, why use the Rustier kernel?
But if they could demonstrate significant improvements in security and stability, then they would have something to say. Maybe the plan should be to rewrite a component that the mainline maintainers wouldn't agree to - something important with a significant affect on security and stability. Yes, it's a risk, but if their claims for Rust are true, then it shouldn't be a problem. If Rust doesn't offer a major improvement then it isn't worth the effort anyway. Put their money (or time) where their mouth is.
steveklabnik 28 days ago [-]
There are drivers that exist only in Rust, so any distro that wants to support that hardware will. Like the Apple A3 silicon graphics driver. Iirc red hat and nvidia are also working on some Rust based drivers.
mmooss 28 days ago [-]
Do the Rust drivers provide significant benefits over C equivalents (or over typical C drivers), enough to make it worth switching?
Rust may have to really prove itself with results. And why shouldn't it?
steveklabnik 28 days ago [-]
There are no C equivalents for the drivers I’m talking about.
mmooss 28 days ago [-]
I got that - that's why I added the parenthetical. My point was the second sentence. Anyway, thanks for the input about the drivers.
And for what it's worth, I expect Rust would offer significant improvements.
steveklabnik 28 days ago [-]
Ah, sorry, I misunderstood you. I don’t have a link handy, but Marcan had a post about how they actually re-wrote some in progress drivers from C to Rust because it was easier to do, and so didn’t expect a c version to exist. Basically it was about how driver complexity has increased over time, and Rust helps tackle that in a way that C can’t.
mmooss 28 days ago [-]
Yes, I realized later that I should add 'efficiency' (for development) to security and stability, which could also be a big win for Rust in particular.
stainablesteel 29 days ago [-]
completely agree on the fork side of things, just show its merits already or be done with it
i think it's going to fail because of rust as a language, not because the ideas in rust are bad but because there's infinite complications
andreww591 29 days ago [-]
I'm a little bit skeptical as to how successful a hard fork of Linux that only differs from the mainline kernel by having a bit more Rust code actually would be.
If you're going to rewrite significant parts of the kernel, you might as well do what I've been doing and try to write what amounts to a better Linux than Linux that tries to maintain compatibility, but moves beyond the rather limiting conventional Unix architecture. The conventional Unix architecture was fine on a something like a 70s/80s-era PDP-11/VAX, but in the modern world its limitations have been apparent for quite some time.
What I've been working on is an OS very similar to QNX Neutrino in terms of general architecture, but with a somewhat different IPC protocol layering that reduces the number of user-visible primitives and allows for more consistent management of security. Most of the functionality of the system will be implemented in user-level server processes that export their services through special filesystems, with the only special/irregular parts of the system being the microkernel, the process manager (which also contains the core VFS and memory filesystems since these will be tightly linked to the process model), and the base syscall library (vaguely akin to the vDSO under Linux). Literally everything else will just be a regular process. It's not a "Rust OS" as such, as there will still be some C (for instance, the microkernel, which was forked from an older version of seL4), although it will have a fair bit of Rust code.
IMO the issues with Linux are mostly due to a combination of poor/ad-hoc extensibility and the development model that's way too decentralized in some places but excessively centralized in others. The architecture I'm going with will allow for more experimentation, since adding functionality to it will typically just be a matter of adding a regular user program (or a plugin for a regular user program), and much of the system will be based around standardized filesystem-based RPC protocols (generic tooling for implementing RPC interfaces will of course be provided). Therefore it would be easier to maintain experimental functionality in a separate repository and merge it into the base system later on.
Currently it's still quite preliminary, and it only runs some hardcoded tests built into the process server, although despite that, some developers from a major company have taken interest in it recently because of the possibility of using it as a replacement for QNX both in embedded systems and development workstations. I'm working on the VFS layer and built-in special filesystems at the moment, and hopefully should be able to get user processes running pretty soon.
You could read books older than 2000+ years to realize this drama can't be avoided (though neither can this smug feel re other's ignorance)
actinium226 29 days ago [-]
Genuinely curious, what book are you talking about?
Ar-Curunir 29 days ago [-]
Please enlighten us, oh knowledgeable one.
dinkumthinkum 29 days ago [-]
Because the Rust used in the kernel is unsafe. All these people downvoting me or talking about 2000 year old books choosing to be maliciously ignorant, which is fine, I guess.
xondono 29 days ago [-]
You have to be rage baiting to make an argument this bad.
First, no, it’s not all unsafe, it’s not even 50% unsafe.
Second, even 50% unsafe is an upgrade from 100% unsafe.
The problem is that the R4L project is raising a lot of questions about how interfaces are handled by some Linux maintainers, and there’s definitely a difference in criteria when it comes to soundness bugs.
I fall on the side that just because nobody has stepped on it on years isn’t a good excuse to keep landmines in the code, but clearly a lot of people in the kernel think differently.
goku12 29 days ago [-]
By your logic, the entire Rust language and ecosystem would be considered unsafe. Even the Rust standard library is full of unsafe blocks and functions. But people don't consider it so, because Rust isn't about avoiding unsafe code. It's about containing unsafe code and presenting a safe wrapper by enforcing the invariants. This philosophy would have been abundantly clear if you cared to look at the patch [1] at the center of this controversy. Perhaps you should verify the validity and harmlessness of your own claims before accusing others.
Marcan certainly can be abrasive (I mean lol, so can Linus), but all the things he points out in the message below are 100% valid - I highly recommend for anyone here to try to contribute something even very small and logical to the Linux kernel or git (which use similar processes), it’s an eye-opening experience that’s incredibly unapproachable, frustrating, and demoralizing.
Having read through the email thread, I think both vocal people are basically in the wrong here. There is a way to constructively disagree and the DMA maintainer did not do that. The Rust maintainer should not have brigaded using social media.
The “in hindsight” version of how this should have gone without ego:
* Patch adds Rust bindings to C API
* Maintainer has concerns about increased maintenance cost and clarifies policy about C changes and Rust abstraction if unsure.
* Since R4L is approved, the binding is allowed to exist in a form that doesn’t inhibit changes to C API. C API is allowed to break Rust (I assume, otherwise the entire effort is moot).
* Any concerns about tooling etc which DON’T exhibit this property (and can demonstrably show that merging this Rust code will make C code harder to change) are brought up.
* These are resolved as a tooling issue before the change is merged (I don’t think there are any in this case).
All the discussion about multi-language projects etc is for the project as a whole to decide, which happened when R4L was approved and the breakage policy was decided (might need to be properly formalised).
If the maintainer (or anyone) is unreasonable, then the only approach is to have someone with more authority weigh in and make the decision to bypass their objections or sustain them (which is sort of the direction this was going before the diatribes).
hajile 29 days ago [-]
Both were wrong, but only one was corrected.
> If the maintainer (or anyone) is unreasonable, then the only approach is to have someone with more authority weigh in and make the decision to bypass their objections or sustain them (which is sort of the direction this was going before the diatribes).
While they were arguing, Linus said nothing. While the maintainer was issuing ultimatums, Linus said nothing. Linus only said something when social media forced his hand. This is the real issue.
ratorx 29 days ago [-]
You’re right - add insufficient leadership to the list as well.
IMO, it seems inconsistent to green light R4L and not declare a clear policy for Rust code interacting with C code without adding a hard dependency (and if it WAS declared, not enforcing it).
The only benefit of doubt I can give is that there wasn’t enough time for Linus etc to weigh in before the thread got sidetracked (and the decision became much more politically charged). It’s unclear what would have happened if only the maintainer was unreasonable.
bombcar 29 days ago [-]
Apparently GregH(?) had already stepped in earlier to resolve the issue before it blew up again. But I’ve not been following it closely.
snvzz 29 days ago [-]
>Both were wrong, but only one was corrected.
People are wrong in LKML often.
This time, somebody was wrong in a much worse way than usual.
nubinetwork 30 days ago [-]
While I never submitted a patch personally, I had once conferred with some of the input devs to add a trackpad to the synaptics driver... they were queueing up an update to add other trackpads, and they said they would add mine... 5 years later, it's still not there. It was just a one-liner, and I'm not really sure why it never got added...
On the other hand, I once ran into an issue with uboot where a bad update knocked out my emmc, usb and sata controllers... found an email address of someone developing the dtb files and got in touch with them, and it was fixed in under a week.
At the end of the day, people are weird sometimes. I wish all the best for marcan.
ogoffart 30 days ago [-]
I tried once to contribute a fix to be able to use the track-pad on my laptop many years ago. But it was not accepted as the maintainer claimed it was an problem in userspace that did not process out of order events correctly. Despite none of the other drivers sent the events out of order. I had no intention to fix the problem on X11 (the only userspace for this at the time), so I used the patched kernel driver locally until I stopped using that laptop.
https://bugzilla.kernel.org/show_bug.cgi?id=43591https://lore.kernel.org/all/1340829375-4995-1-git-send-email...
bsimpson 30 days ago [-]
FWIW, I have submitted a couple small patches to get the display and gamepad for my Lenovo Legion Go recognized correctly - probably similar levels of complexity to your change. One was to input and one was to display quirks.
They did take months to finally land, and the whole process of getting my corp email address to be compatible with their email-based PR system was way more of a faff than it had any right to be, but they did land. You can install mainline Linux on a Legion Go now and the display and controller will behave as expected, out-of-the-box.
Ecco 29 days ago [-]
Thanks!
naasking 30 days ago [-]
> 5 years later, it's still not there. It was just a one-liner, and I'm not really sure why it never got added.
I think they expect people who want things to advocate harder than just mentioning it once. If no one brings it up again, then they assume that no one cares.
harvey9 30 days ago [-]
this seems very inefficient and the opposite of what I assumed. repeated requests take up time on both sides and are not a very good measure of how important something is.
nicce 30 days ago [-]
This is how the most of the open-source development works. There are many projects with thousands of issues and PRs. Those that will get most attention, typically gets prioritized.
stusmall 30 days ago [-]
This is even how closed source development works. If you throw issues in a backlog and never follow up to advocate for it then it will never get done.
dncornholio 30 days ago [-]
it's not perfect but it works.
neoromantique 30 days ago [-]
well, apparently it doesn't.
naasking 30 days ago [-]
Well, apparently nobody even noticed for 5 years, so that's 5 years that nobody had to even think about that code.
amatecha 29 days ago [-]
Nah, people noticed, and then they thought "Linux always has these kind of issues, I'm going back to [whatever other OS]" because 99.9% of users will never even TRY to report a bug.
samus 29 days ago [-]
People just think "that's Linux, it's buggy and we have to live with it"
mid-kid 30 days ago [-]
why bother infering such intent when the obvious answer - that they simply forgot about it with no ill intentions - is right there?
naasking 30 days ago [-]
Requiring people to advocate for their changes is not ill-intent. It handles all cases such as forgetting/missing a patch, and disagreement whether something is needed. The point is there's no system in place to track which patches "should ideally be included but weren't for some reason", it's up for the people who need them to push for them.
adastra22 29 days ago [-]
Quite the opposite. If you “pester” for something, they’ll explicitly reject it.
naasking 28 days ago [-]
I didn't say pester, I said advocate for it.
adastra22 28 days ago [-]
It's the same thing.
arp242 30 days ago [-]
People forget things etc.
Should probably have just asked again, or sent a small one-line patch. It's "mention something on Slack" vs "creating a GitHub issue/PR"
lazyasciiart 29 days ago [-]
Then you get stories like Greg in the linked mail thread, who emailed to check after not hearing anything and got told that now he'd been annoying and it would never be done.
account42 27 days ago [-]
A story about a 17000 line patch with seemingly no discussion before dumping it on the kernel maintainers. Understandable that noone felt like reviewing it.
samus 29 days ago [-]
Which sounds inefficient and exactly the sort of problem that doesn't happen with a Github issue/PR.
BlueTemplar 29 days ago [-]
But Github, being a platform, is a nonstarter.
Have there been any recent popular developments on a similar workflow that is as robust as e-mail ?
samus 27 days ago [-]
They "just" need to settle on a platform. GitLab sounds good and is used by a lot of important Open Source projects.
BlueTemplar 27 days ago [-]
Did you miss the part where being a platform was most of the issue ?
I'm not sure how long GitLab can be trusted either, as well as git becoming a bit too synonymous with GitHub...
arp242 28 days ago [-]
> exactly the sort of problem that doesn't happen with a Github issue/PR
What? PRs or issues being forgotten happens all the time, especially for large projects.
samus 27 days ago [-]
It would still be easier to track the progress (or lack thereof) with a proper ticketing system.
account42 27 days ago [-]
Yeah instead the issue will be auto-closed by some bot. Yay.
arghwhat 30 days ago [-]
Having contributed a few times, I'd rate it as similar (sometimes much easier!) than contributing to Firefox and Chromium. That is to say that it is indeed extremely time-consuming and frustrating, but when compared to projects of the same scale it does not necessarily come out as more time-consuming or more frustrating - this will never be a small team collaborating on a random Github repo. A simple "swap out X workflow for Y" does not fix these annoyances, and false dichotomies and peer pressure towards is not a way to cooperate.
I cannot claim to have felt the effects on the maintainer-side of this workflow in large-scale projects though.
roca 29 days ago [-]
It's way more painful to contribute to the kernel than contribute to Firefox, at least, unless things have changed since I was involved with Firefox.
Suppose you find a bug in the kernel and come up with a patch. You email the patch to some kernel mailing list and ask for feedback. Typically, you will receive no response whatsoever, because no-one is responsible for responding. You can try emailing random developers and eventually maybe one of them will have mercy on you.
In Firefox and I think Chromium, you can file a bug, attach your patch, request review from someone (the UI will help you choose a suitable person), and it's their job to respond.
arghwhat 29 days ago [-]
In my experience it's the opposite - the email patch usually gets dealt with within a week or two, Firefox and Chromium dragged out because it wasn't whatever Mozilla or Google prioritized right now. Or worse, it might go against an internal corporate KPI.
In Firefox you have to fiddle with Mercurial, phabricator, and their homegrown CI. In Chromium its Gerrit and their homegrown CI, and oh btw you touched code that lacked tests so tag, you're it.
roca 29 days ago [-]
"The email patch usually gets dealt with within a week or two" is absolutely not my experience dealing with the kernel.
Firefox and Chromium's bespoke tools have their pluses and minuses but they're a lot easier to deal with that the kernel "workflow".
arghwhat 28 days ago [-]
That your experience is not shared suggests that the other "workflows" are not in fact objectively easier to deal with than the kernel workflow, but instead that there's a high variability in the frustration experienced across all three workflows.
mook 29 days ago [-]
I haven't touched Gecko in a decade, but your second paragraph sounds like my experience. My best record was something like a single character bug fix taking months (might have been years?). Yes, the review flag was set to the right person.
I still remember the story where some other guys had to meet some Mozilla folks for lunch and nag them for reviews…
roca 29 days ago [-]
I'm sorry you had a bad experience with someone, but at least you know who wasn't doing their job. On the kernel side, you don't.
arghwhat 28 days ago [-]
get_maintainer.pl gives you the list. Theres no equivalent in Firefox or Chromium to flag which Mozilla/Red Hat/Google/... manager does not consider your ticket an area of focus.
roca 28 days ago [-]
A kernel maintainer can completely ignore any submission with no repercussions even in principle. And they often do.
In Firefox, in my era at least, a reviewer who simply ignores a review request indefinitely was not doing their job and would get yelled at by someone --- me, if it came to my attention.
zaptheimpaler 30 days ago [-]
Besides the current drama, I'm glad someone of his stature agrees with and can call out the horrible processes and tooling involved in the kernel. Using email and a pile of hacks to mess around with patches just sounds nuts and makes it so much harder to understand or contribute. I don't think decentralized necessitates such a terrible workflow - you can run a local website with a distributed DB, distributed git forges exist, you can use federated chats instead of email, there has to be a better way than email.
ratorx 30 days ago [-]
I don’t think there is enough demonstrable benefit to sacrifice the ubiquity and flexibility of email for a newer solution, especially for existing maintainers who are probably very comfortable with the current workflow.
Harder to understand and contribute is a bad, but unless there is a proposal for a similarly flexible system that has minimal downsides and massive advantages, the preference of existing maintainers should dominate over potential future contributors. Especially factoring in how expensive of a migration it would be.
zaptheimpaler 29 days ago [-]
I can understand this mindset, but I also think this is how communities die. They go to great lengths to avoid inconveniencing existing members while neglecting to welcome new ones. In the short term, the better choice is always to favor the existing contributors right up until they start dropping out and there's no one left to replace them.
Linux is so ubiquitous & important that might never happen, maybe it will just become increasingly captured by corporate contributors who can at least build long lasting repos of knowledge and networks of apprenticeship to help onboard newbies. Open source in name only.
mplanchard 29 days ago [-]
I really like the way sourcehut integrates mailing list patches with a good UI. I’d like to see that become more common in some of these “classic” open source projects.
josefx 30 days ago [-]
Afaik Linus tried Github in the past, but had several significant complaints about it hiding information, messing with basic git operations, generating bad commit messages, etc. . So it is not as if they wouldn't use something better, there just isn't anything that has feature parity with a workflow they have been optimizing for decades.
thayne 29 days ago [-]
That optimization includes things like email filters and email client customization that is individualized to longtime contributors, not to mention that it is just what Linus and others are used to. And the long time contributors have had years, or decades to incrementally set up their tools, and become familiar with the workflow. The problem is that new contributors and maintainers don't have that, and learning the workflow, and setting up tools so that the email based workflow is manageable is daunting and takes a lot of time.
I won't contest that there are advantages to the linux Kernel's workflow, but there are downsides too, and a major one is that it scares off potential contributors.
That said GitHub definitely is far from perfect as well, and has different strengths and weaknesses from email based flows. As do any other options.
But just because there isn't currently anything that is unilaterally better doesn't mean things can't be improved. There is clearly a problem with onboarding new developers to the linux workflow. That should be acknowledged, and a solution sought. That solution doesn't have to be switching to GitHub or similar. Maybe there just needs to be better documentation on how to set up the necessary tools, that is oriented towards developers used to the Github process. Maybe there needs to be better tooling. Maybe the mailing lists need to be organized better, or have the mailing list automatically add metadata in a standard, machine-readable format to emails. Etc.
sandywaffles 29 days ago [-]
> [..] a workflow they have been optimizing for decades.
it sounds the opposite of optimized to me. Unless we're optimizing for something other than developer experience and efficiency?
bombcar 29 days ago [-]
Once you realize the kernel workflow is optimized for Linus’s (and a few other top honchos) efficiency it all begins to make sense.
Any change introduces anomalies and those cause all sorts of hell.
zymhan 29 days ago [-]
> Unless we're optimizing for something other than developer experience and efficiency?
It's almost like there are more important goals wrt software development.
29 days ago [-]
dijksterhuis 29 days ago [-]
> a workflow they have been optimizing for decades
Every time I have to interact with mailing list based projects I feel like I must be missing some secret set of tools and workflows to make it easier.
Then I talk to the old timers and they act like I just need to get used to it.
finnthehuman 30 days ago [-]
I always thought it was a pretty blatant "vibe check" to filter out people who are so uncomfortable with software that they can't customize their environment to create an email workflow that works for them.
sangnoir 30 days ago [-]
That sounds about right - the medium is the message. If you can't stand the clunky-but-working, decades-old, patch process, you probably won't stand the clunky-but-working decades-old code.
I'm grateful the kernel still supports MIPS, which means an old appliance of mine still works perfectly fine and is upgradable. I would be cery sad if someone were to rip-out support of an old MIPS arch, just because it's old and unwieldy
thayne 29 days ago [-]
I've contributed to a couple of projects that use email based workflows. I can customize my environment, but it takes a lot of time, and I would rather do something else than figure out how to filter the firehose of a mailing list to the few emails I actually care about, or learn how to use a new email client that is slightly better and handling patches.
The first few times, it took me longer to figure out how to send a patch than it did to fix the bug I was writing a patch for.
db48x 29 days ago [-]
But you only have to figure that out once. Amortized over many contributions the cost is essentially nothing.
solarkraft 29 days ago [-]
But the initial cost is what determines whether the first patch will ever be sent, so the amortization may never happen.
db48x 29 days ago [-]
I guess technically that’s true, but it cannot possibly take long to learn how to use `git format-patch`, and everyone should already know how to attach a file to an email. Even if you have to spend half an hour reading the entire output of `git format-patch --help`, is that really enough to prevent you from sending your first patch?
adastra22 29 days ago [-]
Yes.
db48x 28 days ago [-]
Ok, let me get this straight. You diagnosed a problem in the Linux kernel. You debugged it and figured out how to fix it. You edited the kernel source code, recompiled it, and tested your fix. After all that, if you have to read a man page you’ll just give up?
That’s seriously lame.
adastra22 28 days ago [-]
What time is more valuable than that, and I don’t owe it to anyone.
db48x 27 days ago [-]
By that same token, there’s no reason for you to expect kernel developers to adopt a different way of working either. Their time is even more valuable than yours.
adastra22 29 days ago [-]
We only have so many hours in our sadly finite lives.
perching_aix 30 days ago [-]
Can't or won't? Surely what you just read would make you reconsider?
finnthehuman 30 days ago [-]
shrug maybe "won't" is a false positive, maybe a true positive, I dunno man, not my vibe check.
knighthack 29 days ago [-]
As someone who has never used mailing lists before (for software development), how much harder/less advantageous it is to migrate to an issues or thread-based approach, like with Github?
And why not?
dharmab 28 days ago [-]
The short version is:
- Distributing patches via email is more scalable than web hosting. Even GitHub could not host the level of activity happening on the LKML mailing list
- Web hosting has a variety of access and legal problems when working with international teams; email crosses borders more easily
- Email is a decentralized and distributed system that prevents any single company from controlling a project's development infrastructure (release infrastructure is another story, but multiple companies will generally manage their own release process anyway)
tptacek 30 days ago [-]
It's not Wikipedia, right? Getting the maximum number of contributors isn't a stated goal? I'm a C programmer with a fair bit of kernel experience, and they don't want me, I'm pretty sure, and I'm completely fine with that.
Hamuko 30 days ago [-]
Wikipedia has plenty of gatekeeping too. I once had to submit a single edit three times before the moderators safeguarding the article begrudgingly accepted it.
tptacek 30 days ago [-]
They do, but they have a stated goal of maximizing contribution. Linux does not, right? I'm asking.
Q: What would make you even more happy with Linux?
GregKH: If you contribute to it.
DrillShopper 30 days ago [-]
The kernel dev process is more pathological than what I deal with at $DAYJOB.
Why the hell would I wish that upon myself?
dfedbeef 29 days ago [-]
A stable career where you can move to any of the companies who have a dependency on your subsystem.
DrillShopper 28 days ago [-]
But I already have that
dfedbeef 17 days ago [-]
happy 4 u
threatofrain 30 days ago [-]
Different Wikipedia communities have different governance policies. In the math wikis there's generally a rule that small fixes are not allowed. This stops people from arguing whether slightly better explained sentences are the right edits.
mhh__ 30 days ago [-]
> Marcan certainly can be abrasive (I mean lol, so can Linus)
My impression of a few glancing online interactions is that they're both abrasive but marcan is quite unwise in a way that Linus has had beaten out of him
cataphract 30 days ago [-]
I'm tired of anaphoras.
And he's not just abrasive
He's a troublemaker. Seriously, code of conduct violation? It was perfectly clear what Hellwig meant by "cancer".
Vegenoid 30 days ago [-]
In my opinion, calling the well-intentioned hard work of others "cancer" is undeniably hyperbolic and dismissive. It is clear that Hellwig used it in this way. To interpret it differently requires bending the mind. Most people would also consider it rude, but I'll grant that rudeness is more subjective.
There is an argument that being hyperbolic, dismissive, and maybe a bit rude isn't as bad as some people make it out to be, and that it is a fine way to hash out disagreements and arrive at the best solution - that it is simply a result of the passion of exceptional engineers. There has historically been much of it in kernel development. But it seems that as the background and culture of kernel maintainers has broadened, that a more measured and positive approach to communication is more constructive.
It doesn't seem like marcan exemplifies this very well either. It is a loss for someone so skilled to abandon collaboration on the kernel, and seems like the unfortunate result of someone being dismissive and rude, and someone else taking that harder than is warranted or healthy.
tssva 29 days ago [-]
"To interpret it differently requires bending the mind."
Stange, I think interpreting it your way requires bending the mind. Hellwig clearly used it to describe what he sees at the ill effects of multiple languages in the kernel. It was not used to describe either Rust the language or this specifically this particular submission.
Vegenoid 29 days ago [-]
> And I also do not want another maintainer. If you want to make Linux
impossible to maintain due to a cross-language codebase do that in
your driver so that you have to do it instead of spreading this cancer
to core subsystems. (where this cancer explicitly is a cross-language
codebase and not rust itself, just to escape the flameware brigade).
It was used to describe the Rust for Linux project, as well as any other potential efforts to bring other languages into the kernel, of which there are none. It is clear why someone working on the Rust for Linux project would feel that "this cancer" refers to the project that they are working on.
I'm not trying to pull out pitchforks, I don't want anyone to burn. I just want people to collaborate effectively and be happy, and I think it is empirically clear that calling something that grows/spreads and that you think is bad "cancer" is not useful, and only inflames things. It is not an illuminating metaphor.
markchuk 29 days ago [-]
I agree with Vegenoid that using diseases for labeling poorly written code is at the very least highly unprofessional. This practice not only diminishes the seriousness of illnesses like cancer when used so casually, but it also cannot provide helpful constructive feedback.
Instead of providing helpful advice like outlining the current situation and suggesting specific improvements (action A, task B, and goal C) to reach the goal, it feels rude and offensive.
Brian_K_White 29 days ago [-]
There is no specific improvement if the problem is fundamental. There is no "better/right" way to spread a cancer. (I'm not saying it is, just that that is the argument, and in that context, there is no such thing as a common goal to reach some better way. Everyone does not actually have to agree that all goals are valid and should be reached.)
The only helpful advice, which they did give, is don't even start doing this because it's fundamentally wrong.
The linux kernel is like a house where everyone is a vegan. Marcan believes that incorporating some meat in the diet is important, and better that being a vegan. He may even be right. But so what? He makes his pitch, the family says that's nice but no thanks. He then demands that they eat this chicken because he wants to live in the house and wants to eat chicken while living in the vegan house?
I don't see how he has any right to what he wants, and I don't see an existing kernel devs refusal to cooperate, or even entertain cooperating, as automatically wrong or unreasonable.
MrJohz 29 days ago [-]
> The linux kernel is like a house where everyone is a vegan. Marcan believes that incorporating some meat in the diet is important, and better that being a vegan. He may even be right. But so what? He makes his pitch, the family says that's nice but no thanks. He then demands that they eat this chicken because he wants to live in the house and wants to eat chicken while living in the vegan house?
While I think this a dumb metaphor, it's also incorrect in this context. The Linux kernel explicitly supports C and Rust code, and there are very clear parameters to allow for Rust code to be integrated into parts of the kernel.
Or in other words, the decision has already been made to allow meat into the vegan household, and now one maintainer is explicitly blocking a package of meat from entering the building, even though it has already been decided from on high that meat should be allowed in.
This isn't quite accurate, though, because of the unnecessary metaphor thing. Reading the original mailing list chain all the way through and talking about these events directly is completely sufficient here. The patch was reasonable within the parameters set out for the R4L project. The maintainer of this subsystem blocked it explicitly because they disagree with the idea of R4L in general (calling it a cancer).
The question is not whether or not R4L is a good thing or a bad thing - anyone can have their own opinion on that. R4L is part of Linux, and will be for the foreseeable future, until it either clearly demonstrates its use, or clearly demonstrates its failure. The question (at least as regards the "cancer" comment) is whether it is okay for a maintainer to describe another team's work as cancer, and to publicly block it as much as they can.
Brian_K_White 29 days ago [-]
Of course it's ok to block something they judge to be harmful as much as they can. That is their explicit job as maintainer is to make exactly that type of judgement.
If they are overstepping, then Linus will make that known. Until then, apparently they are not overstepping.
And he can use that image if it communicates the concept he wants to communicate.
It sounds like a valid image to me to apply to the concept of polyglot.
He is saying that "If there is really no way for a rust driver to exist all by itself without any of the c code having to do anything special to accomodate it, then so be it, I guess rust doesn't fit here after all."
rust devs are saying "you're not even helping a tiny bit!". I am saying, no, they're not, so what? They don't have to. They did not request what rust devs are trying to do.
The concession rust devs got to proceed to attempt to use rust in the kernel at all doesn't promise almost anything beyond "well you can try". It does not promise to facilitate that try at all really.
steveklabnik 29 days ago [-]
No, the rust devs are saying “you do not need to accommodate” and he’s saying “I say no anyway.”
Brian_K_White 29 days ago [-]
It's like the trope of the hyper emotional significant other that turns practically any statement into "You just called me a dog!!??".
Ygg2 30 days ago [-]
Even if you put that aside, the problem is you offer Hellwig two solutions and he NACKs them both.
H: I don't want to support multilanguage codebase
R: We'll have a maintainer verify R4L is behaving properly.
H: I solved issues because they were unified.
R: Rust will be mirror of whatever C is, and you're free to break it, R4L will maintain it.
H: No.
DSMan195276 29 days ago [-]
I'll bite and play devils advocate here - both of those are not a solution to his problem. Ultimately he's the maintainer and he gets the emails if X driver is broken, so because of that he doesn't want to rely on another group to maintain the 'Rust half' of his part of the code. It's also a system that works until it doesn't, the biggest rule of the kernel is no breaking userspace - at some point in the future it won't matter if it's his C changes breaking the Rust drivers, it's still his changes that have to be rolled back if the Rust code isn't updated.
And to clarify I'm not saying he's right or wrong or acting good or bad. I have however expected R4L to ultimately fall apart because of this exact issue, the maintainers have never been on board with maintaining Rust code and that hasn't changed. While that remains the case the project is going to be stuck at a wall - to the point that if they're confident they can maintain the Rust code themselves they should just fork it and do that. If it works well enough they'll eventually be too popular to ignore with people choosing to write their new modules in Rust instead.
dralley 29 days ago [-]
That is not a problem. Christoph does not have the right to gatekeep who can use DMA. If he tried to veto an Nvidia graphics driver from using DMA using the excuse that "it might create more work for me", everyone would rightfully tell him to f-off, because that's not his call.
tw1984 29 days ago [-]
[flagged]
tw1984 29 days ago [-]
[flagged]
Philpax 30 days ago [-]
What is the interpretation of "cancer" in this context that isn't rude, offensive, or hostile to the R4L project?
arp242 30 days ago [-]
He meant to say "the Rust code will spread everywhere [like cancer]".
I agree it's rude, offensive, and hostile, but there are degrees of things and context matters. "You are cancer" would be much worse. I feel we should try and interpret things in good faith and maintain some perspective. For a single word like this: you can just read over it (which is also what the other Rust people did).
Certainly outright removing Hellwig from the Linux project, as Marcan suggested, is bizarrely draconian.
He wasnt talking about Rust specifically, he was referring to codebases in any other language.
He said:
“ And I also do not want another maintainer. If you want to make Linux
impossible to maintain due to a cross-language codebase do that in
your driver so that you have to do it instead of spreading this cancer
to core subsystems. (where this cancer explicitly is a cross-language
codebase and not rust itself, just to escape the flameware brigade).”
dearing 30 days ago [-]
Mixing codebases in the Linux core.
I think the conversation is more about people equating R4L as validation for rust or even themselves.
dralley 30 days ago [-]
That is not what is happening! Nobody is mixing languages in the Linux core...
exDM69 29 days ago [-]
> It was perfectly clear what Hellwig meant by "cancer".
No, it is not perfectly clear.
The generous interpretation is that they meant it is "viral", spreading through dependencies across the codebase (which I don't think is technically accurate as long as CONFIG_RUST=n exists).
The less generous way to interpret it is "harmful". The later messages in the thread suggests that this is more likely.
But I'm left guessing here, and I'm willing to give some some benefit of doubt here.
That said, the response to this comment was incredibly bad as well.
(not taking either side, just interesting to read the reply)
roca 29 days ago [-]
This part of the reply exemplifies one of the big problems in the kernel community:
> You think you know better. But the current process works.
Regardless of how badly broken the kernel development process is, Linus and others observe that Linux continues to dominate and conclude that therefore the development process "works". Success in the market blinds the successful vendor to their defects. Sound familiar?
If Linux carries on down this path then eventually something else that has been subject to more evolutionary pressure will displace Linux, and we'll all be telling stories about how Linux got complacent and how it was obvious to everyone they were heading for a fall.
And honestly, with maintainers like Hellwig maybe that's what needs to happen.
_ph_ 29 days ago [-]
Or worse: Linux is so widespread and managed to practically kill most Unix alternatives, that progress in OS development is slowed down globally. I would strongly prefer Linux being an OS with a lot of progress to stagnation and possible no alternative in the next decades.
lonjil 29 days ago [-]
I find this reply interesting. Linus says that what matters is technical stuff, but even before the social media brigading, the whole thread was nothing but non-technical drama. So why is Linus focused only on that and not Hellwig's behavior?
pelagicAustral 29 days ago [-]
You have to be pretty clueless not to understand that Martin's is wrong here, he, and the rest of Rust bozos he clicks with should have been kicked out of the Kernel the minute they started with their social media drama... of course, drama and rust are just bound to be hand in hand.
_fzslm 30 days ago [-]
Definitely interesting to read both sides. I think they both present compelling arguments. There's a need to ensure stability with the kernel and avoid interference with outside forces. I suppose balancing that principle with eventual change is an inevitable difficulty.
busterarm 30 days ago [-]
Up until the point that he tried to leverage social media to get his way in a kernel maintainer dispute? That's just fundamentally not acceptable.
Linus was right to reprimand him for the suggestion.
seba_dos1 30 days ago [-]
I don't think there's "the point" when it was pretty much modus operandi for years.
busterarm 30 days ago [-]
I agree with you, I'm just not personally familiar with their behavior and was trying to be as charitable as possible.
russdill 30 days ago [-]
I've contributed here and there over there years, even got something merged that broke Linus's printer driver. It really isn't unapproachable, frustrating, or demoralizing.
bombcar 29 days ago [-]
You broke Linus’ printer driver and you’re still alive to post? WOW! ;)
nialv7 30 days ago [-]
Looks like @marcan deleted his existence on mastodon? Does anyone have a copy of what he said on there?
ndiddy 30 days ago [-]
The tweet he got called out for on the thread was
"Thinking of literally starting a Linux maintainer hall of shame. Not for public consumption, but to help new kernel contributors know what to expect.
Every experienced kernel submitter has this in their head, maybe it should be finally written down."
dralley 30 days ago [-]
The person who called him out for that made some testy social media comments of her own this morning.
Personally, seeing
> Being toxic on the right side of an argument is still toxic, [...]
written unironically, on social media, immediately after that person wrote @marcan
> and if that then causes you to ragequit, because you can't actually deal with the heat you've been dishing out coming back around the corner: fuck off
leaves me feeling more sympathetic to marcan's argument about the kernel being full of toxic attitudes, not less. Maybe public shaming isn't the answer but there's a problem here. Maybe don't make comments like that on social media if you want to criticize people for leaning on social media in kernel disputes.
ImPostingOnHN 30 days ago [-]
> Maybe don't make comments like that on social media if you want to criticize people for leaning on social media in kernel disputes.
This seems like a tu quoque fallacy. The feedback is either applicable or not, regardless of who said it. They're absolutely correct that Being toxic on the right side of an argument is still toxic.
Even if there is hypocrisy (whether judged by you personally or someone else), it wouldn't invalidate the point.
mort96 30 days ago [-]
I disagree. The behavior of the person who complains about decorum is relevant because it may indicate a double standard in the community. If a community (such as the Linux kernel maintainer community) is ganging up on an outsider using arguments of decorum, it's highly relevant that the already-accepted members of that community themselves act in a way which would've been deemed unacceptable if they were outsiders.
dralley 30 days ago [-]
Of course it doesn't invalidate the point, but it's hard to blame being so exasperated by the incredible hypocrisy that you ragequit at that point.
ImPostingOnHN 30 days ago [-]
I can also see him quitting because he was unhappy with people pointing out the toxicity of some of his posts
WesolyKubeczek 29 days ago [-]
Kind of reminds me of Kenneth Reitz somehow
arp242 30 days ago [-]
> and if that then causes you to ragequit, because you can't actually deal with the heat you've been dishing out coming back around the corner: fuck off
Yeah this isn't about "being civil" or "friendly" and even less about "don't call out". This is about calling out in an ineffective and imprecise way, so that the people actually trying to change things are busy patching up your collateral damage instead of implementing real changes, while all you've achieved is airing your frustration for internet drama points.
When you're that harmful with your calling out, eventually I'm going to be fed up, and you get a live round shot across your bow.
And if that then causes you to ragequit, because you can't actually deal with the heat you've been dishing out coming back around the corner: fuck off.
Or as Dave Airlie put it upthread in this conversation: "Being toxic on the right side of an argument is still toxic, [...]"
So please do call out broken things, do change things, I've been doing it for well over a decade in the linux kernel. But do it in a way that you're not just becoming part of the problem and making it bigger.
---
And this is not the first time something like this has happened with Marcan. He may be tired of the Linux devs, but many of them are also tired with him (including some of the people working on Rust, it seems).
And this is part of a conversation on what went wrong here, not an attempt to rally the troops. You really can't compare it to Marcan's stuff. This kind of (selective) demand for absolute perfection is really not great.
stock_toaster 29 days ago [-]
> Every experienced kernel submitter has this in their head, maybe it should be finally written down
If true, then it sounds like there are some “missing stairs”[1] (the professionally difficult kind, hopefully not the other kind) in Kernel development.
However it seem that you need to disable js as soon as the content load or it will be overwritten by a 404
danieldk 30 days ago [-]
As a follower of him on Mastodon this makes me sad. Hector posted a lot of valuable, very informative toots that I learned a lot from.
renewiltord 29 days ago [-]
Haha it’s funny that this stuff is still going on. The difficulty of getting things into mainline is why Con Kolivas stopped developing his interactivity-prioritizing schedulers for Linux some 20 years ago. It’s just how the project works.
zamadatix 30 days ago [-]
I agree contributing code to the kernel is by no means as approachable or easy going but it's not self-evident that alone is supposed to be the sign of bad things™ unlike more specific examples boiling up to be part of that picture. Are there things and ways I think it could be improved? For sure! I just don't necessarily think they imply the resulting process would be quick and painless.
gary_0 30 days ago [-]
The Rust drama is an uncommon failure of leadership for Torvalds. Instead of decisively saying "no, never" or "yes, make it so," he has consistently equivocated on the Rust issue. Given the crisis of confidence among a sizeable (and very vocal) contingent of the Linux community, that decision has backfired horribly. And it's quite out of character for Linus not to have a blazingly clear opinion. (We all know his stance on C++, for instance.)
As a pilot program, R4L should have graduated or ended a long time ago. After several years of active development, its status remains unclear. Instead of cracking heads to get everyone on the same page, Linus has instead spent all this time sitting back and watching his subordinates fight amongst themselves, only to then place responsibility for the drama on Martin's shoulders. Poor form.
Arguably his reprimand of Martin is a clear signal that he will never show Rust any favor, but he hasn't said anything explicitly. Maybe he knows he should, but he fears the shitstorm it will cause. Maybe it's time for him to rip off the band-aid, though.
And again, all of this could have been avoided if he'd just put his foot down one way or the other. Imagine how much time and energy (even just Martin's alone) could have been saved if Linus had just said "no, keep it downstream".
arp242 30 days ago [-]
> Arguably his reprimand of Martin is a clear signal that he will never show Rust any favor
That doesn't really have anything to do with Rust; but with Hector's behaviour. Threatening a social media campaign to out people is completely toxic behaviour. This is a long-term contributor who is perhaps a bit abrasive, not Jimmy fucking Saville.
Other than that, it's not a binary yes/no question; no one is really against some Rust in some parts of the kernel, but which parts? How? Where? That's the big disagreement. Linus has always been fairly hands-off on these types of disagreements.
e40 30 days ago [-]
> Threatening a social media campaign to out people is completely toxic behaviour. This is a long-term contributor who is perhaps a bit abrasive, not Jimmy fucking Saville.
I'm no where near in the loop on this, but that sounds incredibly toxic. Are there some good links to summarize this?
EDIT:
OK, these are fully enough to allow me to understand the issue.
There seems to be some issue with unaccountable maintainers, and that’s a problem for innovation. If you can’t even get to the point of “technical debate” (we aren’t interested, sorry), then what hope innovation?
These are “people problems”, and there are no easy or good answers, but it doesn’t mean we should through our hands up and consider things “unfixable” either.
mmooss 29 days ago [-]
People should read it:
"... I come at this from the perspective of having worked on Linux since around December of 1991. I first met you and Tove in 1995 at the Free Software Conference at MIT that Stallman sponsored. ...
Probably the last technical contribution of my career is leading an initiative to provide the Linux community a generic security modeling architecture. Not to supplant or replace anything currently being done, but to provide a flexible alternative to the development of alternate and/or customized workload models, particularly in this era of machine learning and modeling.
Four patch series over two years, as of yesterday, not a single line of code ever reviewed. ...
We were meticulous in our submissions to avoid wasting maintainers time. We even waited two months without hearing a word before we sent an inquiry as to the status of one of the submissions. We were told, rather curtly, that anything we sent would likely be ignored if we ever inquired about them.
We tried to engage, perhaps to excess, in technical discussions attempting to explain why and how we chose to implement what we were proposing. ...
There were never any relevant technical exchanges. The discussion consisted of, we have decided to do things a certain way, no discussion, if you don't like that you should really consider doing something other than submitting to upstream Linux."
bonzini 29 days ago [-]
I don't know, dropping 17000 lines of code is probably not the best way to solicit technical discussions
Okay, but how long is reasonable to take to tell someone that their patch is too big to be reviewed?
> We were meticulous in our submissions to avoid wasting maintainers
time. We even waited two months without hearing a word before we sent
an inquiry as to the status of one of the submissions. We were told,
rather curtly, that anything we sent would likely be ignored if we
ever inquired about them.
It's reasonable to ask that people make smaller-sized patches to get reviewed, and it's reasonable to have to rule out some things due to not having the bandwidth for it compared to other priorities, but it's pretty ridiculous to expect people to know that those are the reason their code isn't getting reviewed if they're not allowed to inquire once after two months of radio silence.
vaidhy 29 days ago [-]
Not everything can be broken down into 5 line patches. Some of the bigger features need bigger code. You can look at the impact radius and see if the patch is behind a feature flag to make a decision. In this case, it seems like it is elective and does not have any changes beyond what is self-contained.
macNchz 29 days ago [-]
I don’t follow the Linux kernel development process closely, but on most projects—open source or proprietary—that I’ve been involved in, dropping a big diff without having proposed or discussed anything about it beforehand would have been fairly unwelcome, even if it’s something that would be infeasible to break down smaller. I’d also argue that even quite substantial changes can be made with incremental patches, if you choose to do so.
raverbashing 29 days ago [-]
There had probably been a lot of discussion in the background
The "every change can be a small patch, can be split in such" is part now of the Linux folklore IMHO. As in, a belief that people kinda heard about but nobody has concrete proof
Also do you know what would make it much easier to review long changes? Not using email patches
GitHub issues with "load 450 hidden comments" on it? No threads, no comparisons between multiple submissions of the same patch, changes from rebasing impossible to separate from everything else? Having to drop anyway to the command line to merge a subset that has been reviewed? Encouraging squash merging makes it easier to work with long changes?
Email is complex and bare bones, but GitHub/GitLab reviews are a dumpster fire for anything that isn't trivial.
raverbashing 29 days ago [-]
Try modern/patched versions of Gerrit, I'm sure Linus could tune it to his preference
And I agree, GH has several issues
kashyapc 29 days ago [-]
I've used Gerrit myself for nearly 10 years. I recognize it's strengths and like it for what it does. I also am comfortable with mailing lists and Git Hub and Git Lab. I've lived in "both worlds".
IIUC, the Kernel project doesn't want to use it because of the single-point-of-failure argument and other federation issues. Once the "main" Gerrit instance is down, suddenly it's become a massive liability. This[1] is good context from the kernel.org administrator, Konstantin Ryabitsev:
"From my perspective, there are several camps clashing when it comes to the kernel development model. One is people who are (rightfully) pointing out that using the mailing lists was fine 20 years ago, but the world of software development has vastly moved on to forges.
"The other camp is people who (also rightfully) point out that kernel development has always been decentralized and we should resist all attempts to get ourselves into a position where Linux is dependent on any single Benevolent Entity (Github, Gitlab, LF, kernel.org, etc), because this would give that entity too much political or commercial control or, at the very least, introduce SPoFs. [...]"
That's interesting, but I think the preocupation with SPoF to be overblown
By that measure, kernel.org is a SPoF as well
Maybe we can figure out a way to archive Gerrit discussions
(offtopic note - don't upvote the comment you're responding to while you're commenting as you'll lose your comment)
kashyapc 29 days ago [-]
SPoF is not the only concern. Gerrit search is painful. You can't search the internet for a keyword that you wrote in v10 of some Gerrit patch, unlike on list-based workflows. Also, there's too much point-and-click for my taste, but I lived with it, as that's the tool chosen by that community. It's on me to adapt if I want to participate. (There are some ncurses-based tools, such as "gertty"[1]; but it was not reliable for me—the database crashed when I last tried it five years ago.)
In contrast, I use Mutt for dealing with high-volume email-based projects with thousands of emails. It's blazingly fast, and an absolute delight to use—particularly when you're dealing with lists that run like a fire-hose. It gives a good productivity boost.
I'm not saying, "don't drag me out of my email cave". I'm totally happy to adapt; I did live in "both worlds" :-)
That's a great post, and also the presentation linked there is very interesting and hints at some of the issues (though I disagree with some of the prescriptions there)
Yes, the model is not scaling. Yes the current model is turning people away from contributing
I don't think linux itself is risking extinction, but someday the last person in an IRC channel will turn the lights off and I wonder if then they will think about what could they have done better and why don't people care about finicky buildsystems with liberal use of M4. Probably not.
account42 27 days ago [-]
> There had probably been a lot of discussion in the background
If that were the case then the patch would have a lot more CCs.
f1shy 29 days ago [-]
Then you have to discuss first, before throwing tousands of lines of code at somebody.
f1shy 29 days ago [-]
Totally. And also: the discussion must take place FIRST!
refulgentis 29 days ago [-]
One of the first habits I learned at BigCo was to have a sense of the DAG in any work over 400 lines, so I could make patches arbitrarily large or small. Because whichever I chose, someone would complain eventually
bonzini 29 days ago [-]
Indeed, and that's exactly what the Rust for Linux guys are doing. They have Binder, multiple changes with various degrees of dependency on newer compilers, support for different kinds of drivers, and they are extracting them and sending them to Linux in small bits.
HumblyTossed 29 days ago [-]
17KLoC? Maybe he should consider they’re probably still reviewing it through bloody eyes. But seriously I wouldn’t want to review that much code.
cutemonster 29 days ago [-]
I'd get mildly angry if someone sent a giant patch without having discussed with me first. (Not working with any kernel things) But a quicker "no, don't have time, probably never will" response would have been nice I guess?
tw1984 29 days ago [-]
no feedback whatsoever for 2 months - just because it was 17k lines - and you are blindly defending it? if you don't know what you are posting & talking about, then maybe you shouldn't.
if someone is willing to put in the efforts to submit such a huge patch, how about just show them a little bit respect, I mean the minimum amount of respect, for such efforts and send them a one line reply asking them to break the patch into smaller ones.
surely that won't take more than 45 seconds. still too hard to get the point?
bonzini 29 days ago [-]
> if you don't know what you are posting & talking about, then maybe you shouldn't
I hate to appeal to authority, but I have been working with large cathedral-style open source projects (mostly three: GCC, QEMU, Linux itself) for about 20 years at this time and have been a maintainer for a Linux subsystem for 12. So I do know what I am posting and talking about.
The very fact that I had never learned about this subsystem from LWN, Linux Plumbers Conference, Linux Security Summit etc. means that the problem is not technical and is not with the maintainers not replying it.
A previous submission (7000 lines) did have some replies from the maintainers. Apparently instead of simplifying the submission it ballooned into something 150% larger. At some point I am not sure what the maintainers could do except ignoring it.
chacham15 29 days ago [-]
> At some point I am not sure what the maintainers could do except ignoring it.
Ignoring people is a childs approach to communication. If there is a problem, its your responsibility to communicate it. If you have communicated the issue and the other party is refusing to hear it, that is a different issue, but it is your responsibility to communicate.
bonzini 29 days ago [-]
Yes, as I wrote they had communicated it before. (BTW of course it's bazaar not cathedral... Brain fart for me).
Lerc 29 days ago [-]
Surely if there were insufficient established context for a reviewer to easily follow a large patch the correct response would be a swift rejection with a request that such context be established prior to submitting again.
It sounds like there was willingness to meet any requirements, but submitters end up in a position of not knowing what the requirements are and if they have met them or not.
bonzini 29 days ago [-]
It's very easy to develop tunnel vision when working remotely with people you've not even ever met. It's happened to me multiple times and there's a very high chance that this is happening here.
Important to note that Ted is extremely anti-Rust and literally shouted down someone irl that was doing a presentation on Rust in the Linux kernel.
HereIGoAgain 29 days ago [-]
The short of his rant is that he wants a "Code Of Standards for maintainers" in addition to a CoC, in order to witch hunt people he feels "gets in the way."
Yikes, this is EXACTLY what Linus was talking about except an order of magnitude worse!
fl0id 29 days ago [-]
No. He just wants people to have some decency and standards in communication and not arbitrarily decide that their little kingdom can never be touched.
seivan 28 days ago [-]
[dead]
lll-o-lll 29 days ago [-]
> The short of his rant…
This does not read as a rant at all to me. Rather it seeks to highlight a problem using an example from his own work and proposes a possible solution (with a previous caveat of “I don’t know how to fix this”).
> "Code Of Standards for maintainers" in addition to a CoC
He wants maintainers to behave in some pre-determined understandable fashion. He wants some accountability, and that seems reasonable to me. This is not a “maintainers must do what I want”, this is “let’s set basic expectations” and ensure people follow them. Whatever those should be.
> in order to witch hunt people he feels "gets in the way."
B does not follow A. You are simply straw-manning here, so I have nothing to say to it other than it’s a fallacious point.
robertlagrant 29 days ago [-]
> This is not a “maintainers must do what I want”, this is “let’s set basic expectations” and ensure people follow them. Whatever those should be.
But presumably it's not whatever they should be. It's what he wants them to be. And what should happen if they're not followed?
rincebrain 29 days ago [-]
His complaint is, in essence, that people will block technical proposals for nontechnical reasons, and that attempts to resolve this result in people complaining that you're talking about nontechnical things at all.
Few people like dealing with interpersonal conflict. They want to think that technical meritocracy wins the arguments.
But in that discussion, a maintainer said "I am going to try to sabotage this because I hate it.", and there's no technical argument to resolve that. And there's not really any route other than escalation to some kind of authority if there's not a common negotiation baseline.
"You can't reason someone out of a position they weren't reasoned into."
IntelMiner 28 days ago [-]
>in order to witch hunt people he feels "gets in the way."
When has this ever happened with the Linux CoC? The only people who I've seen banging pots and pans together about the CoC are folks who like to sealion [1]
There are easy and good answers, just none that every single one would agree with, and that is the problem.
The current management model is based on consensus in some parts, and a dictatorship in others. Its not clear which parts are which because of sprawl, and non-responsiveness.
This is a core communication people issue. The problems arise because in consensus models, people are expected to adopt archetypical roles based somewhat on preference, but mostly on the needs of the group, towards productivity.
If no one else is doing that type of role, someone will be forced into doing it, and will adopt characteristics of that role, regardless of their personal opinions about it.
When they get punished for fulfilling the role, you lose people.
> doesn't mean we should throw our hands up and consider things "unfixable" either.
The given structure is unfixable, because it sets the stage for a trauma loop where actions can't take place without people who are expected to fulfill a role to meet consensus, but in doing so they get punished for volunteering.
There is no way around this structure so long as you use a consensus model in whole or part, in dysfunctional groups the people involved either fail to communicate or worse there are members that impose coercive cost by assuming the unproductive roles so no action happens while resources are wasted.
This really is basic stuff covered in your college level intro to communications coursework.
For those wanting to know more about this, you can read more about the roles at the link below.
I think "Code of Civility" is what Dr. G was describing. Conduct presupposes civility, but acceptable online discourse has changed amongst new internet natives raised in the era of moral totalitarianism, aggression as a service, and popular outrage incubators.
hitekker 29 days ago [-]
Looks like Dr Greg (not Greg KH) is just piling his own personal grievance on top of the drama. Saying "Jim are you listening?" makes me wonder who he's sniping at.
Speaking as an actual People Manager, his ideas sound pretty shallow.
the-smug-one 29 days ago [-]
I'm not a "People Manager" -- what is shallow about the ideas?
bonzini 29 days ago [-]
Maybe Jim Zemlin, who is the executive director of the Linux Foundation and has nothing to do with Linux.
CRConrad 26 days ago [-]
> Jim Zemlin, who is the executive director of the Linux Foundation and has nothing to do with Linux.
That sounds... Not good. Seems like like this is exactly what's wrong with... Well, not just this, but much of the "FOSS" world. (Maybe about since "Free Software" became "Open Source"?)
throwaway2037 29 days ago [-]
This part is wild. Some people get in so deep they cannot see the forest from the trees.
> there is the tangible risk of stifling innovation and Linux is the only place that innovation can occur in the operating system space.
One thing I know: HN loves drama, and this stuff reads like first class drama.
markhahn 29 days ago [-]
The proponents think the value of their "innovation" is obvious, but it is not.
Is it innovative? Is it valuable? Is it worth the cost? Who is it valuable to?
I don't see why the kernel team should be obligated to react in any particular way to a random submission.
This is a recurring pattern I see with drama in some open source communities, where people measure others using yardsticks they themselves don't live up to. People can't post stuff like this while accusing everyone in the vicinity except themselves of bad behavior. Choose one.
account42 27 days ago [-]
Yikes, at great example of how not all thoughts that pop into your head should be publicised.
CRConrad 26 days ago [-]
Hm, good thing I'm not a Linux maintainer. 'Coz that first C in my username... (My given name is the only thing about me that has anything to do with "Christ".)
Basically, there is concern that even with a declaration that Rust-for-Linux devs will maintain this (and potentially every other) cross-language API translation layer file, the demarcation point between C and Rust isn't sufficient, and is causing C developers lag or headaches by having PRs rejected because of Rust-side failures. I don't see how that can be fixed without wholesale buy-in to Rust of enough kernel devs that they can fix whatever Rust problems are created by C API changes. Or Linus will have to accept PRs that break Rust-enabled builds. The R4L devs, by themselves, don't have the bandwidth to keep up. Even if they can rapidly fix problems, that adds potential friction to every C API change.
Hellwig may not be communicating in a good way, but he might be right, unfortunately. Linux may need to stay as a C-only codebase until an AI language-translation tool is good enough to do things like maintain the Rust API translation layer itself. Or until basically all maintainers learn and accept Rust.
> Then I think we need a clear statement from Linus how he will be working. If he is build testing rust or not.
> Without that I don't think the Rust team should be saying "any changes on the C side rests entirely on the Rust side's shoulders".
> It is clearly not the process if Linus is build testing rust and rejecting PRs that fail to build.
The matter and the question at heart is still unsettled. The answer of whether or not Rust being in a broken state is a blocker for working and valid C code will hopefully be addressed by the end of this cycle of development. Either the patches are accepted and Rust is truly allowed to be broken or the patches will not be accepted due to breaking the Rust builds. If it is the latter, as many of the C developers fear, that is the exact burden being placed upon them that they have been stressing very loudly that they have no interest in taking on. And once other maintainers see this, what is the inevitable response to this metastasization? Comments like those from Ted and Christoph will pale in comparison. The only bright side might be that this finally accelerates the inevitable demise of this failed Rust experiment so that all parties can move on with their business.
steveklabnik 29 days ago [-]
Let's say that we both agree that Linus should be making clear statements here, and that lack of clarity is causing lots of problems.
That one bug happened one time does not mean that the promise is broken. To be clear, it's a bad thing, but acting like this means the entire working rules are a lie is overreacting.
rc00 29 days ago [-]
> That one bug happened one time does not mean that the promise is broken.
It's not been once. Don't you understand that is why things have gotten to this point? Are you aware of how the developers have been using Coccinelle in their workflows and how many subsystems support it? And are you aware that the Coccinelle for Rust implementation is constantly in a dire state? Have some empathy for the folks who have had their workflows broken and burdens increased because of it.
> Let's say that we both agree that Linus should be making clear statements here, and that lack of clarity is causing lots of problems.
Clarity will be communicated by the result of this patch set.
jorvi 28 days ago [-]
> Have some empathy for the folks who have had their workflows broken and burdens increased because of it.
Okay. Will you show empathy to the R4L folks constantly having sand poured into their fuel tank by kernel maintainers?
CRConrad 26 days ago [-]
> Will you show empathy to the R4L folks constantly having sand poured into their fuel tank by kernel maintainers?
But the thing is, the kernel isn't "the R4L folks"' "fuel tank", is it? Doesn't the very name you use, "kernel maintainers", tell you that that's their "fuel tank"? Seems the people pouring sand into that are "the R4L folks".
harshreality 28 days ago [-]
Kernel maintainers aren't doing anything to R4L folks except where their activities intersect with the upstream linux kernel. Your analogy isn't right.
R4L folks thought that preliminary R4L infrastructure being accepted upstream meant that all the changes they needed in the future would be accepted easily as well, and now that there are concerns from subsystem maintainers, a few R4L folks are playing the dramatic victim card.
From what I understand, market pressures are causing R4L folks to panic. If they can't get more R4L stuff upstream, people can't ship Rust drivers, and R4L development falls apart.
That's not kernel maintainers' problem, though. They have a job to do to, and it has nothing to do with Rust kernel drivers except as far as they're persuaded Rust drivers help the linux community overall and will be maintainable without unacceptably disrupting their tool-assisted workflows. Several of them have concluded, so far, that R4L PRs will unacceptably disrupt existing workflows.
That's where R4L has failed. They've failed to persuade subsystem maintainers that some added headaches/retooling/efficiency-loss is worth it to enable Rust drivers. Which drivers, and who wants to use them? Perhaps the potential downstream users of those drivers can talk with kernel devs, persuade them it's really valuable, and figure out a plan?
jorvi 27 days ago [-]
> a few R4L folks are playing the dramatic victim card.
Not just 'a few R4L folks', these are basically the spearhead of the effort. And it hasn't been a single occurrence, we now have seen two of those Rust developers resign from the effort out of pure frustration from the entrenched, heels-in-the-sand attitude from kernel maintainers.
The same thing has happened in the past. I will point to TuxOnIce, which got stonewalled by a stubborn maintainer. It would have moved most suspend and hibernation code to userspace, where it would have been easier to maintain and iterate. Or right now we have two divergent RAM compression paths (Zram and Zswap). There are patches for Zram to use the unified Zpool API, but the Zram maintainer refuses to integrate these for absolutely no solid technical reason.
It seems that the R4L peoples are fine with doing any effort required, as long as they know it is not in vain. So far, comments akin to "language barriers in the kernel are a cancer" and "I will do everything to prevent/sabotage this" do not exactly build trust in that regard.
As an aside, would it really be so horrible for kernel maintainers to learn (some) Rust? This is not a dire ask for someone in the software world, your job will often ask this of you. And I can't imagine the maintainers haven't ever dabbled in other languages and/or aren't capable enough to learn a second language.
I understand the fear that saying "ok, we can do more languages than one" opens up the door to a third and fourth language down the road, but that seems unlikely. There's a reason Rust has passed Linus' sniff test where no other language has so far.
> Which drivers, and who wants to use them?
Short term it seems mostly GPU drivers.
Long, looong term (multiple decades?) the plan is probably to rewrite more important parts of the kernel, to significantly increase memory safety.
account42 27 days ago [-]
> language barriers in the kernel are a cancer
Well they are. Second class citizens like this just cause problems.
> As an aside, would it really be so horrible for kernel maintainers to learn (some) Rust?
Are the Rust folks planning to pay the existing kernel developers for spending that time? Because otherwise it should be up to those existing maintainers to decide and not something anyone else gets to demand.
Overall this just sounds like people crying that their hostile takeover of an existing project is being met with resistance.
CRConrad 25 days ago [-]
> > a few R4L folks are playing the dramatic victim card.
> Not just 'a few R4L folks', these are basically the spearhead of the effort.
A "spearhead" is by definition a few people.
> As an aside, would it really be so horrible for kernel maintainers to learn (some) Rust?
If they want to contribute to the Linux kernel, would it really be so horrible for these Rust programmers to learn the language the kernel is written in?
> There's a reason Rust has passed Linus' sniff test where no other language has so far.
Doesn't seem it has, really.
> the plan is probably to rewrite more important parts of the kernel
So just fork it and rewrite it all in Rust.
account42 27 days ago [-]
No, because they are the once choosing to add this complexity to an existing project because of their own interests/ideals.
jorvi 27 days ago [-]
Calling memory safety an 'ideal' is like calling back-ups an 'ideal'. You can cast it off as a "nice to have", until you get bitten in the ass by a lack of it.
CRConrad 26 days ago [-]
To quote myself[1]: I don't get why those Rustafaris do this in the first place. Like, if you want to contribute to a piece of software written in C, then write your contributions in C. If, on the other hand, you want a Linux kernel in Rust... Then just fork it and rewrite it in Rust. It's not as if that were a new idea, is it? Heck, most days it feels like about half the top headlines here are “<Software X> rewritten in Rust!” So why don't they just do that in stead of this constant drama???
I'm not sure this is fundamentally different from e.g. a complex filesystem implementation relying on a specific MM or VFS or whatever API, and a "C developer" wanting to change that API. Just because the callers are in C doesn't necessarily make the global change easy.
rdtsc 29 days ago [-]
> If shaming on social media does not work, then tell me what does, because I'm out of ideas.
That's just manipulative. Maybe it's just a moment of frustration and they'd take it back eventually, but blackmailing people with social drama is not cool. That's what X and Reddit is for.
> Rust folks: Please don't waste your time and mental cycles on drama like
this [...] they know they're going to be on the losing side of history sooner or
later.
That sounds very cult-like, doesn't it?
darthrupert 29 days ago [-]
Threatening with social media seems to me like a professional suicide, especially when it's followed by a doubling down and a complete lack of anything resembling an apology.
I'm amazed that Hector is doing this fully in public using his real name.
29 days ago [-]
Aeolun 29 days ago [-]
It’s true though? I don’t see anyone picking C/C++ over Rust/Go in my immediate environment.
That might reflect my environment, but all of the things I’d consider C variations for I’d use Rust for as well…
59nadir 29 days ago [-]
It's definitely your environment, Rust isn't nearly as popular for actual projects getting done as it is in (for example) StackOverflow's survey. C, C++, Odin and Zig are all languages where whatever C knowledge you have right now can trivially be put to use to do things, immediately, I think it makes perfect sense that unless someone is just really into doing Rust things they'll just take the trivially applicable ways of working and use the aforementioned languages (which all have much better support for batch memory management and custom allocators than Rust, it should be added).
baranul 29 days ago [-]
There are a lot of C programmers who do not like or are not fond of Zig or Odin. For highly proficient C and C++ programmers, many consider them not worth their time. Not even counting, that both Zig and Odin are in beta. It's an investment to become as proficient in the other language.
An example is Muratori from handmade hero, who publicly stated he dislikes Zig and pretty much sees it as a confused mess[1]. He thinks Odin is kind of OK, because it has metaprogramming (which other languages do too), but is way below Jai. Between Jai and Odin, he thought Jai was the one with potential and could get him to switch/use. Odin's slight popularity, as a kind of Jai-lite, is often attributed to Jai being a closed beta. But, it appears that might change soon (Jai going public or opening up beta use more), along with an upcoming book on Jai.
Programming languages like Go and V (Vlang), have more of a use case for new programmers and general-purpose, because they are easier to learn and use. That was the point of their creation.
I would suggest linking to a timestamped point in the video instead of the entire thing. With regards to Odin having metaprogramming this is either a misunderstanding on your part of what was said or a misunderstanding from Casey Muratori with regards to Odin; Zig has a much stronger claim to having metaprogramming with `comptime` being as powerful as it is, whereas Odin only scarcely can be said to have a limited "static if" in the `when` keyword, plus your average parametric polymorphism via template parameters.
C programmers (and C++ programmers) who don't like Zig or Odin can simply use C (or C++), it's not really the case that they have to switch to anything, much less something as overwrought as Rust. My point is that it is natural for someone who is at any proficiency level above 0 in C to want to apply that proficiency in something that allows them to make use of those skills, and C, C++, Odin and Zig all allow them to do that, pretty much immediately.
You contend that "It's an investment to become as proficient in the other language" but I would argue that this is a very wide spectrum where Rust falls somewhere in the distance as opposed to all of the languages I mentioned instead being far closer and more immediately familiar.
baranul 29 days ago [-]
True that Odin is admittedly quite limited in that area. Muratori made the case that Jai was far beyond both Zig and Odin, thus recommending its use and what made it attractive for him. The other issue, is investing in languages that are in beta.
The counter, in regards to "any proficiency above 0", is there are other alternative languages (that are easier to learn and use) where knowledge of C can be put to immediate use too. Getting up to speed in those languages, would likely be much faster, if not more productive for less proficient or experienced programmers.
59nadir 29 days ago [-]
> The other issue, is investing in languages that are in beta.
I work full time with Odin and I wouldn't put too much stress on this point as I've found that whatever issues we have with Odin are simply issues you'd have with C for the most part, i.e. C knowledge will help solve it. It's not a complex language, it doesn't need to do much and language-specific issues are few and far between because of it. Tooling is a bit of a mixed bag but it's about 80% solved as far as we're concerned.
Odin day-to-day for working on 3D engines (which I do) is not beta quality, whatever that means. I would rate it a better net fit for that purpose than I would C++, and I wrote the kind of C++ you would write for engine work for about 10-11 years (at least what we knew to be that kind of C++ at around 2001). For server software I'd rate it worse, but this is mostly because there are a few missing FFI wrappers for things that usually come up, it's not really because of the language per se.
As for Jai, I can't claim to know much of anything about it because I've never used it, and I wouldn't take many peoples' word for much of anything about the language. As far as I'm concerned Jai will exist when it's publicly available and until then it's basically irrelevant. This is not to disparage the effort, but a language is really only relevant to talk about once anyone with motivation and an idea can sit down, download/procure it and use it to build something, which is not the case with Jai.
jorvi 28 days ago [-]
> It's not a complex language
You cannot claim this when even codebases with veteran C developers will be virtually guaranteed to have memory safety issues at some point.
59nadir 28 days ago [-]
My comment was addressing the idea that Odin is a "beta language" in comparison to C and my assertion was that the issues we have with using Odin are the same ones you'd have with C. So assuming that you have accepted C-style issues, then Odin really does not present many or common additional roadblocks despite being relatively young.
Also, I know this may shock a lot of people who don't regularly use sharp tools: The possibility (and even occurrence) of memory safety issues and memory corruption doesn't tank a project, or make it more costly than if you'd used a GC, or Rust. Memory bugs range from very easily avoided and solved to surprising and very, very hard to solve.
jorvi 28 days ago [-]
> The possibility (and even occurrence) of memory safety issues and memory corruption doesn't tank a project, or make it more costly than if you'd used a GC, or Rust. Memory bugs range from very easily avoided and solved to surprising and very, very hard to solve.
I never said this. The Linux kernel and any other project will thrive with or without Rust. But it is a certainty that the higher the ratio of C-to-Rust in the world (or well, any memory-safe systems language), the higher the amount of CVEs we will see. It would seem reasonable to me to assume that we want as few CVEs as possible.
To be honest, I also don't understand the dogmatic stance a lot of C developers have against Rust. Yes, it does cause some friction to learn a new language. But many of the correct idioms Rust enforces are things you should be doing in C anyway, its just that the compiler is a lot more strict instead of just nagging you, or not even nagging at all.
29 days ago [-]
29 days ago [-]
rdtsc 29 days ago [-]
I meant the whole “we are on the right side of history” and if you’re not with us you’re against us and we’ll wage a public drama campaign against you.
uecker 29 days ago [-]
Exactly.
markhahn 29 days ago [-]
Brings to mind certain world figures who have normalized this kind of petulance (which is bullying when real power is involved).
account42 27 days ago [-]
> in my immediate environment
Social bubbles can work like that.
a3p 29 days ago [-]
When i was the focus of the rust community, and trending #1 on HN, i simply deleted my repos and disappeared.
Some people in that community reflexively see a conspiracy or invoke the CoC or use whatever other non technical tools they find to derail the discussion.
It's not even that they're always wrong or that I directly oppose the culture they want to have, but the shotgun blast of drama that this comes with is just so much effort to navigate that i decided to just never contribute to rust again.
KennyBlanken 29 days ago [-]
[flagged]
soraminazuki 29 days ago [-]
The dirty laundry of the entire kernel community not immediately knuckling under and implementing a rather long list of technical changes in the preferred way of one specific individual? That's an unreasonable take. It would be disastrous for all of us if the project ever went that way, considering the importance of Linux today. It's not like I disagree with some of the points that Marcan raised, but others have equally valid concerns as well. However, he wants to get discussion and compromise out the window and go straight to social media drama. That's never okay.
And please, stop using the concept of ad hominems to selectively justify blatant abuse. That's not what the term is about.
jorvi 28 days ago [-]
> straight to social media drama.
It was a move of frustration due to having exhausted all other avenues. It wasn't his first action.
account42 27 days ago [-]
Things not moving as fast as he wants isn't the same as having exhausted all other avenues.
serf 29 days ago [-]
.. or it could just be that 'the public' has little to add to kernel development other than social landmines that the kernel teams have to navigate in order to achieve technical work..
agoodusername63 30 days ago [-]
I'm usually very critical of how Torvolds treats the people around him and the culture he maintains but this is a rare case when I'm not really against Torvalds on this.
I've had to remove Hector's postings from my feeds because he just constantly bitches and complains about pretty much everything. He's capable, smart, and is doing more than anybody ever will for Apple hardware. But he desperately needs to Stop Posting. Without anybody he works with regularly to give him a reality check, I don't think he's going to change course.
I think Hector has some valid complaints about the contribution process to the kernel, I know. It fucking sucks ass and I've given up on trying. But screaming the way he does is counter productive to improving it
xenago 30 days ago [-]
I feel the exact same. Marcan has done amazing work, and his random blog entries etc have saved me hours of debugging time in the past. But jeez, it is really painful to see him say absolute nonsense like "If shaming on social media does not work, then tell me what does, because I'm out of ideas." - he has gotta Stop Posting and keep those kinds of thoughts away from his keyboard.
hajile 29 days ago [-]
If Linus thinks that the social media angle is wrong, he should defuse situations before they become explosive because even if one of the devs didn't bring up the drama, there are dozens of news companies that would have printed up articles the second they found the discussion anyway.
Linus should have stepped in long before a maintainer blew their stack and started throwing out ultimatums. Once that happened, Linus could have still stopped everything with one sentence -- "Let me look into this.", but he did not.
Linus only got an opinion once things blew up on social media which proves that social media works which is the exact opposite of what he says he wants (and will just encourage more of the same).
ferfumarma 29 days ago [-]
> Linus only got an opinion once things blew up on social media which proves that social media works which is the exact opposite of what he claims.
That is really an apt point. You can't condition people one way, and tell them to do the opposite.
bigiain 29 days ago [-]
And it's not _that_ long ago since Linus was King of the arrogant and rude flame posts on what's effectively hos own "social media", the linux kernel mailing list.
10 years back, Linus _was_ "that guy". And it worked, extremely effectively, if you measure success by the ability to stamp on someone else's technical contribution by ridiculing them in public instead of making a convincing technical defense of his position in the discussion.
You can expect professionals to not act like trained monkeys.
chikere232 29 days ago [-]
Well... the maintainer also shouldn't blow their stack
You can certainly imagine ways an authority figure could have defused a situation of a maintainer blowing their stack, but your framing kinda absolves the maintainer of any accountability for their actions.
A team member who needs a lot of defusing is doing something wrong, and needs to learn how to defuse themselves.
CountHackulus 29 days ago [-]
What happens when Linus retires (or god forbid dies)? He can't defuse those situations forever, there needs to be some sort of process.
tsimionescu 29 days ago [-]
Someone will have to take over Linus' role. There's no way that kernel development can work without a person in charge, at least not in anyway that is remotely similar to today.
adastra22 29 days ago [-]
Not being remotely similar to today could be a very good thing.
robertlagrant 29 days ago [-]
If you can point to a better model of a more successful kernel that would be interesting to read about.
adastra22 29 days ago [-]
FreeBSD? But there is nothing fundamentally different in open-source project management between a kernel and any other large open-source project. The linux code base is the largest, but not by a large margin. Chrome, GCC, OpenOffice, Android (excluding the linux part obvs.), and the various BSDs are all comparable in scope, complexity, lines of code, and number of contributors. Only linux is (in)famous for having a toxic and unproductive culture.
markhahn 29 days ago [-]
Odd. Linux is by far the most/largest/longest successful project. Or do you have a counterexample?
adastra22 29 days ago [-]
I assume we're only comparing to operating systems, as I would say that e.g. Chrome as an open-source project is just as impactful if not more so. But generally speaking the Linux support experience is decidedly worse than *BSD or any proprietary OS. It is much harder to get patches upstreamed, and many hardware have errata that never get fixed. (If you haven't experienced this, it might be because companies like canonical and red hat maintain their own patches to support their customers.)
account42 27 days ago [-]
> But generally speaking the Linux support experience is decidedly worse than *BSD or any proprietary OS.
Going to have to disagree on that one.
account42 27 days ago [-]
Good for who? External parties that want to force their vision of what the project should be?
rincebrain 29 days ago [-]
Linus, as someone far removed from LKML, seems like he hates external visibility of what he wants to be effectively "internal" discussion more than anything else.
Not in the sense of "he wants the mailing lists private", but in the sense that "he doesn't want public complaint about private discussions", which feels like an evolution of "technical merit should win", as a position.
tacker2000 28 days ago [-]
I dont think Linus gives a damn about any social media drama. Why should he care?
29 days ago [-]
josephg 29 days ago [-]
It just ("just") sounds like he's out of alignment with the kernel development process.
That shouldn't be too surprising - I mean, its an old project with a whole lot of technical baggage. Projects tend to slow down over time. And that is legitimately really frustrating when you want to shake things up or push for change. I would be rubbish as a linux kernel developer. I have the wrong temperament for it.
There's a reason why some tech companies interview for both technical skill and culture fit. Sounds like he's got the technical chops, but he's not a good fit for linux.
And when you're in a situation like that, your choices are essentially Voice or Exit. Voice is to do what he's tried to do - kick up a fuss about the problems to try and get them fixed. Thats a skill on its own - and it sounds like he's not been super effective at that. The other option is Exit. Which of course - sensibly, he's now done.
> he has gotta Stop Posting and keep those kinds of thoughts away from his keyboard.
Nah. Bottling this stuff up is a bad long term play. You end up getting bitter, cynical and resentful. I think we've all worked with people like that, and its miserable - both for the person and for their coworkers. I think its better to shoot your shot. Even if you miss - as he has here - you learn a lot about yourself and the world. And there's no shortage of interesting projects out there to work on. Pick something that matches your speed.
bigiain 29 days ago [-]
> some tech companies interview for both technical skill and culture fit. Sounds like he's got the technical chops, but he's not a good fit for linux.
You're right.
To fit with historical "linux culture" he needs to be much more aggressive and rude.
He needed to lead with something more inline with linux project leadership's examples, perhaps something like: Christoph " ... should be retroactively aborted. Who the f*ck does idiotic things like that? How did they noty die as babies, considering that they were likely too stupid to find a tit to suck on?"
Yeah, reading these back in 2025 it's amazing Linux got as far as it did with Linus being like this for a long time.
Aeolun 29 days ago [-]
But this is just frustration coming out. I don’t think for a moment he expected shaming on social media to work.
preisschild 29 days ago [-]
But it did work. Linus actually got involved because of it...
chikere232 29 days ago [-]
If we were dealing with a toddler, one could blame the parent for rewarding their misbehaviour attention... an adult developer not so much
noobermin 29 days ago [-]
I've said this before, but the rust community really seems to attract the most toxic and drama-thumping types as their icons. I'm not really sure why such types are drawn to it.
dralley 29 days ago [-]
This is profoundly silly.
First of all because we're talking about the kernel community here, which was incredibly toxic and dramatic long before Rust even existed. Linus has chilled out in the past few years but that legacy isn't entirely gone.
C++ drama has nearly come to fistfights at conferences, and the only reason that doesn't get talked about more is that the toxicity stays mostly on private (not public) mailing lists as a result of the more insular nature of that ecosystem. Nowadays you have a lot of people just quitting over things like the fact that a member of the standard committee was convicted on CSAM charges.
There are plenty of "C supremacists" in the tech influencer community and the maintainer mailing list of every distribution.
And streamers like PrimeTime that eagerly jump on every opportunity to shit on Rust and actively dump gasoline on every flareup of drama for ad revenue.
In general, programmers seem to love being elitist about languages and tools. Remember how everyone used to dump on PHP constantly?
uecker 29 days ago [-]
Discussions on the internet often were dramatic. There are certainly also many "C supremacists", but I don't generally see C people coming to C++ or Rust projects and insisting that it should be rewritten in C because "C is better". I believe C is a better language myself and definitely much better than how it is currently perceived, but I do not mind if other people have a different opinion and do projects using other languages. While the mindset of many C++ and Rust proponents seems to be that "C has to die", so is inherently much more hostile. This makes it then sometimes difficult to ignore this completely.
tinco 29 days ago [-]
I'm a Rust coder who also occasionally watches Prime, and I've never seen Prime casually pour gasoline on fires. Yes his whole business model is reacting to whatever content is hot right now, but he always does so in a considerate and non inflammatory manner.
He's not a fan of Rust for totally legitimate reasons.
throwaway2037 29 days ago [-]
If not Rust, what does he prefer? Zig?
tinco 29 days ago [-]
Yeah, mostly Golang and Zig I think.
baranul 29 days ago [-]
He is apparently mostly a Golang guy, and has stated he would play around/experiment with Zig. However, this was against the advice of Muratori (who does not like Zig), and suggested Jai (preferred choice) or Odin.
Aurornis 29 days ago [-]
My experience with Rust and people who use Rust has actually been great.
There seems to be an entire second world of “Rust community” and Rust zealots online who are heavy on the drama, though. It really does feel like an alternate Rust universe.
Although when I think about it, several of my other interests and hobbies are exactly like this. Great in the real world, but as soon as you step into certain online spaces it’s drama and toxicity.
In this specific case, I think this is more about kernel drama than Rust drama.
imtringued 29 days ago [-]
I don't think that's true. I think the C guys told themselves that writing safe C code is just a matter of skill, but data shows that the amount of skill necessary to avoid writing unsafe C just isn't there. The average C developer isn't as competent as they claim.
You can lie to yourself and say that the same security problems exist in other languages, but that isn't true.
When I check the vulnerabilities marked as HIGH on a JVM based project, it's often banal stuff like a denial of service in Spring. The consequences of an attack are a few days of downtime until we patch the library, but the truth is that while downtime on our application might be profitable for a competitor, it's not profitable for a black hat hacker working alone. They can't blackmail us, because we can update the library without paying them to stop.
Meanwhile the average C vulnerability is usually some form of RCE that would let the hacker install ransomware.
Eggpants 29 days ago [-]
Rust is sadly more about marketing than actually being popular or safe.
That stackoverflow survey rust folks so proudly crow about shows it’s the #1 ‘admired’ language, well #2 was closure and Zig over the years which clearly shows the value of the survey. Just marketing slop.
The rust produces safe code claim is also marketing garbage. The rust standard library has over 7.5k (of 35k) unsafe functions in it. The core library has 7K (of 21k) unsafe functions. So any Rust program that claims not to have “unsafe” code is most likely not true since any program that doesn’t use the standard library is a toy.
The rust community unearned arrogance is only surpassed by the Haskel folks. It’s breathtaking. Yes yes not all in the rust community are like this, but the social media amplified squeaky wheels one sure are loud.
> To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code.
That was 2022. I am aware of at least one security bug in their Rust code, but it wasn't a memory safety issue. I'll be interested to see what they say when they post updated numbers.
jodrellblank 29 days ago [-]
> "The rust produces safe code claim is also marketing garbage. The rust standard library has over 7.5k (of 35k) unsafe functions in it. The core library has 7K (of 21k) unsafe functions."
"it’s important to understand that unsafe doesn’t turn off the borrow checker or disable any other of Rust’s safety checks"[1]. Using the Rust keyword 'unsafe' doesn't make the code inside it the Wild West or automatically an exploit or a problem, it is a limited-scope relaxing of only some checks.
> The rust produces safe code claim is also marketing garbage. The rust standard library has over 7.5k (of 35k) unsafe functions in it. The core library has 7K (of 21k) unsafe functions. So any Rust program that claims not to have “unsafe” code is most likely not true since any program that doesn’t use the standard library is a toy.
Why does any of that imply that Rust doesn't produce safe code? There's no argument here - just some numbers and unjustified conclusions.
ivell 29 days ago [-]
Java also had its share of remote code execution attacks. Security is quite complex domain and it is not just memory overwrites that can allow RCE attacks. Though I can agree that in average C/C++ is more vulnerable.
gmokki 29 days ago [-]
Most CVEs for Java are about untrusted code escaping the sandbox. No one is saying JavaScript is a bad language for server side development despite browser sandboxes constantly leaking.
Yes, there was a popular logger library that was written badly that tried to interpret log messages as potential source for fetching code dynamically from remote locations. Something that was thought to be the future 25 years ago, but had mostly been abandoned in all modern code.
uecker 29 days ago [-]
I think already phrasing it like this "the C guys" is inflammatory and not helpful. The C community is huge and there is also a large part interested in more secure programming. Also the idea that tall C code is hopelessly unsafe while all Rust code is perfectly memory safe are both far from the truth. In reality, you can make C code quite good and you make Rust code very unsafe. While Rust certainly has some advantage, this is not as black-and-white as the Rust marketing wants you to believe. But this fuels the "C must die" and "we are on the right side of history and if you can not see this, you are an enemy" lines of thinking some people have.
account42 27 days ago [-]
It also doesn't help that the Rust comes with more than just the safty changes. The expectations for development models, distribution models, backwards compatibility guarantees not to mention the cultural aspects are very different which is the real reason it causes so many clashes.
It get pushed with the argument for better memory safety but then wants to change the entire world as well.
rednafi 29 days ago [-]
This.
From shaming everything else as either slow or unsafe to rewrite the universe, the Rust community makes it hard for new comers to consider the language by its merit.
But the good thing is, the hype has settled down and Rust has found its niche. It’s not tackling Go or Python anytime soon and competes in a different plane.
Zig is another great alternative for someone like me who never found Rust a pleasant language to work with.
cute_boi 29 days ago [-]
This is not because of Rust, but C.
chikere232 29 days ago [-]
Any trending language will attract some not so great people who make their choice of a shiny language their whole personality. It's really a pity for rust to be in that position now, as those people are there for the feeling of superiority and will cause drama to get it
If rust ends up being mainstream successful, those people will move on to something else and start attacking rust for whatever they feel their new language is superior in
Someone should have hugged them when they were kids
tw1984 29 days ago [-]
[flagged]
chikere232 29 days ago [-]
I haven't seen that as much. The horde of people chasing the hype curve left C behind long ago. When they leave rust, rust will be better off
tw1984 29 days ago [-]
I don't care as I don't use rust. I learned and played with it, it is just horrible. I use Python, Golang and C almost everyday for living and fun!
Just hate the fact that quite often people get judged or even treated differently just based on the languages they choose to use. It is just a tool, nothing different from a screwdriver.
p0nce 29 days ago [-]
This is unfortunately my take with almost every interaction I had with the Rust community. Expressing any diverging opinion is enough to get ostracized.
efnx 29 days ago [-]
Who are these icons?
Ar-Curunir 29 days ago [-]
[flagged]
llm_trw 29 days ago [-]
If you don't want to use C perhaps you shouldn't contribute to a 33 year old project written in C?
dragonelite 29 days ago [-]
It sounds so simple, I don't get it why the Rust people don't write their own operating system or bundle their human capital to such a project.
They have been trying for years now to integrate Rust in the Linux kernel they could have made some good progress on a rust only OS by now.
If only just a kernel that can run server like application without a gui shell.
jenadine 29 days ago [-]
There are many Rust OS mentioned in this thread. (Eg Redox)
But the success of an OS also depends on the availability of drivers, and it's hard to compete with existing proven OS such as Linux on that front.
llm_trw 29 days ago [-]
So build a kernel that uses the same API as Linux but in Rust.
Surely it should be easy if you're asking the Linux people to do the same thing for drivers written in Rust?
makapuf 29 days ago [-]
Defining a rust API to the linux kernel is one of the endeavours of the Linux kernel project AFAIK
FullGarden_S 29 days ago [-]
No?
This was never about the languages primarily though. The C programmers here would react the same way towards any other language, be it Zig or Swift, its not Rust specific. They just don't want to partake the additional headache they'll have to deal with to for making the Linux kernel more accessible to languages other than C.
Despite than, Rust devs kept on pushing it after all that was clearly stated, just to make things more and more annoying. Maintaining a software as huge and widely used as the Linux kernel is a huge responsibility that can't be relied on words like "leave it on our shoulders", especially when real time, immediate response is demanded. Development of something like the Linux kernel in Rust will be left unmaintained eventually, unless millions of dollahs are constantly invested into maintaining it because Rust is not as simple as C and the need to avoid accidental copying, memory leaks and almost all memory related issues will add more work because you can't escape "unsafe" when dealing with low level hadrware and C, making the usage of the Rust programming language for Linux kernel development utterly pointless.
imtringued 29 days ago [-]
I somewhat disagree on the "you can't escape unsafe" part. It's true for a C+Rust project, but the idea that you need an unsafe language for low level hardware access is plain wrong. That's a "C-ism". Something that might seem true in a universe where most low level work is done in C, but wouldn't be true in a universe where C doesn't exist at all.
steveklabnik 29 days ago [-]
At work, we have an OS written entirely in Rust. You still need unsafe to make it work. Not much (3%) but it's nonzero.
The hardware is outside of Rust's safety guarantees. This is truly a fundamental issue.
FullGarden_S 29 days ago [-]
its fine if you disagree and think that using "unsafe language" for low level hardware access is wrong but that doesn't change the fact that the more closer one operates to the hardware, the more bare-bone they need the tools to be or else they'll only get in the way of the job. Having to worry about something like a borrow checker or a reference counter just to manipulate a couple of bytes is not an efficient way to perform low level hardware programming.
Also, there is nothing wrong with any "unsafe language". Memory safety is a skill issue, not a language issue. All functional languages are safe and procedural languages are unsafe by nature. Its better to settle on a functional language and compromise on performance if memory safety is of utmost priority. The additional complexity and performance overhead of any supposedly safe procedural language is not worth it for doing low level stuff but it sure could be a fun choice when doing high level stuff.
f1shy 29 days ago [-]
As long as you can directly write registers, you can screw it.
cogman10 29 days ago [-]
Partially, but it takes two to tango.
There are softer ways to work with abrasive attitudes that can ultimately accomplish your goals. A key part of that is knowing which battles are worth fighting. Sometimes, it's better to let a suboptimal solution in to appease an ego.
I think Hector's change is the right one, but I also think with the dma maintainer being unwilling to budge the next move is to hack in a location with less resistance, potentially making more work and churn, but ultimately achieving the goal of rust in Linux.
Two people being abrasive to each other with code involved is a disaster.
gmokki 29 days ago [-]
Do you mean location as in different subsystem than dma, which is required for all modern devices.
Or just location as in stash the files outside the dma directory?
cogman10 29 days ago [-]
> Or just location as in stash the files outside the dma directory?
This one. The code in question, AFAIK, is a rust wrapper around the DMA subsystem. I think that does best belong in the DMA subsystem but with the maintainer unwilling to accept it the next place to put it is either in a new rust-dma subsystem/wrapper or to pull out the parts needed and integrate them directly in the drivers in question (certainly nasty and a lot of duplicate effort).
The goal for such code should ultimately be to cause as little friction as possible with the DMA maintainer.
If it comes up in the mailing list that "this is dumb and you shouldn't do this" that's when you loop in the DMA maintainer and request their suggestions on how to proceed with whoever challenges the change. Put them in the seat of making the decision of where the code should go.
thinking_monkey 29 days ago [-]
Like others have mentioned it was really the hypocrisy of this guy that made me side against him, not so much whether he was right or wrong.
He's a known, certified, card-carrying obnoxious rebel coming pretty close to violating a "Code of Conduct" himself pretty well every other day then his beef with Christoph about wanting to "mix languages" (C and Rust, of course) and Christoph said "I'm maintaining it and I'm not doing it, it's like a cancer" (I'm paraphrasing and he was notably not talking about Rust itself but "mixing" C and Rust) then Martin exploding and screaming that Christoph said "cancer" and that he had violated a Code of Conduct. Please.
A serious case of the pot calling the kettle black.
slanterns 29 days ago [-]
> then his beef with Christoph about wanting to "mix languages" (C and Rust, of course) and Christoph said "I'm maintaining it and I'm not doing it, it's like a cancer"
You don't even take time to figure out who's the commit author.
KennyBlanken 29 days ago [-]
[flagged]
29 days ago [-]
ToucanLoucan 30 days ago [-]
[flagged]
dmix 29 days ago [-]
This is the logic that generates generic corporate PR speak and a fear of being honest in organizational communication. It's not a more 'adult' world, it's just heavily sanitized. Calling something "a cancer in x" is a common analogy, we know what they mean.
ToucanLoucan 29 days ago [-]
[flagged]
tsimionescu 29 days ago [-]
> Other than that, it's not a binary yes/no question; no one is really against some Rust in some parts of the kernel, but which parts? How? Where? That's the big disagreement. Linus has always been fairly hands-off on these types of disagreements.
Some Kernel maintainers are absolutely against Rust anywhere in the kernel tree [0]:
> The only reason Linux managed to survive so
long is by not having internal boundaries, and adding another language
complely breaks this. You might not like my answer, but I will do
everything I can do to stop this.
This is from Christoph Hellwig, the DMA maintainer. And is in fact what started the thread that led to Hector Martin quitting Linux. You can see other comments by Hellwig in that thread as well, he is extremely explicit - any Rust anywhere in the kernel is a big problem, and even if he can't stop it everywhere, he will do what he can to make it harder to use Rust by blocking it from the pieces he maintains.
> > The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language complely breaks this. You might not like my answer, but I will do everything I can do to stop this.
If a maintainer of a major subsystem has those objections, it is a good chance to try to convince them otherwise.
If something is not clear, ask him to elaborate.
But blackmailing with a social media campaign is not productive. Even more it’s anti-productive. This just adds to rust=drama=stayaway feeling.
jonkoops 29 days ago [-]
If you looks at the history then you will see that many different solutions have been proposed but Christoph's responses essentially boil down to 'do it somewhere else' and 'no not there', until it is basically 'not at all'. He is not in a position to make this decision, only Linus is. The patch as it stands lives outside of any sub-systems within Christoph's purview, he is simply being obstructionist out of tribalism.
diggan 29 days ago [-]
> he is simply being obstructionist out of tribalism.
What about the part quoted in GPs comment?
> > The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language complely breaks this
Wouldn't adding another language add an internal boundary? I don't know enough the kernel or kernel development to say it's an good argument or not, but it doesn't seem to be tribalism. I do know Rust already seems to be in some/few places in the kernel, but adding more would add more internal boundaries, as it'll get more and more divided. But again, maybe I don't understand clearly.
tsimionescu 29 days ago [-]
I agree that it may not be tribalistic, it's very possible that the maintainer has a valid technical/social opinion on this.
However, I don't think it is in any way acceptable to insert this in discussions about a random Rust patch. It's disrespectful to the time and expertise of the people who submitted these patches to first nitpick various technical items, only to later make it clear you were never going to accept their patch in the first place, because you dislike and oppose the decision that you know has already been made, to allow Rust in the kernel.
If he instead was (1) upfront about the fact that he would never allow Rust code in the subcomponent he maintains, and (2) stepped out of the discussion of this patch once it was moved out of said component, and then (3) started a completely separate thread on changing the kernel's stance on Rust to block all future patches and consider removing it entirely, that would all have been normal respectable behavior.
CRConrad 25 days ago [-]
> The patch as it stands lives outside of any sub-systems within Christoph's purview
Wait what? Thought I saw somwehere that he's the DMA maintainer, and wasn't this a DMA patch?
> he is simply being obstructionist out of tribalism.
Or is it the Rust people who are being intrusionist out of their tribalism? Looks at least as much like that to me.
whytevuhuni 25 days ago [-]
> wasn't this a DMA patch?
Although it was a DMA patch, it was not in the DMA subsystem that Christoph maintains. More specifically, it was not a file in the kernel/dma directory, but rather a file in the rust/kernel directory, which is where the Rust subsystem lives.
The Rust code is essentially a consumer of the DMA public API, much like many other subsystems in the kernel that consume it.
This is why some people are upset and confused about the situation; he added a Nacked-by tag to a patch that is outside his area. He had good reasons for it, but it was hard to see them based on the way he wrote his replies.
CRConrad 24 days ago [-]
Aha, I see. Thanks!
tsimionescu 29 days ago [-]
Oh, yes, the idea of settling anything on social media is horrible.
I was just pointing out that the positions are much more binary and un-nuanced than the previous poster was claiming, even in the thread in question. I'd bet the DMA maintainer is not the only one who holds this dogmatic position, either.
I'll also note that the complaints from this maintainer aren't even social though. He is very explicit in his reasoning: two+ languages bad, single language good. There's clearly little that will change this, other than working around him (though, again, I agree that social media blackmail certainly won't improve anything).
CRConrad 25 days ago [-]
> He is very explicit in his reasoning: two+ languages bad, single language good. There's clearly little that will change this, other than working around him
I see you're not even considering the possibility that he might be right, so working around him would be bad.
___
ETA: I see on further reading that you are indeed acknowledging that possibility, good for you! I just didn't see that in this comment.
chikere232 29 days ago [-]
It's not without merit. Two languages is an extreme cost in complexity compared to one, and you have to be a deep expert in both to fully figure out anything on the boundary.
Perhaps rusts potential benefits are worth it, but it's certainly possible to disagree with that
tsimionescu 29 days ago [-]
Sure, but (1) that ship has sailed for now, there are already Rust bits in the kernel; and (2) a patch email thread is not the best place to start discussing whether Rust has a place in the kernel.
armitron 28 days ago [-]
There are no Rust bits anywhere outside drivers, and hopefully that will continue to be the case. This means that mainline Linux kernel has no hard dependency on Rust whatsoever, which also means that Rust can be excised at any point with a minimum of effort.
I'm 100% behind Christoph, the last thing Linux needs is the extra complexity that Rust brings. I'm fairly optimistic that Rust will never be a hard dependency for the foreseeable future.
f1shy 29 days ago [-]
Is it impossible to just delete the rust parts and go back to pure C?
That ship could come back to port anytime.
tsimionescu 29 days ago [-]
That's not a decision that can or should come out of a patch review. I agree it's a possible decision, not something unthinkable. But if it were, it should be taken at a completely different level.
Basically, it's an obstructionist, uncivilized thing to hold up every discussion about a topic that you get to participate in by insisting the topic shouldn't be discussed in this forum. It's perfectly OK to advocate for the removal of Rust from the kernel, it's not ok to bring this up in every random Rust patch while the consensus is that Rust has a place in the kernel.
surajrmal 28 days ago [-]
The kernel doesn't really have a better system mechanism for having these sorts of decisions made unfortunately.
Filligree 28 days ago [-]
I would quite like my laptop to keep working, and half its drivers are rust…
surajrmal 28 days ago [-]
The Linux drivers can be maintained in a downstream fork. Ultimately that seems to be what upstream wants, unfortunate as that may be.
account42 27 days ago [-]
Then you (and others interested in running Linux on fruit company hardware) can sponsor someone to rewrite those drivers in a way that fits the Linux project.
steveklabnik 30 days ago [-]
> no one is really against some Rust in some parts of the kernel
This drama included the dma maintainer saying he is categorically opposed to any Rust in any part of the kernel.
arp242 30 days ago [-]
Where? Because "keep the wrappers in your code" and "do that in your driver so that you have to do it instead of spreading this" doesn't sound like that.
cycomanic 29 days ago [-]
He said explicitely:
>Every additional bit that another language creeps in drastically reduces the maintainability of the kernel as an integrated project. The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language completely breaks this. You might not like my answer, but I will do everything I can do to stop this.
I think that clearly means he is out to sabotage any other language than C making it into Linux.
gpm 29 days ago [-]
The end of the paragraph also emphasized the point
> I do not want it anywhere near a huge C code base that I need to maintain.
This was also on a patch that did "keep the wrappers in [rust-folder, not DMA] code". Arp242's interpretation isn't just belied by the direct words of the maintainer, it's belied by the fact that the code the maintainer rejected was exactly what Arp242 is suggesting the maintainer was asking for.
IncreasePosts 29 days ago [-]
I wouldn't call being vocally against something "sabotage". Would it be reasonable if that person said anyone trying to get rust integrated is sabotaging the Linux kernel?
tsimionescu 29 days ago [-]
You're conflating two things. The fact that he voices his belief that Rust is harmful for kernel development is fair.
The fact that he is using his powers as maintainer of the DMA module to prevent Rust code from being added, with the explicit goal of making it harder to develop Rust drivers so that maybe the Rust-for-Linux project might get abandoned is an explicit act of sabotage against the R4L project (no one is saying he is sabotaging the Linux project itself).
In contrast, even accepting the "two languages bad" perspective, you can't call the R4L project "sabotage" in the same way, because they are clearly not intending to prevent or break anything in the Linux kernel, even if you think they will end up doing so as this maintainer does.
snvzz 29 days ago [-]
>The fact that he is using his powers as maintainer of the DMA module to prevent Rust code from being added
This is a misinterpretation of the facts. It's not actually up to Hellwig whether or not the patch gets accepted; the relevant maintainer that would merge the patch is somebody else.
He's totally within his right to express his opinion in a NACK.
tsimionescu 29 days ago [-]
At least at some point, the proposal was to add this code in the DMA submodule, where he did have the ~final say whether it would be merged in.
When it became clear that wasn't an option, they decided to put it somewhere else, but since he'd been consulted, he still wanted to make it clear he isn't ok with the patch regardless of where the files go or any other aspect of it; but you're right that he is not the final authority on what code goes into that new subpath.
I never said in any way that he doesn't have a right to his opinion. Just that he is explicitly and vehemently opposed to Rust in the kernel, and to anything that makes that easier to happen.
saghm 29 days ago [-]
You're comparing the actual intent of one side of the argument to a watered down version of the other side. "I will do anything in my power to stop this" is the stated intent of sabotage, not "I'm vocally stating my opposition to this" If someone said "I will do anything in my power to stop Linux development to proceed without Rust integrated into it", then yes, that would sound like intent to sabotage, but that's not anywhere close to what anyone is saying.
AnonymousPlanet 29 days ago [-]
So there's actually a reasoning behind this and not just personal preference or someone being stubborn. And as someone who has maintained large old code bases I must say the reasoning sounds pretty convincing.
If any of
> Every additional bit that another language creeps in drastically reduces the maintainability of the kernel as an integrated project. The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language completely breaks this.
is correct, he is actually fighting against sabotage.
edit for readability
derhuerst 29 days ago [-]
This [0] seems to be the closest to your parent's statement:
> The common ground is that I have absolutely no interest in helping
to spread a multi-language code base. I absolutely support using
Rust in new codebase, but I do not at all in Linux.
He needs really to be removed from the process. He may be useful for now but for long term he is an impediment. C is the 1970’s. Sure it’s proven itself… but so had Assembly when Unix was invented.
account42 27 days ago [-]
This kind of zealotry is not going to convince people over to accept Rust into their projects.
buttercraft 29 days ago [-]
Are you referring to Hellwig saying, "No rust code in kernel/dma, please."? I took that to mean just dma.
rst 29 days ago [-]
The objection was to a separate file entirely outside of his subtree, describing its interface, which is apparently supposed to be duplicated instead in each rust driver that references it, for no clear reason -- other than his stated reason of not wanting to see languages other than C in the kernel at all.
steveklabnik 29 days ago [-]
I was referring to the statements provided by the children of this comment: https://news.ycombinator.com/item?id=42978746 (they were made at roughly the same time you posted this, so you wouldn't have seen them then)
buttercraft 29 days ago [-]
Ah, sorry. I see it now.
steveklabnik 29 days ago [-]
No need to be sorry, you're all good!
wbl 30 days ago [-]
The DMA infrastructure is core to drivers. Saying no to having a wrapper to use it in rust means every rust driver needs to reimplement it, which creates more work and issues.
ww520 29 days ago [-]
Just curious. Why can't the wrapper be an independent library outside of the DMA infrastructure? It can still be used by all rust drivers.
I think Hellwig is against moving the wrapper into the DMA project that he's forced to maintain it.
loeg 29 days ago [-]
No, Hellwig also Nack'd the patch that added the wrapper to an independent library outside of the core C DMA directory.
ww520 29 days ago [-]
Why would he do that? He has no control over an independent library outside of C DMA? I thought he said he's fine with any drivers written in Rust. Just that the maintenance of such including any wrapper cannot fall into C DMA's lap.
loeg 29 days ago [-]
> Why would he do that?
It's a great question. I mean, my read of it is he hates the idea of Rust4Linux and is using his position to obstruct.
> He has no control over an independent library outside of C DMA?
Apparently not.
> Just that the maintenance of such including any wrapper cannot fall into C DMA's lap.
The patch he rejected did not add any code to C DMA, nor C DMA's directory (kernel/dma). Just:
(Nor does any Rust4Linux code add any maintenance burden to C -- C maintainers are allowed to break Rust code at will.)
saghm 29 days ago [-]
This isn't even just your read of it; as other people in this thread have pointed out, he's pretty explicitly stated it at this point.
tsimionescu 29 days ago [-]
No, he said very explicitly that he is against any Rust code in Linux whatsoever. He doesn't have any beef with Rust, the same would be true for him if people tried to add C++ or Pascal or Ada or any other kind of drivers or infra in Linux: he believes that the project will be much harder to maintain if it's not 100% pure C (and assembly).
> Why would he do that? He has no control over an independent library outside of C DMA?
That is the crux of the entire drama and why R4L developers got upset at Christoph in the first place, and asked Linus to intervene.
tw1984 29 days ago [-]
[flagged]
arp242 30 days ago [-]
I am aware. Doesn't mean it's not an option, or even a bad idea. Or maybe there is a third option; I don't know.
By the way: I don't agree with Hellwig, insofar I can judge things, I'm just saying his opinion is valid, and that "Linus agreed on Rust, so therefore we can merge this patch" is not really a valid argument.
Tuna-Fish 30 days ago [-]
It's just really, really dumb to both a) have rust drivers in the kernel and b) not merge this patch. It's just obviously stupid.
If you start with the assumption of a), there are no valid technical challenges to merging it. It's just better for everyone. Before Hellwig put his foot down as "not merging because rust sucks", he made a series of technical arguments against the patch, which were all transparently bullshit. It was those arguments that really raised such a furor, instead of all the other ways some C devs have disdained rust in the kernel in the past, because they were obviously made in bad faith. And when he was called out for them, he just went full "no rust in kernel".
arp242 30 days ago [-]
> Before Hellwig put his foot down as "not merging because rust sucks"
He didn't say this at all. He explicitly and repeatedly said he has no problems with Rust as a language.
And you can't just assert "there are no valid technical reasons". Just because you don't agree with the objections, or even think they're dumb, doesn't mean you can just dismiss them and start ascribing bad faith motives.
Tuna-Fish 30 days ago [-]
> He didn't say this at all.
Okay, sorry. He just said there should be no rust in the kernel.
You can ascribe bad faith motivations when someone presents technical objections that are already fully answered in the patch that was submitted, and when this is pointed out, they admit that, but don't retract their objections.
The original objections are specifically not a case of differing values or design ideas. They are nonsensical, the equivalent of 1 = 2.
arp242 30 days ago [-]
> Okay, sorry. He just said there should be no rust in the kernel.
That's also not what he said; it's "no Rust in kernel/dma". He pretty much explicitly said it's okay for drivers to do their thing in Rust, but with their own wrappers. You can consider that dumb, but you can't shorten that to "no Rust in the kernel".
And "I replied to your objections, therefore the matter is settled" is arrogant beyond belief. People can disagree, you know, because they have different priorities, different preferences, different perspectives, etc.
aeldidi 29 days ago [-]
No he did say he doesn’t want rust in Linux at all. Now I understand that he didn’t say “I won’t allow rust to be in Linux”, which is a useful distinction to make. But let’s not pretend like he didn’t say “rust shouldn’t be in Linux” at all.
> Every additional bit that the another language creeps in drastically reduces the maintainability of the kernel as an integrated project. The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language complely breaks this. You might not like my answer, but I will do
everything I can do to stop this.
> That's also not what he said; it's "no Rust in kernel/dma". He pretty much explicitly said it's okay for drivers to do their thing in Rust, but with their own wrappers. You can consider that dumb, but you can't shorten that to "no Rust in the kernel".
Have you actually taken a look at the patch?
There was NO RUST CODE ADDED TO kernel/dma, they wanted to add a dma wrapper to a rust/ folder.
josephg 29 days ago [-]
> The common ground is that I have absolutely no interest in helping
to spread a multi-language code base. I absolutely support using
Rust in new codebase, but I do not at all in Linux.
He said no Rust (or any other language except C) in any core code. Notably the patch was not eve being added to kernel/dma
tsimionescu 29 days ago [-]
I think he even hates non-C code in the drivers, he just cares less about that. But his position is that kernel maintenance will only work longterm if it's all a single language (C).
Tuna-Fish 29 days ago [-]
> "I replied to your objections, therefore the matter is settled" is arrogant beyond belief. People can disagree, you know, because they have different priorities, different preferences, different perspectives, etc.
I'm sorry for not being clearer, but that is specifically not what is going on. The objections were of factual, technical nature. As in, "do not do X". The problem is that the code in question was not doing X, and it was not doing anything that could be construed as doing X. The objections did not arise from differences in priorities, preferences, or perspectives, they were just factually wrong.
tw1984 29 days ago [-]
please stop spreading such highly misleading nonsense. look at what is black and white. blindly defending such toxic people is not doing linux any good.
sdwr 30 days ago [-]
It's pretty clear that the battle over rust is a power struggle. You can't take any of it at face value
arp242 29 days ago [-]
So what are you saying? That it's okay to just invent quotes and spread misinformation about people, based on what you suspect their true thoughts might be?
Ar-Curunir 29 days ago [-]
You’re the one doing that by pretending that Hellwig is acting contrary to his own statements.
tw1984 29 days ago [-]
wait a second, I thought you are the one labelling people as "toxic" when completely ignoring the context that really matters.
cyberax 30 days ago [-]
He literally called "Rust" a "cancer".
johndunne 30 days ago [-]
I beleive he clarified in the same sentence that he was not calling the language Rust cancer... to quote "where this cancer explicitly is a cross-language codebase and not Rust itself, just to escape the flameware brigade"
int_19h 29 days ago [-]
So, to be more specific, he called Rust in Linux kernel source a cancer.
johndunne 28 days ago [-]
It needs to be a little more specific to be correct; a cross language codebase would be the cancer.
arp242 30 days ago [-]
He literally did not. He literally explicitly said right there in the (in)famous "cancer" message that it didn't refer to Rust as a language.[1]
"And I also do not want another maintainer. If you want to make Linux impossible to maintain due to a cross-language codebase do that in your driver so that you have to do it instead of spreading this cancer to core subsystems. (where this cancer explicitly is a cross-language codebase and not rust itself, just to escape the flameware brigade)."
Stop spreading this kind of misinformation.
And no, I don't think he came off very well here, but please, give it a good faith reading.[2]
rejecting such patch is the exact cancer that need to cured. stop misleading people.
SXX 29 days ago [-]
The reason patch got rejected is super simple: because this wrapper not lives in specific driver and depends on DMA subsystem internal API.
And this cause problem. When someone make any change to Linux kernel they suppose to fix all the code they break across all kernel. And if said wrapper accepted then maintaner of DMA will have to make sure that all patches he accepts also fix Rust parts.
So he just dont want extra burden for himself.
tw1984 29 days ago [-]
> because this wrapper not lives in specific driver and depends on DMA subsystem internal API.
if multiple rust based drivers all need to have DMA support, what should they do? each come up with their own little magic?
> And this cause problem. When someone make any change to Linux kernel they suppose to fix all the code they break across all kernel.
this has been explained like 10+ times in this thread - it was made crystal clear to the DMA maintainer that he/she doesn't need to maintain the rust stuff, it is totally okay to break it.
> So he just dont want extra burden for himself
he can just resign. simple and period. no one is ever forcing him/her to be the maintainer when he/she is literally forcing other people to stop developing Linux support for the only powerful & affordable ARM machine for home use.
28 days ago [-]
scoutt 27 days ago [-]
> what should they do?
Sorry to ask, but couldn't it be solved with cargo? I hear all the time about the benefits of Rust tooling and zero-cost abstractions.
Why can't a driver just pull/include the latest-dma-bindings crate and glue the gap with zero-cost abstractions?
If kernel DMA code/API changes, then nothing breaks in the kernel (hopefully) and the "Rust devs will quickly solve the changes" theory can be really proven and tested by quickly updating the bindings AND the updating the drivers.
preisschild 29 days ago [-]
> that it didn't refer to Rust as a language.
No, he didnt refer to Rust as cancer, but to Rust in the Linux kernel / the R4L project.
hitekker 30 days ago [-]
One lesson I feel we can all learn from this is that social media really should not be used for self-therapy.
api 29 days ago [-]
IMHO social media is toxic period and has no place in any professional interaction. It is inherently biased toward drama and bullshit by design, since this “maximizes engagement.”
The sooner politicians are outright banned from using it for anything connected to their office the better.
iknowstuff 29 days ago [-]
> no one is really against some Rust in some parts of the kernel
Dude, this was literally caused by a stubborn maintainer, Hellwig, saying he wants NO second language in the kernel at all, and his explicit vow to do anything he can to stop it.
pverghese 29 days ago [-]
And there is no issue with that. What's this pervasive need to spread Rust to every part of the software space. It's just becoming a little too pushy and desperate
johnny22 29 days ago [-]
c'mon.. please know about the issue at all to some level before commenting.
The rust for linux project exists because Linus approved it. It's that simple. Linus thinks it a good idea to at least try Rust in the kernel. If he didn't, then none of this would be happening.
CRConrad 25 days ago [-]
> The rust for linux project exists because Linus approved it. It's that simple. Linus thinks it a good idea to at least try Rust in the kernel.
Pepople can change their minds; after a while, they may come to think that what they once thought was a good idea wasn't actually so.
With stuff like this going on -- and I gather this is not the first time something like it has happened -- how long do you think Linus will continue to think so? Do you think stuff like this is likely to make Linus more convinced, or less convinced, that setting himself (and all the other Linux kernel maintainers) up to have to interact with Rust people on an ongoing basis really was a good idea?
johnny22 15 days ago [-]
He continued to express his support on the subject as of yesterday (i think).
account42 27 days ago [-]
That may be what you want the situation to be but at this point it isn't what the situation is.
honeybadger1 29 days ago [-]
Completely agree with you.
OtomotO 29 days ago [-]
I totally agree that even "just threatening" a social media campaign is the wrong way. We are on the same page here.
I totally disagree that the other contributor is "a bit" abrasive though.
It's like a religious war. Brings the worst out of otherwise smart and not asshole people.
seivan 29 days ago [-]
[dead]
tw1984 29 days ago [-]
[flagged]
blueflow 29 days ago [-]
Imagine if i would take a screenshot of your post and repost it to the fediverse, with a caption like "Look at this dude, he has the same delusions as marcan". Replies go like "omg peak HN again"
Would you consider that a healthy way of disagreeing? I think if i actually did that, you would probably feel like shit and be more empathetic to the harm that marcan causes.
artyom 30 days ago [-]
> an uncommon failure of leadership for Torvalds
Exactly the point. IMHO the one and only thing that made Linux successful as a project is Linus' strong leadership - which has been criticized ad-nauseam over the years; yet it's the only thing that yields results.
So in the specific instances (like this one) where he's not decisively, unequivocally, and even harshly saying "yes" or "no" to something, the community shows a very clear incapability of reaching a decision.
Reminds me of a similar scenario that happened years ago with GVR stepping down as BDFL for Python - just after a tiresome and wasteful fight with the community's opinions.
"Community" is just a very naive ideal for me. There's a finite number of people that can do the job, and even a more finite number of people that can make a decision and stand by it.
raverbashing 30 days ago [-]
Agree
The more I hear about "community" the more I roll my eyes
It can be great at doing the work but it is awful at setting direction, evolving with the times and focusing on what's important
Going by another story on the front page, I have my long list of criticism about systemd but the "get things done" attitude needed to be commended
broodbucket 29 days ago [-]
What an absolutely awful statement about one of the most successful community projects ever. Direction usually comes from the community and the maintainers just steer it. Little in the kernel comes from maintainers saying "let's do X" and community members implementing it
SXX 29 days ago [-]
> Little in the kernel comes from maintainers saying "let's do X" and community members implementing it
Maintainers do steer direction of development though. A lot comes from maintainer saying "we are not accepting XYZ".
Today we only have proper open source GPU drivers because people like David Airlie who stand for their principle against likes of Nvidia and AMD.
raverbashing 29 days ago [-]
See how slow Wayland progress has been for an example of my grudges with that model of development
WesolyKubeczek 29 days ago [-]
Almost two decades later, for unexplicable reasons, every new client not piggybacking on an eatablished toolkit or a new toolkit/compositor struggles with clipboard support, I shit you not.
chikere232 29 days ago [-]
Perhaps you could fork the kernel and start a better community?
KennyBlanken 29 days ago [-]
> IMHO the one and only thing that made Linux successful as a project is Linus' strong leadership - which has been criticized ad-nauseam over the years; yet it's the only thing that yields results.
I wear garlic every day and have yet to be attacked by a vampire; clearly this is due to the garlic!
Tang/ballpoint pens/velcro never would have been invented if it weren't for the Apollo program.
etc.
themerone 29 days ago [-]
All of those inventions were invented at least a couple years before the Apollo program.
ksec 28 days ago [-]
>"Community" is just a very naive ideal for me.
I guess you are safe to say this now. But from 2014 to 2024, open source is not about code licensing but about the Community.
artyom 28 days ago [-]
[flagged]
CRConrad 25 days ago [-]
> IMHO the one and only thing that made Linux successful as a project is Linus' strong leadership
Naah, I don't think that's the only thing that did it. It was that, and the fact that people dared rely on it -- dared trust it to stick around, and to stay a single thing in stead of splintering up. And the thing that made it Open Source that stays Open Source -- that made it, in fact, Free Software -- is the license.
The two things that made Linux successful as a project are Linus' strong leadership and the GPL.
Just look at BSD: It had the backing of a whole darn university near Silicon Valley, not a single student somewhere North of The Wall. It had a head start by several years. And it had name recognition far beyond its home country[1]. And look where it is now: There are (at least?) three of them, and even together they're a marginal phenomenon among operating systems. I think that's because of the too-permissive BSD license.
___
[1]: The first I heard of "Open Systems" was well before I got into working with computers for a living, as a student at another university in the Frozen North in the late 1980s. My fiend and neighbour, a computer student, raved about how cool Unix was: "And you can even get it for free! It's called BSD!"
30 days ago [-]
pipes 30 days ago [-]
[flagged]
tjohns 30 days ago [-]
Some of Linus's past messages came across as needlessly aggressive and insulting. There really was no practical reason for that and just served to alienate contributors, and it came across as unprofessional.
You can be a strong, opinionated leader and still be kind (or at least neutral) to the people you're working with.
A good leader is someone who can deliver hard messages while still keeping your team inspired. It doesn't do any good if the people working under you feel like trash.
It's the difference between telling a contributor "you're an f**ing idiot" vs "this code isn't up to standards, try again". Same message, but completely different impact on your team.
dylan604 30 days ago [-]
> A good leader is someone who can deliver hard messages while still keeping your team inspired.
Do you have examples of this? The only "good" leaders that are strong and opinionated I can think of always comes across as leans towards being an asshole.
> Same message, but completely different impact on your team.
Let's change it from "you're a fucking idiot" to "this code is fucking trash". It's not insulting to the specific person, but it definitely gets the point across that the code is no good and much less ambiguous to "it's not up to standards".
tjohns 29 days ago [-]
A few public ones off the top of my head: Satya Nadella (Microsoft) and Ed Catmull (Pixar) are both folks who I consider to be strongly opinionated and effective leaders but who don't come across as jerks.
I'm not sure how "this code is not up to standards, try again" is ambiguous? That seems pretty direct to me.
Ultimately it's about showing empathy. Especially when you're dealing with employees who are struggling with anxiety, impostor syndrome, or burnout - all of which seem to be overrepresented in tech.
account42 27 days ago [-]
Using business-approved language doesn't actually make your message more friendly.
It's not line Linus was prone to using flowery prose against random novices - the rant he's known for were mostly addressed at senior maintainers who really should have known better.
anaisbetts 30 days ago [-]
Bad faith arguments like this don't really belong on HN. Please represent the substance of your argument accurately rather than debating this inaccurate strawman argument.
account42 27 days ago [-]
You disagreeing with an argument does not mean it was made in bad faith (or is without merit for that matter).
30 days ago [-]
sevg 30 days ago [-]
You seem to be implying that he had nothing to apologise for, and that abusive behavior is an acceptable part of strong leadership.
It’s sad that this even needs to be called out.
artyom 30 days ago [-]
Except you have no authority to call that out, and we're not forced by law to agree with you.
In my opinion Linus was never abusive or disrespectful - just blunt and direct.
Unfortunately, there seems to exist people (like me) that would prefer such individuals instead of nice empty words just in case someone gets offended.
dafelst 30 days ago [-]
Are you serious? Linus has a long history of being abusive, it is no secret. He has gotten better for sure in recent years, but especially in the earlier days he would fairly regularly insult people, tell them to kill themselves because it would make the world a better place, and more.
olddustytrail 30 days ago [-]
[flagged]
hulitu 30 days ago [-]
> In my opinion Linus was never abusive or disrespectful - just blunt and direct.
The way he spoke with Alan Cox was "not apropiate".
alexey-salmin 30 days ago [-]
Not appropriate for what exactly?
exe34 30 days ago [-]
could you give some examples of "nice empty words"?
wiseowise 30 days ago [-]
Seriously? I’m a huge fan of Linus, but you have to be delusional to not find his rants abusive or disrespectful.
artyom 30 days ago [-]
Seriously. And I say this because apparently every comment on this thread has to be on either side, with no actions being considered counterbalance whatsoever. So given that I have to pick a side, yep, seriously.
account42 27 days ago [-]
Not as disrespectful as calling those who don't agree with you "delusional".
I agree, engaging in further conversation would be futile.
alexey-salmin 30 days ago [-]
Can you explain in simple terms why a person cannot reply abusively (whatever that means) if he so desires? You're not obliged to interact with him, it's a free choice to join or to quit the lkml.
One of the main issues Torvalds says the kernel has is not being able to find maintainers. People don’t want to be abused while volunteering could be part of that.
Another possibility is that he gets paid over a million dollars a year by an employer, who will have some concerns over legal risks, reputation, etc.
alexey-salmin 27 days ago [-]
Perhaps, but if Linus would rather see the mainline kernel development dwindle than compromise his way of managing people and code, he's still well within his rights.
As for his relationship with his employer — they both have the freedom to terminate it when their interests do not align anymore.
I genuinely struggle to understand where all the high expectations come from. Somehow people think that an open source project leader is obliged to be kind and polite and humble and understanding. None of these obligations exist as far as I can tell.
jodrellblank 27 days ago [-]
Do you genuinely think an employer ordering an employee "don't tell people to kill themselves" is "high expectations"?
This is tragedy of the commons stuff, everyone is sitting quietly on the commons in a shared space, respecting the other people, and you drive your modified pickup truck through the middle rolling coal and blaring dance music and jeering "if you don't like it you can always move to another city" as if toning it down a bit is unreasonable but telling people to uproot their entire lives is reasonable.
> "Somehow people think that an open source project leader is obliged to be kind and polite"
Everybody is obliged to be kind and polite[1], that's one of the foundational parts of society - saying please and
thank you, 'don't stare', consider the effect of your actions on other people - is kindergarten teachings; we all live in a shared space, and politeness is the grease that smoothes all the interactions between different peoples.
In any other situation, if a person has some power, authority or influence over people who can't leave or won't leave, and they immediately turn to abusing them just because they can, we would say that was bad. If a husband abuses a wife who can't leave, if a manager abuses employees who won't quit, if a religious leader abuses devotees, if a child abuses a pet, if a teacher abuses students, if a government mistreats illegal immigrants, we (society, possibly the legal system) would object quite strongly. Why does invoking the words "open source" excuse anyone from these expectations as if 'leading an open source project' makes someone above everyone else and outside the normal expected behaviours?
It is also a thing that you can't separate "don't scream abuse at people" with whining "why do I have to be polite?" as if those are the only two options, there's quite a range of rude responses which are not abusive - saying the code sucks, saying 'I wont read all that' - and there are polite responses which are blunt and not saccharine - saying 'I have the decision making authority and do not want to do it that way.', 'nope, PR rejected, do not try again', 'I am not taking PRs of any kind, I do not want to'.
Aside from that, as mentioned, this is not just any open source - he's a paid employee, this is not him sharing his work on his own server with the scope of him being rude or abusive limited to a few people; this is a hugely important worldwide system. The Linux Foundation is funded by companies who use Linux such as Amazon and Google. They employ people who work on the Linux kernel and have to be subscribed to lkml to do their jobs. The Linux Foundation benefits from the work they do and the changes they upstream. The companies donating money have shareholders and expectations of the companies they work with and charities they donate to. And presumably they have some ability to lean on their donations to ask for favours. All this happens under US employment laws and regulations on several sides. This presenting it as a trivial "if you don't like it, leave" is a deliberate and bad-faith oversimplification. It's the race to "person who cares less wins, and I'm a cynical nihilist so I care about nothing, hah!".
I'm sorry, but I just can't make any sense out of this.
> This presenting it as a trivial "if you don't like it, leave" is a deliberate and bad-faith oversimplification
This is not an oversimplification, this is a fact that you don't like and prefer to ignore. It doesn't disappear when you close your eyes though.
A grumpy person made an open source project that by chance became successful. He didn't force all these people and corporations to use it and fund it, it was a free choice on their part.
What is he supposed to do now, change his personality to please random people on the internet? Why? How do you even see this happening? Or you think grumpy people should have been prohibited from writing code in the first place?
Furthermore he does not hold anyone hostage as you try to present this. Linux is not Linux Foundation. You can use and develop Linux without funding the Linux Foundation. It's just more convenient like that but again you are free to exchange patches outside of it.
People who walk in and say "nice project you have here, now you comply or we take it away from you" don't have my sympathy.
30 days ago [-]
artyom 30 days ago [-]
Yep, that happened. "Forced to apologize" essentially describes it.
A quick sweep through recent messages in LKML shows that there's a healthy return to form for him, maybe with less curse words, but as succinct and impactful as it should be nonetheless.
deepsun 29 days ago [-]
No, you get it backwards. Open source community folks despise any commands, the moment Linus orders free folks like you to do something will be the moment his leadership ends.
jmull 30 days ago [-]
The drama, though, is due to personalities.
A directive from Linus on the technical roadmap isn't going to solve anything. It could declare someone the "winner" in this particular thread or this particular issue, but lets the personality issue fester.
It's probably best for Linux to work through its technical issues in boring email threads which never get any attention on social media. And its organizational issues and its personality issues, for that matter.
So it's probably good all around that Martin has bowed out. If you reach for the nuclear button whenever the people you're working with don't give you what you want, it's time to go work on your own (nothing wrong with that, BTW). It's not really a question of who's right, but whether people can find a way to work together. That's quite difficult in a big project, so you have to both really want it and be good at it or it's just not the place for you.
It's definitely a ballpark estimate, but "boring email threads" are 99% of LKML.
There's an average of 1000 messages per day, we get news of a drama-fueled thread like, three times on a bad year?
My ballpark estimate is probably low.
_ph_ 29 days ago [-]
Well, while Hector had a long history of frustrations with working with kernel development, the project of integrating rust drivers in the kernel has reached a cross-roads. Either to take the next steps or effectively close the door of the kernel progressing further with C and all the debt it brings.
From what I saw, the project of writing the graphic drivers for ARM Macs was quite a success, so the door for those projects shouldn't be closed.
quelsolaar 30 days ago [-]
The policy of "No C++, because I don't want to deal with C++ people", should be extended to the Rust community. Whatever you think of the merits of the Rust language, the drama, the lecturing and the general superiority complex of the Rust community is quite off putting, at least to C developers.
coliveira 29 days ago [-]
I also agree that Linux should close the door to Rust as a matter of principle, as it has done to any other language other than C. I don't believe in a mixed language kernel, it is just nonsense, specially with such a different language such as Rust which is closer to C++ in philosophy.
preisschild 29 days ago [-]
I love Linux and have no preference to either C or Rust, but locking Linux in to a programming language that was designed in the relatively early stages of computing will lead to Linux dying in the long term.
There will be fewer and fewer new C programmers with people instead taking up newer systems programming languages like Rust or Zig.
Keyframe 29 days ago [-]
There are zero indicators for that happening. In fact, if history is by any means an indicator for the future, we might see these dying out over the years in favor of new hyped ones and C standing against the time. Zig is nothing so far, personally I believe Rust has some staying power for now, but we'll see. As for C, kernel C is not all that C where C was led to in recent years.
coliveira 29 days ago [-]
C and Unix have stood the test of time. It has been 50 years since they were designed, this is a long time in terms on computing. It is not unreasonable to think that they will stay for another 50 years.
bbkane 29 days ago [-]
Yes, they SHOULD be adding Fortran, another language that has stood the test of time, to the Linux kernel.
Or... Maybe it's good that they add a new (still 10 years old) language with security and DX improvements occasionally. 50 years ago, that language was C...
account42 27 days ago [-]
Adding languages is plainly a bad idea. Migrating to a different language might make sense at a time but IMO rust is still too young to consider that.
coliveira 29 days ago [-]
How many operating systems are written in FORTRAN and still widely used?
metaltyphoon 29 days ago [-]
If other, safer language would have existed the same time as C, I don’t think it would have stood the time as you say.
chii 28 days ago [-]
that's just hindsight. You can also argue the same for the dvorak keyboard vs qwerty. And yet, qwerty stood the test of time.
Momentum and legacy is hard to displace, when the new fangled thing attemping to be an improvement is not proven, and has unknown unknowns.
metaltyphoon 27 days ago [-]
> that's just hindsight.
Is it? Do you think it's hindsight to use the only "successful" story as "the only way forward?" Look at the gas vs electric vehicles. Yes, displacing legacy is hard but not insurmountable when there is a clear improvement. I don't think anyone can argue in good faith the Rust is NOT an improvement in C.
account42 27 days ago [-]
Electric vehicles are also not a clear improvement over combustion engines. Which is why they need to be forced into use.
_ph_ 29 days ago [-]
They did. But they were disregarded.
jorvi 28 days ago [-]
Interestingly enough the Windows kernel is slowly rusting. If they they see a significant drop in CVEs eventually (which is bound to happen, with how easy it is to footgun memory safety in C), it blows a huge hole in the stance of "no Rust in the Linux kernel". It'd be akin to saying "yes, more security issues please".
account42 27 days ago [-]
Just like C++ has already led to there being fewer new C programmers and has caused C projects to die out? I don't think the programming language is a real problem for someone capable of working on the kernel. Some people might prefer to work in another language but with a large project you need to compromise in many ways and the language is just part of that.
account42 27 days ago [-]
I agree. If it wasn't for the memory safety meme this would have never been considered.
J_Shelby_J 29 days ago [-]
Then make it so, so that we can RWIR, and Linux can fade into the sunset with Linus.
chikere232 29 days ago [-]
Nothing is stopping you
mrits 29 days ago [-]
If the Kernel stopped all development it would still not fade into the sunset in our lifetime.
mrits 29 days ago [-]
Linux kernel community is afraid of drama? I've been using Rust as a primary language for years now and would agree that the community is lead by immature drama queens. However, the linux kernel team would be the best comparison.
tw1984 29 days ago [-]
> at least to C developers.
so it is not about technical merits, but just some language religious thing? nice.
astrobe_ 29 days ago [-]
Not "religious" (even though I've used the word "zealot" right here) but rather political or social.
Keyframe 29 days ago [-]
those are still technical merits/non-merits, albeit on the project management level.
patrick451 29 days ago [-]
The rust doesn't write itself.
dralley 30 days ago [-]
>Arguably his reprimand of Martin is a clear signal that he will never show Rust any favor
You're reading way too far into this. Linus has been publicly positive about the R4L project plenty of times.
gary_0 30 days ago [-]
Positive, yes, but can you point to where he says R4L is here to stay and an integral part of the kernel? He needs to commit, or drama like this will continue to boil over. He also seems content to let the C-only old guard give the R4L guys a hard time. If you only enforce the rules on one side of a conflict, it makes it pretty clear which side you agree with.
starspangled 30 days ago [-]
Nothing in Linux is "here to stay", it always has to demonstrate its worth, and what it's worth is depends enirely on the technology and its developers, not Linus.
threatofrain 30 days ago [-]
Perhaps C is here to stay and that is the way Linux should live and naturally die. That's what's being proposed here by the guy who opposes multi-language projects.
PedroBatista 30 days ago [-]
That's my overall point of view too. Regardless of infinite technical discussions about one or another, if Alice and Bob can't live together than just don't get married.
Why spend all this energy on conflict and drama to no end? If one language/technology/group is so much better then just fork the thing and follow their own path.
I'm actually not defending the C guys, I just want to leave them alone and let "Nature" take his course, if they die on obsolescence, then they die. who cares..
d3Xt3r 30 days ago [-]
I concur. Personally, I'd love to see all the Linux Rust effort being redirected at Redox OS.
If the Asahi team focused their efforts on Redox, with all the genius talent they they have, we could see an actually practical, usable implementation of Redox on real hardware; a potential daily-driver which would catapult the development of whole ecosystem - and that can only be a good thing.
snvzz 30 days ago [-]
Redox has stayed drama free so far.
I am sure most people involved with the Linux rust effort are also not problematic; these would be very welcome there.
OTOH, please don't let Redox be taken over by problematic people.
gkbrk 29 days ago [-]
Redox is drama-free because Redox has very few developers working on it. In the last 12 months, Redox had 7 contributors that touched more than 100 lines of code.
Hard to have too much drama if you have a handful of developers that do code changes, and no users to complain about any of your decisions.
scj 29 days ago [-]
"In 2010, after twenty years under development, Stallman said that he was "not very optimistic about the GNU Hurd. It makes some progress, but to be really superior it would require solving a lot of deep problems" - https://en.wikipedia.org/wiki/GNU_Hurd
pjmlp 30 days ago [-]
Most UNIX systems that were not implemented in C, and thus lacked the symbiotic relationship, never survived in the market, sadly.
There have been UNIX systems implemented, Pascal, Ada, Modula-2, Modula-3, as the most relevant ones.
All gone.
Also note that POSIX/UNIX certification requires a C compiler presence.
Narishma 30 days ago [-]
I don't think you can conclude anything from that since a ton of UNIX systems implemented in C are also dead.
pjmlp 30 days ago [-]
C was created to rewrite UNIX from its original Assembly implementation, naturally it is a symbiotic relationship not shared by other languages.
Note that many folks even forget that C++ was equally developed on the same Bell Labs group, and is probably one of the first examples of guest languages, making their best to fit into the platform, taking advantage of the ecosystem with almost zero friction, but never being able to control where the platform goes.
cdumler 30 days ago [-]
> C was created to rewrite UNIX from its original Assembly implementation
I don't think I can go with that one. C was created in the same period as people were trying to find a way to create a common platform, but C was more about trying to solve the problem of having a higher-level language that wasn't available for the low-end hardware (ie PDP-11, etc) of the time. Richie wasn't trying to reinvent the wheel.
He would have been happy to use other languages, but they were either design for large platforms which needed more resources (Fortran) or looking to be locked behind companies (IBM's PL/I). Richie considered BCPL, which at the time had a design that made it pretty easy to port if your computer was word-based (same size of bit-width for all numbers regardless of purpose). But, mini-frames were moving towards byte-based data and word or multi-word-based addressing. Plus, mini-frames had poorer hardware to make it cheaper, so typing on them meant more physical work.
A lot of UNIX design came from trying to use less: less memory, less paper, less typing. Richie tried to simplify BCPL to be less wordy by making B, but ultimately decided to jump to the next thing by making a language that would require as few keystroke as possible. That's why C is so symbolic: what is the least amount of typing to perform the concept? That made it pretty easy to translate to a fixed set assembly instructions; however, it hasn't had a symbiotic relationship with assembly.
If anything, it is the reverse. Just look at the compiler for all of the memory addressing it has to know. Look at any reasonably complex program of all of the compiler directives to see all the platform exceptions. C++ really took failure modes to the next level. My favorites is "a = b/*c;" Is that "a equals b divided by value pointed at by c" or "a equals b" with a comment? I left C++ a long time ago because I could take code that would compile on two different platforms and result in totally different behavior.
I think all of this drama has to do with the simple fact of there a bunch of people content to live in a one-langauge dominated environment and the head of Linux doesn't want to decide if that is or isn't the mandate; however, by not taking sides, he has effectively taken the one-language mandate. Rust needs to reimplement Linux.
tsimionescu 30 days ago [-]
> C++ really took failure modes to the next level. My favorites is "a = b/*c;" Is that "a equals b divided by value pointed at by c" or "a equals b" with a comment?
That is a really bizarre comment, especially including a comment that is perfectly valid K&R C, and just as "ambiguous" in that. The answer is of course that it is an assignment of the value b to a variable called a, followed by a comment. "/*" is always the start of a block comment.
Since C99 (and since forever in C++) there is also the new style comment, //, for commenting out the rest of the line, and this in fact broke certain older C programs (`a = b//* my comment*/ c;` used to mean a = b / c; in C89, and means `a = b` in C++ or C99).
int_19h 29 days ago [-]
Well, it is kinda weird to take what would otherwise be perfectly legitimate and meaningful syntax and make it a comment. E.g. Pascal uses (* *) instead, and there's no other construct in the language where those can legitimately appear in this order.
tsimionescu 29 days ago [-]
Sure, but it's still a choice that C made, long before C++, so it's bizarre to see it in reference to how much worse C++ is.
As for the actual syntax itself, I do wonder why they didn't use ## or #{ }# or something similar, since # was only being used for the preprocessor, whereas / and * were much more common.
int_19h 28 days ago [-]
/* */ is a PL/I thing that somehow ended up in B. I suspect that Ritchie just wanted multiline comments (which BCPL didn't have - it only had // line comments), and just grabbed the syntax from another language he was familiar with without much consideration.
Or maybe he just didn't care about having to use whitespace to disambiguate. The other piece of similarly ambiguous syntax in B is the compound assignment, which was =+ =- =* =/ rather than the more familiar C-style += etc. So a=+a and a= +a would have different meaning.
pjmlp 30 days ago [-]
That is the usual cargo cult story of C, systems programming languages go back to JOVIAL in 1958, NEWP in 1961, one of the first systems programming languages with intrinsics and unsafe code blocks.
You surely aren't advocating that hardware predating PDP-11 for a decade are more powerful.
There is enough material that show had UNIX been a commercial product instead of free beer source code, most likely C would have been just another systems language in the mysts of time.
doug-moen 29 days ago [-]
> You surely aren't advocating that hardware predating PDP-11 for a decade are more powerful.
That's correct. The PDP-11 used for the first Unix system had 24KBytes of memory, and no virtual memory. The kernel and the current running process had to both fit in 24KB. This PDP-11 minicomputer was vastly underpowered compared to ten year old mainframes (but was also far less expensive). The ability of Unix to run on such underpowered (and cheap) machines was a factor in its early popularity.
BCPL was first implemented on an IBM 7094 running CTSS at Project Mac at MIT. This was one of the most powerful mainframes of its era. It had 12× the memory of the Unix group’s PDP-11, plus memory protection to separate kernel memory from user memory. One of the historical papers about C noted that a BCPL compiler could not be made to run on the PDP-11 because it needed too much memory. It needed to keep the entire parse tree of a function in memory while generating code for that function. C was designed so that machine code could be generated one statement at a time while parsing a function.
okanat 29 days ago [-]
Market failures of the other Unices aren't necessarily related to the technical advantages or disadvantages or symbiosis with C or being implemented in C. However, making C programmers' life easier was crucial.
Linux was at the correct place at the correct time. It was the only free version of Unix-like OSes that didn't have legal bullshit to deal with. IBM and Intel's support also made GNU/Linux ecosystem successful, without them it would stay as an academic project. Being free meant that it had an advantage where price sensitivity mattered and dotcom boom and VC explosion is very sensitive to cheaping out and preffers suffering with less-than-ideal software. So Linux stayed popular while other ones died slowly.
C had a huge following and all OSes had to support it. Simplicity made it popular when average hardware at the hands of many academics and young professionals was very weak. Being written in C may have made things marginally easier but neglecting it for Ada or Pascal was a terminal mistake. Windows isn't Unix at all but it also had to support C well.
pjmlp 29 days ago [-]
Free beer OS with source tapes and the Lions book made the huge following of academics and young professionals.
Had AT&T been able to sell UNIX, and naturally C, at the same price points as VMS, System 360, and many other contemporary OSes, and none of us would be talking about them today, other than history curiosities.
Instead we are left with UNIX haters handbook, and still trying to fix the security issues across the industry caused by C's adoption, the JavaScript and PHP of systems programming languages, both in adoption scale, and code quality.
msh 30 days ago [-]
OSX would like to disagree with you.
pjmlp 29 days ago [-]
First of all I mentioned most, not all.
Second, while OS X, and NeXTSTEP before it, are technically UNIX, they aren't seen as such by either NeXT, nor Apple.
The focus of the whole userspace experience is on Objective-C frameworks, nowadays also a mix of Swift and C++.
Steve Jobs was famously against UNIX culture, there was even a famous attendance of him at USENIX.
NeXTSTEP was based on UNIX, because Steve Job wanted to win the workstation market against Sun, using UNIX compatibility as EEE, bringing folks into NeXTSTEP and keeping them there with Objective-C development experience, Lotus Improv, Renderman and such.
kennysoona 29 days ago [-]
> NeXTSTEP was based on UNIX, because Steve Job wanted to win the workstation market against Sun, using UNIX compatibility as EEE, bringing folks into NeXTSTEP and keeping them there with Objective-C development experience, Lotus Improv, Renderman and such.
So Embrace, Extend and Extinguish?
int_19h 29 days ago [-]
If macOS isn't see as UNIX by Apple, why does the latter continue to submit it for certification?
tsimionescu 30 days ago [-]
Is the OSX kernel not written in C?
KerrAvon 29 days ago [-]
the modular parts (IOKit) are C++
p_l 30 days ago [-]
Linux kernel is also one of the few that do not use C ABI as entry point for user programs at all.
As for C compiler presence in POSIX, only existence of C-accessible APIs with specific structure are mandated, C compiler is optional just like Fortran runtime and compiler are.
> On systems providing POSIX Conformance (see XBD Conformance), c99 is required only with the C-Language Development option; XSI-conformant systems always provide c99.
If XSI conformance is not asserted, only requirement is that C APIs and runtime libs for use by C programs exist on the system, and presence of C compiler is optional,
2017 POSIX had done away with including Fortran 77 in the same category as C, only providing an option for Fortran runtime libs but no longer specifying a Fortran development environment.
Also, I do not have relevant systems on hands to check, but as far as I know multiple Unix systems including behemoths like SunOS/Solaris shipped as POSIX compliant without C compiler.
pjmlp 29 days ago [-]
Ok, but that is the split certification due to the way Sun started to introduce on UNIX world the SDK concept, where customers had to additionally pay for the development tools, the UNIX version of UNIX Home and UNIX Pro editions.
Naturally UNIX Home users are also using a UNIX, and UNIX Pro, users have anyway a C compiler.
Also to note, exactly because nothing else is required, there used to be UNIX vendors, like Sun, that only included C and C++ on their base SDK. Fortran and Ada compilers were additional products to acquire on top of the SDK. Naturally most folks didn't even bother.
30 days ago [-]
starspangled 30 days ago [-]
Yes, perhaps a C-only Linux would do that and die, and perhaps it would continue its customization of C flavor and runtime it uses (e.g., the various static and dynamic memory limitations and checkers) and closes the gap with Rust to a point where the incremental benefit of using it is not significant enough that it makes a Rust based competitor an inevitability. We may already be beyond that point, even.
Philpax 30 days ago [-]
The changes required to bring C to a Rust level of safety would make it an entirely different language, even when restricted to the kernel's domain. Also, if you're already doing codebase-specific patches to the language itself, many of the arguments around codebase portability that justify the use of C fall apart.
Aside from that, there are other benefits to Rust than safety: it's better at modelling data and states, as the now-infamous filesystem talk [0] outlined.
> The changes required to bring C to a Rust level of safety would make it an entirely different language, even when restricted to the kernel's domain.
Maybe. 1. It may not have to be "Rust-level of safety" to be good enough to make Rust benefit less compelling. 2. Linux C is already a different languag than C, continued incremental changes might be a better way to get there than adding Rust even if it does become very different in the end.
> Also, if you're already doing codebase-specific patches to the language itself, many of the arguments around codebase portability that justify the use of C fall apart.
Sure, but Linux never had a "codebase portability" argument. It always had to be GCC C. It eventually made some relatively small changes to allow clang to compile it, the far bulk of that work being changing of clang to behave like GCC.
> Aside from that, there are other benefits to Rust than safety: it's better at modelling data and states, as the now-infamous filesystem talk [0] outlined.
Yeah, it's not only safety improvements that are in Linux-C.
hulitu 30 days ago [-]
> The changes required to bring C to a Rust level of safety
cough* Cargo cough* /s
You cannot have safety or security when you download your code from the internet and this code is a moving target.
steveklabnik 30 days ago [-]
The kernel does not use Cargo.
hulitu 29 days ago [-]
For the moment./s
ivell 29 days ago [-]
Or may be Zig might be more acceptable to the Kernal team, once it becomes mature enough?
coliveira 29 days ago [-]
This is inevitable: Rust is proposed as a safe language, but there is no way to have a "half-secure" kernel. The only option for people who believe in Rust is to have its own kernel, and Linux should have no part on this.
whytevuhuni 29 days ago [-]
> there is no way to have a "half-secure" kernel.
There is, and this is how Rust naturally works. If you look at its standard library, you will see a lot of unsafe code or libc calls hidden away under safe interfaces.
In fact, this is how all memory safe languages work, including Java, Python, etc: A small trusted base written in an unsafe language that exposes a safe interface (i.e. the interpreter, the JVM, etc), with the large majority of the code written over that safe interface (i.e. the Java/Python code).
Rust is used to make kernel drivers secure by providing a safe interface for them to use.
account42 27 days ago [-]
Keeping the project single language doesn't mean that the project can't change. The C used today is not the same C used when when the project was started. Changing language is also possible. Using two different languages long-term however means that everyone effectively needs to be proficient in both languages and a lot of work is duplicated.
mort96 30 days ago [-]
Would you say that C is "here to stay" in Linux? I would say so. I think you understood what was meant.
mu53 30 days ago [-]
The drama is the problem, not rust. I don't know why, but either zealots choose rust or rust induces zealotry.
Its exactly what Linus said.
Aeolun 29 days ago [-]
Of perfectly moderate Rust users get annoyed with C zealots?
account42 27 days ago [-]
That might be an argument if those C zealots were trying to add their language to a Rust project. Don't play in someone else's back yard and then complain that their are not pampering you enough.
mort96 30 days ago [-]
I don't understand how this is related to what I said.
ksec 28 days ago [-]
>. I don't know why, but either zealots choose rust or rust induces zealotry.
That is actually quite well put together. May be The language that introduce absolute control also induces zealotry and produce zealots.
However that doesn't happen with Ada. So that cant be the full explanation.
starspangled 28 days ago [-]
No I wouldn't say that. If Rust or another language eventually proved itself more value than C and things were eventually all rewritten, C would go away.
For that matter the C of Linux 10 years ago was not there to stay either, it has changed and certain features and practices are deprecated and dropped and others adopted. It's not the same C.
winocm 30 days ago [-]
DEC Alpha support is somehow still in the mainline Linux kernel...
To be fair, anything that does not support BWX is really painful to deal with.
Take, for example, an 8-bit/byte store. Without BWX the sequence would be something like:
bic a0, #3, t1
and a0, #3, t4
ldl t2, (t1)
insbl a1, t4, t3
mskbl t2, t4, t2
bis t2, t3, t2
stl t2, (t1)
ret zero, (ra)
But with BWX, it becomes:
stb a1, 0(a0)
ret zero, (ra)
Locutus_ 29 days ago [-]
The ghost of the Alpha's infamously weak memory model coming back to bite it's undead self.
starspangled 29 days ago [-]
Yeah m68k is still around too and it has more than a decade on alpha.
People use and maintain them and they have very little impact outside arch/ nowadays so they're on the happy side of cost/benefit I guess.
winocm 29 days ago [-]
I guess the biggest difference is that Coldfire parts are still being produced (c.f: MCF52256CVN66).
I'm not sure if Alphas are even being made anymore, even 15-20 years ago.
Locutus_ 29 days ago [-]
M68k has the advantage that it has a fairly typical memory model.
Alpha's memory model has problems with providing atomic access to single bytes, which i'd imagine in a kernel is a bit annoying :-)
And then there's just the social aspect, m68k was used in the Amiga/Atari/Mac/QL/x68k, so there is a whole generation of us m68k fans who are willing to keep it alive.
Alpha has it's fans (me included!), but it's not exactly the same. So in a way it's no surprise it's slowly bitrotting away.
starspangled 27 days ago [-]
Since the C compiler can hide that, for core kernel code I think the more problematic thing was Alpha's memory consistency model where (data-)dependent loads accesses did not imply ordering, which is unusual and more burdensome to the programmer than any other ISA.
That required this smp_read_barrier_depends() through the kernel, but actually in recent years that has basically been subsumed by other concurrent access primitives that all the core kernel must use, so I think alpha is no longer much of a problem outside arch/alpha
winocm 29 days ago [-]
Ah, my favorite instructions, 'hw_ldl/l', 'hw_stl/c', 'ldl_l', 'stl_c' and their quadword siblings.
cycomanic 29 days ago [-]
The problem is, that he let's a maintainer say he is going to fight any Rust code getting into any "core" (whatever he considers core) part of the kernel, even if it's just a wrapper to make driver code more maintainable. I would say, that's a strategy decision that should not be up to any subsystem maintainer, that's a decision that should be up to Linus, by not intervening he essentially endorses that getting rust into the kernel requires consensus from all subsystem maintainers. I don't believe that was what the rust guys thought they'd be signing up for.
gary_0 29 days ago [-]
> by not intervening he essentially endorses that getting rust into the kernel requires consensus from all subsystem maintainers
And let's not be obtuse, some of those subsystem maintainers are staunchly opposed, so "it's up to them" is obviously an indirect way of saying "no rust". I don't blame those maintainers for balking at a whole new very different language, but Torvalds has a choice of telling them either "suck it up, buttercup" or "I hear you; rust is gone". Instead, he's just letting things fester.
chikere232 29 days ago [-]
This seems like black and white thinking. There's a huge spectrum between
> "suck it up, buttercup" or "I hear you; rust is gone".
where various levels of compromise happens.
Maintainers are people and people can change their mind over time. If rust was a huge success in large parts of the kernel and you still had a few holdouts, sure, you could tell them to adapt or go away. In this early stage, it's kinda up to rust people to show that both they and rust can work in this setting
tomnipotent 29 days ago [-]
> that's a strategy decision that should not be up to any subsystem maintainer
So people are not allowed to hold positions and argue for them in public, or take actions that align with that position?
> I don't believe that was what the rust guys thought they'd be signing up for
It's not like there wasn't any existing precedence with C++, and many of the arguments I've read seem consistent with that history.
cycomanic 29 days ago [-]
The C++ situation was completely different, Linus said from the get go "no way", thus nobody put serious work writing c++ code for the kernel. With Rust Linus essentially said let's see how it goes, but specifically said he would deal with maintainers who would be unwilling to consider code that would be necessary for R4L.
Based on this people invested significant work into writing code that is quite widely used, only to now have a maintainer saying he'll oppose any Rust code coming into the kernel, and Linus saying the guys trying to get the code in are the problem.
account42 27 days ago [-]
> that's a decision that should be up to Linus, by not intervening he essentially endorses that getting rust into the kernel requires consensus from all subsystem maintainers.
And that's a perfectly resonable position.
gauge_field 30 days ago [-]
Agree with that. His statements are available on youtube. I was suprised how positive and eager to the change he was.
melodyogonna 29 days ago [-]
Why would he make such blanket decision on something he does not completely understand?
The maintainers of core subsystems are the people he trusts, at least trusts as much as you can in this space. He'll take their opinions before anyone else, since they know best about the subsystems they maintain.
To get Linux to overrule them you not only need to come up with very very convincing technical argument, you have to make sure you also posses the depth and competence required to maintain any such subsystem if the maintainers rage quit. Because you see, maintainers of these subsystems resigning is the bigger blow
lonjil 29 days ago [-]
> The maintainers of core subsystems are the people he trusts, at least trusts as much as you can in this space. He'll take their opinions before anyone else, since they know best about the subsystems they maintain
But there were no technical arguments against the Rust wrapper. And in any case, the Rust wrapper isn't in that subsystem, it just uses that subsystem. Hellwig's argument was nothing more than "there shouldn't be a second language in the kernel". He had nothing specific about the DMA wrapper. And Linus has already approved Rust in the Linux kernel, so what's the problem? Why can't Linus put his foot down on an issue that he has already decided on?
soraminazuki 29 days ago [-]
> Hellwig's argument was nothing more than "there shouldn't be a second language in the kernel".
Which is a valid viewpoint. Let's not pretend that's not a technical argument.
Having different technical views from yours isn't a crime, legally or morally.
> And Linus has already approved Rust in the Linux kernel, so what's the problem?
As an experiment, as clearly stated in the kernel docs. It's still up to the whole community to figure out how exactly to proceed with it.
> > Hellwig's argument was nothing more than "there shouldn't be a second language in the kernel".
> Which is a valid viewpoint. Let's not pretend that's not a technical argument.
So if Linus shouldn't overrule his deputies, and one deputy can completely block something in a subsystem that isn't theirs and has explicitly stated to do "everything in their power" to stop it, what exactly can the community "figure out" to get it to proceed? His decision not to get involved literally makes it impossible for the situation to change, so the confusion is why it's being phrased as if it's anything other than that.
If Linus were to come out and say "I changed my mind, I no longer think it's worth pursing trying to integrate Rust in the kernel due given the issues at hand" or even "regardless of my personal views, I don't have any desire to change the current system we have for how code gets merged into subsystems or who has the ability to block it, so I'm not going to overrule this", it would make a lot more sense to me, but by making it sound like there's anything left to figure out when someone with veto power has a stated intent to stop things from moving forward is just going to let the issue fester and produce more frustration on both sides. It almost seems inevitable that any future discussions will spiral out of control; there's no other way for it to conclude than either Linus overruling his deputy or the experiment just ending as a failure at this point, so he might as well just make that decision now rather than later.
Ar-Curunir 29 days ago [-]
It is not a valid reason to reject a patch when the decision to include the second language in the kernel has already been made.
soraminazuki 29 days ago [-]
A decision to include Rust in the kernel isn't a decision to include any patches from any specific person with no questions asked.
It's valid for maintainers to reject a patch even if you disagree with the reason. Repeatedly causing social media storms to "shame" them for doing so, Marcan's own word BTW, isn't.
Rust is young and efforts to use it in kernel programming is even more so. It's completely understandable for wanting to take things slow and not be too quick to put it in places where there would be no going back. Everyone should at least be able to recognize that this concern exists, regardless of their opinions on Rust.
johnny22 29 days ago [-]
> A decision to include Rust in the kernel isn't a decision to include any patches from any specific person with no questions asked.
This is not what's happening.
preisschild 29 days ago [-]
> It's completely understandable for wanting to take things slow and not be too quick to put it in places where there would be no going back.
Have you even seen the original thread? It wasnt about "taking it slow", he was trying to block R4L permanently.
dralley 29 days ago [-]
I'm sorry, but no. Christoph clearly didn't even spend 5 seconds looking at the patches before rejecting them. His first objection was obviously false, and when this was pointed out he fell back on blanket objection to rust without any real technical argument.
29 days ago [-]
tptacek 30 days ago [-]
I think at the point where you're loudly complaining about the email patch process (and hey, I agree it's the worst), this has stopped being about Rust.
Hackbraten 30 days ago [-]
May I ask which aspect of the email patch process you're referring to?
Arguably, I've used it only once to contribute a kernel bugfix, and I was lucky enough that my patch got accepted as is. So I found the process pretty straightforward.
But even with iterations and revisions factored in, kernel work itself feels orders of magnitude more complex and cumbersome to me than a patch process based on a mailing list could ever be?
I agree that Linus should have made a clear statement.
> Maybe he knows he should, but he fears the shitstorm it will cause.
I always felt that the Rust community is creating a huge social pressure on lots of projects. Rust was more forced into the Linux kernel than being welcomed by Linus and many core maintainers. The pronounced evangelism (not a compliment!) in the Rust community is not only off-putting by being a form of non-violent aggression but creates real problems like wasted energy and resources. This is not generally true, as there're great examples of Rust being adopted from within projects. But also others where Rust was pushed from the outside, like curl.
In my opinion it's a failed experiment. The reason for the failure might not be on the technical side, but on the social side. On the other hand, if Linus wants Rust in the kernel as a way to get new, young, enthusiastic devs into Linux core development, than he should use his role and make a very clear statement as he's done before, like: "Everybody shut up and accept and welcome Rust as first class citizen."
29 days ago [-]
ouraf 30 days ago [-]
Maybe it's because of Linus' age or because the players involved are bigger than many past issues, but the way I see it, both decisions are really costly:
- Endorse Rust with little reserve and over half of the C++ devs will feel betrayed and quit supporting the Linux project. They've been working on C++ for Decades and things mostly worked, so they won't pivot for a new language and way of developing for something that exists for less than 30 years.
- Ban rust contributions and the entire Linux foundation goes directly against some big players, like DARPA and other departments of the American government[1], which itself is a trend setter. Some big sponsors might also pull out and that ALSO removes devs from the project.
So, which decision would be so overwhelmingly more advantageous that's worth taking all the negatives of the other on the chin rather than trying to minimize harm and wait to see if either Rust software proves to be not so magically immune to memory leaks and vulnerabilities or if some tool makes the transition less contentious?
> over half of the C++ devs will feel betrayed and quit supporting the Linux project. They've been working on C++ for Decades and things mostly worked, so they won't pivot for a new language and way of developing for something that exists for less than 30 years.
You mean C? C++ has been dead and buried for years and there are 0 kernel devs thinking that C++ will ever be allowed in (that idea was killed in the 00s if I recall correctly).
I don't think the situation is quite as extreme as you're making it out. For example, the employers of Linux kernel devs are getting pressure to use Rust because of the push from within & without the industry. I think push comes to shove, most people have a stronger preference for their paycheck than for the language they work in.
stycznik 29 days ago [-]
With a project as massive as Linux I doubt you can ever assert "there are 0 kernel devs who want [something]"
And I still think the culture clash angle should be taken more seriously.
An accomplished senior C dev can find good jobs writing drivers or microcontroller code more easily than starting over into a junior rust dev and being talked down by whomever joined the rust wave before them.
(which would be even more aggravating if the C dev is doing it since before the rust adopter was born).
vhantz 29 days ago [-]
> C++ has been dead and buried for years
LOL, lmao even.
ashenke 29 days ago [-]
In the Linux kernel
hypothesis 29 days ago [-]
> like DARPA and other departments of the American government[1]
Eh, that White House link is dead right now and I would not be shocked if whole department is purged soon, so who knows anymore…
4bpp 29 days ago [-]
I do wonder if Linus is actually opposed to Rust in the kernel, but for whatever reason thinks that he can't afford to openly ban it or do anything beyond deniably letting it be obstructed by maintainers. The Rust language project and community are political and politically savvy in ways that few other open-source infrastructure projects are - it seems conceivable that if he declared against it, this might result in personal attacks and pressure on key backers/sponsors that would endanger his position or Linux itself.
chikere232 29 days ago [-]
It would be a silly strategy compared to saying that mixing languages is a bad idea and rely on inertia.
Also, letting rust in doesn't seem to stop the personal attacks, case in point
geodel 28 days ago [-]
Very reasonable take. I feel the same. Any kind of real or perceived attack on Rust is heresy today.
kashyapc 29 days ago [-]
> Arguably his reprimand of Martin is a clear signal that he will never show Rust any favor, but he hasn't said anything explicitly. [...]
I don't see it that way. Linus is conscious of not becoming a bottleneck on every topic; he doesn't want to baby-sit overly grown adults. I read most of the relevant LKML thread[1]. Martin did the unwise thing of escalating it on social media:
"If shaming on social media does not work, then tell me what does, because I'm out of ideas."
That is not the way to build bridges and relationships in a community! No matter how frustrated you are. He reaped the whirlwind for taking that destructive approach.
Also, Christoph Hellwig, as an established maintainer, totally missed the mark by using the highly-flammable word, "cancer", to describe Rust. It scorched the LKML and the internet. He should have showed more restraint and wisdom.
And his viewpoint at the time seemed fairly agnostic - he enjoyed the passion on both sides but said nothing about what his thoughts were. This leads me to believe that he hasn't spent the time to think about the important issues on either side and make a decision (the failure of leadership mentioned in the parent comment).
Personally, I'm surprised Linus hasn't gone 100% in on Rust as he is normally very forward-thinking, so perhaps that has added to the frustration from so many kernel developers like Hector.
chikere232 29 days ago [-]
If you're gonna lead a group of people effectively, you kinda have to listen to them. leading by decree works occasionally, but you can't afford to do it often.
If there's a lot of people sceptical to rust, doing a limited experiment is one way to figure out if it's going to work. Rust people working in the kernel should act accordingly. Drama like this is not helpful
eviks 29 days ago [-]
How is it uncommon if the issues identified in this drama cycle (eg from here https://lore.kernel.org/rust-for-linux/208e1fc3-cfc3-4a26-98...) are systemic and have existed for many years? That's just a continuous failure of leadership, all ignored by said leadership under the pretense that "it works, so it must be right"
astrobe_ 29 days ago [-]
> The Rust drama is an uncommon failure of leadership for Torvalds. Instead of decisively saying "no, never" or "yes, make it so," [...]
It feels like over the year he has been sort of beaten into submission both for his outbursts (which I've always found more funny than offensive) and the lobbying of the zealots of a certain relatively young programming language (which sometimes has a little taste of propaganda) against "memory unsafe languages".
rednafi 30 days ago [-]
People get old and stop caring. Linus is still doing amazing. But I agree he should have just said no to Rust and move on.
nomel 30 days ago [-]
Why? Was it not worth seeing where it would go, or how many would be interested? Is it possible he believed the tides could turn that way?
snvzz 29 days ago [-]
It wasn't going to work without ample support within the kernel.
At a minimum, all prominent developers would have to be convinced and ready to put a lot of effort into this.
As this was never the case, Linus should have put his foot down with a clear No, thus preventing the conflict and overall waste of resources we're seeing.
Rust devs would still be able to fork or otherwise (much better idea imho) work on their own kernel, hopefully with a much better design.
Redox is doing this, with a microkernel multiserver approach.
rednafi 29 days ago [-]
And look where it got us!
ksec 28 days ago [-]
>..... Instead of decisively saying "no, never" or "yes, make it so," he has consistently equivocated on the Rust issue.......if Linus had just said "no, keep it downstream".
I have been thinking for years that the reason why Linux dont attack Rust like all other languages is that his close friend or close subordinate like Greg actually like rust. So rust as a language has huge leverage within the Linus decision mental model.
Not to mention the huge Rust gang both on the internet and around him. Friends that support Rust. Having the usual strong opinions of Rust like he had for C++ will obviously damage friendship.
account42 27 days ago [-]
I always suspected it was commercial/government pressure. Hard to argue against "doing something" for safety.
throwaway2037 29 days ago [-]
Can I ask something controversial? What if Rust never becomes a significant part of the Linux kernel? What if they keep stalling and all the people pushing for it give up? There seems to be this faith on HN that Rust absolutely belongs in the Linux kernel and if not, the project is a failure.
hinkley 29 days ago [-]
If you wait long enough a Rust competitor will gain traction. And honestly I wonder if that might not be for the best. How many of rust’s features have only been tried a couple of times?
pornel 29 days ago [-]
The Rust project started 15 years ago, and spent a decade growing userbase, library ecosystem, and proving that it's a serious language that's here to stay (which some C maintainers still don't believe).
We don't have a Rust-killer language yet. The closest one is SafeC++ (Circle), but it's still a single-dev proof of concept, and the C++ leadership firmly rejected it. Zig went in a different direction. Swift is adding Rust-like features, but it's unclear if that's going to be compelling. Ownership and borrowing is spreading to Mojo and Ocaml, but they're not kernel languages.
Even if there's a Rust-killer tomorrow, it will go through the same growing pains of rewriting everything and being treated as just a temporary hype. It will have to prove why use the new language instead of Rust that's already here, and had even more time to establish itself.
matu3ba 29 days ago [-]
> We don't have a Rust-killer language yet.
The type-system analysis of Rust is smart, but not restricted to the language per se, see https://github.com/ityonemo/clr. One merely has to have proper namespacing and necessary type info from generic code to do annotations and solve them. These things are solved in Rust via trait system.
Retroactively patching C to have namespaces will not work and same holds for generics, meaning concrete how to attach lifetimes to generic code.
> Zig went in a different direction.
There is stuff cooking for debugging comptime and better than lsp infos, but this is only wip and hearsay. Might be enough to write external static analysis or not.
Correct me, if wrong etc.
pornel 28 days ago [-]
There was also Cyclone before Rust, and Checked-C in the meantime. The concepts like regions and affine types existed long before Rust, and Rust started out by copying from older languages (http://venge.net/graydon/talks/intro-talk-2.pdf).
It's not enough to have just a proof-of-concept compiler that could match Rust's checks — that's where Rust was 10 years ago. Rust had time to polish its compiler, expand tooling, integrations, platform support, attract contributors, grow userbase, create learning materials, etc. To displace Rust of today you don't need to just match the old starting point, but offer something better by a margin large enough to offset the cost and risk of switching to a less mature language. That's the same problem that Rust is facing when trying to displace even more established C and C++.
matu3ba 28 days ago [-]
Yes, I do agree with you. Just wanted to inform you that it may still be possible in principle and as you can see with development speed, build system, dependencies etc there is a potential angle.
jandrewrogers 29 days ago [-]
> We don't have a Rust-killer language yet.
We don't even have a C++ killer language yet. These things move very slowly.
throwaway2037 29 days ago [-]
> If you wait long enough a Rust competitor will gain traction.
Are you implying that a fork of the Linux kernel will win? I doubt it. The Linux kernel is over 30 years old and has resisted multiple attempts to fork. In all cases, it was the winner. What is different this time?
Gibbon1 29 days ago [-]
My thought is what's telling is the 'rewrite it in rust'. Rust doesn't have a new business case.
C was better than assembly.
C++ was better than C for GUI applications.
JAVA has garbage collection and usually won't force you to fix your machine after a bad crash.
Python is better than Perl for quick and dirty stuff.
PHP lets you build a web service without much pain.
C# is a better Java that also gives you better integration with Windows.
Go does a good job with small quick running services.
Lua is easy to integrate into programs.
I look at existing C codebases. They're usually well worn and work okay.
C++ codebases would probably be better rewritten in Go or C#
Go codebases? Switching to Rust so you can what exactly?
PHP? Keep using it or us Go.
I also feel like Go, C#, and Python are designed to be fairly easy for a noob to come up to speed. Where Rust is the opposite.
jack_pp 29 days ago [-]
I guess you make a living writing zero day exploits?
Gibbon1 29 days ago [-]
Keep believing that Rust magically prevents you from getting owned when you fuck up.
_ph_ 29 days ago [-]
That is a fallacy. No one has claimed that Rust magically prevents you from getting owned. Quite to the contrary: there is no magic in preventing most, if not all memory handling errors. Which are the most common reason for security problems. Removing one category of errors entirely would free a lot of resources to deal with the remaining ones.
uecker 29 days ago [-]
Even the "removing one category of errors" is not true when you use unsafe blocks in Rust, which is done generously in system programming.
_ph_ 29 days ago [-]
Is that so? How large parts of the Rust kernel drivers in existence are inside unsafe blocks?
Yes, unsafe, as the name says, allows unsafe parts. But it is trivial to audit code for the usage of unsafe. Which means, everything else isn't. And it is there where the most common mistakes are made.
This is exactly the mistakes we also have in C and Rust people would do a little dance and take such bugs as argument why C is really dangerous and needs to be avoided. But rather obviously, mistakes can also happen in Rust and Rust does not "eliminate a class of errors" except when completely avoiding unsafe blocks. Maybe Rust is still more memory safe than C, I actually also believe this, but it is nowhere as safe as people like to claim and whether this is worth all the complexity is entirely unclear.
_ph_ 29 days ago [-]
It is trivial to audit the usage of "unsafe". Grep does this. Of course auditing the unsafe functions is another thing. But you can have large codebases without unsafe and consequently a lot of less work with auditing your code.
I don't have personal experience with Rust, but quite a bit with Go. It is almost ridiculous, how much more safe Go is in comparison with C. So yes, it is worth every bit.
uecker 29 days ago [-]
The example shows that Rust can not even prevent an error as something simple as in a matrix transpose. Sure, you could write safe code, but how does this help if people don't do it? It is the exact same problem as in C and I have seen C code that is very reasonable.
_ph_ 28 days ago [-]
Do you have a link to the code with the error? Following your link I didn't see it.
Ok, thanks, finally found the source of transpose. That uses unsafe. Which of course means, all guarantees of safety are off. I am not sure why the usage of unsafe is necessary here, but one way or the other, safety now is in the hand of the programmer.
My point rather was: wherever you don't use unsafe, you are protected by the compiler from certain errors. Which I consider extremely important, that is why I am a strong proponent of memory-safe languages.
Now, if there is a question whether Rust requires you to use unsafe to often, that would be a valid technical critique of Rust, but that didn't seem to drive the Linux discussion.
uecker 27 days ago [-]
I think this is exactly the life lie of Rust. It claims to be memory safe and equally suited for system programming. But you get memory safety only when completely avoiding unsafe and it competes with C only when using unsafe. And it is certainly not true that you get memory safety in the part not using unsafe or that you only need to review the unsafe part. The memory safety of the safe part depends on the programmer maintaining invariances in the unsafe part that the Rust compilers needs to ensure the memory safety. At the same time the safety prerequisites of the unsafe parts can be violated by logic errors in the safe part (as in the transpose examples). It still helps to isolate the unsafe part, but in practice I am not convinced that the typical Rust code I see for system programming is fundamentally more secure than equally well designed C code which was also written with an eye towards memory safety and with use of modern tools to find problems.
WesolyKubeczek 29 days ago [-]
Still owns you, but without data races!
WesolyKubeczek 29 days ago [-]
> Go codebases? Switching to Rust so you can what exactly?
The way I heard it, the Rust's type system, async implementation(s), they way lifetimes just keep propagating once you start, and its macro languages are way more engaging, thus Rust must be superior.
kykeonaut 29 days ago [-]
but those improvements, and the complexity that they bring, are not enough to make the switch from a Go codebase to a Rust codebase unless performance is REALLY an issue.
andrewstuart 30 days ago [-]
Rust is bad news for Linux.
No because its Rust, but because it's a bad idea to use more than one single language across the entire code base.
I also am surprised that Linus has not ended this folly.
If Rust wants a Linux kernel it should make one.
tadfisher 30 days ago [-]
Do you feel the same about Make, Device Tree, KConfig, Python, the myriad of machine-specific assembly, POSIX shell, Perl, and every other non-C language currently in the code base?
wahern 29 days ago [-]
That's a false equivalency. All of those languages are integrated through strong semantic and concrete abstractions (e.g. file system I/O or GCC interfaces) that evolve, if at all, very slowly. Some, like assembly, are necessary concessions, and are exceptions that prove the rule--developers prefer GCC builtins if available, for example.
The problem with Rust in the kernel is that the kernel has historically eschewed strong internal abstractions. The Linux kernel has no principled abstract architecture in the same way that Windows NT does; it has evolved very organically and even some of the most foundational subsystem APIs regularly see refactorings that touch almost every corner of the kernel.
The latest dispute (if it could be called that) regarding Rust was Rust building abstractions around the DMA interface. There's nothing wrong with this, per se. For Rust it's a necessary chore. But when you build complex abstractions atop something, you're either ossifying the interface or building a sand castle. If we're being charitable, some Linux developers felt like this was pressure to ossify the existing abstractions. Rust developers, OTOH, promised that they'd take full responsibility for any future refactoring, implicitly admitting that they understood they were building a sand castle.
How do you bridge that divide? Because of the lack of hard architectural line drawing in how Linux is developed, the norm is that both redesigns and refactoring are in many respects highly cooperative (notwithstanding the bickering and friction). A subsystem maintainer contemplating a redesign takes into consideration the burdens on other users, and how a redesign might be incrementally rolled out, if at all. Conversely, users of interfaces know--or should know--to take into consideration future potential changes in an interface when relying on an interface for their subsystems. It's a constant back-and-forth, give-and-take, but also messy and chaotic. Transparency in source code is key--this kind of development would never work in commercial projects across binary interfaces. Yet in important respects that's what the interface between C and Rust is like--opaque--especially when developers on one side aren't intimately familiar with the semantics of the other and how they translate, if at all, across the boundary.
Now here comes Rust, which has spent years putting into place the infrastructure just to get some drivers going. Rust as a language demands careful architecture and line drawing. It's no surprise that much of that initial infrastructure effort, excluding the build, was expended on building towers of abstraction. Refactoring can be painful in Rust when it involves very low-level changes in semantics (the kind that are common in kernel development), and while there are tools to help address that, they don't work well, or at all, outside of Rust. There's a huge impedance mismatch between Rust and historic Linux kernel development. In user land, developers' experience is that Rust is relatively easy to interface with C libraries. But that experience is primarily interfacing with public APIs, those public APIs have always been quite stable, and user land libraries (at least the good ones) are designed to be, as much as possible, blackboxes from the outside. Abstractions that leak tend to be fixed abstractions, like file descriptors, etc, that are typical for the environment and rather predictable.
That situation with user land C FFI is utterly incomparable to how interfaces evolve in Linux. The clash between these worlds, at both a technical and cultural level, was inevitable. Heck, it was evident from day 1. This doesn't make either side right or wrong, and I'm not trying to suggest that the Linux developer community can't figure out a path forward. But it's a difficult problem on many levels.
roca 29 days ago [-]
> Refactoring can be painful in Rust when it involves very low-level changes in semantics
I don't know what this is about. In my experience, refactorings that change the semantics of APIs are much easier in Rust than in C. E.g., change assumptions about the lifetimes of pointers passed into APIs: the Rust compiler will tell you where you need to change anything; the C compiler will happily compile your code and you'll corrupt memory at runtime.
wahern 29 days ago [-]
Right, and while sometimes a lot of code needs to change in Rust, it's often largely mechanical, at least in typical contexts (e.g. user land development). But Rust won't automatically detect changes in semantics that happen across FFI boundaries. And I didn't argue that refactoring is easier in C than Rust. For one thing, it's an inapt comparison in the context of a mixed C and Rust kernel codebase in which the vast majority of the code and semantics come from the C side.
And there are more subtle issues. From the perspective of C code, Rust looks and behave as if it assumes strict aliasing, a consequence of the borrowing rules--a mutable pointer can never alias. But the Linux kernel uses -fno-strict-alias (i.e. any pointer can alias, regardless of type), so a subtle change in C code which works fine for the kernel could silently break Rust code if the C-side developer wasn't aware of these subtle nuances in memory models and how they were expressed in the unsafe wrappers. This might be a totally contrived scenario[1], or it could be very real given the tower of abstractions built on the Rust side over the C APIs, which might overspecify certain semantics to fit "cleanly" (i.e. best practice) into the Rust model.
Which points at another issue: all of these hypotheticals might be (probably are?) overblown. But over the past 2-3 years, with the exception of a couple of high-profile drivers not yet mainlined (AFAIU), the vast majority of the effort on the Rust side has been building towers of abstraction. In almost any open source project, C or otherwise, a newcomer who starts writing towers of abstractions rather than concrete, usable code would be shooed away. There are reasonable justifications for why Rust has been doing this, yet its also understandable why this might draw suspicions about the practicality and utility of mixing C and Rust in the kernel. But either way it means that after all this time people are still largely arguing over hypotheticals.
[1] Or entirely wrong. Maybe kernel Rust is using flags to ensure aliasing optimizations can't happen. clang (and thus LLVM) supports -fno-strict-alias, but AFAIU alot of Rust code massaging happens on the Rust (MIR or equivalent) side.
steveklabnik 29 days ago [-]
Just to be super clear about it, Rust does not do strict aliasing. That’s a totally different set of rules than Rust’s aliasing rules.
wahern 29 days ago [-]
I know Rust doesn't do "strict aliasing", literally speaking. But that's partly because Rust's borrowing rules change the framing of the term strict aliasing as used in C, etc. It's similar for terms like "undefined behavior", where there's sometimes a certain amount of pedanticism from Rust developers that merely serves to deflect the point of contention.
> In the previous example, we used the fact that &mut u32 can't be aliased to prove that writes to output can't possibly affect input. This lets us cache *input in a register, eliminating a read.
steveklabnik 29 days ago [-]
Yes, it is a completely different set of rules. Strict aliasing is also referred to as type based aliasing analysis. Rust has categorically rejected this form of analysis, the aliasing rules are very different. It has nothing to do with types.
steveklabnik 29 days ago [-]
Oh, and "undefined behavior" has effectively the same definition in Rust and in C and C++. There's wording differences:
C/C++: behavior for which this document imposes no requirements
Rust: is not bound by any specification
But that's just a wording difference, not a semantic difference.
There are some instances where Rust and C/C++ use similar words to mean different things, but that's also changed over time. For example, Rust used to use rvalue and lvalue, but has moved to
"place expression", defined as "lvalue" in C and "glvalue" in C++
"value expression", defined as "rvalue" in C and "prvalue" in C++
The only reason to not use the C++ terms here is that these are the only two value categories in Rust, and it's unlikely to need all of the other three that C++ has.
You're not wrong that there's stuff called the same but has different meanings, for example, "reference," but what can you do.
samiv 29 days ago [-]
"The problem with Rust in the kernel is that the kernel has historically eschewed strong internal abstractions. The Linux kernel has no principled abstract architecture in the same way that Windows NT does; it has evolved very organically and even some of the most foundational subsystem APIs regularly see refactorings that touch almost every corner of the kernel."
And this is the reason why it's always regressing and never moves beyond alpha.
andrewstuart 29 days ago [-]
No, I feel this way about the Linux kernel.
surajrmal 28 days ago [-]
Those all exist in the Linux kernel repository. Granted they are not overlapping with c in their purpose for the most part.
One language per repo rules makes sense when you can have many smaller repos, but for something as immense as the Linux monorepo it's really limiting. Especially considering the lack of desire to add stable interfaces from which other repos could operate independently.
30 days ago [-]
chippiewill 30 days ago [-]
> Arguably his reprimand of Martin is a clear signal that he will never show Rust any favor
His reprimand is a clear signal that he won't tolerate brigading. Marcan was making a pretty blatant attempt at using social pressure to influence decisions.
nialv7 30 days ago [-]
And that is very fair since brigading is definitely not helping here. However, he should have also done the same to Hellwig for his unproductive behavior, yet he did nothing.
Oh and I got this quote for you:
> Linus Torvalds admonished the group that he did not want to talk about every subsystem supporting Rust at this time; getting support into some of them is sufficient for now. When Airlie asked what would happen when some subsystem blocks progress, Torvalds answered "that's my job".
People using Mastodon to promote pile-ons or brigading?
No, never! That's actually one reason I don't use Mastodon, it's extremely common. Isn't this the guy that blocked HackerNews links to the Asahi Linux homepage because the moderators wouldn't do his bidding?
Hamuko 30 days ago [-]
>Isn't this the guy that blocked HackerNews links to the Asahi Linux homepage because the moderators wouldn't do his bidding?
Yup, that was Hector Martin (marcan) as well.
29 days ago [-]
nozzlegear 30 days ago [-]
I don't know anything about him, but it seems like he has a pretty negative view of Reddit users as well:
> Added some clarifications in bold, because Reddit users having enough reading comprehension to understand what Christoph said and why it's exactly* what I described with other words is apparently a Lv.100 impossible challenge boss.*
An Intel employee in a reply makes a extremely good point that I think everyone these days needs to follow
> And if you're wondering why you didn't realize this: It's impossible to
change people by telling them they're wrong. What does tend to work is
explaining different perspectives, so that they can figure it out
themselves. And sometimes that's just way too subtle to ever register.
dralley 30 days ago [-]
Said Intel employee needs to follow their own advice.
> when you're that harmful with your calling out, eventually I'm going to be fed up, and you get a live round shot across your bow and if that then causes you to ragequit, because you can't actually deal with the heat you've been dishing out coming back around the corner: fuck off
>or as Dave put it "Being toxic on the right side of an argument is still toxic, [...]"
(that second comment made apparently without any sense of irony re: the first)
tomnipotent 29 days ago [-]
This seems like a perfectly reasonable response given Hector's prior comments. Pushing someones buttons until they explode and then pointing out they exploded isn't the indictment people think it is.
dralley 29 days ago [-]
No, not really.
The meaning of
> "Being toxic on the right side of an argument is still toxic, [...]"
Is very straightforwards. Toxic behavior is toxic behavior. Sima shouldn't lash out in "toxic" ways even if she thinks she's right.
Otherwise shouldn't Hector be given grace because "his buttons were pushed until he exploded"?
Like, you fundamentally can't have it both ways. Excuses for Sima's comments work for Hector. Condemnations of Hector's comments apply to Sima. Anything else is a double standard.
tomnipotent 28 days ago [-]
I fail to see anything in Sima's post that you linked that could be interpreted as toxic, rather than a perfectly normal human response. It's absolutely unreasonable to expect everyone to be perfect, always take the high road, or otherwise shrug off personal attacks.
Sima's responses can be excused. Even Hector's initial frustrations and his reactions to it can be excused. Hector's continued public reactions and escalations, however, are a different story and the reason folks are piling on him.
Philpax 30 days ago [-]
[flagged]
arp242 30 days ago [-]
I have paid special attention to these threads, and I have not seen this. And [flagged] comments don't count: any asshole can create an account and post any ol' bollocks. These posts are not "the community": these are posts "the community" has explicitly flagged and rejected.
busterarm 30 days ago [-]
So moving to effectively censor criticism that you can't control is justified?
Maybe the problem IS marcan, as Linus suggested.
If you do things that are in the public interest, people are going to have opinions about what you do and on a wide spectrum. If you can't handle that, you probably shouldn't be doing work that's so public and visible. Especially something like maintainer work that is inherently social.
Philpax 30 days ago [-]
[flagged]
loeg 30 days ago [-]
I remember that HN thread[0] and don't think Asahi's version is a good-faith, accurate summary of the contents. IMO they are inaccurately viewing a small number of flagged/dead comments as representative of HN in general.
Basically he has to avoid any community with significant numbers of people. Not liking HN, reddit, twitter and so on, its just a numbers game.
To respond to that by trying to cut of access to any place where many people exists is a questionable approach.
And judging people simply by from where they arrived in a place is also questionable tactic one that we should not tolerate in real live.
onli 29 days ago [-]
I call bullshit on that. The Asahi Linux intiative got a lot of respect and praise on this site whenever I looked at those threads. It's very very unlikely that this negative depiction is accurate. Please show a specific example of a thread that got out of hand like that, otherwise this is completely unbelievable.
Otherwise I would suggest that it says a lot when downvoting of comments is not understood as disapproval. And that it is a big warning sign when public devs/maintainers hallucinate hostile intentions to other communities as a whole.
busterarm 30 days ago [-]
I said opinions on a spectrum. Yes, an extreme end of that spectrum is an extreme response.
This is something you have to put up with some amount of if you do work in public, just like if you were a public figure or celebrity. Being a kernel or even package maintainer is like being a politician.
It sucks, but if your response is to cut off that channel of opinion _entirely_, that says more about you than the people you're silencing.
If something violates HN Guidelines, flag it and dang will see it. If there's anything that should be blatantly obvious by now it's that HN's moderation staff does not have the kind of alt-right bias suggested by your quote.
zimpenfish 30 days ago [-]
[flagged]
busterarm 30 days ago [-]
To think that you can control opinions people have of you in public forums is kind of insane.
Also denying links to their site isn't equivalent to "leaving the room". It's more like demolishing the room entirely, given the way that HN works. If your site can't be linked to it can't be the topic of discussion.
zimpenfish 30 days ago [-]
[flagged]
busterarm 30 days ago [-]
No, to your first two points. 100% of the discussion was happening on HN. The blocking of links from HN was 100% about silencing discussion _happening on HN_.
It has nothing to with "not letting assholes in". Asahi Linux doesn't have a discussion board.
To your third point, also no. HN guidelines keep the content of our posts relevant to the topics they are in. They also guide us to link to original sources, not archive links. Both of these mean that if you can't link to Asahi Linux content, it can't be the topic of discussion unless for some reason it's otherwise newsworthy and was posted elsewhere.
zimpenfish 30 days ago [-]
> The blocking of links from HN was 100% about silencing discussion _happening on HN_.
How does blocking HN from linking to a site silence discussion on HN? Because, as you say, "100% of the discussion was happening on HN" which seems to imply that blocking HN from linking didn't actually silence the discussion.
> Both of these mean that if you can't link to Asahi Linux content, it can't be the topic of discussion
You can link to it - you just get the "HN referer" block page just as other people get other block pages (eg. [0], [1]. Haven't noticed people moaning about how those sites are silencing discussion on HN, mind.)
Copy and paste the URL and you can read the link perfectly happily[2].
[0] Much like many of us in Europe get block pages for sites in the US who can't be bothered with GDPR or the cookie law.
[1] Or those of us who aren't subscribed to the various news sites which show a paragraph before putting up a blocker.
[2] Or someone pastes an archive.ph link.
loeg 29 days ago [-]
> Haven't noticed people moaning about how those sites are silencing discussion on HN, mind.
People whine about GDPR blocks and paywalls all the time. But also, clearly, those sites are not specifically targeting HN. It's not the same thing.
lenkite 30 days ago [-]
Your argument is valid. But the person you are supporting is in favour of "social media brigading". So, there is a fundamental dichotomy here, since by your argument he should be kicked and banned.
HideousKojima 30 days ago [-]
[flagged]
busterarm 30 days ago [-]
It's extra weird to me that people try to live a very public life but then accuse anyone with the slightest amount of criticism of behaving criminally...
dralley 30 days ago [-]
Who has made accusations of behaving criminally?..
busterarm 30 days ago [-]
doxxing.
harassment.
And to answer your question of "who?", marcan themselves based on marcan being the one to block HN links.
But more generally, the majority of people posting online (especially streamers, content creators, even just twitter posters) these days seem to be very thin-skinned and will claim that any amount of pushback that they get for their words or actions is an organized harassment campaign.
kyleee 30 days ago [-]
I think you are generally correct. I think also the personality types who become public makers, etc. tend to also be controlling, so any negative comments / discussion, etc. that they can’t suppress really irks them and often they go to great lengths to try to get rid of it
account42 27 days ago [-]
Yeah it's really weird. Why push your weird subculture into the spotlight and then cry foul when people are weirded out. Kind of feels like it's all about fishing for even more attention.
debugnik 30 days ago [-]
[flagged]
HideousKojima 30 days ago [-]
[flagged]
debugnik 30 days ago [-]
Holy false equivalence, how is keeping a pseudonimous vtuber identity comparable to verbal abuse, adultery or social media brigading? See, I'm ok with discussing his mistakes as well, but exposing Lina despite being irrelevant, which happens in every thread about her, feels like bigotry. "Heads up, they're one of those!"
busterarm 30 days ago [-]
[flagged]
30 days ago [-]
duxup 30 days ago [-]
I'm not arguing that this is or isn't a problem but I think the statement "using social pressure to influence decisions" is so general that it could apply to just any discussion. That's kinda what discussion is.
Granted there are acceptable methods within that, and not acceptable.
XorNot 30 days ago [-]
Throwing up a call to arms in unrelated discussion venues with the purpose of drawing people to the original venue, or to harass the original participants in other venues, would count though.
i.e. no one would consider it acceptable for me to go on reddit and start ranting about a Hacker News username, link the thread and argument, and imply either implicitly or explicitly that they should go and join the argument.
nicce 30 days ago [-]
Martin has a habit of polarizing and aggregating discussions too much. It is not healthy at all. Linus is definitely correct, especially since he has the history of doing the same and he has tried to fix it.
Imagine if the discussion would have started with an article like this. Patch probably would be merged already:
Very doubtful. The maintainer was clear and nothing in there is sufficient to address his criticism: polyglot is unmaintainable and Rust people should write a whole new OS as a separate effort.
Yoric 30 days ago [-]
Well, Fuschia has been largely ported to Rust, I believe, so... that's coming.
bakugo 30 days ago [-]
> "using social pressure to influence decisions" is so general that it could apply to just any discussion
Not really. It's one thing to discuss these things directly in the proper channels, namely the mailing list, but it's another thing entirely to make childish, passive-aggressive posts on not-Twitter about how anyone who disagrees with your actions is trying to "sabotage the project" and trying to rally your followers to cancel them on the grounds of "Code of Conduct violations" (once again proving that "Codes of Conduct" are little more than tools to enable cancel culture).
He himself acknowledged the fact that what he did was childish and embarrassing by deleting his entire Mastodon account.
mort96 30 days ago [-]
I honestly don't understand what the difference is between "brigading" and "complaining about a thing on mastodon". It's not uncommon to express frustration about something/someone associated with the kernel development process, what makes this particular instance "brigading"?
stonogo 30 days ago [-]
The difference is between posting "ugh, having a hard time with someone on a project, they're blocking this merge and I don't think it's for a good reason" and literally starting your post with "Behold," linking directly to a mailing list post, and misrepresenting the other person's objections as "sabotage."
mort96 29 days ago [-]
I mean when what you're frustrated about is a leader actively sabotaging what you're working on...
stonogo 28 days ago [-]
Go on?
mort96 28 days ago [-]
Then complaining about that on social media is going to sound a lot like "the leader of this subsystem is sabotaging this thing I'm involved with"
stonogo 28 days ago [-]
Right, and phrased just like that, it wouldn't have been as objectionable. As I said before, the problem is in the specificity and the direct linking to the conversation. I still take issue with the word 'sabotage' being used here, since the person in question didn't do anything except express objections and an intent not to cooperate. Since this was in a context where that person's cooperation is not needed, I'm not sure he sabotaged anything.
duxup 30 days ago [-]
Help me out here because I'm not sure how to navigate the submitted link https://lkml.org/lkml/2025/2/7/9. Where is this reprimand / can it be seen?
> As for how to move forward, (...) Either Linus takes the pull, and whatever Christoph says is irrelevant, or he doesn't, and R4L dies. Everything else is a waste of everyone's time and energy.
It does look like maintainers should have a "disagree and commit" mentality at some point, whatever decision they end up making.
I thought Rust in Linux was evaluated, discussed and agreed upon years ago. The fact that there are people still trying to sabotage it shows that they don't follow the "disagree and commit" principle.
They are more like "disagree and make the others lives a living hell until they bend to my will".
justin66 30 days ago [-]
> I thought Rust in Linux was evaluated, discussed and agreed upon years ago.
I've seen Linus talk about it in one of his public chats with Dirk Hohndel as an interesting experiment that might succeed or fail, or that's the impression I got. I'm not sure everyone else got that memo.
geodel 30 days ago [-]
> disagree and commit
It is not some million dollar RSUs getting vested by year end either way. A lot of them working for the love of craft and prestige. If they can just rollover on a technical disagreement then corporate office job is more suitable than open source OS kernel.
gf000 30 days ago [-]
The Linux kernel is most definitely not developed for free by some college student in their bedroom for the most part. It's Intel and Red Hat and similar.
"R4L dies" is hyperbolic nonsense. There are many ways/places to integrate Rust in the kernel, even for wrappers. It's not like "I think this code should be someone else" automatically means the death of Rust.
Marcan goes full nuclear every other time someone disagrees with him. He's very much the "if it's not my preferred way then we might as well not do it at all"-type of engineer (many of us have worked with those people).
steveklabnik 30 days ago [-]
Rust is only allowed for drivers, because that sidesteps the platform support questions.
DMA is needed for an overwhelming number of useful drivers.
If you can’t use DMA from Rust, then you can’t really properly evaluate the usefulness of Rust, hence the effort is basically dead.
arp242 29 days ago [-]
People can just include their own dma.rs in driver/.../mydriver/
Whether that's a good or bad approach is besides the point. It's what was suggested as an alternative, and clearly it's something that would work. "You can't use DMA from Rust" is just not true.
codys 29 days ago [-]
If it was a good approach, the C folks would have copied around C files instead of having common core code. They did not do that though, because it'd be counter productive due to increasing maintenance burden.
Everyone knows it would increase maintenance burden, decrease reliability, and increase the amount of apparent churn of rust code in the linux kernel.
Brian_K_White 29 days ago [-]
Everyone knows you could start the crude way today and refactor the duplication later after it proves itself, if you actually wanted to proceed rather than throw fits.
dralley 29 days ago [-]
You can't just endlessly dump more busywork on Rust developers (including genuinely bad code practices) and expect them to deal with it.
There is zero good reason to duplicate that code and refactor it later.
Brian_K_White 29 days ago [-]
[flagged]
yazaddaruvala 29 days ago [-]
Hey I think you’re missing important context and in the meantime getting a bit aggressive. Neither is helpful.
Regarding the context:
> A redundant wrapper is such a trivial mechanical problem to solve or work around,
The DMA maintainer explicitly NAKd a wrapper. He insisted that each Rust driver copy and paste the needed Rust code.
He even explicitly stated the reason was to ensure he did everything possible to keep C the only language in the kernel.
Brian_K_White 29 days ago [-]
So do it. Paste it in.
And after that driver is in use for a while and a million users all depend on it because it works so good, other developers will all on their own start asking "why are we diing this this stupid way? I think the original argument is no longer valid, or we can see now that it never was valid. We should revisit that."
Or as more rust devs work on more modules that each need some similar redundant boilerplate, a larger number of individual devs who each ask the same "hey, can we please get at least this level of concession to have a shim somewhere we can interface with instead of all this fragile tight coupling?" When that grows to become a respectful request from many, including users, instead of a disrespectful demand from a few, you get a different result.
But that is step 2. The opportunity for step 2 sometimes simply will not exist without first going through a step 1.
You want in? Yes but the terms are shitty. Yeah, so, you don't want in? It's obviously OK with most of the kernel devs if the rust devs decide this is not rewarding and go away. They are not eagerly welcoming to this particular development. And they don't have to be. How welcoming would rust developers be to c developers demanding to rewrite cargo in c? Go work on redox and make it so great it takes over and replaces linux by simply being the better choice while being equally free and at least as well managed and clearly visioned.
29 days ago [-]
tptacek 29 days ago [-]
I don't know the better way to ask this question, so I'm just going to ask it:
"Congratulations, you're right, and nobody cares."
Now what? Just complain that the kernel isn't hospitable to Rust, and hope 15 years from now we're all using some Linux-compatible kernel built ground-up in Rust?
I genuinely want to know where you go from this position.
steveklabnik 29 days ago [-]
I am trying to explain why someone would say this.
I think Rust in Linux makes sense, but honestly, Rust doesn’t need Linux to be successful, and I barely use Linux personally. If they decide Rust for Linux is not a thing, that’s for the folks who work on and care about Linux to deal with. This isn’t my fight, I am just observing.
I’ve been primarily a Windows user for many years now, but I do use some WSL. My main OS is already shipping Rust, and in the actual kernel, without all of this wailing and gnashing of teeth. (That said I respect the approach Linux is taking here, I don't think it's inherently bad.)
Oh, and honestly, what I believe is happening here is just that, from Linus's perspective, folks should know that because this isn't in Hellwig's part of the tree, his NACK doesn't actually matter, and he'll just end up pulling this patch in anyway. There's no need to intervene because there isn't actually obstruction going on. The internet is just going wild about this drama because they fundamentally misunderstand how kernel development works, and because people are slinging mud on the LKML. That's why he only commented on Hector's behavior.
I can see that perspective, though I would prefer a different management style, but that's also why (among other reasons) I don't care to contribute to the kernel.
slanterns 29 days ago [-]
> Every additional bit that the another language creeps in drastically reduces the maintainability of the kernel as an integrated project. The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language complely breaks this. You might not like my answer, but I will do
everything I can do to stop this.
Maybe you can try to read what Christoph Hellwig said first.
tptacek 30 days ago [-]
That's a much stronger argument when you aren't at the same time yelling about the email patch system. I want R4L to succeed!
30 days ago [-]
lII1lIlI11ll 30 days ago [-]
> The Rust drama is an uncommon failure of leadership for Torvalds. Instead of decisively saying "no, never" or "yes, make it so," he has consistently equivocated on the Rust issue. Given the crisis of confidence among a sizeable (and very vocal) contingent of the Linux community, that decision has backfired horribly.
Efficiently collaborating on large distributed open source projects like Linux is as much social activity as technical. For people like Kent Overstreet or marcan and many before them this is apparently a hard thing to grasp and they have been failing badly at following the process, building consensus, earning respect and trust of people from other subsystems, that kind of things. To me it looks like that for Linux big part of R4L experiment is to specifically understand whether Rust people can convince key stakeholders that R4L is good idea and get their buy-in and that is why he doesn't attempt to force it. Also, what is he gonna do to the reluctant but key maintainers? Refuse to accept anything from them until each of them shows him a repo with all Rustlings exercises solved to ensure they are ready for Rust or what?
> And it's quite out of character for Linus not to have a blazingly clear opinion.
Linus tends to have clear opinions on things he is world class in. He is technically brilliant and very knowledgeable in most of the low level systems things but likely not in Rust, so it is understandable for him to just keep being open minded about it and let the chips fall where they may.
> As a pilot program, R4L should have graduated or ended a long time ago. After several years of active development, its status remains unclear.
Which is absolutely normal for the kernel. You can have a driver spending years in staging or RTLinux taking 20 years to get there. It is totally expected for such a disruptive change as introducing new (and quite complicated) programming language to take a few more years to reach maturity.
> Arguably his reprimand of Martin is a clear signal that he will never show Rust any favor, but he hasn't said anything explicitly.
Not it isn't.
> decision has backfired horribly
> place responsibility for the drama on Martin's shoulders
> Imagine how much time and energy (even just Martin's alone) could have been saved if Linus had just said "no, keep it downstream".
HN crowd and random JavaScript-kids on Reddit are only hotly debating this because the "drama" has the word "Rust" in the title. For Linux maintainers it is just another day at the office, nothing much to see here honestly.
jabwd 30 days ago [-]
> To me it looks like that for Linux big part of R4L experiment is to specifically understand whether Rust people can convince key stakeholders that R4L is good idea and get their buy-in and that is why he doesn't attempt to force it.
This is the entire point. This has been DONE. First its "lets see if you can build a good driver", now its "ew rust". The maintainer of the DMA subsystem is showing how they're actively trying to make sure Rust doesn't make it in. .
lII1lIlI11ll 29 days ago [-]
No, it is not the entire point. No one is really doubting whether you can write a driver in Rust, C++ or Swift. The whole experiment is whether you can slowly move in to existing mature kernel subsystems without being too disruptive.
okanat 29 days ago [-]
If the minority maintainers scream every time they see other languages due to their insecurities, technical inability and stubbornness, and their overreactions get a pass, it is not the fault of Rust, C++ or Swift. The source of the disturbance is not the people who are making an effort to cause as little disturbance.
Blatant NIMBYism is the problem here and you cannot reduce it by accepting everything.
lII1lIlI11ll 29 days ago [-]
In general, upstreaming code to Linux involves interacting with difficult and sometimes outright hostile people. I've certainly had my share of both with much smaller changes. IMO pushing something like R4L requires very thick skin and almost infinite amount of patience. Bitching about that won't get you far, you need to be able to either work with or around those people.
jabwd 29 days ago [-]
This again gets back to the main point which you keep misrepresenting. This has nothing to do with a thick skin, this is a core subsystem maintainer outright saying they won't support R4L, which means its dead.
lII1lIlI11ll 29 days ago [-]
I'm not misrepresenting anything and R4L is not dead. In fact, two ways forward where suggested right in the LKLM email thread:
- Send the series directly to Linus since there is no code that Hellwig is maintainer of is actually being changed by it and let Linus decide whether to ignore Hellwig's nack. Linus may have done so before, but likely not after marcan's public meltdown.
- Copy/paste the code to every driver that will be using it. If it becomes useful, it will cause more pressure on Hellwig down the road because people will question why every change in code that is being wrapped by this is causing a fix in 10 different copies.
People here and on Reddit who are unfamiliar with the Linux development process but are attracted to the "drama" because it involves Rust somehow keep missing it.
jabwd 29 days ago [-]
> No, it is not the entire point. No one is really doubting whether you can write a driver in Rust, C++ or Swift. The whole experiment is whether you can slowly move in to existing mature kernel subsystems without being too disruptive.
Which Chris did doubt, as a way to gatekeep Rust (as you misrepresented, and which is clearly visible in the LKML thread).
regardless, back to the other stuff:
First point: Which is what was suggested as well in the LKML and still does not really solve the problem, which is not TECHNICAL but POLITICAL.
Second point: Obvious, and wasteful, and again is thus a political move which is the entire point of this entire saga. It isn't about drama, its about the political aspect of the kernel dev being tiring and wasteful.
lII1lIlI11ll 29 days ago [-]
> Which Chris did doubt, as a way to gatekeep Rust (as you misrepresented, and which is clearly visible in the LKML thread).
Can you provide the exact quote where Hellwig is suggesting that it is impossible to write a driver in Rust? No, you can't? So who exactly is misrepresenting here?
> regardless, back to the other stuff: First point: Which is what was suggested as well in the LKML and still does not really solve the problem, which is not TECHNICAL but POLITICAL. Second point: Obvious, and wasteful, and again is thus a political move which is the entire point of this entire saga. It isn't about drama, its about the political aspect of the kernel dev being tiring and wasteful.
You are shifting the goalpost from this making R4L "dead" to the way forward being "tiring and wasteful". It doesn't look like you are arguing in a good faith so I won't participate in the discussion with you anymore.
wyldfire 29 days ago [-]
> just keep being open minded about it and let the chips fall where they may.
It's a failure of leadership to not intervene when discord threatens the group. He should weigh in, or make sure that someone else who has mutual trust weighs in.
In youth sports, something similar happens when referees fail to call fouls on rough play. Players naturally test the limits and then others recognize the lack of protection and retaliate until it gets really out of hand.
lII1lIlI11ll 29 days ago [-]
> It's a failure of leadership to not intervene when discord threatens the group. He should weigh in, or make sure that someone else who has mutual trust weighs in.
Nothing in that particular "drama" threatens Linux kernel maintainers as a group. Multiple solutions were proposed, like just sending the change directly to Linus bypassing Hellwig or copy/pasting the code to each individual driver for now. Marcan having public meltdown in that thread probably makes option 1 no-go though and doesn't improve R4L standing with the skeptical group of maintainers.
> In youth sports, something similar happens when referees fail to call fouls on rough play. Players naturally test the limits and then others recognize the lack of protection and retaliate until it gets really out of hand.
For better or worse the social contract in LKLM is not like what a lot of Rust people used to where you come in with furry avatar and pronouns in your profile, then cry for mommy to enforce CoC on first signs of conflict. Basically, extending your analogy, you don't come to an American football match expecting the referee to enforce basketball no-contact rules.
AnIrishDuck 29 days ago [-]
> In youth sports, something similar happens when referees fail to call fouls on rough play.
This is actually not limited to youth sports, you can even see it happen with professional athletes.
It's a very common human reaction when participants feel like the rules aren't getting enforced. For all ages. Which only reinforces your point.
chikere232 29 days ago [-]
You can't rely on an authority to step in every time some disagrees. People need to resolve their own conflicts rather than yell until bailed out
30 days ago [-]
ajross 30 days ago [-]
> We all know his stance on C++, for instance.
Yeah, but that's because Linux was actually built with g++ for a few versions! The opinion was informed by experience, not an a priori thing. And it was likewise extremely controversial at the time. And eventually they rolled it back out and gave up.
Maybe that will happen with Rust too, or maybe not. But The Process, such as it is, is working today the same way it always has. They try stuff and fight about it, and eventually a winner is clear and a consensus emerges. And, yeah, there are losers, too.
meindnoch 29 days ago [-]
> Instead of decisively saying "no, never" or "yes, make it so," he has consistently equivocated on the Rust issue.
He probably didn't want to end up like Stallman.
tarruda 29 days ago [-]
> And it's quite out of character for Linus not to have a blazingly clear opinion. (We all know his stance on C++, for instance.)
People change. As you get older, you might find you no longer care that much about subjects you previously had very strong opinions about
> As a pilot program, R4L should have graduated or ended a long time ago.
Disagree. These things take time. Linus knows that, and as I see it, he's giving it the time it needs. "After years of active development" we've only recently arrived at a point where actual driver development in Rust is possible.
> We all know [Linus'] stance on C++
Yes. And looking back I think that was a good stance. C++ is not for kernels: the language is too big, containing features that don't fit well with kernel development, thereby inviting all kinds of discussion not conductive to kernel development.
Rust is another story. Rust has potential to bring benefits to the kernel. I think Linus knows that.
Off-topic: I'm looking forward to an --largely automated (maybe with use of LLMs)-- port of the kernel in Zig. Just because I think the developer ergonomics of Zig are so much better than C. Not holding my breath: in 10 years or so would be nice.
TuxSH 29 days ago [-]
> C++ is not for kernels
That's a broad generalization to make.
Nintendo's custom OS (Horizon OS, used on Switch and a previous version on 3DS) is almost fully written in C++, including the entire kernel and all drivers.
I agree with you that C++ has plenty of misfeatures. Fortunately, compiler vendors make it fairly easy to dodge the bad parts of the language.
cies 28 days ago [-]
There's C-- (and a few other similar efforts) that are basically C++ with a lot of features forbidden/disabled. I suspect Horizon OS also does this.
I'm not sure if we can still call it C++ in those cases. C++ is more/less a superset of C: we need to know what style of "C++" we're talking about.
TuxSH 28 days ago [-]
3DS HOS was known to be using armcc and Switch HOS is known to be using clang.
Both OSes are huge C++ codebases. Features being disabled or forbidden is a non-userland thing (basically only because resources are constrained. 20KB of exception runtime bload isn't the same thing when you only have 200KB of available RAM vs. when you have 20MB+)
My opinion (and the opinion of people using C++ in such constrained envs.):
* C++ (the language itself along with stuff like <type_traits> and other freestanding headers) is the best thing since sliced bread. So many ways of reducing boilerplate while both writing safe code (RAII) and being mostly in control of produced asm
* most of the other parts of the stdlib are defective
* the committee process sucks, but fortunately compiler vendors allow us to dodge their bad decisions (making #embed available for C++, -fno-exceptions, etc.)
gerritjvv 23 days ago [-]
He sould've and should say no. No Linux has and will be a C project.
Imagine going to a project like Rails and trying to convince them they should use C# instead because its better than their language and everyone is wrong. Then if they refuse to change you start going on social media shit posting how all of them are wrong and and they should use the language you decided is king.
I think Linus was happy for people to use Rust peripherally, but then they needed changes to the kernel and slowly wants to infiltrate every other project to become rust dependent. This didn't sit well with other maintainers as they use C and arguably don't want or need to deal with Rust. The same they don't want to use Zig, V or C++. You're welcome to develop your driver in Zig, but don't expect others to change their code for you so you can be happy.
hadad 29 days ago [-]
I agree with all statement from Linus. Keep it separated/downlined project I think is the best for both worlds.
bhasi 29 days ago [-]
Could you please post more details on the reprimand you refer to?
> How about you accept the fact that maybe the problem is you.
> You think you know better. But the current process works.
> It has problems, but problems are a fact of life. There is no perfect.
> However, I will say that the social media brigading just makes me not
want to have anything at all to do with your approach.
> Because if we have issues in the kernel development model, then social
media sure as hell isn't the solution. The same way it sure as hell
wasn't the solution to politics.
> Technical patches and discussions matter. Social media brigading - no
than\k you.
> Linus
up2isomorphism 29 days ago [-]
Obviously he does not like Rust just as much as C++, which is understandable.
The difference is that he is a little bit more diplomatic than he used to be.
But why someone want to push a language into someone else's kernel? Fork your own, if you want.
mariconrobot 29 days ago [-]
thank Linus for you
devit 30 days ago [-]
[flagged]
mu53 30 days ago [-]
I think you overestimate rust and misunderstand the problems. This is classic junior engineer "rewrite everything" thinking
caspper69 30 days ago [-]
I didn't downvote you, but I think you have a misunderstanding of a couple of things that are clouding your judgement: (1) the sheer size & inertia of the Linux kernel; there are tens of millions of lines of code, and even thinking about integrating another language will take time- lots of it; and (2) the distributed nature of its development and the diversity of its engineers; the community is not one that can be brought into an auditorium and made to change direction on a dime. Rust may have been around for 10 years, but no one was going to go all in on day one.
Further, this attitude of "Rust is clearly superior, so what's the holdup" is itself a holdup. You can't expect people to just spend their time learning a new language just because it's there, especially professionals with personal lives. These people do serious work, on a codebase that millions of people around the world, including virtually every tech company, relies on in some fashion. That's not a game. It's "serious business."
Serious business doesn't just chase something because it's new and hot and solves a certain class of problems (while simultaneously introducing its own set of problems).
Nothing is a panacea (yet, I suppose). This ship has been sailing for 30+ years. So many millions of man-hours have been put into it that people are justifiably cautious.
Now, all of that being said, I read the DMA maintainer's comments a few days ago and I thought he was being unreasonable, however, he is correct about the external dependency on his code. Even if the Rust DMA wrapper is kept completely separate, under a separate tree, he would still have to contend with the fact that any changes he makes might influence that wrapper and all the code that depends on it. So now, even if they claim to maintain the wrapper 100%, he is still beholden to all those downstream developers that rely on the Rust DMA wrapper's functionality, because if he breaks their code, he knows it'll cause a shitstorm. It's easy to say you'll maintain something 100% and the upstream guy doesn't have to worry, but time passes, things change, and all of a sudden, his hands get tied because it'll impact too many people. That's just reality.
Truth be told, I would eventually suspect some (or maybe many) Rust developers will migrate to a new project, because the rate of change is not going to be fast enough to ever satisfy them. And that's understandable. People want to make an impact, especially when contributing to an open source project (and doubly so on an unpaid basis).
Unfortunately I don't think Redox is the answer. UNIX and its clones/derivatives have had a long run, but anyone who wants to create the next big thing is not going to want just another clone of UNIX, even if it is in Rust.
We have seen the enemy. We understand the threat models and know far more about virtualization, containerization, sandboxing, etc., just by virtue of having had to dogfood these technologies for the last 25 years.
The next big thing (if there is one), will likely be something more like a cross between the Windows world (where ACLs rule the roost, and centralized management is built-in), UNIX with its CLI focus, process composition & command familiarity, and something like L4 which has unforgeable capabilities built in and a formally verified kernel.
Or we'll just go back to a modern day version of the UNIX wars, lol. Something, something about history rhyming.
steveklabnik 30 days ago [-]
> he is still beholden to all those downstream developers that rely on the Rust DMA wrapper's functionality, because if he breaks their code, he knows it'll cause a shitstorm.
It is the explicit policy of the project, and was repeated in the thread, that the Rust folks are solely responsible for fixing any breakage. There will be no shitstorm.
caspper69 29 days ago [-]
I see you responded to both of my comments in this thread, but I'll save us both the trouble by doing a single reply.
I understood/understand the representations, and I am sure they are made in good faith.
At the same time, I also understand the reality of having the things you do seriously impact the work of others and the types of issues that can cause.
I did state that I was leaning on the side of him being unreasonable, but also that I understood the concern. Nothing more, nothing less.
devit 29 days ago [-]
I think Linus should change this though, so that the maintainers that don't want to learn Rust have to step down, and there are no more conflicts.
doublerabbit 30 days ago [-]
Or dump linux and move to freebsd / haiku
jhoechtl 29 days ago [-]
Get rust out of the kernel, now! Rust as a language is meant to be the output of an llm which can be verfied by humans.
mathfailure 30 days ago [-]
Torvalds lost respect of a lot of people, that's the most important thing.
AgentME 30 days ago [-]
If an individual maintainer can veto critical parts of the Rust for Linux project and announce they'll do everything they can to stop it, then Linus is wasting everyone else's time pretending it's a real project. It's not a proper environment to put contributors in.
jeroenhd 30 days ago [-]
I think it's rather silly to have some subsystem maintainers do everything in their power to sabotage the improvement projects by subsystem and even high level maintainers in the kernel.
It was a fine position to take back when introduction of Rust into the kernel was still very much a discussion point. However, the discussion is over, Rust has been accepted into the kernel. This entire struggle has been kernel developers sabotaging other kernel developers.
This infighting is only going to hurt the kernel in the long run. Every time this "discussion" comes up, I walk away with the feeling that Linux kernel developers are unreasonably hostile and impossible to work with. It makes me wonder why new people would ever bother trying to contribute anything.
That said, using social media to cause drama when a Linux maintainer is being an ass is just as stupid, if not worse. Both sides of the conflict are in the wrong here.
CopperWing 30 days ago [-]
The DMA subsystem maintainer has some reasons: at this time you can disable all rust drivers when building the Linux kernel but you cannot disable rust wrappers to C language APIs. So if you need to change for example the DMA APIs, you also need to fix the rust wrapper before submitting the C patches otherwise you cannot even build a C only kernel.
Zollerboy1 30 days ago [-]
A C only kernel build without CONFIG_RUST will not build a single line of Rust code nor will it touch anything in the rust subdirectory. If you don’t want to deal with rust, you don’t have to at all.
WesolyKubeczek 29 days ago [-]
It’s a little bit more nuanced than this. Your parent commenter is wrong, by the way.
Suppose you want Rust, just not a single Rust driver using PCI. But CONFIG_PCI and CONFIG_RUST both selected will cause the PCI abstractions to get built anyway, even if not a single driver using them is selected. Then if the PCI subsystem introduces a change but the Rust counterpart fails to follow it fast enough, the build will break for the kernel as a whole.
This was illustrated with an example in that email thread.
I have some sad experience with polyglot projects. Unless you enjoy pain and drudgery, it’s an extremely unrewarding thing requiring very careful treading.
paholg 30 days ago [-]
I don't think that's true. I have seen R4L folks reiterate time and again that C changes are allowed to break Rust code, and they will be the ones to fix it.
account42 27 days ago [-]
> However, the discussion is over
It's not. Certainly not until Linus says it is.
> Rust has been accepted into the kernel.
As a limited experiment. This kind of drama may be an indication that the experiment has failed and should be rolled back.
Longhanks 30 days ago [-]
> This infighting is only going to hurt the kernel in the long run. Every time this "discussion" comes up, I walk away with the feeling that Linux kernel developers are unreasonably hostile and impossible to work with. It makes me wonder why new people would ever bother trying to contribute anything.
Well, this is your take, as you explicitly wrote "I walk away with the feeling". My take is: The kernel developers are the ones doing the actual work, which legitimates their opinion of doing things. If too many people aren't happy with the way the linux kernel is developed, they are free to fork it and develop in the way that they see fit.
Luckily, the kernel seems to be doing fine.
pyrale 30 days ago [-]
> The kernel developers are the ones doing the actual work, which legitimates their opinion of doing things.
Both sides of the argument are kernel developers here, though.
Longhanks 30 days ago [-]
Well, one side just quit.
And that particular side was told by Linus Torvalds himself that his way of Social Media brigading is inappropriate for kernel development, and that the current process works.
I choose to believe Linus. His work on and guidance of the kernel used to and still does work pretty great.
mort96 30 days ago [-]
No, the entirety of the Rust for Linux kernel development community didn't just quit. One guy quit. There are plenty of other kernel developers who are trying to push Rust 4 Linux forwards and make it viable for more kinds of drivers.
steveklabnik 30 days ago [-]
The person who quit was not the author of the patch, or a member of Rust for Linux.
iczero 30 days ago [-]
The person who quit wrote the Linux graphics driver for Apple M-series GPUs in Rust.
edit: I may have gotten some things confused, please see below
mort96 30 days ago [-]
No. The person who quit upstream kernel work is Marcan, the head of the Asahi Linux project. The person who developed the kernel driver for M-series GPUs is Lina.
anonfordays 22 days ago [-]
Not sure why my comment was flagged, but marcan is Asahi Lina. There is demonstrable proof in threads all over this comment section.
anonfordays 29 days ago [-]
[flagged]
platybubsy 30 days ago [-]
[flagged]
mort96 30 days ago [-]
[flagged]
bitbasher 30 days ago [-]
[flagged]
mort96 30 days ago [-]
[flagged]
bitbasher 30 days ago [-]
There's nothing to joke about here.
We're talking about a developer, and a persona they created. Yes, they haven't outwardly said they were one and the same but it's pretty obvious. There's nothing to joke about and no feelings to be hurt here.
mort96 30 days ago [-]
[flagged]
bitbasher 30 days ago [-]
Hector's hostname in their shell is the same as Lina's (raider).
The DNS for asahilina.net points to the same servers as marcansoft.com.
Their KDE setups are oddly similar (the same).
The list goes on. Is it circumstantial? Sure...
account42 27 days ago [-]
Not to mention, "Lina" coming out of nowhere to work on a highly technical and very nieche project that Hector is a major contributor of.
If it quacks like a duck...
mort96 28 days ago [-]
[flagged]
amiga386 29 days ago [-]
[flagged]
mort96 28 days ago [-]
Luna comes across as unhinged and obsessive, in both public communications and in Lina's document detailing her experience with Luna (https://docs.google.com/document/d/1W2Vvwg0rwSVb5r4TQ_NmAF8S...). As "Luna said so" is really the best you got, I'll keep viewing this claim as entirely unsubstantiated.
amiga386 28 days ago [-]
Luna is also the main developer of Inochi2D, the software used to animate Asahi Lina, and is acknowledged as the character's co-creator. Your ad-hominem attack on Luna aside, do you really think Luna would not know who Asahi Lina is? Who do you think Hector worked with in order to have "Asahi Lina" appear on his stream?
The first line of your Google document, written by "Asahi Lina", confirms it straight up:
> Unfortunately, on August 1st, Luna publicly: Doxxed me with a real-world identity
You should verify that reference for yourself, archives of what Luna said are readily available on the internet. I can confirm that what Luna said on August 1st, 2024, is the same thing she's saying today: Hector Martin is Asahi Lina.
The dossier corroborates Luna's claims.
(Also, what kind of person has a dossier ready to go if their contributor goes rogue? A controlling and manipulative person, that's who.)
We don't know who "Jia Tan" is, nor "Jigar Kumar", but we know that the person, or group of people behind these identities and others, used sockpuppetry to bully Andres Freund into giving them control over xz-utils, and we know what they did with that access. Even if pseudonyms are accepted, there should be zero tolerance for sockpuppetry in the Linux Kernel. If Hector Martin quits (https://lore.kernel.org/lkml/20250207-rm-maint-v1-1-10f069a2...), the personas/pseudonyms/avatars/characters of Hector Martin should quit too, but "Asahi Lina" continues to post on LKML.
mort96 28 days ago [-]
I know who Luna is.
When your argument is "a person said it so it's probably true", the natural next step is to ascertain whether that person is credible or not. That's not an instance of the ad hominem fallacy.
amiga386 28 days ago [-]
It does not matter how "unhinged and obsessive" (that's an ad-hominem attack, btw), the co-creator of a fictional character is. They are still co-creator. They know who the other co-creator is; it's Hector Martin.
You know this.
You also know the document you linked affirms that "Asahi Lina" (not a real person) did not like being "doxxed" on the date that Luna said Asahi Lina was Hector Martin.
What I take from that is Hector Martin wrote the document. Do you disagree?
mort96 28 days ago [-]
What I'm saying is I do not take Luna's word for it. I do not consider her a reliable source.
amiga386 28 days ago [-]
Fine, that's your opinion (it's not mine), so please discuss the document you brought up, that you've auspiciously avoided mentioning for the past two replies.
The document you brought up says "Unfortunately, on August 1st, Luna publicly: Doxxed me with a real-world identity". On that day, Luna said Asahi Lina was Hector Martin. Discuss.
hananova 24 days ago [-]
There's a reason why the document says "Doxxed me with a real-world identity" and not "Doxxed me with MY real-world identity." It's because she was doxxed, but the doxxing was wrong.
amiga386 23 days ago [-]
"Doxxing" refers to providing the real world identity of a psuedononymous person, breaking their pseudoanonymity.
It doesn't refer to providing the WRONG identity, as that wouldn't break their pseudoanonymity. You, hananova -- are the QUEEN OF FRANCE! Did I doxx you or not? I don't believe I did.
You can't have it both ways. Either Hector Martin is Asahi Lina (which he is), and Luna revealed this to Martin's chagrin, and Martin published a document to try and trash Luna's reputation as a clumsy attempt at damage control, or Luna didn't reveal Martin's barely-concealed secret and no need to publish the document.
By publishing the document, we know which interpretation is correct.
alchemio 30 days ago [-]
So they stirred a whole lot of drama for not much, potentially harming R4L.
steveklabnik 30 days ago [-]
I am not willing to pass a value judgement on his decision to do this, but I do agree that I don't think it ended up being helpful to R4L.
tedivm 30 days ago [-]
The kernel is doing fine today, but I don't think that's sustainable. The average age of the maintainers seems to be rising, and plenty of skilled people completely avoid kernel development explicitly because of the hostility and, frankly, assholish behavior that comes from the folks on these mailing lists.
Eventually a lot of these people are going to age out, retire, or otherwise move on. I do think there will be a crisis moment at some point in the future.
Filligree 29 days ago [-]
Also it's, y'know, written in C.
I used to know C. It was my first language, and I spent a fair bit of time in it, but that was before compilers started to treat undefined behaviour as an excuse to break reality.
Arguably I'm not smart enough, or disciplined enough, to write C. This may be the case, and therefore I have naturally focused on other languages. Rust, to no-one's surprise, is my current favorite. I've never contributed to the kernel — for more reasons than just the language — but the language would be reason enough on its own.
C programmers are getting rare...
Longhanks 29 days ago [-]
Why are you projecting your own feelings onto others?
There’s plenty of people who write C, there’s plenty of newcomers who start writing C and if they’re willing to, they can find guidance, mentoring, and tooling to improve their skills. If that’s not the path you want to pursue, that’s fine. But C isn’t going anywhere soon and if you go to any university/college, there’s lots of C being taught and lots of people eager to learn.
bechampion 29 days ago [-]
they don't avoid it cause the hostility , they avoid it case we live in this high level era , where nobody knows where code runs or how it runs.
caycep 30 days ago [-]
how forkable is the whole thing? I mean, it is several decades of code but...
mort96 30 days ago [-]
It's not.
convolvatron 29 days ago [-]
its totally forkable. in fact its totally possible to write a 99% workalike.
the issue here is whether or not the broader community would ever seriously consider using an alternative, and whether contributors, particular commercial ones writing drivers for products, would ever agree to maintain two versions.
jen20 30 days ago [-]
What?! Almost every major server and desktop Linux distribution ships a kernel full of patches, which are absolutely forks. That’s before we start getting into the crazy town of the embedded world. Clearly the software can be forked. The question is whether the community can - and that is yet to be seen.
mort96 30 days ago [-]
All those "forks" are dependent on regularly rebasing their patch sets on top of mainline (or they never get updated and lose what semblance of support they had once the SoC they were made for reaches EoL), so they're pretty much irrelevant to this conversation. We have seen no indication that it's feasible for anyone to hard-fork the kernel and continue development in a way that's independent from what we today call "mainline".
ta8645 30 days ago [-]
[flagged]
n144q 30 days ago [-]
> At least, it was exactly that environment that gave us the amazing product that has changed the world.
You need some extraordinary evidence to claim things like that.
To stretch things a bit, it's like saying, while male dominated the field of engineering in the 60s (and still do), it was exactly that kind of environment that made it possible for humans to get to the moon. Can you actually prove it? Really?
It's hard for me to imagine using git will slow down kernel development compared to sending patches in emails.
ta8645 30 days ago [-]
> You need some extraordinary evidence to claim things like that.
No. It's a legitimate possibility. Maybe it wont happen. But maybe it will. There's a reason that military training is meant to be hard though, and not filled with comfort and affordances for personal feelings.
> To stretch things a bit, it's like saying, while male dominated the field of engineering in the 60s (and still do), it was exactly that kind of environment that made it possible for humans to get to the moon. Can you actually prove it? Really?
No human has been back to the moon since that male dominated field sent them there. And when they added women, they couldn't produce a shuttle that could work without huge budget overruns, or reliably. And the only example of a real surge in a return to space, is run by an asshole dictator at Space X.
> It's hard for me to imagine using git will slow down kernel development compared to sending patches in emails.
No, that definitely worked out great. It was created by a gruff guy who was an asshole to everyone, and wrote the basics of Git by himself in a week.
noirscape 30 days ago [-]
He couldn't veto it anyway; by reading the entire thread, you'll see that the maintainer NACKed the request.
After that, Greg KH stepped in (since he was soft asked to help earlier in the thread with an @) to reconfirm that what seems to be the general policy for r4l is followed (aka it'll be a separate file with its own maintainer), with the subtle implication that it would probably just get merged as a separate patch to Linus directly, the complaints of the maintainer be damned.
Marcan's sudden outburst and forcibly adding Linus and Greg to the thread he was responding to came afterwards. You can even see some other rust4linux devs asking him to please not do this, since the situation is under control.
gpm 30 days ago [-]
Put yourself in the shoes of the person submitting this patch. Is a "subtle implication" (and to be clear, it was a very subtle one if it was one at all) that a senior maintainers NAK on a patch is going to be ignored enough to make the whole situation not incredibly demoralizing?
Does it do much of anything to solve the fact they've publicly declared that they are going to do everything they can to stop the project, and that there's a history of them doing just that going on for years now?
Marcan's response clearly wasn't the most productive way to raise these issues, but the issues are there and are not being addressed.
noirscape 30 days ago [-]
To me the implication isn't subtle; the maintainer NACKs, the response from someone on the contributing team is "maybe we should involve @Linus or @Greg" and from that point on, you see Greg KH get involved to note what the proper procedure is and to ensure that it'll be followed. Hellwig is completely sidelined from that point onwards, minus some grumbling noise on his side.
Hellwig is a jerk, yes (probably crosses a few lines), but there's a procedure that sidelines him and his mention for this patch was a mere courtesy (since r4l maintains the wrappers and they're not even kept in his folder).
Marcan's insertion in the thread is extremely overblown and as someone in the thread notes, comes across more like a several hours late cavalry to appeal to his social feed. I have a slightly "nicer" interpretation of it than that (in that I don't think Marcan is that kind of person) since it reads like it's probably just the sort of rage best reserved for a private message to a friend, but he's making it everyone else's problem by threatening social media brigading (which is plain and simple: harassment and unlike Hellwig's rudeness, extremely easy to identify as something to push back on).
nicce 30 days ago [-]
That is not what the maintainer said. The maintainer said that for Rust code in the area he is currently maintaining. I think the main issue was, the he was not accepting second maintainer to take care the Rust part on the same area.
About the Rust code itself; the primary issue was code duplication rather than preventing the use of Rust altogether. Since the suggested code is not merged, every driver needs to write the same code over and over again. That was also something that the maintainer suggested himself (?). There is of course a big downside, but I am not sure if this justifies all the hate.
dralley 30 days ago [-]
>That is not what the maintainer said. The maintainer said that for Rust code in the area he is currently maintaining. I think the main issue was, the he was not accepting second maintainer to take care the Rust part on the same area.
The Rust code is not in the area he was currently maintaining. Christoph didn't even look at the patches before objecting to them. Once it was pointed out that they were not in his area, he rejected them anyway.
Note that, because they are not in his area, he does not actually have the authority to do this. He was CC'd in an advisory sense, it's not really his call to accept them or not, and as a longtime kernel maintainer he surely knows this.
caspper69 30 days ago [-]
The issue is it creates a downstream dependency on his code, even if it is 100% separate and separately maintained.
Once the wrapper is written, any breaking changes he makes in the DMA subsystem will, by their very nature, percolate downstream to the Rust wrapper and then to any Rust code that relies on it.
So basically from that point forth, he will always have to consider the ramifications of his changes on another group of developers, and deal with any backlash those may cause.
Is he being unreasonable? I tend to lean on the side of "yes," but I can certainly empathize with his point of view (not necessarily his approach, however).
steveklabnik 30 days ago [-]
He does not need to consider those ramifications because it is up to the rust for Linux people to fix the issues. He does not need to care about them at all.
They reiterated that in the thread too.
adrian_b 29 days ago [-]
This works only if you trust the Rust people to do their job.
Obviously the maintainer does not trust the Rust people, but they also did nothing to gain his trust, but the opposite.
Just saying "Trust me, or else I will shame you" is not a viable strategy.
The default position of any code maintainer who sees some people coming and saying that they would maintain from now on some parts of the code and that there should be no worries about that, is to not trust them immediately, but only after enough time passes during which they demonstrate that they are really competent and not just claiming to be so.
intelfx 29 days ago [-]
Saying "I do not trust you, so I'm going to stonewall your entire work with which you could have built that trust" is not viable either.
Besides, none of this was said. Hellwig did not say "I do not trust you enough". He said "you are cancer, go away". First is harsh, but at least somewhat reasonable (in the sense that it _can be reasoned with_); second is not reasonable at all. Your interpretation is excessively charitable to an obvious bad-faith actor.
veidr 29 days ago [-]
Why do you guys keep saying he said this?? He did not say that, and you (and everybody else) can see it for yourselves:
> If you want to make Linux impossible to maintain due to a cross-language codebase do that in your driver so that you have to do it instead of spreading this cancer to core subsystems. (where this cancer explicitly is a cross-language codebase and not rust itself, just to escape the flameware brigade).
That's totally, utterly different than your characterization of it.
(So many other people were also falsely claiming that he said it like that, I initially assumed it was true, so I'm a little irritated.)
intelfx 26 days ago [-]
Echoing @steveklabnik's words, you're just hanging up on the semantics of how a particular insult has been made. This does not refute or diminish the fact of an insult.
If I actively participate in and align myself with a community that is committed to doing the $thing, and you come and say to me that "$thing is cancer", or that "the fact of doing of $thing is cancer", then it's functionally equivalent to insulting this community, and by extension to insulting me. In other words, it's clearly supposed to make _me_ feel bad (for pushing $thing, or participating in the doing of $thing), regardless of the precise wording.
It's still an unprofessional, uncooperative, and _unreasonable_ thing to do.
veidr 26 days ago [-]
Sorry; although I'm "on your side" in the sense that I want Rust in Linux and am bummed out that it seems increasingly like it's going to be a multigenerational slog, thanks to entrenched opposition from some of the C old guard, and which might even outlive Linux's window of viability.
But this is Linux kernel development. You just can't be such snowflakes, and so quick to be outraged. My mom died young, of cancer. I don't like cancer. I know that using "cancer" as a metaphor is a very negative way to characterize anything.
But the qualifier he added in the original statement is absolutely enough to make it a fair comment.
He really, really doesn't think using multiple programming languages is a sane approach. Would you really feel better if he said, "I think a multi-language approach is a very bad idea, it will inevitably spread, and it will end up causing systemic problems far away from this initial usage, and make the kernel increasingly frail and unhealthy over time" ?
If so, ... weird?
If not, then I think you are overreacting to the blunt (but technical, if perhaps motivated from some more emotional response) that he really doesn't like this idea at all.
"Cancer" is an appropriate shorthand to refer to a practice that you think causes systemic harm that compounds or grows worse over time. (I'm afraid I myself may have used it to describe PowerPoint presentations as the basis for meetings.)
I think his comment meets the minimal etiquette bar for a serious technical discussion. I mean, it wasn't nice. But the fact that he doesn't agree with you, or like your work, isn't an insult.
> He said "you are cancer, go away".
I find this absurd mischaracterization of what he said a lot more unacceptable than what he actually said. He's bluntly stating his technical opinion (which, again, I don't agree with). But you're not paraphrasing; you're basically lying.
intelfx 26 days ago [-]
> Would you really feel better if he said, "I think a multi-language approach is a very bad idea, it will inevitably spread, and it will end up causing systemic problems far away from this initial usage, and make the kernel increasingly frail and unhealthy over time" ?
Yes, I absolutely would. Because this statement is neutral, specific, and technical (if unfounded, so I'd feel even better if such a statement would have been supplemented with justifications), therefore it can be attacked, argued, and refuted point-by-point on a technical basis. No such thing is possible when technical concerns are replaced with emotionally loaded metaphors.
So yes, I stand by my belief that saying "$thing is a cancer" when talking to someone who is good-faith committed to doing $thing is 1) unreasonable (because it cannot be reasoned with), and 2) an insult (because it is designed to appeal to emotions rather than facts).
> You might not like my answer, but I will do everything I can do to stop this.
rc00 29 days ago [-]
In the face of Coccinelle for Rust still being unreliable, can you blame him or any maintainer? The codebase is too large to suggest that manual intervention every time something breaks is acceptable, especially when the same automated tool has been in place for C for nearly two decades. And worse yet, much of the code that is generated for Rust is in the form of macros which are quite possibly some of the most unmaintainable and difficult to parse parts of Rust.
You might not like the response for being strongly worded but it is indeed backed by a technical stance and not a political or social one as has been repeatedly suggested. Already overworked maintainers are not willing to sign up for additional maintenance to what has been a solved problem. Objectively, no one should disagree with that stance.
steveklabnik 29 days ago [-]
Yes, I do think endlessly relitigating project decisions that have been made is inappropriate.
It is not a technical stance. It is a project management one.
> Objectively, no one should disagree with that stance.
That is exactly why the maintenance burden is not his problem. He is under no obligation to take any additional work here.
rc00 29 days ago [-]
> Yes, I do think endlessly relitigating project decisions that have been made is inappropriate.
Will you feel this way when the ruling eventually comes down that the Rust for Linux experiment has been declared a failure? Referring to what is currently an experiment as a decision is a rather bold misrepresentation of the current state. You want to present Rust in the kernel as a foregone conclusion when the reality couldn't be further from that.
> It is not a technical stance. It is a project management one.
Unstable infrastructure becoming a bottleneck is project management? Maybe a working implementation of Coccinelle for Rust should have been among the criteria before the experiment should have been allowed to proceed. That would have precluded the years of furor this has otherwise caused.
> That is exactly why the maintenance burden is not his problem. He is under no obligation to take any additional work here.
This highlights the crux of the issue and the reason your bias is clouding your view of the issue objectively. You are operating on the belief and trust of the small amount of Rust developers. Reality is proving otherwise time and time again.
steveklabnik 29 days ago [-]
> Will you feel this way when the ruling eventually comes down that the Rust for Linux experiment has been declared a failure?
Yes. What Linus says goes. That's how Linux works.
> Referring to what is currently an experiment as a decision is a rather bold misrepresentation of the current state.
It has been decided that having Rust in tree currently is acceptable. That is not a misrepresentation.
> Unstable infrastructure becoming a bottleneck is project management?
That is not the argument, it is a reason the argument is being made. The argument being made is "Linus should not have allowed Rust in the codebase." That there are technical consequences to project management decisions is not surprising, and they can be good or bad, but it's not the direct objection here, it's a reason why the objection is being made.
> That would have precluded the years of furor this has otherwise caused.
He himself said that he is unilaterally opposed, full stop, and nothing will change his mind. The state of Coccinelle wouldn't make any difference.
> You are operating on the belief and trust of the small amount of Rust developers.
I am taking Linus at his word.
veidr 29 days ago [-]
I know, and I in fact do not like his answer, and think he is wrong in general.
But he didn't say "rust is a cancer", "you are a cancer", "your work is a cancer", or the other permutations of that I've read in this long thread; that's what I was replying to.
His technical assessment doesn't make sense, and apparently isn't even his to make. So that can, and should be, rebutted and refuted. But not by distorting his words, by attacking the substance of it.
(Which I do acknowldge that you have been doing; I've read the entire HN thread, so kudos for that.)
steveklabnik 29 days ago [-]
He said
> (where this cancer explicitly is a cross-language codebase and not rust itself, just to escape the flameware brigade).
Where the cross-langauge in this case is Rust. Rust for Linux is creating a cross-language codebase. That means Rust for Linux is cancer.
> and not rust itself, just to escape the flameware brigade
is like when people say "I'm not trying to be rude, but" and then says an incredibly rude thing. Saying "I think this abstract idea is cancer, and you're the specific instance of this abstract idea, that doesn't mean I'm saying you are the thing" is incoherent.
rc00 29 days ago [-]
> Your interpretation is excessively charitable to an obvious bad-faith actor.
And yet you keep defending Hector.
xmgplays 29 days ago [-]
No it does not require trust.
If the RfL people don't do their job, well then Linux releases with the Rust parts marked broken and that's that.
nicce 30 days ago [-]
If that is true, why he was the one that was asked to review/ or why his opinion even matters here? The must be some sort of correlation to his code or this does not make sense at all..
dralley 30 days ago [-]
He wasn't asked, he was CC'd on the patchset because it wraps his subsystem. If he was interested in doing a driveby review in good faith, or taking interest in what was going on, then he could have done so.
Dr_Emann 30 days ago [-]
"The common ground is that I have absolutely no interest in helping to spread a multi-language code base. I absolutely support using Rust in new codebase, but I do not at all in Linux." https://lwn.net/ml/all/20250204052916.GA28741@lst.de/
That doesn't sound like he's only talking about in his area to me
rcxdude 30 days ago [-]
It's just in his area where he has the power to say no, and it's important enough to be a big impediment to the whole project.
bjord 30 days ago [-]
is this just weird religious adherence to the belief that a multi-language codebase will be harder to maintain? what's the rationale, exactly?
zoogeny 30 days ago [-]
I'm just parsing the thread but it seems that changes to the C api can break the Rust bindings.
This leads to two situations: the C maintainer has to also update the Rust binding, or the patch has to wait for a Rust capable maintainer to fix them up.
For the first solution, the C maintainer is claiming he has enough work on his plate just keeping up with the C code that he doesn't want to work on Rust. He also believes it is unfair to force every C maintainer to learn enough Rust to keep their integration points working.
For the second solution, the C maintainer is pointing out that Linus has a history of refusing to merge C patches that break Rust builds. So even though the Rust advocates promise they will handle all of the Rust stuff and they are OK with their stuff being broken after C changes until they get around to fixing it, Linus doesn't seem to actually allow for this in practice.
I can see the maintainers point. Sooner or later Rust bindings on critical systems will be essential and changes to the C code will be gated on changes to the Rust code. It is a fantasy of the Rust maintainers that they will have to shoulder that entire burden. But even if they did, it would give them some pretty hefty leverage over the C maintainers in those essential cases. And it also introduces a requirement that someone with enough Rust and subsystem knowledge is even available for the job. People making promises today may disappear tomorrow, leaving the maintainer with an essential binding to a language he doesn't want to support.
edit: as has been said elsewhere, Linus could make some of this go away by committing to let the Rust builds break. I don't know if that could be done in a way that wouldn't be a de facto fork.
steveklabnik 30 days ago [-]
> Linus could make some of this go away by committing to let the Rust builds break.
Linus already did that. This is the state of things today. C code is allowed to break the Rust, and it's the Rust for Linux people's responsibility to get it working again, not the C folks.
zoogeny 30 days ago [-]
I'm just an interloper and only going on the linked thread, but there are specific patches that missed merge windows due to Rust build breaks. The patches referenced are claimed to be exceptions but I can understand the fear. Linus is saying one thing but making exceptions in some cases. As Rust becomes more and more integrated into core Linux systems those exceptions may become more frequent and may eventually become the rule.
To be fair, I think another valid solution to this problem is just to bite the bullet and tell the grumpy C developers to deal with it. At some point the fallout from an exodus of grey beard Linux maintainers will actually be less than fighting this battle. As many point out, they are going to exit the project one way or another eventually.
steveklabnik 30 days ago [-]
> The patches referenced are claimed to be exceptions
From what I understand, this is correct, or at least that is, this was a build system bug that caused accidental breakage, not a deliberate change in the policy that the kernel must be able to be built with Rust support turned off, and that that is the build that matters. Exceptional in a "rarely happens" sense and not a "deliberate choice to create an exception to a rule" sense.
XorNot 30 days ago [-]
This entirely depends on the supposition that there are more new kernel developers who want to, and are able to, use Rust then C.
I don't think this is proven: what we have is a specific group of Rust developers, but they are there by virtue of that group existing. There are numerous more kernel contributors today who work in C, and since the greybeards are happy to keep up the work it's not like anyone else is going to easily step in to replace them (since it would be a coup not a handover, if they didn't actually want to step down).
An equally plausible future is some such Rust mandate happens, you drive off the existing C developers, then it turns out the Rust developers aren't actually numerous enough or committed enough (or even good enough at long term project social management) to keep the project going and it dies (or forks into CLinux or something).
Linux itself was a "hobby project" which ultimately succeeded because it did the work which needed to be done, while everyone else was still completely sure the microkernels were the way of the future.
ho_schi 30 days ago [-]
Thanks.
dralley 30 days ago [-]
No, the point is nonsense. Rust is a consumer of the APIs just like every other driver / subsystem is. Any change to the C APIs would likely require collaboration with those other maintainers no different than Rust. And CH would be immediately shut down if he tried to roadblock some random driver that needs DMA purely because he doesn't want the existence of that driver to "increase his workload".
zoogeny 30 days ago [-]
I think you are using inflammatory language by calling the point nonsense.
As an outside observer, literally no skin in this game, I can see his point. If his C code changes breaks other C code then he is at an advantage compared to if his C code breaks a Rust binding or Rust drivers. The degree to which this adds to his burden of maintenance is up to him to decide.
dralley 30 days ago [-]
The kernel is extremely complex. He very likely still needs to work with other maintainers if his code breaks their code. In this case he has LESS work to do, because the R4L developers own all fixes to Rust code, and he is free to break them, and they have to clean it up themselves.
zoogeny 30 days ago [-]
The complexity of kernel isn't relevant, unless your point is that the kernel is already so complex that maintainers shouldn't advocate against new and significant complexity?
As for less work, that is alternative two from my original post which states the maintainer now has to wait for someone else to do the work or risk his change being stalled (worse case: indefinitely). It doesn't matter if the R4L team promises that they are OK with broken Rust code since the only person whose decision matters is Linus. Until Linus clarifies his stance on broken Rust builds the promises of the R4L team are promises that they are literally incapable of delivering on.
steveklabnik 30 days ago [-]
It's nonsense because if his C code breaks the Rust binding or drivers, that is not his problem. It adds zero maintenance for him.
alchemio 30 days ago [-]
But it does. He has to notify R4L of what his changes were and how it broke the Rust driver. Even if he didn’t, he will still be contacted for information regarding these things.
steveklabnik 30 days ago [-]
He does not have to notify them.
> he will still be contacted for information regarding these things.
Just like any other user, and he is free to ignore them just like any other person doing so.
dralley 30 days ago [-]
How is that different from any C driver currently in existence? Notifying API consumers of what is changing and how and answering the occasional is absolute table stakes for any software developer and throwing a tantrum about that is incredibly juvenile.
FridgeSeal 30 days ago [-]
How is that literally any different from C code?
There’s 2 kinds of scenarios here:
- Rust code involved: C code change breaks Rust. ~Send~ ~an~ ~email~ ~and~ move on.
- C code involved: inform other C devs, either work with them or wait for them to fix.
The way I see it, either way, the “Rust stuff adds unacceptable amounts of workload” doesn’t really check out.
Edit: turns out he doesn’t even need to inform the Rust devs.
nicce 30 days ago [-]
> some random driver that needs DMA purely because he doesn't want the existence of that driver to "increase his workload".
This isn’t blocking any drivers. Just adds duplicate code.
naasking 30 days ago [-]
Maintainers come and go, languages come and go. C will never go away and everyone working on kernels knows C, so there's a certain labour pool and skillset that will always be available that doesn't necessarily apply to Rust. That's even setting aside any technical issues, like bugs creeping up in the language interoperability layer, which obviously doesn't really happen if you're only using one compiler.
ChocolateGod 30 days ago [-]
I think both arguments have credibility.
The R4L says they will make sure the Rust code is fixed when the C code is, and that's admirable, but the concern it means a developer now has to wait for that, holding up their work for release/submission. The bus factor is now on the R4L team.
Meanwhile, everyone involved in development for Linux already knows C.
steveklabnik 30 days ago [-]
> the concern it means a developer now has to wait for that, holding up their work for release/submission.
They do not have to wait.
ChocolateGod 29 days ago [-]
That's apparently still unclear according to the LKML.
somanyphotons 30 days ago [-]
The linux kernel project specifically cares about the labor pool of maintainers.
My assumption is that it's easier to train someone on rust then to train someone to be a kernel subsystem maintainer
WesolyKubeczek 29 days ago [-]
It’s adherence dictated by lived experience, if anything.
Much like the “don’t rewrite from scratch” mantra was written in blood and tears.
30 days ago [-]
znpy 30 days ago [-]
I think the core of the issue is expecting people to agree with stuff.
Linux is free software and there's really nobody stopping people from forking it and doing things the way they want. It used to happen all the time once upon a time, nowadays people seems to be afraid of doing it.
bitbasher 30 days ago [-]
The kernel is nearly 30 million lines of code. I would love to see a fork where Rust starts taking over sections of it, but that's a huge undertaking that would clearly take many years.
znpy 28 days ago [-]
Yep, either people are willing to do the fork and take the challenge or they accept that nobody has to be forced to accept their opinions and contributions, good or not.
n144q 30 days ago [-]
I can easily fork your project with 1k lines of code, but not Linux kernel and stay up-to-date with all the latest commits. Nobody can.
gkbrk 29 days ago [-]
Why would a Rust for Linux fork want to stay up-to-date with all the latest commits that are in C?
If all the latest commits in C are so useful, even to a Rust fork, perhaps the Linux C devs are not off-base that Rust isn't worth it for now.
sgt 30 days ago [-]
Give him time, Linus will reach out soon regarding Rust.
I wouldn‘t expect a grand Rust announcement anytime soon, above what has already been said. Rust in the kernel seems to be fine, but it will have to adapt to longstanding kernel processes. And if it means there won‘t be Rust in some maintainers‘ subsystems, so be it. The kernel won‘t be 100% Rust next year anyway.
Dalewyn 30 days ago [-]
I've conversed with marcan a few times (on completely unrelated and inconsequential things). As far as I know he's a decent man.
That said, I'm going to agree with Linus there: Cancel culture ("social media brigading") isn't the solution.
rcxdude 30 days ago [-]
Indeed, but where is the 'real' solution? If no-one higher up is going to step in and merge the patches despite the blocking maintainer, how is "the process" going to move R4L forward?
(Edit: Ok, reading some other context, it seems like this is indeed what's happening, which does make this reaction a little less justified. I can certainly see why it's no fun to have people in the project saying they will do whatever they can to stop an initiative, but if they aren't actually able to block it, then it doesn't seem worth quitting over)
chippiewill 30 days ago [-]
They can merge regardless. The maintainer nacked something they don't even own, they were asked for a review as a courtesy as it wraps their subsystem.
That said there's an outstanding question about whether Linus would accept something that breaks Rust builds for merge. Linus hasn't commented on this yet, but I'm sure he will.
pas 29 days ago [-]
Sometimes there's no win-win-win solution.
I think people who write C should stop unless it's to fix security bugs and should do something else, anything else, maybe even learn about programming. But even with this mindset Linux is a C project and the R4L folks promised to thread the needle, if it cannot be done this time, then it cannot be done this time. They need to wait.
sgt 28 days ago [-]
> "I think people who write C should stop unless it's to fix security bugs and should do something else"
That's pretty harsh. C has provided so much value to the world and security isn't the most important thing in the world - functionality is. Not saying security isn't important overall though.
And also, imagine another Rust competitor comes up in 5 years called "Moose" and M4L comes up, competing with R4L?
pas 28 days ago [-]
Of course, internal combustion engine motorcycles too, but I hate the aggressively noisy noxious little shits whizzing around my code, I mean, me. :)
... but I'm aware that it's simply not realistic. These are raw thoughts not "working policy" . My problem is that old software is just barely functional (huurah, we achieved the barely standing equivalency from civil engineering) and we are not spending enough resources on that, nor on security.
And probably my Linux honeymoon period ended after ~10-20 years of work (and/or personal) use, and I feel every point of Marcan's letter, even though I never did kernel development, only the usual troubleshooting and trying to figure out which bug/patch/feature has what status.
But, of course, as long as this blessed circus continues to deliver every ~3 months a new version with this velocity it'll keep going. And Linus is right, if we don't like it maybe (:p) it's on us to accept that. And also maybe Drew's humble suggestion will be the prescient one.
If Moose is better I expect people to fairly consider it, and when the consensus forms that yes it's at least as good as C then I want the C people to realize their own responsibility in maintaining critical infrastructure, and I want them to at least have a plan on how to improve, because even in civil engineering the baseline for "barely" has increased a lot over the past decades. (And of course in many cases arguably society has overshoot that, for example with the 2-stairs requirements and so on, where these concerns drastically disincentivize evolution of population centers and transportation networks.)
sgt 28 days ago [-]
Given the choice between a Linux compatible OS made in Rust and R4L I would absolutely hope sanity prevails and the latter is chosen. It's just going to take them forever to get the optimizations right, then people will still prefer Linux since that's going to be the "server OS" standard for a very long time.
pas 26 days ago [-]
Ideally there's room for both. I'd argue for many many things stability/security is more important than performance.
> Simona Vetter: (addressing Hector) ...Now I'm left with the unlikely explanation that you just like thundering in as the cavalry, fashionably late, maximally destructive, because it entertains the masses on fedi or reddit or wherever. I have no idea what you're trying to achieve here, I really don't get it, but I am for sure fed up dealing with the fallout.
> Dave Airlie: To back up Sima here, we don't need grandstanding, brigading, playing to the crowd, streamer drama creation or any of that in discussions around this. The r4l team and drm maintainer team have this sort of thing in hand, it's not like we don't understand the community of the Linux kernel, and having this first reaction to blow shit up and dramatise it just isn't helpful.
(Obviously I am taking things a bit out of context here, I recommend giving this thread a read.)
Seems to be pretty level-headed, on point, and damning. So yeah, I don't know if I am on marcan's side this time.
dralley 30 days ago [-]
Sima also went way too far with some of her comments this morning:
> Being toxic on the right side of an argument is still toxic, [...]
unironically, immediately after saying @marcan
> and if that then causes you to ragequit, because you can't actually deal with the heat you've been dishing out coming back around the corner: fuck off
...is quite tonedeaf at the very least. Especially given what Marcan said about dealing with this not being his paid job.
> Currently I work at Intel’s Linux Cloud SE group, mostly creating havoc in kernel driver’s given my more than a decade of work in the graphics subsystem. I’m also co-maintaining the graphics subsystem. I also have been drm/i915 kernel maintainer for a few years, but handed that all off to a great new team.
hitekker 29 days ago [-]
Sima is another Rust for Linux member, right?
nialv7 30 days ago [-]
Yeah I commented before I saw that one toot from @sima. Indeed they both look bad here.
moralestapia 29 days ago [-]
[flagged]
Havoc 30 days ago [-]
From what I can piece together it seems Hector is upset about someone ("Hellwig"?) doing something that was seen as intentionally sabotaging the rust efforts. Hector posted about it on socials. Linus came down on Hector for leveraging socials to fight kernel disputes. Hector quits.
No doubt that is a flawed summary so feel free to correct
steveklabnik 30 days ago [-]
You're roughly correct but you're missing some important context.
Hector wasn't the developer of this patch. However, he is a user of it. He has had some rough interactions over the last few years. And so seeing this happen (even though it's happening to someone else) is a "the straw that breaks the camel's back" kind of deal.
chippiewill 30 days ago [-]
No that's 100% accurate.
Marcan is probably a little acutely upset not just because he was told off, but also because Linus hasn't waded into the actual issue at hand (which he needs to, not even Greg K-h can answer it). But that issue is less urgent and it's probably reasonable for Linus to:
a) Mull it over before making a rash decision
b) let tempers calm.
I would guess Linus will wait til Monday and is probably also having some off-list chats anyway.
gpm 30 days ago [-]
I couldn't speak to off-list chats, but this has been going on for awhile.
The statement that they were going to maintain this without the support of the DMA maintainer was made 22 days ago [1]. That statement was rejected 11 days ago [2]. Linus was explicitly asked to intervene 10 days ago [3]. (Too complete the timeline Hector Martin first got involved 4 days ago, Linus intervened about that yesterday).
I don't know why you think Linus will suddenly choose to address this Monday.
Note: I did not intend to particularly link to Christoph Hellwig comments, it just so happens that these contain enough quoting form previous answers to trace out something coherent.
For the complete context, you should walk up/down (and laterally) the thread to get more details and make your own opinion of it. It doesn't take very long.
30 days ago [-]
FridgeSeal 30 days ago [-]
I saw the social media post, and it didn’t even register as “trying to start a brigade” IMO.
I read it as “look at this shit” and general frustration with the likes of DMA-guys behaviour.
amatecha 29 days ago [-]
Yup, I'm not at all understanding the framing of those posts as "brigading". He's venting, justifiably angry. He wasn't like "go post at these guys and help me fight!", at least I didn't see anything in his messages suggesting anything along those lines.
coldtea 30 days ago [-]
Martin has worked hard on Asahi, but comes of as looking for drama and virtue signalling oftentimes. I'd give this to Linus.
duxup 30 days ago [-]
>and virtue signalling
I'm not disagreeing as I don't know what exact things you're talking about, but I find "virtue signalling" and "communication" to be very similar terms these days. From statement to statement I'm not sure what anyone means by that phrase anymore.
ubermonkey 30 days ago [-]
[flagged]
duxup 30 days ago [-]
I like to not assume the worst, more so on HN, but I do run into a lot of situations elsewhere on the internet where "virtue signaling" just means "someone said something I don't like".
But generally I do like to wait to understand specifically what someone means before assuming.
Dansvidania 30 days ago [-]
so how should it be called, in good faith?
duxup 30 days ago [-]
That's almost what I'm asking, knowing what they mean would help that some. It's almost peak irony when I saw people repeatedly tweeting about someone else's "virtue signaling". I honestly don't know what the difference is between whatever they thought the first person was doing vs. their action.
WolfeReader 29 days ago [-]
The post above what you replied to already had a good synonym: "communication".
littlestymaar 30 days ago [-]
I personally have no idea, because I don't even know what's the good faith meaning of this phrase.
ubermonkey 30 days ago [-]
They should be clearer about what they mean.
Cumpiler69 30 days ago [-]
>but comes of as looking for drama and virtue signalling oftentimes
It's easier to name the major Linux FOSS projects that DON'T have drama and virtue signaling than the ones with.
If you read the Github comments on System-D, GNOME, etc, it's like watching children bickering on Sega VS Nintendo.
Turns out FOSS devs are humas just like everybody else and suffer from the same flaws.
wolvesechoes 30 days ago [-]
"Turns out FOSS devs are humas just like everybody else and suffer from the same flaws."
Hell no. FOSS communities, as other spaces created by permanently online individuals, definitely have higher-than-average number of mentally unhinged snowflakes.
Cumpiler69 29 days ago [-]
[dead]
bmicraft 30 days ago [-]
It's called systemd, all lowercase, no punctuation :)
randmeerkat 30 days ago [-]
> Turns out FOSS devs are humas just like everybody else and suffer from the same flaws.
It is rather anticlimactic. I had always imagined FOSS to be this free exchange of ideas, thoughtful consideration, and intentional action. Seeing what it has become though… Maybe closed source is better.
toast0 30 days ago [-]
> Maybe closed source is better.
I've had similar pissing matches in closed source development, instigated by me and not...
Often, these things get resolved or left simmering without any public visibility, so that's nice as a user. And there's usually a somewhat clear heirarchy of authority, where the boss can say I don't care who's right, do X; which resolves issues in ways that sometimes a technically minded open source project can't; that can often help with bikeshedding between usable options.
But sometimes you just keep working somewhere because deep in your heart of hearts you want to do it your way, and once that other person quits or maybe even goes on vacation, you can. And sometimes people endeavor to actively push that person out, which I guess I've seen on FOSS drama too, but office politics have a way of lurking under the surface more, IMHO.
arp242 30 days ago [-]
> Seeing what it has become though… Maybe closed source is better.
You thought it was better in the past? Read up on the great ncurses maintainer drama. Or the NetBSD/OpenBSD split. Or FreeBSD/DragonflyBSD split. Or the Emacs forks, GNU libc forks, GCC fork, etc. etc. etc.
This kind of drama has always existed. Difficult people have always existed. And even good people have always been struggling with their emotions.
And in all my closed-source $dayjobs I've had to deal with all of that too. Sometimes significantly worse than I'm seeing here.
aleph_minus_one 30 days ago [-]
> Maybe closed source is better.
At least in some cases this is plausible. The money people get for working on closed source software irons out some issues, for example:
Some people who voluntarily work on open source code do it for self-actualization, which indicates that they have a strong desire to push their wishes through. This implies that a lot of drama gets involved if these people don't get their way.
flohofwoe 30 days ago [-]
> Seeing what it has become though...
Was it ever different? Not as far as I can remember at least. I think one of the main strengths of open source development is that it works despite the drama.
With open source projects, everybody is free to start their own fork over disagreements, and if the fork actually turns out to be objectively better it will replace the original project.
> Maybe closed source is better.
It's the same and worse over there, the drama just isn't public.
n144q 30 days ago [-]
This is much less likely in a company. Any sane company decides on a clear direction which way to go. Either do X and put resources in it, or not and instead focus on something else. They may change directions, but never "maybe X" at a specific point in time. Someone at the company makes a decision on this.
Of course, with notable exceptions. See Apple Car, Android tablets etc.
randmeerkat 30 days ago [-]
> It's the same and worse over there, the drama just isn't public.
At least you’re getting paid. What’s the point of spending one’s free time arguing with strangers on the internet over some code that will be refactored anyway ten years from now..? Life is short, have fun, enjoy it. If you’re spending time or money on something that sucks, walk away.
ThrowawayR2 30 days ago [-]
> "Maybe closed source is better."
I assure you it isn't; it really, really isn't. You don't see the drama because 1) it's behind closed doors and 2) because the people involved know their job is at risk if they cross the line.
duxup 30 days ago [-]
I hate to mention this but closed source appears to involve humans too. I was disappointed when I discovered this as well.
renewedrebecca 30 days ago [-]
"People are a problem" - Douglas Adams
throawayonthe 30 days ago [-]
[dead]
Dansvidania 30 days ago [-]
FOSS devs put a lot of time in what they do and they are understandably attached to whether what they do is good/successful, at least in the same proportion the general population is (but arguably more due to how much dedication goes into FOSS, kind of by construction)
bakugo 30 days ago [-]
[flagged]
ziddoap 30 days ago [-]
>Starting to think it's not just a coincidence.
Is your theory that rust makes people dramatic? Or that dramatic people like rust? What other options are there, if not coincidence?
Eval-Apply 30 days ago [-]
>Is your theory that rust makes people dramatic? Or that dramatic people like rust? What other options are there, if not coincidence?
There is a cognitive bias called "loyalty to the brand", in which it says that people prefer the things they have because they rationalize their choices to protect their sense of ego. When they invest time (or a lot of money) to something, they create an emotional connection, especially if that was a choice and not something imposed on it. It is choosing one thing about the other that leads to narratives about why you have done a certain thing, something that is usually connected to your self-image.
There are a number of cognitive trends that converge to create this behavior. This assignment effect appears when you feel that the things you have are superior to things you don't have.
Another bias is the fallacy of irrecoverable costs. This happens when you spend time or money on something you don't want to have or don't want to do, but you can't avoid. For example, imagine that you spent time studying Rust. You will be "hooked" on the idea that given the time spent in this, it is better to defend the language, even if you imagine that it is not for all things.
To combat post-decisional dissonance, the feeling that you committed to one option when the other option could have been better, you strive to feel justified as to what you selected to reduce the anxiety created when questioning himself. All this forms a gigantic group of neurological associations, emotions, details of self-image and trends around the things you have.
jamincan 30 days ago [-]
All of these are valid, but would this not equally apply to a linux dev stamping their feet and obstructing other people's work because they don't like rust?
bakugo 30 days ago [-]
> Is your theory that rust makes people dramatic? Or that dramatic people like rust?
Both, really. As a language that was designed from the ground up to be a replacement for C and C++ (thus implying that it's superior to these established languages), it positions itself as inherently "dramatic" and anti-establishment.
This obviously attracts these political activist types who love to insist that their way of thinking is the way forward, that everyone else was simply doing it wrong before they came along, and that anyone who questions their beliefs is an obvious enemy of progress who should be silenced at all costs. It's a cult, basically.
Pannoniae 30 days ago [-]
I think the second one is more likely. People choose languages and ecosystems which fit their way of thinking so naturally, the ecosystem shifts to that direction. This is a self-reinforcing loop :) (one can naturally see this in many languages when the language advocates say "you are just holding it wrong...")
bigstrat2003 30 days ago [-]
I'm inclined towards the second explanation. But whatever the case may be, there really is an unusually high amount of drama in the Rust community. Maybe Rust just attracts really passionate nerds with a lack of social skills, IDK. But there's something going on there.
I think it is a human trait to like to win arguments. In some card games, there is a thing called a trump card [1]. The trump card has this special ability to beat all other cards.
Rust has a kind of trump card: memory safety. If you get in an argument about code it is often possible to maneuver the argument in the direction of memory safety at which point the Rust advocate gets to default win the discussion.
I think this "trump card" aspect attracts a particular kind of person to advocate for Rust simply because they like to feel technically superior to others. Whenever they are in an argument, no matter what the context, they simply have to play the game: how can I make this technical argument about memory safety so that I can win by default.
This perspective just shifts the problem one meta-layer up: one side (Rust advocates) considers compiler-enforced memory safety to be a trump card, while the other side does not. So side A is "right" because they have the trump card who they played, but side B is also "right" in that they don't consider the stupid card that side A played to be a trump. The rest is drama.
Thus, instead of drama, we get meta-drama, i.e. nothing has changed.
rc00 30 days ago [-]
“Never argue with an idiot. They will drag you down to their level and beat you with experience.”
― Mark Twain
dralley 30 days ago [-]
...As opposed to kernel developers? Or even Linus himself 5 years ago?
zamalek 30 days ago [-]
> Martin has worked hard on Asahi, but comes of as looking for drama and virtue signalling oftentimes.
Aren't these diametrically opposed? Virtue signaling is loudly claiming to have some virtue in the absence of that virtue. Hector has receipts, in the form of commits, as proof.
Virtue signaling would be me appearing on the mailing list and spouting my beliefs.
moralestapia 29 days ago [-]
There's more than one flavor of virtue.
SamuelAdams 29 days ago [-]
I cannot find it, but I distinctly remember a post by Rachel on her blog (rachelbythebay) that talks about this exact problem in open source.
Sometimes the nuance of appealing to maintainers emotions is more work than writing the software yourself and maintaining your own private fork.
If someone could find that blog post (and subsequent hacker news ref) it would be a fun way to compare this discourse to Rachel’s discourse.
How is this not the top comment? I was scratching my head wondering until I found your links.
So the smackdown from Linus is what motivated it. Honestly though if you read the email Linus is replying to, it was deserved. To be fair, Hector Martin may be one of the smartest hackers alive today. His fame goes way back to hacking the Playstation 3 with geohot and Hector has even found security vulnerabilities in Apple Silicon. He's done great work with Asahi Linux by weaponizing his keen penetrating mind to support open source freedom. But like his buddy geohot he can be a bit childish. Right now Hector seems to be laying low. His social media accounts are no longer accessible. It seems even archive.org and archive.today have no recollection of him. That's impressive.
So what triggered him to act out of character? It seems like he wrote his Apple GPU driver in Rust and he needed Rust DMA support in the kernel. I know, a curious thing for a Rust developer to want more power to do things that are memory unsafe. So the DMA maintainer Christoph Hellwig hates Rust. He thinks Rust is a cancer in the kernel. Cristoph refused to help Martin create Rust APIs for DMA. That's why he went ballistic.
Chances are they'll all make up when this blows over, or someone will just rewrite his GPU driver in C. There's not going to be as big of a push for Rust with this recent government. For example, the White House recently took down its paper about the future of programming being memory safe. The money for Rust is going to dry up. It's becoming socially acceptable to push back against efforts to convert everyone to Rust.
lazyasciiart 29 days ago [-]
> Cristoph refused to help Martin create Rust APIs for DMA. That's why he went ballistic.
No, he tried to prevent other people from doing the work to create Rust APIs, and said that he would do everything in his power to prevent anyone from doing it.
depr 29 days ago [-]
> the White House recently took down its paper about the future of programming being memory safe
> It seems like he wrote his Apple GPU driver in Rust and he needed Rust DMA support in the kernel.
Did he really NEED it? Why he couldn't use the C API?
asadalt 29 days ago [-]
that’s exactly my question. why can’t he depend on C API and just consider it is memory safe and all.
mixmastamyk 29 days ago [-]
Thanks for explaining what rust had to do with apple hardware drivers.
eqvinox 29 days ago [-]
He also got his treehouse.systems Mastodon account "suspended by a moderator". Not sure if the treehouse people have said anything more specfic, but I am entirely unsurprised given how he behaved on there.
It's a quite clear case of "what you accuse others of is what you yourself resort to". He was calling out others for unreasonableness, flaming and sabotage — and did exactly that himself.
neobrain 29 days ago [-]
It doesn't say anything about moderator action for me.
He closed the account himself:
> I actually wasn't sure if I wanted to delete my Mastodon entirely or not, but as I intended to fill in my password for confirmation and decide whether to click the button, my password manager auto-submitted the form for me. Call it fate, I guess. I mostly don't regret it. Maybe I'll be back some day, maybe not.
It is gone now and gives a generic "nothing here"; I have no idea whether the "suspended by moderator" display was some kind of bug, transient state, or whether he's just lying, or both things are true and he just deleted his account after it was suspended.
(Well, his Reddit post doesn't claim his Mastodon account didn't get suspended, so it'd "only" be the omission kind of lie…)
FWIW, I don't understand the logic of deleting the Mastodon account but continuing to post on Reddit… those are both "social media" in my mind…
neobrain 29 days ago [-]
> whether he's just lying, or both things are true and he just deleted his account after it was suspended
This is obviously just a Mastodon bug (backend treats suspension and deletion as the same thing, for example). I'm not sure why one would entertain the idea of marcan making up a lie about being suspended from an instance he's an admin of.
adrienne 28 days ago [-]
I am on the moderation team at Treehouse. Marcan has not violated any of our community guidelines and he categorically was not suspended from our Fediverse instance. He chose to delete his own account.
Feels like a problem with the dynamic/partial JS content loading.
(Apologies for the confusion, there's no indication that made me suspect a bug... and I hadn't at that point seen anything about him deleting his own account yet.)
adrienne 27 days ago [-]
Thanks, yeah, this is definitely a bug or something.
eqvinox 29 days ago [-]
Actually… I'm really not a fan of how Mastodon handles account deletion. I've interacted with him there about a week ago, and all of his posts are now missing from those threads. I guess it makes sense from a "be able to change your ways and not be stuck with ancient bad things you did" perspective, and there's a right to deletion/"be forgotten" in some legal frameworks, but this hinders necessary community processes. At least the LKML mails are permanent…
I would've liked to link a post or two of his to show just how little flexibility and tolerance there was from his end regarding his social interactions, even when being questioned about them in an outside context and in a reasonably neutral manner. Ohwell…
steveklabnik 29 days ago [-]
When you delete something, your instance sends Delete events to other instances. Well behaved instances respect this request, but you could have an instance that does not.
karel-3d 29 days ago [-]
See, nobody would close his account if he was still on Twitter.... sorry X now
eqvinox 29 days ago [-]
Yeah, on X he would've been shadow banned long ago instead, for some random left-leaning post that just happened to get too much attention…
mjw1007 30 days ago [-]
> Apple/ARM platform development will continue downstream. If I feel like
sending some patches upstream in the future myself for whatever subtree
I may, or I may not.
I suppose it's possible that that could turn out well.
The situation with Apple hardware feels a bit like the early days of Linux (including the fast pace of development). There was a time when if you wanted broad hardware support it was better to run an Alan Cox kernel than a Linus kernel. And the whole point of git was to have a system that didn't require one central blessed tree.
trollied 30 days ago [-]
Linus replied:
How about you accept the fact that maybe the problem is you.
You think you know better. But the current process works.
It has problems, but problems are a fact of life. There is no perfect.
However, I will say that the social media brigading just makes me not
want to have anything at all to do with your approach.
Because if we have issues in the kernel development model, then social
media sure as hell isn't the solution. The same way it sure as hell
wasn't the solution to politics.
Technical patches and discussions matter. Social media brigading - no
than\k you.
ho_schi 30 days ago [-]
Context
I struggle to follow the LKML through the web-interface. LORE seems to provide a better view:
My impression, while still struggling to follow the message flow:
I think social media and shaming are harmful and understand the reaction of Torvalds. The position of the DMA maintainer seems also to make sense for me, to keep code maintainable over decades it must remain in a nice and tidy state. That is the hard work.
PS: I want to avoid actual names of persons.
dralley 30 days ago [-]
>Maintainer of DMA wants to keep the code clean and not mixing languages[1]. And tries to avoid dangerous offers like "we will maintain it for you".[2]
The Rust bindings are not in his tree. They do not touch his code. They are effectively no different than any other subsystem or driver which uses DMA. If he tried to veto some random driver that needed DMA from using DMA for no reason other than because he didn't want to have to deal with it if he changed the API in the future, that maintainer would be told to F-off because that's not his call.
Christoph is throwing NACKs around that he doesn't actually have the authority to NACK.
exDM69 30 days ago [-]
> The position of the DMA maintainer seems also to make sense for me, to keep code maintainable over decades it must remain in a nice and tidy state.
Perhaps so, but that discussion was two or three years ago. Stalling other contributors' work now is counterproductive, especially for changes that do not touch files maintained by them.
This does not justify any brigading behavior, though.
crossroadsguy 28 days ago [-]
> no than\k you
Is that a typo or he indeed intended to escape that 'k'?
(Sorry, I know this doesn't add to the drama or what's going on there, which really doesn't interest me one way or the other, but this tiny bit had me curious)
30 days ago [-]
gigatexal 29 days ago [-]
I don't have anything to add regarding the Hector v. Linus debate, who was in the wrong, who was in the right, who's to blame etc...
All I want to know is what's the long term viability of Asahi Linux or Linux for that matter on M series chip'd Macs? What's the burden going to be for Fedora Asahi if the work remains out of tree? Has Redhat/IBM stated they'll support it via the Fedora project going forward? What if they pull support?
ddtaylor 29 days ago [-]
I think right now Marcan can work magic and reverse these chips and other pieces. Long term it's an arms race and Apple has other motivations to lock the platform down further. They may even get told to make it compatible, but they seem to be willing to maliciously comply with those directives.
I am reminded of the Beeper messenger stuff. Like it's cool when people hack these things together to do stuff, but the community as a whole has seen this episode before. We probably shouldn't be making any choices or compromises to make Apple stuff work, because they are adversarial.
gigatexal 28 days ago [-]
Some other devs from the project have stepped up to coordinate getting their work into the kernel!
sturza 29 days ago [-]
Wow, this thread is wild. It’s like everyone’s losing their minds over mixing Rust into our old, battle-tested C kernel. Sure, Rust promises a ton of safety benefits and could really help keep nasty bugs at bay, but some folks are super worried that every time a C API changes, the Rust side will break—and then someone’s stuck fixing it. It’s as if everyone’s saying, “We’re cool with experimenting, but don’t force us into a multi-language mess we didn’t sign up for.”
What really gets me is the whole leadership vibe. If Linus had just clearly said, “Alright, Rust is in, but only in these specific parts and under these conditions,” a lot of this back-and-forth and social media shouting would’ve been avoided. Instead, we’ve got a bunch of maintainers arguing about process and even threatening to use social media to shame people, which just adds more fuel to the fire.
At the end of the day, it’s not as simple as “Rust or no Rust.” Some parts of the kernel might really benefit from Rust’s safety, while other parts might be fine sticking to C. The real challenge is figuring out how to integrate Rust without turning everything into a maintenance nightmare. We’re all aiming for a better, more robust kernel here, but if we keep getting bogged down in personal drama and endless debates about process, nobody wins. Maybe it’s time to take a deep breath, set some clear rules, and move on instead of letting all this online drama derail progress.
0x1ceb00da 29 days ago [-]
Linus vs. Rustaceans: the get off my lawn sequel nobody asked for. Kernel devs now double as drama critics, social media is the new mailing list flamewar arena, and somewhere a C pointer quietly segfaults out of spite. Will rust ever "make install"? Stay tuned! To find out in the next episode of Keeping Up with the Rustaceans
adager 29 days ago [-]
Marcan hasn't actually resigned. He's still posting on the LKML under a well-known alias.
Marcan is still posting to the LKML as himself too and he said he might contribute patches in the future if he feels like it. What he did, and this entire thread is about, is he resigned as a maintainer:
So the title is factually correct. But I wouldn't be surprised if he tries to add Lina as a maintainer once things calm down.
Topgamer7 28 days ago [-]
I always enjoyed watching Marcan's streams. But I couldn't do Lina's, only because the high pitched voice changing was grating.
secondcoming 29 days ago [-]
Is this the same person who has YouTube videos narrated by a cartoon Japanese schoolgirl?
alberth 29 days ago [-]
> I am supported
exclusively by donations, which incidentally, have been steadily
decreasing since the start of the Asahi Linux project. The project has
zero corporate sponsorship.
People’s donations to Asahi Linux have decreased, according to Hector from this thread [0]
He basically said goodbye like 4 times and continued to make long ass rants that lead to nothing. Is this what you want to spend your time on? I already feel gross that I went through all these threads. I can't imagine how you would feel having written all these paragraphs of slop.
izacus 29 days ago [-]
I had to remove marcan from my social media because he constantly generates this kind if drama. :/
zamalek 30 days ago [-]
You know, Redox (as the "most serious" Rust kernel I can think of) could probably do with non-trivial drivers. It would be unfortunate for aspiring or even seasoned kernel developers to step away from the practice entirely, simply because R4L fails to launch.
jabwd 30 days ago [-]
Part of me feels like something like Redox isn't exactly worthit. Now I hope the project succeeds in whatever goals they have, and honestly where they've gotten to is impressive; what I mean to say is that I think it would be far more interesting to imagine beyond just Unix and especially the problems of POSIX. I think the "next" thing, if that even ever materializes needs to be that, something reimagined. Computers aren't emulated PDP-11's anymore.
vander_elst 29 days ago [-]
It seems fuchsia might me something for you
docandrew 30 days ago [-]
I don’t see why forking is not an option here.
If the upstream maintainers don’t want to adopt it, the Rust folks can gradually rewrite the bits they want to and let the market decide. Use the Ballmer “embrace, extend, extinguish” model.
mu53 30 days ago [-]
Linux is not a side project. It has thousands of developers being paid by chip and hardware manufacturers to ensure that linux works on their products.
With the complexity of systems engineering, for a single driver, it takes months to build one from scratch. Plus, there is not enough expertise within the rust community to take on a project like the linux kernel to match the rate of development by many large corporations with hobbyists.
docandrew 30 days ago [-]
It started as a side project.
They may not match the rate of upstream development, but doing their own thing is going to be a faster path to their goal of Rust in the kernel than trying to convince everyone else to do something that they don’t seem to want.
grandempire 29 days ago [-]
The goal is to make rust relevant to Linux raising its own importance and legitimacy. The value is at least in part political. It can't achieve that goal in a branch.
29 days ago [-]
WesolyKubeczek 29 days ago [-]
Because forking requires a lot of hard work and time to even get acknowledged, while bringing Rust into the kernel, given enough PR, establishes a whole new hierarchy in which not only do they get to be at the top of right away, but they also get to depose the old guard!
anonnon 29 days ago [-]
Can someone steelman Linus's:
> ABSOLUTELY NO C++ in the kernel EVER. But Rust is totally fine.
stance? It seems pretty absurd when you consider the closer similarity between C and C++ (and the more straight-forward migration path from C to C++), and the fact that GCC supports C++ (even recent vintages) natively on many more architectures.
fooker 29 days ago [-]
The rust folks should make a Linux compatible kernel and distros that include a stripped down Linux kernel as a compatibility layer for legacy software.
There was actually a proposal to do what he's suggesting in redox at some point, some sort of emulator layer to run linux to take advantage of linux drivers. I haven't followed up to see what's happening with it.
It is a quandry, the kernel is predominantly C, Rust has demonstrated a path forward, producing safer code without sacrificing performance, but it is undeniable that a mixed code base is far harder to maintain, not impossible.
Here's the thing, in the next couple of years languages like Carbon, Zig, even Jai, will come of age. They will have their proponents and people who want to introduce them into kernel code.
If there is a rust developer out there who doesn't resist the introduction of these languages as ardently as the chosen people (C) are resisting rust, then I will show you someone who lives in some kind of alternate reality.
Personally, I'd be pressuring the C committee to introduce defer, tout suite, otherwise Zig looks favourite. But the reality is that your preferred language is just that, your preferred language, most have seen this drama before and will choose not to participate.
As to whether Linus is failing in his leadership role? Nah, Then again, I wish Sony would open source the PS OS and we can be done with this juvenile debate as to which OS should rule the world. Either that or let's have an exokernal and move on from this monololithic story, surely that would meet the needs of the MY FAVOURITE LANGUAGE isn't appreciated crowd!!
steveklabnik 28 days ago [-]
Hi! I’m a Rust developer. The kernel should include whatever languages they want to include. I’m in the same reality as you.
rednafi 29 days ago [-]
There will be a similar drama when Zig reaches 1.0. There will be a bunch of Ziggers trying to get it into the kernal. The Rust fad is already slowing down. Maybe it's a good idea to wait 10-15 years before trying to rewrite the universe in a "memory safe" language and pushing that upstream.
dcsommer 29 days ago [-]
Zig brings developer velocity benefits over C, but developer velocity is not the reason R4L exists. Until Zig has an easily segmented part that is memory safe, there is no demand for its potential benefits in Linux. Memory safety is the only reason a new language was considered within Linux.
robmccoll 29 days ago [-]
Zig is at least better impedance matched to C. Procedural and relatively small conceptually. Simple interop. Rust feels closer to C++ than C.
rednafi 29 days ago [-]
Zig fixes many of my woes with C. Compilation time is better than Rust’s, and there’s no borrow checker. I also find the Zig community more pleasant than Rust’s.
The Rust ecosystem never clicked for me the way Go or Zig did. But I work with I/O-heavy distributed systems, where Go outshines Rust in most cases, so that’s what I use the most.
Systems programming is a different beast, though, and I’m glad the push for rewriting everything in Rust has lost its initial momentum while Zig is emerging as a strong contender. Even then, I wouldn’t want Ziggers to start pushing things upstream into the kernel anytime soon.
jakeogh 29 days ago [-]
Maybe, I think it's more likely that a Zig soft fork would first replace the kernel build system and then, with unit tests, piece by piece port the whole beautiful thing. Zig is on a strong path to compile and interact with C better than existing C compilers.
rednafi 29 days ago [-]
I like Zig a lot over Rust but I guess people should give it a while (10y) before attempting something like that. Zig isn’t even 1.0 yet and it’s not going to be for at least 2 more years.
elcritch 29 days ago [-]
In 10 years C compiler may include the benefits of a borrow checker but in a more flexible manner.
rednafi 29 days ago [-]
Or C can get cleaned up and become something like Zig. I would rather read messy C or Zig code over Rust in any day.
dark-star 29 days ago [-]
I understand the frustration, but I don't understand the drama.
There are other big Linux forks that met a similar resistance, best example is probably Realtime Linux / RTLinux that was not welcome in the Kernel for what, 15 years? Yet they still continued in their own fork and now most of their patches have finally gone in.
The way they're going to work now should have been the default. Just as RTLinux was a big change to the Linux kernel, Rust will be a big change. You cannot expect the Kernel community to welcome such a huge change with open arms and deal with all the fallout (build system, interfaces, etc.)
Just be ready for your project to take a decade, instead of trying to force it in "now or never". Until then, maintain some out-of-tree modules written in rust that every Linux distro/user can try and test without much fuss. For example, I don't think it will be a huge problem if Mac users have to get their DRM driver at some other repo (or if distributions would have to package some `linux-module-drm-apple` package separately from the Kernel)
Tomte 29 days ago [-]
> and now most of their patches have finally gone in.
Is there anything outstanding? I thought they recently reached the point where everything from -RT is in mainline.
dark-star 29 days ago [-]
yeah, probably. Sorry, I admit I haven't been following them too closely.
dingi 30 days ago [-]
Rust or not, mixing two different languages within a single project is a sure fire way for a maintenance nightmare. Specially for a large project like Linux. I sincerely don’t want something like that happening to the Linux kernel. Just let it die with C. However it may seem improbable, writing a kernel from scratch is the way to go for new wanna be system programming languages.
uecker 29 days ago [-]
Indeed. I grew up with open-source. I still like C very much. I do not think Linux would die. But I may be wrong and Rust is the future. In the past, people just created their own projects. If they were truly better, eventually the were adopted more and more, but who did not like it, could also just stay with the older projects as long as they were recently maintained.
airhangerf15 30 days ago [-]
and they have one: Redox
pjmlp 30 days ago [-]
Likewise most Rust efforts going on from Microsoft and Google are on downstream, Android, Sphere OS,...
This was to be expected, many of their anti-C++ complaints also apply to Rust, given that both languages share many common ideas, even if presented in different forms.
littlestymaar 30 days ago [-]
> This was to be expected, many of their anti-C++ complaints also apply to Rust, given that both languages share many common ideas, even if presented in different forms.
I was genuinely surprised when Linus opened the door for Rust in the Kernel for that reason. And the real waste is there: had Linux said a straight “no”, then nobody would have lost their time trying to make this work against all odds.
Or maybe Linus really thinks Rust is the future, but he doesn't want to enforce its inclusion in the Kernel against his senior maintainers because he's afraid of an uprising.
pornel 29 days ago [-]
Linus said he's worried that he and core kernel maintainers are getting old, and there may not be enough younger contributors to replace them. There's an implication there that Rust will continue to grow and attract more talent, and it'll get harder and harder to find devs passionate about old C codebases.
metaltyphoon 29 days ago [-]
It’s absolutely a wild to me how this is not talked about more. All it takes is for a set of highly praised institutions to use Rust for their major courses and now you will have generations which C is just something you know about.
diath 29 days ago [-]
[flagged]
sc68cal 29 days ago [-]
It's cowardly and easy for me to say now after the fact, but I saw the original Mastodon post because I follow Hector Martin. I didn't think that it was going to make the situation any better but I didn't have the energy to even fire off a one-off comment saying so.
I absolutely get emotional about my work. I have absolutely sabotaged myself by not having the presence of mind to step back and take a deep breath. I had a moment of clarity reading Hector's post on Mastodon, and I'm sad that my suspicion that this was going to just make things worse was correct
shadowgovt 29 days ago [-]
I think it looks like both sides are making some pretty valid points here.
Those who are nervous about embracing Rust further are just fine. Rust is still a young language. It shows an awful lot of promise, but it isn't a magic cure for safety and security concerns, especially at the kernel level. It is entirely possible that Linux is a bad fit for the language, and the real way to get ta Rust kernel is for a team to come together and implement a kernel in Rust, from scratch, perhaps with POSIX compatibility.
On the flip side, Hector is entirely correct that the overall process of maintaining and improving Linux is incredibly baroque and grounded squarely in some tooling that just stinks in the modern ecosystem. It has worked for Linux for ages. It is also increasingly making working on Linux a specialized project space because nobody else manages projects like this. Hector is fine leaving if he finds that process two owners to be worth his volunteered time. And it is entirely possible that there will come a day when the value of the project itself is outweighed by the cost of interacting with the project and Linux will get supplanted in the common ecosystem by something else.
In short, Hector is probably making the right move here. If he wants to continue working on a problem like this, a new operating system might actually be the right solution.
vednig 29 days ago [-]
Linux is one of the most complicated OS in the history of OS and both of them understand this in someway or the other, it's still not cracked enough market share to dominate the personal computer market even in 2025, but is already on millions of other devices except PCs and a small change in decision like r4l brings the whole perspective into matter, after the fact that rust is highly compute intensive language and low end processors might not be able to catchup the speed in the best possible way these industries work, memory is cheap to include and hence the decision to include Python was a comparatively easy one, but rust is a highly balanced choice currently which makes the decision more difficult for Linux to include R4L in kernel, hence the dissolution on parts in which to include.
This is based on my limited experience with rust, but I believe we really need to give rust more time to mature it enough to see where we're going with the builds to actually decide on this matter, even personally. Plus, Linux has been keeping the Linux Kernel project alive for so long that he probably already has got the experience of knowing the repercussions of a wrong decision. Being hasty in this scenario doesn't solve the problem
ranguna 29 days ago [-]
> the fact that rust is highly compute intensive language
care to elaborate on that?
vednig 29 days ago [-]
rust utilizes various methods at compile time which significantly increases compute, such as compiler is optimised for memory safety, which causes it do a lot of tasks and changes at compile time unlike C and inturn during execution to ensure ms, which could easily be avoided, it is good for overflow situations but in terms of compute required in exchange for the program is simply(currently) not at the level that would be great to have in Linux kernel, in a few years maybe
ranguna 27 days ago [-]
So when you say its compute intensive, you only mean at compile time, is that correct?
vednig 18 days ago [-]
correct
danpalmer 29 days ago [-]
Arguably the billions of Android phones/tablets running the Linux kernel are the personal computer market.
vednig 29 days ago [-]
Exactly my point in terms of the chipsets, and the limited acceleration in capacity of evolution per year for small chip manufacturing companies unlike mediatek and qualcomm, furthered by silicon shortage and many other manufacturing facts, including a language like Rust at this stage should be subject to observation.
markus_zhang 30 days ago [-]
I have a question. Instead of fighting an uphill war in the Linux kernel community, why don't Rush developers just make a new kernel or fork their own? Sure it's going to take years, but at least they don't have to suffer the mental outrages from time to time and can do whatever they want? I mean I'd do it if that's what I want.
P.S I don't have skin and skill for the kernel game. I'm just a curious bystander.
gpm 30 days ago [-]
Linux is a cooperation between numerous companies to develop a shared artifact that works with all of their hardware, solves all of their use cases, etc. No one company involved can just go make their own replacement, because they need the cooperation of the other companies involved to get it to work on the hardware manufactured by the other companies.
Even ignoring the driver problem, it's not really an economically viable amount of work. Right now everyone benefits from everyone else's bug fixes, from everyone else's security improvements (like introducing rust!), etc. Going it on your own means you have to redo everything everyone else has done (unless you just fork linux), and that you don't get the benefit of everyone else working on the shared codebase (I suppose unless you fork linux and keep merging in upstream... which is actually what projects like Android do).
A complete rewrite also means a huge time lag before you start seeing payback in terms of faster development speed and a more reliable/secure operating system. Unlike introducing rust in new work to the existing kernel which sees relatively immediate payback.
I suppose I wouldn't be too surprised to see a project like Android just maintaining a whole series of rust changes in their own branch if the RFL project continues to be impeded by the maintainers. That's what Asahi linux (Linux on apple computers) is already doing (and poking at the android-mainline branch it looks like there are some rust additions that aren't in Linus's tree... but I'm not sure what the extent is).
Also note that many of Rust 4 Linux contributors are Microsoft and Google employees that would like to upstream their changes, they already have plenty Rust on their own Linux derived systems.
plagiarist 30 days ago [-]
Redox looks great. Device drivers should be in userspace, though I think that's far easier said than done with everything being on shared busses. A kernel cannot (safely) just simply check permissions for accessing a device and route the messages.
snvzz 30 days ago [-]
IOMMUs do help.
markus_zhang 30 days ago [-]
That's good to hear. Thanks.
lelanthran 30 days ago [-]
> I have a question. Instead of fighting an uphill war in the Linux kernel community, why don't Rush developers just make a new kernel or fork their own?
Because their primary goal is to widen the community and reach of Rust, with "preventing memory error class bugs in the kernel" a secondary objective.
After all, the Rust additions, if properly designed, can be maintained in an out-of-tree fork that tracks the main Linux repo. If they did that, there'd be no one to block their patches but themselves, and yet they don't do that.
Rust is more about community than Linux is. Within the Rust community they make it very clear that it is vital that everyone goes the same way, while the Linux community has had, for decades, people each doing what they or their employer are interested in.
These two communities are not going to mix well, TBH. A community in which every member is a vocal prosyletiser isn't going to mix well with a community which prides itself on "Show Me The Code".
enragedcacti 30 days ago [-]
> After all, the Rust additions, if properly designed, can be maintained in an out-of-tree fork that tracks the main Linux repo. If they did that, there'd be no one to block their patches but themselves, and yet they don't do that.
Mainlining whenever possible is highly incentivized by technical and organizational aspects of linux[1], nothing about rust changes that. Obviously R4L introduces complexity and tradeoffs but I don't see why a rust kernel dev whose only goal was preventing bugs would do anything differently in this regard. Linux is a consensus project and opting out of the process of building consensus would mean not actually preventing any bugs.
No idea what the particular bit of drama discussed here is about, but that's my impression of the Rust "community".
baq 29 days ago [-]
any community can be called that if you squint hard enough and especially if you ignore the silent, get-the-job-done-and-go-home members of it and only listen to evangelists.
nottorp 29 days ago [-]
Not all communities have evangelists tho.
And if they need evangelists, it's a safe assumption for me that they don't have other merits.
panstromek 30 days ago [-]
That sounds like a pretty dishonest interpretation of that effort.
hdbsbdb 28 days ago [-]
I don't quite get the fuzz. A subsystem's maintainer's job is to maintain. If he cannot guarantee the maintenance of something, it's his/her job to say no
You are free to either take over maintenance of the Subsystem or do a fork
But throwing a tamper tantrum on social media is definitely the wrong way forward
(This is a shared link to a subscriber-only LWN article, please consider a paid subscription to LWN if you liked it!)
hitekker 29 days ago [-]
This isn’t impartial. Jonathan Corbet is naming and shaming, on behalf of one side.
> But Christoph Hellwig … turned this submission away with a message reading, in its entirety: "No rust code in kernel/dma, please" (despite the fact that the patch did not put any code in that directory)
> Already overworked kernel maintainers will have to find time to learn Rust well enough to manage it within their subsystems.
Frankly, this article feels like it’s steps away from social media brigading.
otterley 29 days ago [-]
Journalists having an opinion in a news article, or even printing an opinion in an op-ed page, is not the same as—or even close to—social media brigading. It’s also a practice as old as the press itself. Brigading is about harassment and intimidation, not about possessing or publishing an opinion.
ninkendo 29 days ago [-]
I came away with the opposite interpretation of yours.
The first quote of yours edited out the part where it says he does a lot of work in the DMA subsystem. It’s saying “someone who does a lot of work in the kernel turned the patch away”, which is absolutely true.
The second quote is understanding of the maintainers’ side, saying that they’re already overworked and now they’ll have to find time to learn rust on top of that. Not so much “I think these people ought to learn Rust”, but “accepting these patches means they will now have to learn rust”. This seems true to me? If anything it’s overly partial to the maintainer’s side, admitting that rust patches put more work on the old guard maintainers who are already overworked. It’s interesting that you feel this is too partial to the Rust side.
anonfordays 29 days ago [-]
Zig will likely go through the same trials and tribulations that Rust has for introduction into the Linux kernel. Considering Zig's better C interopt, the fact that the Zig compiler can natively compile C, the Zig community's lack of zealotry and proselytizing that plagues the Rust community, etc., I believe it will be better received.
ge96 30 days ago [-]
Damn, I liked watching the YT streams, above my head but yeah
Edit: I'm not super invested in the topic at hand I use all 3 OS's and only use Mac to develop with/for using MacOS
But kernel-level dev is hardcore and especially for open source, I've experienced that with the Pine64 devices which are almost worthless without the devs contributing to its software
shae 29 days ago [-]
I tried helping with the Linux kernel once, in 2001.
I haven't since.
I don't need abrasive people in my life.
OtomotO 29 days ago [-]
It's fine to say no to a particular patch on technical grounds.
It's fine to say no to any other language but C in the Linux Kernel on a global basis.
What's not fine is caprice and depotism.
Either Rust is allowed, or it is not.
Stop wasting time.
And stop C-zealotry, it's as embarrassing as Rust zealotry, if not more so.
mhh__ 30 days ago [-]
An interesting question: Who is the Linus Torvalds for Rust in the kernel? Who says no to slop?
sushidev 29 days ago [-]
Such a huge discussion and I can’t really understand the problem from reading the comments or some of the excerpts linked. Can anyone explain to me what is the real issue here?
weberer 29 days ago [-]
Developer A wants to make a change. Developer B rejects it. Developer A makes a big fuss about it on social media. The creator of the project steps in and chastises Developer A for his behavior.
And as additional context, developer A has a history of causing drama on social media. So much that he even has his own page on KiwiFarms.
baq 29 days ago [-]
Also, developer B publicly stated that he will do everything he can to prevent changes written in language 2 from getting merged regardless of technical merit.
aprilnya 28 days ago [-]
Incredibly biased summary there
sushidev 28 days ago [-]
Please give me an unbiased summary of the facts
sussmannbaka 29 days ago [-]
silly hector, everyone knows that bullying, screaming at people in public and insulting them online is a privilege of long-term maintainers who can do no wrong
ThinkBeat 29 days ago [-]
Linus has to have one of the most stressful and difficult jobs available.¹
The Linux kernel is part of so many different things, projects, products, companies, etc. A change can really duck things up.
Being conservative, and slow, in adopting new things is good for the main line.
You have idealistic developers who have seen a way to do something better,
that is great. I know the feeling.
I have never done anything with the Linux kernel, but I have worked on some
large legacy codebases. and it is to come in, look around, and just go
"Gosh, this here is just slow, I'll just fix this".
and it will be a good solution right there, but it might be suboptimal overall.
Chances are really good that you dont understand the entire picture when you
"fix something", and someone who does, may not like the change.
and even if the technical solution is clearly better from one angle.
I am glad I will never be involved in blessing or passing on 1.000.000 different
changes being proposed as improvements to Linux every week.
kunley 29 days ago [-]
I wish Linus Torvalds to have long life and powers to keep his down-to-earth approach as long as it is possible. I wish his era was never replaced.
29 days ago [-]
cosmic_cheese 30 days ago [-]
I haven’t read the entire thread but based on the except I did, while I won’t claim that Hector isn’t entirely in the right there’s also major longstanding issues with the process that the kernel devs seem to refuse to do anything about.
It seems like big enough of a sticking point that if a forked alternative with a less insular contribution model appeared, it could gain enough steam to keep itself afloat. All it’d take is for someone with deep enough pockets to fund a few founding engineers to be the subject of this kind of frustration.
nailer 29 days ago [-]
I hope they fork Linux. A safer kernel and modern faster development practices would be excellent for the entire ecosystem
uecker 29 days ago [-]
Absolutely! If Rust and the modern development practices are truly so much better (I doubt this, but I am old and could be wrong), then why not show this by creating better kernels and other projects!
nailer 28 days ago [-]
Exactly. And I feel the same as you do: the Rust community can put it’s money where it’s mouth is and if nobody wants safe Linux or they can’t make it happen, then fine they can be happy to lose.
markhahn 29 days ago [-]
Not an especially significant event, by the numbers. It's a large community so there are tails.
29 days ago [-]
mperham 30 days ago [-]
By the time Rust is welcome in the Linux kernel, projects like Redox will be full fledged competitors. I'd bet Hector would be welcomed there.
It's taken Wayland 16 years to become a serious alternative to X11. You think a whole kernel can do it faster?
Well, with AGI...
jodrellblank 28 days ago [-]
Can't be many years until we can take the first ever version of Linux kernel, ask an LLM to port it to Rust, spin it up in QEMU and re-prompt until it works, then feed in every patch set and ask the LLM to add these changes to the Rust version, ... repeat for 30 years of patches until the full kernel is rewritten in Rust.
fud101 29 days ago [-]
because that's what the world needs, an obscure half assed implementation of unix? why not innovate and come up with a new paradigm instead. No one is asking for this.
mperham 29 days ago [-]
It sounds like you don’t know anything about Redox.
fud101 28 days ago [-]
I don't care, any OS that claims inspiration from Plan9 is doomed from the start, it's Unix done right which is exactly the worst possible thing.
qbq 29 days ago [-]
Good reminder to take a look at FreeBSD
29 days ago [-]
30 days ago [-]
vednig 29 days ago [-]
in my mind Swift is a much better language to include than rust, unfortunately the support for Swift on Linux is so bad currently that it's not worth exploring.
If ever integrated Swift might change the whole paradigm
samcat116 30 days ago [-]
This really makes me want to learn rust and contribute to Redox.
aleph_minus_one 30 days ago [-]
Do it.
30 days ago [-]
rdtsc 29 days ago [-]
“How did you hurt yourself today?” - “I threatened Linux devs with social media shaming and publicly quit contributing to Linux to teach them a lesson. But it boomeranged, and now everyone is talking about my behavior”
DSingularity 29 days ago [-]
How dare he be tired of using emails for reviews. Or manual formatting his work.
Let him fork!
Jokes aside: I hope he forks and establishes a CoC and if what he does is more effective we will all benefit by it.
qbq 29 days ago [-]
Good reminder to look at FreeBSD
leoh 28 days ago [-]
Not wanting 2 languages is ridiculous. Only one of them is actually safe. Whatever Linus thinks, empowering someone to say “no” to “two languages” is pretty idiotic; if someone did that to me, I wouldn’t go to social media to bitch about it, but I can sure as heck sympathize with the sentiment.
Whoever owns DMA or whatever and rejected rust out of hand like this should frankly be _forced_ to resign. This is truly arrogant and egotistical behavior, almost certainly contingent upon FUD and insecurity and laziness about not just learning Rust.
Good grief, last time I feel excited about submitting a kernel patch; what a ridiculous situation.
999900000999 30 days ago [-]
Have to side with the one language argument here.
It's hard enough to get a single programming language to work right. C is old and stable.
Rust is new and mostly stable, mostly stable isn't going to cut it when billions upon billions of devices depend on your work.
At the same time this type of ego driven drama keeps me out of the open source community. I have enough people telling me how to code during my 9-5.
I open source most of my projects, but it's not a collaboration. I'll even admit, I get really annoyed when someone puts in a PR that's literally just a bunch of spacing changes in a readme. I think there was some influencer who was claiming that you should go through GitHub, and submit as many changes for things like grammar as possible to a bunch of different projects .
And then on your resume you can put that you contribute it to all these projects. Not fun.
parl_match 30 days ago [-]
I don't agree with this anymore tbh. But for a project as large, mature, and widely worked on as the Linux Kernel, I absolutely agree.
I think it's a noble goal worth working towards, but Marcan's smug as hell "ill merge and y'all will fix all your broken shit" attitude predictably backfired
xeonmc 30 days ago [-]
Consider using Codeberg for personal projects and reserve GitHub to just collaborative contributions. Codeberg lets you disable pull requests and other unwanted features that GitHub forces down your throat.
remram 30 days ago [-]
Everybody hates spam and abuse, I don't think it supports your claim that much. This is definitely not what anybody thinks of as "collaboration".
999900000999 30 days ago [-]
In any big project your going to have disagreements.
I need to get paid to deal with stuff like that. No one is going to tell me how to write code without writing me a check.
Even at work I have my limits, although now that I'm older I'm much more inclined to just go with the flow. But if I'm not getting paid what's the point.
I do enjoy game jams though. We only need to work together for a weekend. Plus at least in my circle we only care if the code works.
SaggyDoomSr 30 days ago [-]
fwiw, i always make my first PR to an open source as simple / uncomplicated as possible. Something like a spelling or grammar fix in documentation. It's a litmus test for how much drama I will need to face on the more complicated code issues to follow. When the project owners ignore or reject simple stuff, I generally wander off somewhere else.
christophilus 30 days ago [-]
Not to mention Rust tooling is painfully slow compared to C, last I checked. I wouldn’t want to switch unless that problem went away somehow.
30 days ago [-]
denysvitali 29 days ago [-]
[dead]
29 days ago [-]
mystified5016 30 days ago [-]
[dead]
rembrand69 29 days ago [-]
[dead]
30 days ago [-]
30 days ago [-]
amiga386 30 days ago [-]
[flagged]
jisnsm 29 days ago [-]
[flagged]
42lux 29 days ago [-]
[flagged]
kazinator 29 days ago [-]
[flagged]
rednafi 30 days ago [-]
[flagged]
blueflow 30 days ago [-]
[flagged]
superkuh 30 days ago [-]
[flagged]
im3w1l 30 days ago [-]
So I heard some rumors about US policy affecting Rust. That Rust formely got money from USAID, and also the thing about the US government should promote memory safety (or smth like that?) was removed.
Could that be relevant to this story, or is that a complete sidetrack?
Edit: Asking because the timing is curious.
gpm 29 days ago [-]
This has absolutely nothing to do with the US government. This current drama started before January 20th.
Rust has never as far as I'm aware or can tell via google recieved money from USAID. Though amusingly there has been money invested by USAID to combat it's namesake - a category of fungus - from destroying coffee plants.
What you're probably thinking of with regards to the US government is that the Trump administration has been deleting all sorts of websites and guidance, and one of the things deleted was a report by the White House Office of the National Cyber Director calling on developers to use memory safe languages [0]. Various other similar documents (e.g. randomly picked via google [1]) still exist and it's unlikely that this document was deleted because of its contents and not because the white house was just destroying the entire category of things related to the ONCD - even the landing page 404s [2].
That report was just a "this is a good idea", I don't believe it ever came with any funding or support.
It wouldn't surprise me if other similar things were deleted too, that's just the one I saw hit the news, so I'm guessing that's the news you saw.
Frankly I immediately knew incidents like these would increase when it was added.
Not possible to have rust without the "" community"", it seems.
codr7 29 days ago [-]
Obvious from the start for anyone paying attention, take a look at the founder.
tw1984 29 days ago [-]
[flagged]
eqvinox 29 days ago [-]
You're missing context. Linux Rust devs themselves were unhappy with Hector's flaming "on their behalf".
tw1984 29 days ago [-]
again, as a user, I don't care. I use linux & visiting HN because of tech, not because of any politics.
Martin's patch should not be delayed or rejected because of the rust language, it is an approved language. If some maintainer has issue with such rust language approval, they should address that particular issue not patches using that language. They can also choose to resign.
eqvinox 29 days ago [-]
One problem: it wasn't even his patch. He just jumped in on the discussion. And other Rust devs are calling him out for derailing the thread.
Edit: eh, hadn't seen that your root comment is now flagged. Don't even remember what you had written initially, but it did feel rather uninformed. You should probably check a bit more that you have enough information before forming an opinion?
30 days ago [-]
sim7c00 29 days ago [-]
always knew rust was good for nothing... now look what it did. the language itswlf is in conflict with itself and anything it touches in a serious way reflect that silly state
aero-glide2 29 days ago [-]
I agree with Hector Martin here. The mailing list format is putting off so many developers. Linux needs to modernize.
meindnoch 29 days ago [-]
Rust has probably the most toxic people in open source software.
leonewton253 29 days ago [-]
I would encourage it in the Kernel. Maybe even go as far as porting large portions to Rust.
feverzsj 30 days ago [-]
Linus should have already accepted the C++ patch instead of these Rust dramas.
pjmlp 30 days ago [-]
We have plenty of drama on C++ community as well, rest assured.
yarosh 30 days ago [-]
1. I do believe that Rust type system needs to be reworked, so all the drama around it is needlessly bloated. We have RustBelt, RustHornBelt and myriads ways of converting HIR/THIR/MIR to CoQ, for better or worse, but no MLIR support for rust codegen whatsoever. Rust is temporary, we'll get a simpler and better Lang further down the road.
2. The upstream fight had always followed the Cash Flow. If you have so called "problems" you either act yourself, or let other people do something about it, the way it won't result in more long-term issues. Deliberate Detraction IS a Sign of Corruption and Abuse of Power.
3. An ambiguous Point of Conflict may not be Conflict at all, but just an outcome of the Lack of Proper Communication and Transparency. Detraction is Accountable, social dynamics and social incline with explicit or implicit motives is Accountable as well. The lack of Effective Code of Conduct, and absence of Proper Punitive Action, for everyone, will cause Authoritarianism (or just Genocide of Engineering Thought).
I do feel bad about the state of Linux Kernel development, but we'll have either to move on, and learn from This Mistake, or do something about it.
williamDafoe 29 days ago [-]
I get this impression that the Rust people think they are a stage where Rust is a viral phenom but it's really not. Nevertheless, they are behaving like its viral and trying to force it down everybody's throats, even though I never heard of some software package or system that was built natively in rust that truly went viral. The other day I tried to install a python package and - big surprise - it REQUIRED me to install a rust toolchain to install the python package! Well, that package went straight into the dumpster (i'm on WSL which DOES NOT have a rust toolchain)!
This "we're viral" behavior when "it's really not" is very childish.
orf 29 days ago [-]
Was this comment written by an 80 year old who’s watched a Fox News segment on Rust? It definitely reads like that.
wsl ‘DOES’ have a rust toolchain, nobody is saying rust is going viral (what on earth…), you tried to install the python packages’ sdist rather than the wheel.
Get it together.
Yeask 29 days ago [-]
Not wanting a huge dependency tree is something understandable by any seasoned developer.
Was your comment wrote by a junior javascript developer?
MathMonkeyMan 29 days ago [-]
Get a room you two
redundantly 29 days ago [-]
Where are you seeing these "we're viral" statements?
Permik 29 days ago [-]
If you're using WSL, then you can just run the linux rustup installer to have a linux version of the toolchain installed.
steveklabnik 29 days ago [-]
> (i'm on WSL which DOES NOT have a rust toolchain)!
This is plainly false.
johnea 30 days ago [-]
People do love their drama don't they 8-)
Regarding the point of "community" being difficult to manage in "open source" projects, I would argue managing a large group of developers on any project is difficult and full of drama.
I'm personally not an advocate of the "open source" obfuscation term myself, but the public license of the linux kernel has little to do with the drama.
Maybe the fact that linux developers have some kind of say at all, as opposed to some proprietary dev projects where every decision is handled by fiat (and Linus has certainly served this role at times), causes it to have more drama.
But no matter what model is followed, people do love their drama, and a large dev group is a social activity regardless of the licensing of the software itself.
Its like every social issue ever: the thing all participants have in common is that they are all humans...
Rendered at 11:42:52 GMT+0000 (Coordinated Universal Time) with Vercel.
Spending significant time adapting core kernel code or developing a safe Rust abstraction for DMA, only to be summarily shut down by a single gatekeeper who cites "not wanting multiple languages" is demotivating. It's especially incongruent given that others have championed Rust in the kernel, and Linux has begun hosting Rust modules.
If the project leadership — i.e. Linus — truly wants Rust integrated, that stance needs to be firmly established as policy rather than left up to maintainers who can veto work they personally dislike. Otherwise, contributors end up in a limbo where they invest weeks or months, navigate the intricacies of the kernel's development model, and then find out a single personality is enough to block them. Even if that personality has valid technical reasons, the lack of a centralized, consistent direction on Rust's role causes friction.
Hector's decision to leave is understandable: either you have an official green light to push Rust forward or you don't. Half measures invite exactly this kind of conflict. And expecting one massive rewrite or an all‐encompassing patch is unrealistic. Integration into something as large and historically C‐centric as Linux must be iterative and carefully built out. If one top‐level developer says "no Rust", while others push "Rust for safety", that is a sign that the project's governance lacks clarity on this point.
Hector's departure highlights how messy these half signals can get, and if I were him, I'd also want to see an unambiguous stance on Rust — otherwise, it's not worth investing the time just to beg that your code, no matter how well engineered, might be turned down by personal preference.
But since then a lot of experience was made and I got the notion that the Rust drivers were quite a success.
And now we are at a point where proceeding further does need a decision by Linus, especially as one of the kernel maintainers is actively blocking further work.
Christoph Hellwig is one of the oldest subsystem maintainer.
Maybe the Rust developer shall have a more careful behaviour. Nobody wants to break core kernel code.
Also it's not his domain, from Marcan's Reddit response Greg is one in charge of maintaining this area.
So this is drive by reviewing.
Automated verification (including as done by rust in it's compiler) does not involve anything popularly known as AI, and automated verification as it exists today is more complete for rust than for any other system (because no other widely used language today places the information needed for verification into the language itself, which results rust code being widely analyzable for safety).
Human validation is insufficient and error prone, which is why automated verification of code is something developers have been seeking and working on for a long time (before rust, even).
Having "explicit" (manual?) memory management is not a benefit to enabling verification either by humans or by machines. Neither is using a low level language which does not specify enough detail in the type system to perform verification.
Kernel modules aren't that special. One can put a _lot_ of code in them, that can do effectively anything (other than early boot bits, because they aren't loaded yet). Kernel modules exist for distribution reasons, and do not define any strict boundary.
If we're talking about out-of-tree kernel modules, those are not something the tend to exist for a long time. The only real examples today of long lived out-of-tree modules are zfs (filesystem) and nvidia (gpu driver). These only exist out-of-tree because of licensing and secrecy. This is because getting code in-tree generally helps keep code up to date with less effort from everyone involved: the people already making in-tree changes can see how certain APIs are being used and if those in-tree folks are more familiar with the API they can/may improve the now-merged code. And the formerly out-of-tree folks don't have to run their own release process, don't have to deal with constant compatibility issues as kernel APIs change, etc.
Basically, if you assume thats impossible for humans to be correct, or that its impossible to write correct memory safe C code, you start down the path that leads to things like Java, Haskell, and now Rust. And then when nobody takes you seriously, you wonder why - well, its because you are telling people who know how to write correct and memory safe C code that we are insufficient and error prone
>Kernel modules aren't that special.
By definition, they interface with the core kernel code. They are not core kernel code
Even if that is the case Rust specifically is design not to be GC.
Ontop of that you csn do manual memory management if you want in Rust afaik.
Closest is most likely Ada.
Then one of two things will happen:
* Rust will prove its worth and their fork will be the better operating system. Distros will start switching to it one by one due to its increased performance and stability, and they will have dethroned Linus and become gods of the new world.
* The project will die because the C programmers will outcompete it with good ol' C, and all their talk about safety doesn't pan out in the real world.
If I were the rust4linux leadership, I'd roll those dice.
Sounds like Hector Martin is doing exactly that, burning the bridge along the way. Good luck! I think it's the right move (minus the bridge burning).
(Brackets added for clarity)
Isn't the current Linux already Linus + communities + companies?
More to the point, any two such projects would quickly diverge. Once a particular piece of Linux is reimplemented in Rust, if the C version adds a feature it is no longer as simple as applying a patch to keep in sync.
Absolutely. To that point the companies I listed are the ones that I'm aware of employing kernel developers who work specifically on rust in linux.
The control of the project is in Linus's/community hands though, not corporate ones, and I think that's a good thing.
> More to the point, any two such projects would quickly diverge. Once a particular piece of Linux is reimplemented in Rust, if the C version adds a feature it is no longer as simple as applying a patch to keep in sync.
I don't think so. Linux is a huge modular system, and no one is really interested in rewriting the core components of it at this point. Nor maintaining their own copies of components that some other company is responsible for (like graphics drivers). Until and unless it became the dominant fork I'd expect that they'd keep merging in the mainline branch and updating their things as necessary.
This is already how projects like Android work.
I don’t remember seeing this bullying accusation in your original comment. Was it edited in?
Regardless, the “bullying” happened on both sides. Hector Martin started the social media brigading and quit when he couldn’t get his personal enemy suspended for CoC violations. Jonathan Corbet wrote a letter naming and shaming maintainers, in the guise of a report.
All in all, I agree with the GP. Most of the arguments against (even temporary) forking feel like excuses for a lack of will and a maybe even a lack of ability. The space is open for a fork.
(I have edited this comment on the other hand, first to explicitly disagree with various statements in the above, then to delete those disagreements since I don't really want to get baited into an argument)
It seems like a huge technical factor holding back a stable ABI is the C compiler itself. Binaries changing between compiler versions and changing with different compiler flags.
So while your code can be written such that it appears to respect the interface of an external library, the underlying binary representation might not line up correctly.
If there is agreement that modularity is good for the kernel but technical limitations prevent that from being a reality - surely the solution is to improve C's interoperability first?
---
I'm not a kernel developer and am probably naive here, but on the surface it feels like offering a stable driver ABI is one possible solution to the rust-in-linux controversy that has lead to so many people exiting kernel development.
I'd imagine if projects like Asahi could simply offer out-of-tree drivers, they wouldn't need to maintain a kernel fork (at least not for drivers) or negotiate with core maintainers (which I understand is stressful).
Might also make it easier for vendors like Qualcomm/Samsung/Nvidia to distribute drivers out-of-tree, perhaps reducing the need for long running Linux forks and allowing devices to update to modern Linux kernels.
As a novice hacker, I'd imagine the ability to reuse proprietary driver blobs would allow distros to be created targeting hardware that was otherwise impossible to access as drivers were hidden behind custom kernel forks (e.g. install mainline Fedora on a Samsung phone, taking the GPU driver from the Samsung build of Android - or OpenWRT on an Android powered portable 5g modem).
Not really. Every OS has a stable C ABI, otherwise there would be no stable OS API functions and no application plugin APIs. The actual reason seems to be that they simply do not want to commit to a stable ABI/API so they are free to make breaking changes and remove outdated APIs. Fair enough, but don't blame it on the compiler!
Additionally, there is politics in play here. Not the politics that is normally discussed outside of HN, but the politics of having companies (at least) release the detailed specifications of their hardware. I cannot really state authoritatively what the Linux developers think on this side, but Linus brandishing his middle finger to Nvidia (https://youtu.be/MShbP3OpASA?si=GJ1_0B81b7bFY_iZ&t=2890) says a lot of things.
I think nvidia uses out-of-tree drivers that are dynamically loaded - does that mean that nvidia drivers are tied to specific kernel versions?
RE: nvidia - yes
Closed source modules like nvidia frequently have a kernel-independent proprietary piece and a kernel-specific (open source) ABI piece. Whenever you upgrade your kernel, DKMS will re-build the kernel-specific shim and re-link the proprietary blob. The result is a .ko tailor made for your running kernel, even though most of the code is in a kernel-independent blob.
[1] https://www.phoronix.com/news/NVIDIA-Exploring-Upstream-KMD
There is a reason why in-tree drivers are preferred, and that's because the Linux driver interface and API changes with kernel API changes. The API is considered unstable in the sense that is it not unchanging.
A driver written for one release of Linux may not work with the next release as the API changes.
Can they do that to openssl instead?
Thank you.
(Not in rust, but it's mostly assembly anyways so I'm not sure rust provides much. There is https://github.com/briansmith/ring in rust, not sure if it's sponsored by anyone)
Unfortunately, what Hector Martin was actually doing is producing rather spectacular flame on LKML and Mastodon. And he isn't representative of other Rust developers either, at least one has voiced their disagreement with him: https://lore.kernel.org/rust-for-linux/Z6OzgBYZNJPr_ZD1@phen...
I agree maintaining a fork would've been a more productive use of Hector's time, but that's not what has been happening and I see no reason to believe it is what will be happening from now on. From my own experience, personalities like Hector quit after not getting their way, rather than looking for other constructive options.
That is a perfect description on what has been happening over the years.
Has anyone done that?
Asterinas is such an experiment. Purely written in Rust and Linux ABI compatible.
It's not a fork of Linux but a ground up effort to write a kernel in Rust. Still they're trying to make it compatible with Linux/BSD
And, of course, drivers run in userspace and interact with the system through a clearly defined API.
Other systems like this include Robigalia, Lions OS and Genode.
They would likely quickly overtake Linux if they got 1% of the resources Linux receives.
Robigalia is also an effort, but one that hasn't been touched in nearly a decade.
But if they could demonstrate significant improvements in security and stability, then they would have something to say. Maybe the plan should be to rewrite a component that the mainline maintainers wouldn't agree to - something important with a significant affect on security and stability. Yes, it's a risk, but if their claims for Rust are true, then it shouldn't be a problem. If Rust doesn't offer a major improvement then it isn't worth the effort anyway. Put their money (or time) where their mouth is.
Rust may have to really prove itself with results. And why shouldn't it?
And for what it's worth, I expect Rust would offer significant improvements.
i think it's going to fail because of rust as a language, not because the ideas in rust are bad but because there's infinite complications
If you're going to rewrite significant parts of the kernel, you might as well do what I've been doing and try to write what amounts to a better Linux than Linux that tries to maintain compatibility, but moves beyond the rather limiting conventional Unix architecture. The conventional Unix architecture was fine on a something like a 70s/80s-era PDP-11/VAX, but in the modern world its limitations have been apparent for quite some time.
What I've been working on is an OS very similar to QNX Neutrino in terms of general architecture, but with a somewhat different IPC protocol layering that reduces the number of user-visible primitives and allows for more consistent management of security. Most of the functionality of the system will be implemented in user-level server processes that export their services through special filesystems, with the only special/irregular parts of the system being the microkernel, the process manager (which also contains the core VFS and memory filesystems since these will be tightly linked to the process model), and the base syscall library (vaguely akin to the vDSO under Linux). Literally everything else will just be a regular process. It's not a "Rust OS" as such, as there will still be some C (for instance, the microkernel, which was forked from an older version of seL4), although it will have a fair bit of Rust code.
IMO the issues with Linux are mostly due to a combination of poor/ad-hoc extensibility and the development model that's way too decentralized in some places but excessively centralized in others. The architecture I'm going with will allow for more experimentation, since adding functionality to it will typically just be a matter of adding a regular user program (or a plugin for a regular user program), and much of the system will be based around standardized filesystem-based RPC protocols (generic tooling for implementing RPC interfaces will of course be provided). Therefore it would be easier to maintain experimental functionality in a separate repository and merge it into the base system later on.
Currently it's still quite preliminary, and it only runs some hardcoded tests built into the process server, although despite that, some developers from a major company have taken interest in it recently because of the possibility of using it as a replacement for QNX both in embedded systems and development workstations. I'm working on the VFS layer and built-in special filesystems at the moment, and hopefully should be able to get user processes running pretty soon.
https://gitlab.com/uxrt/uxrt-toplevel
First, no, it’s not all unsafe, it’s not even 50% unsafe.
Second, even 50% unsafe is an upgrade from 100% unsafe.
The problem is that the R4L project is raising a lot of questions about how interfaces are handled by some Linux maintainers, and there’s definitely a difference in criteria when it comes to soundness bugs.
I fall on the side that just because nobody has stepped on it on years isn’t a good excuse to keep landmines in the code, but clearly a lot of people in the kernel think differently.
[1] https://lore.kernel.org/rust-for-linux/20250108122825.136021...
https://lore.kernel.org/rust-for-linux/208e1fc3-cfc3-4a26-98...
The “in hindsight” version of how this should have gone without ego:
* Patch adds Rust bindings to C API
* Maintainer has concerns about increased maintenance cost and clarifies policy about C changes and Rust abstraction if unsure.
* Since R4L is approved, the binding is allowed to exist in a form that doesn’t inhibit changes to C API. C API is allowed to break Rust (I assume, otherwise the entire effort is moot).
* Any concerns about tooling etc which DON’T exhibit this property (and can demonstrably show that merging this Rust code will make C code harder to change) are brought up.
* These are resolved as a tooling issue before the change is merged (I don’t think there are any in this case).
All the discussion about multi-language projects etc is for the project as a whole to decide, which happened when R4L was approved and the breakage policy was decided (might need to be properly formalised).
If the maintainer (or anyone) is unreasonable, then the only approach is to have someone with more authority weigh in and make the decision to bypass their objections or sustain them (which is sort of the direction this was going before the diatribes).
> If the maintainer (or anyone) is unreasonable, then the only approach is to have someone with more authority weigh in and make the decision to bypass their objections or sustain them (which is sort of the direction this was going before the diatribes).
While they were arguing, Linus said nothing. While the maintainer was issuing ultimatums, Linus said nothing. Linus only said something when social media forced his hand. This is the real issue.
IMO, it seems inconsistent to green light R4L and not declare a clear policy for Rust code interacting with C code without adding a hard dependency (and if it WAS declared, not enforcing it).
The only benefit of doubt I can give is that there wasn’t enough time for Linus etc to weigh in before the thread got sidetracked (and the decision became much more politically charged). It’s unclear what would have happened if only the maintainer was unreasonable.
People are wrong in LKML often.
This time, somebody was wrong in a much worse way than usual.
On the other hand, I once ran into an issue with uboot where a bad update knocked out my emmc, usb and sata controllers... found an email address of someone developing the dtb files and got in touch with them, and it was fixed in under a week.
At the end of the day, people are weird sometimes. I wish all the best for marcan.
They did take months to finally land, and the whole process of getting my corp email address to be compatible with their email-based PR system was way more of a faff than it had any right to be, but they did land. You can install mainline Linux on a Legion Go now and the display and controller will behave as expected, out-of-the-box.
I think they expect people who want things to advocate harder than just mentioning it once. If no one brings it up again, then they assume that no one cares.
Should probably have just asked again, or sent a small one-line patch. It's "mention something on Slack" vs "creating a GitHub issue/PR"
Have there been any recent popular developments on a similar workflow that is as robust as e-mail ?
I'm not sure how long GitLab can be trusted either, as well as git becoming a bit too synonymous with GitHub...
What? PRs or issues being forgotten happens all the time, especially for large projects.
I cannot claim to have felt the effects on the maintainer-side of this workflow in large-scale projects though.
Suppose you find a bug in the kernel and come up with a patch. You email the patch to some kernel mailing list and ask for feedback. Typically, you will receive no response whatsoever, because no-one is responsible for responding. You can try emailing random developers and eventually maybe one of them will have mercy on you.
In Firefox and I think Chromium, you can file a bug, attach your patch, request review from someone (the UI will help you choose a suitable person), and it's their job to respond.
In Firefox you have to fiddle with Mercurial, phabricator, and their homegrown CI. In Chromium its Gerrit and their homegrown CI, and oh btw you touched code that lacked tests so tag, you're it.
Firefox and Chromium's bespoke tools have their pluses and minuses but they're a lot easier to deal with that the kernel "workflow".
I still remember the story where some other guys had to meet some Mozilla folks for lunch and nag them for reviews…
In Firefox, in my era at least, a reviewer who simply ignores a review request indefinitely was not doing their job and would get yelled at by someone --- me, if it came to my attention.
Harder to understand and contribute is a bad, but unless there is a proposal for a similarly flexible system that has minimal downsides and massive advantages, the preference of existing maintainers should dominate over potential future contributors. Especially factoring in how expensive of a migration it would be.
Linux is so ubiquitous & important that might never happen, maybe it will just become increasingly captured by corporate contributors who can at least build long lasting repos of knowledge and networks of apprenticeship to help onboard newbies. Open source in name only.
I won't contest that there are advantages to the linux Kernel's workflow, but there are downsides too, and a major one is that it scares off potential contributors.
That said GitHub definitely is far from perfect as well, and has different strengths and weaknesses from email based flows. As do any other options.
But just because there isn't currently anything that is unilaterally better doesn't mean things can't be improved. There is clearly a problem with onboarding new developers to the linux workflow. That should be acknowledged, and a solution sought. That solution doesn't have to be switching to GitHub or similar. Maybe there just needs to be better documentation on how to set up the necessary tools, that is oriented towards developers used to the Github process. Maybe there needs to be better tooling. Maybe the mailing lists need to be organized better, or have the mailing list automatically add metadata in a standard, machine-readable format to emails. Etc.
it sounds the opposite of optimized to me. Unless we're optimizing for something other than developer experience and efficiency?
Any change introduces anomalies and those cause all sorts of hell.
It's almost like there are more important goals wrt software development.
obligatory reminder about breaking someone's workflow https://xkcd.com/1172/
Then I talk to the old timers and they act like I just need to get used to it.
I'm grateful the kernel still supports MIPS, which means an old appliance of mine still works perfectly fine and is upgradable. I would be cery sad if someone were to rip-out support of an old MIPS arch, just because it's old and unwieldy
The first few times, it took me longer to figure out how to send a patch than it did to fix the bug I was writing a patch for.
That’s seriously lame.
And why not?
- Distributing patches via email is more scalable than web hosting. Even GitHub could not host the level of activity happening on the LKML mailing list
- Web hosting has a variety of access and legal problems when working with international teams; email crosses borders more easily
- Email is a decentralized and distributed system that prevents any single company from controlling a project's development infrastructure (release infrastructure is another story, but multiple companies will generally manage their own release process anyway)
Q: What would make you even more happy with Linux? GregKH: If you contribute to it.
Why the hell would I wish that upon myself?
My impression of a few glancing online interactions is that they're both abrasive but marcan is quite unwise in a way that Linus has had beaten out of him
And he's not just abrasive He's a troublemaker. Seriously, code of conduct violation? It was perfectly clear what Hellwig meant by "cancer".
There is an argument that being hyperbolic, dismissive, and maybe a bit rude isn't as bad as some people make it out to be, and that it is a fine way to hash out disagreements and arrive at the best solution - that it is simply a result of the passion of exceptional engineers. There has historically been much of it in kernel development. But it seems that as the background and culture of kernel maintainers has broadened, that a more measured and positive approach to communication is more constructive.
It doesn't seem like marcan exemplifies this very well either. It is a loss for someone so skilled to abandon collaboration on the kernel, and seems like the unfortunate result of someone being dismissive and rude, and someone else taking that harder than is warranted or healthy.
Stange, I think interpreting it your way requires bending the mind. Hellwig clearly used it to describe what he sees at the ill effects of multiple languages in the kernel. It was not used to describe either Rust the language or this specifically this particular submission.
It was used to describe the Rust for Linux project, as well as any other potential efforts to bring other languages into the kernel, of which there are none. It is clear why someone working on the Rust for Linux project would feel that "this cancer" refers to the project that they are working on.
I'm not trying to pull out pitchforks, I don't want anyone to burn. I just want people to collaborate effectively and be happy, and I think it is empirically clear that calling something that grows/spreads and that you think is bad "cancer" is not useful, and only inflames things. It is not an illuminating metaphor.
Instead of providing helpful advice like outlining the current situation and suggesting specific improvements (action A, task B, and goal C) to reach the goal, it feels rude and offensive.
The only helpful advice, which they did give, is don't even start doing this because it's fundamentally wrong.
The linux kernel is like a house where everyone is a vegan. Marcan believes that incorporating some meat in the diet is important, and better that being a vegan. He may even be right. But so what? He makes his pitch, the family says that's nice but no thanks. He then demands that they eat this chicken because he wants to live in the house and wants to eat chicken while living in the vegan house?
I don't see how he has any right to what he wants, and I don't see an existing kernel devs refusal to cooperate, or even entertain cooperating, as automatically wrong or unreasonable.
While I think this a dumb metaphor, it's also incorrect in this context. The Linux kernel explicitly supports C and Rust code, and there are very clear parameters to allow for Rust code to be integrated into parts of the kernel.
Or in other words, the decision has already been made to allow meat into the vegan household, and now one maintainer is explicitly blocking a package of meat from entering the building, even though it has already been decided from on high that meat should be allowed in.
This isn't quite accurate, though, because of the unnecessary metaphor thing. Reading the original mailing list chain all the way through and talking about these events directly is completely sufficient here. The patch was reasonable within the parameters set out for the R4L project. The maintainer of this subsystem blocked it explicitly because they disagree with the idea of R4L in general (calling it a cancer).
The question is not whether or not R4L is a good thing or a bad thing - anyone can have their own opinion on that. R4L is part of Linux, and will be for the foreseeable future, until it either clearly demonstrates its use, or clearly demonstrates its failure. The question (at least as regards the "cancer" comment) is whether it is okay for a maintainer to describe another team's work as cancer, and to publicly block it as much as they can.
If they are overstepping, then Linus will make that known. Until then, apparently they are not overstepping.
And he can use that image if it communicates the concept he wants to communicate.
It sounds like a valid image to me to apply to the concept of polyglot.
He is saying that "If there is really no way for a rust driver to exist all by itself without any of the c code having to do anything special to accomodate it, then so be it, I guess rust doesn't fit here after all."
rust devs are saying "you're not even helping a tiny bit!". I am saying, no, they're not, so what? They don't have to. They did not request what rust devs are trying to do.
The concession rust devs got to proceed to attempt to use rust in the kernel at all doesn't promise almost anything beyond "well you can try". It does not promise to facilitate that try at all really.
And to clarify I'm not saying he's right or wrong or acting good or bad. I have however expected R4L to ultimately fall apart because of this exact issue, the maintainers have never been on board with maintaining Rust code and that hasn't changed. While that remains the case the project is going to be stuck at a wall - to the point that if they're confident they can maintain the Rust code themselves they should just fork it and do that. If it works well enough they'll eventually be too popular to ignore with people choosing to write their new modules in Rust instead.
I agree it's rude, offensive, and hostile, but there are degrees of things and context matters. "You are cancer" would be much worse. I feel we should try and interpret things in good faith and maintain some perspective. For a single word like this: you can just read over it (which is also what the other Rust people did).
Certainly outright removing Hellwig from the Linux project, as Marcan suggested, is bizarrely draconian.
As I argued a few days ago: part of "being nice" is accepting that people aren't perfect and dealing with that – https://news.ycombinator.com/item?id=42940591
He said: “ And I also do not want another maintainer. If you want to make Linux impossible to maintain due to a cross-language codebase do that in your driver so that you have to do it instead of spreading this cancer to core subsystems. (where this cancer explicitly is a cross-language codebase and not rust itself, just to escape the flameware brigade).”
I think the conversation is more about people equating R4L as validation for rust or even themselves.
No, it is not perfectly clear.
The generous interpretation is that they meant it is "viral", spreading through dependencies across the codebase (which I don't think is technically accurate as long as CONFIG_RUST=n exists).
The less generous way to interpret it is "harmful". The later messages in the thread suggests that this is more likely.
But I'm left guessing here, and I'm willing to give some some benefit of doubt here.
That said, the response to this comment was incredibly bad as well.
https://lore.kernel.org/rust-for-linux/CAHk-=wi=ZmP2=TmHsFSU...
(not taking either side, just interesting to read the reply)
> You think you know better. But the current process works.
Regardless of how badly broken the kernel development process is, Linus and others observe that Linux continues to dominate and conclude that therefore the development process "works". Success in the market blinds the successful vendor to their defects. Sound familiar?
If Linux carries on down this path then eventually something else that has been subject to more evolutionary pressure will displace Linux, and we'll all be telling stories about how Linux got complacent and how it was obvious to everyone they were heading for a fall.
And honestly, with maintainers like Hellwig maybe that's what needs to happen.
Linus was right to reprimand him for the suggestion.
"Thinking of literally starting a Linux maintainer hall of shame. Not for public consumption, but to help new kernel contributors know what to expect.
Every experienced kernel submitter has this in their head, maybe it should be finally written down."
Personally, seeing
> Being toxic on the right side of an argument is still toxic, [...]
written unironically, on social media, immediately after that person wrote @marcan
> and if that then causes you to ragequit, because you can't actually deal with the heat you've been dishing out coming back around the corner: fuck off
leaves me feeling more sympathetic to marcan's argument about the kernel being full of toxic attitudes, not less. Maybe public shaming isn't the answer but there's a problem here. Maybe don't make comments like that on social media if you want to criticize people for leaning on social media in kernel disputes.
This seems like a tu quoque fallacy. The feedback is either applicable or not, regardless of who said it. They're absolutely correct that Being toxic on the right side of an argument is still toxic.
Even if there is hypocrisy (whether judged by you personally or someone else), it wouldn't invalidate the point.
Certainly in context, this seems fairly reasonable: https://chaos.social/@sima/113961283260455876
Yeah this isn't about "being civil" or "friendly" and even less about "don't call out". This is about calling out in an ineffective and imprecise way, so that the people actually trying to change things are busy patching up your collateral damage instead of implementing real changes, while all you've achieved is airing your frustration for internet drama points.
When you're that harmful with your calling out, eventually I'm going to be fed up, and you get a live round shot across your bow.
And if that then causes you to ragequit, because you can't actually deal with the heat you've been dishing out coming back around the corner: fuck off.
Or as Dave Airlie put it upthread in this conversation: "Being toxic on the right side of an argument is still toxic, [...]"
So please do call out broken things, do change things, I've been doing it for well over a decade in the linux kernel. But do it in a way that you're not just becoming part of the problem and making it bigger.
---
And this is not the first time something like this has happened with Marcan. He may be tired of the Linux devs, but many of them are also tired with him (including some of the people working on Rust, it seems).
And this is part of a conversation on what went wrong here, not an attempt to rally the troops. You really can't compare it to Marcan's stuff. This kind of (selective) demand for absolute perfection is really not great.
If true, then it sounds like there are some “missing stairs”[1] (the professionally difficult kind, hopefully not the other kind) in Kernel development.
[1]: https://en.wikipedia.org/wiki/Missing_stair
https://web.archive.org/web/20250204162031/https://social.tr...
However it seem that you need to disable js as soon as the content load or it will be overwritten by a 404
As a pilot program, R4L should have graduated or ended a long time ago. After several years of active development, its status remains unclear. Instead of cracking heads to get everyone on the same page, Linus has instead spent all this time sitting back and watching his subordinates fight amongst themselves, only to then place responsibility for the drama on Martin's shoulders. Poor form.
Arguably his reprimand of Martin is a clear signal that he will never show Rust any favor, but he hasn't said anything explicitly. Maybe he knows he should, but he fears the shitstorm it will cause. Maybe it's time for him to rip off the band-aid, though.
And again, all of this could have been avoided if he'd just put his foot down one way or the other. Imagine how much time and energy (even just Martin's alone) could have been saved if Linus had just said "no, keep it downstream".
That doesn't really have anything to do with Rust; but with Hector's behaviour. Threatening a social media campaign to out people is completely toxic behaviour. This is a long-term contributor who is perhaps a bit abrasive, not Jimmy fucking Saville.
Other than that, it's not a binary yes/no question; no one is really against some Rust in some parts of the kernel, but which parts? How? Where? That's the big disagreement. Linus has always been fairly hands-off on these types of disagreements.
I'm no where near in the loop on this, but that sounds incredibly toxic. Are there some good links to summarize this?
EDIT:
OK, these are fully enough to allow me to understand the issue.
Marcan: https://lore.kernel.org/rust-for-linux/208e1fc3-cfc3-4a26-98...
Linus: https://lore.kernel.org/rust-for-linux/CAHk-=wi=ZmP2=TmHsFSU...
I must say, I think I'm on Linus' side on this one.
EDIT2:
I was a $$ supporter of Marcan for over a year on github. I was predisposed to believe him, I'd say.
There seems to be some issue with unaccountable maintainers, and that’s a problem for innovation. If you can’t even get to the point of “technical debate” (we aren’t interested, sorry), then what hope innovation?
These are “people problems”, and there are no easy or good answers, but it doesn’t mean we should through our hands up and consider things “unfixable” either.
"... I come at this from the perspective of having worked on Linux since around December of 1991. I first met you and Tove in 1995 at the Free Software Conference at MIT that Stallman sponsored. ...
Probably the last technical contribution of my career is leading an initiative to provide the Linux community a generic security modeling architecture. Not to supplant or replace anything currently being done, but to provide a flexible alternative to the development of alternate and/or customized workload models, particularly in this era of machine learning and modeling.
Four patch series over two years, as of yesterday, not a single line of code ever reviewed. ...
We were meticulous in our submissions to avoid wasting maintainers time. We even waited two months without hearing a word before we sent an inquiry as to the status of one of the submissions. We were told, rather curtly, that anything we sent would likely be ignored if we ever inquired about them.
We tried to engage, perhaps to excess, in technical discussions attempting to explain why and how we chose to implement what we were proposing. ...
There were never any relevant technical exchanges. The discussion consisted of, we have decided to do things a certain way, no discussion, if you don't like that you should really consider doing something other than submitting to upstream Linux."
(https://lore.kernel.org/lkml/20240826103728.3378-1-greg@enje... is the patch set in question)
https://lore.kernel.org/linux-security-module/20230204050954...
> We were meticulous in our submissions to avoid wasting maintainers time. We even waited two months without hearing a word before we sent an inquiry as to the status of one of the submissions. We were told, rather curtly, that anything we sent would likely be ignored if we ever inquired about them.
It's reasonable to ask that people make smaller-sized patches to get reviewed, and it's reasonable to have to rule out some things due to not having the bandwidth for it compared to other priorities, but it's pretty ridiculous to expect people to know that those are the reason their code isn't getting reviewed if they're not allowed to inquire once after two months of radio silence.
The "every change can be a small patch, can be split in such" is part now of the Linux folklore IMHO. As in, a belief that people kinda heard about but nobody has concrete proof
Also do you know what would make it much easier to review long changes? Not using email patches
But I'm glad there's an good answer on "how to do it" in the thread https://lore.kernel.org/rust-for-linux/Z6bdCrgGEq8Txd-s@home...
GitHub issues with "load 450 hidden comments" on it? No threads, no comparisons between multiple submissions of the same patch, changes from rebasing impossible to separate from everything else? Having to drop anyway to the command line to merge a subset that has been reviewed? Encouraging squash merging makes it easier to work with long changes?
Email is complex and bare bones, but GitHub/GitLab reviews are a dumpster fire for anything that isn't trivial.
And I agree, GH has several issues
IIUC, the Kernel project doesn't want to use it because of the single-point-of-failure argument and other federation issues. Once the "main" Gerrit instance is down, suddenly it's become a massive liability. This[1] is good context from the kernel.org administrator, Konstantin Ryabitsev:
"From my perspective, there are several camps clashing when it comes to the kernel development model. One is people who are (rightfully) pointing out that using the mailing lists was fine 20 years ago, but the world of software development has vastly moved on to forges.
"The other camp is people who (also rightfully) point out that kernel development has always been decentralized and we should resist all attempts to get ourselves into a position where Linux is dependent on any single Benevolent Entity (Github, Gitlab, LF, kernel.org, etc), because this would give that entity too much political or commercial control or, at the very least, introduce SPoFs. [...]"
[1] https://lore.kernel.org/rust-for-linux/20250207-mature-paste...
By that measure, kernel.org is a SPoF as well
Maybe we can figure out a way to archive Gerrit discussions
(offtopic note - don't upvote the comment you're responding to while you're commenting as you'll lose your comment)
In contrast, I use Mutt for dealing with high-volume email-based projects with thousands of emails. It's blazingly fast, and an absolute delight to use—particularly when you're dealing with lists that run like a fire-hose. It gives a good productivity boost.
I'm not saying, "don't drag me out of my email cave". I'm totally happy to adapt; I did live in "both worlds" :-)
[1] https://opendev.org/ttygroup/gertty
https://lore.kernel.org/rust-for-linux/20250208204416.GL1130...
Yes, the model is not scaling. Yes the current model is turning people away from contributing
I don't think linux itself is risking extinction, but someday the last person in an IRC channel will turn the lights off and I wonder if then they will think about what could they have done better and why don't people care about finicky buildsystems with liberal use of M4. Probably not.
If that were the case then the patch would have a lot more CCs.
if someone is willing to put in the efforts to submit such a huge patch, how about just show them a little bit respect, I mean the minimum amount of respect, for such efforts and send them a one line reply asking them to break the patch into smaller ones.
surely that won't take more than 45 seconds. still too hard to get the point?
I hate to appeal to authority, but I have been working with large cathedral-style open source projects (mostly three: GCC, QEMU, Linux itself) for about 20 years at this time and have been a maintainer for a Linux subsystem for 12. So I do know what I am posting and talking about.
The very fact that I had never learned about this subsystem from LWN, Linux Plumbers Conference, Linux Security Summit etc. means that the problem is not technical and is not with the maintainers not replying it.
A previous submission (7000 lines) did have some replies from the maintainers. Apparently instead of simplifying the submission it ballooned into something 150% larger. At some point I am not sure what the maintainers could do except ignoring it.
Ignoring people is a childs approach to communication. If there is a problem, its your responsibility to communicate it. If you have communicated the issue and the other party is refusing to hear it, that is a different issue, but it is your responsibility to communicate.
It sounds like there was willingness to meet any requirements, but submitters end up in a position of not knowing what the requirements are and if they have met them or not.
https://lore.kernel.org/rust-for-linux/20250208204416.GL1130...
Yikes, this is EXACTLY what Linus was talking about except an order of magnitude worse!
This does not read as a rant at all to me. Rather it seeks to highlight a problem using an example from his own work and proposes a possible solution (with a previous caveat of “I don’t know how to fix this”).
> "Code Of Standards for maintainers" in addition to a CoC
He wants maintainers to behave in some pre-determined understandable fashion. He wants some accountability, and that seems reasonable to me. This is not a “maintainers must do what I want”, this is “let’s set basic expectations” and ensure people follow them. Whatever those should be.
> in order to witch hunt people he feels "gets in the way."
B does not follow A. You are simply straw-manning here, so I have nothing to say to it other than it’s a fallacious point.
But presumably it's not whatever they should be. It's what he wants them to be. And what should happen if they're not followed?
Few people like dealing with interpersonal conflict. They want to think that technical meritocracy wins the arguments.
But in that discussion, a maintainer said "I am going to try to sabotage this because I hate it.", and there's no technical argument to resolve that. And there's not really any route other than escalation to some kind of authority if there's not a common negotiation baseline.
"You can't reason someone out of a position they weren't reasoned into."
When has this ever happened with the Linux CoC? The only people who I've seen banging pots and pans together about the CoC are folks who like to sealion [1]
[1] https://en.wikipedia.org/wiki/Sealioning
The current management model is based on consensus in some parts, and a dictatorship in others. Its not clear which parts are which because of sprawl, and non-responsiveness.
This is a core communication people issue. The problems arise because in consensus models, people are expected to adopt archetypical roles based somewhat on preference, but mostly on the needs of the group, towards productivity.
If no one else is doing that type of role, someone will be forced into doing it, and will adopt characteristics of that role, regardless of their personal opinions about it.
When they get punished for fulfilling the role, you lose people.
> doesn't mean we should throw our hands up and consider things "unfixable" either.
The given structure is unfixable, because it sets the stage for a trauma loop where actions can't take place without people who are expected to fulfill a role to meet consensus, but in doing so they get punished for volunteering.
There is no way around this structure so long as you use a consensus model in whole or part, in dysfunctional groups the people involved either fail to communicate or worse there are members that impose coercive cost by assuming the unproductive roles so no action happens while resources are wasted.
This really is basic stuff covered in your college level intro to communications coursework.
For those wanting to know more about this, you can read more about the roles at the link below.
https://pressbooks.pub/smallgroup/chapter/roles/
Speaking as an actual People Manager, his ideas sound pretty shallow.
That sounds... Not good. Seems like like this is exactly what's wrong with... Well, not just this, but much of the "FOSS" world. (Maybe about since "Free Software" became "Open Source"?)
Is it innovative? Is it valuable? Is it worth the cost? Who is it valuable to?
I don't see why the kernel team should be obligated to react in any particular way to a random submission.
This is a recurring pattern I see with drama in some open source communities, where people measure others using yardsticks they themselves don't live up to. People can't post stuff like this while accusing everyone in the vicinity except themselves of bad behavior. Choose one.
Gunthorpe [nvidia]: https://lore.kernel.org/rust-for-linux/20250130154646.GA2298...
Basically, there is concern that even with a declaration that Rust-for-Linux devs will maintain this (and potentially every other) cross-language API translation layer file, the demarcation point between C and Rust isn't sufficient, and is causing C developers lag or headaches by having PRs rejected because of Rust-side failures. I don't see how that can be fixed without wholesale buy-in to Rust of enough kernel devs that they can fix whatever Rust problems are created by C API changes. Or Linus will have to accept PRs that break Rust-enabled builds. The R4L devs, by themselves, don't have the bandwidth to keep up. Even if they can rapidly fix problems, that adds potential friction to every C API change.
Hellwig may not be communicating in a good way, but he might be right, unfortunately. Linux may need to stay as a C-only codebase until an AI language-translation tool is good enough to do things like maintain the Rust API translation layer itself. Or until basically all maintainers learn and accept Rust.
> Then I think we need a clear statement from Linus how he will be working. If he is build testing rust or not.
> Without that I don't think the Rust team should be saying "any changes on the C side rests entirely on the Rust side's shoulders".
> It is clearly not the process if Linus is build testing rust and rejecting PRs that fail to build.
The matter and the question at heart is still unsettled. The answer of whether or not Rust being in a broken state is a blocker for working and valid C code will hopefully be addressed by the end of this cycle of development. Either the patches are accepted and Rust is truly allowed to be broken or the patches will not be accepted due to breaking the Rust builds. If it is the latter, as many of the C developers fear, that is the exact burden being placed upon them that they have been stressing very loudly that they have no interest in taking on. And once other maintainers see this, what is the inevitable response to this metastasization? Comments like those from Ted and Christoph will pale in comparison. The only bright side might be that this finally accelerates the inevitable demise of this failed Rust experiment so that all parties can move on with their business.
That one bug happened one time does not mean that the promise is broken. To be clear, it's a bad thing, but acting like this means the entire working rules are a lie is overreacting.
It's not been once. Don't you understand that is why things have gotten to this point? Are you aware of how the developers have been using Coccinelle in their workflows and how many subsystems support it? And are you aware that the Coccinelle for Rust implementation is constantly in a dire state? Have some empathy for the folks who have had their workflows broken and burdens increased because of it.
> Let's say that we both agree that Linus should be making clear statements here, and that lack of clarity is causing lots of problems.
Clarity will be communicated by the result of this patch set.
Okay. Will you show empathy to the R4L folks constantly having sand poured into their fuel tank by kernel maintainers?
But the thing is, the kernel isn't "the R4L folks"' "fuel tank", is it? Doesn't the very name you use, "kernel maintainers", tell you that that's their "fuel tank"? Seems the people pouring sand into that are "the R4L folks".
R4L folks thought that preliminary R4L infrastructure being accepted upstream meant that all the changes they needed in the future would be accepted easily as well, and now that there are concerns from subsystem maintainers, a few R4L folks are playing the dramatic victim card.
From what I understand, market pressures are causing R4L folks to panic. If they can't get more R4L stuff upstream, people can't ship Rust drivers, and R4L development falls apart.
That's not kernel maintainers' problem, though. They have a job to do to, and it has nothing to do with Rust kernel drivers except as far as they're persuaded Rust drivers help the linux community overall and will be maintainable without unacceptably disrupting their tool-assisted workflows. Several of them have concluded, so far, that R4L PRs will unacceptably disrupt existing workflows.
That's where R4L has failed. They've failed to persuade subsystem maintainers that some added headaches/retooling/efficiency-loss is worth it to enable Rust drivers. Which drivers, and who wants to use them? Perhaps the potential downstream users of those drivers can talk with kernel devs, persuade them it's really valuable, and figure out a plan?
Not just 'a few R4L folks', these are basically the spearhead of the effort. And it hasn't been a single occurrence, we now have seen two of those Rust developers resign from the effort out of pure frustration from the entrenched, heels-in-the-sand attitude from kernel maintainers.
The same thing has happened in the past. I will point to TuxOnIce, which got stonewalled by a stubborn maintainer. It would have moved most suspend and hibernation code to userspace, where it would have been easier to maintain and iterate. Or right now we have two divergent RAM compression paths (Zram and Zswap). There are patches for Zram to use the unified Zpool API, but the Zram maintainer refuses to integrate these for absolutely no solid technical reason.
It seems that the R4L peoples are fine with doing any effort required, as long as they know it is not in vain. So far, comments akin to "language barriers in the kernel are a cancer" and "I will do everything to prevent/sabotage this" do not exactly build trust in that regard.
As an aside, would it really be so horrible for kernel maintainers to learn (some) Rust? This is not a dire ask for someone in the software world, your job will often ask this of you. And I can't imagine the maintainers haven't ever dabbled in other languages and/or aren't capable enough to learn a second language.
I understand the fear that saying "ok, we can do more languages than one" opens up the door to a third and fourth language down the road, but that seems unlikely. There's a reason Rust has passed Linus' sniff test where no other language has so far.
> Which drivers, and who wants to use them?
Short term it seems mostly GPU drivers.
Long, looong term (multiple decades?) the plan is probably to rewrite more important parts of the kernel, to significantly increase memory safety.
Well they are. Second class citizens like this just cause problems.
> As an aside, would it really be so horrible for kernel maintainers to learn (some) Rust?
Are the Rust folks planning to pay the existing kernel developers for spending that time? Because otherwise it should be up to those existing maintainers to decide and not something anyone else gets to demand.
Overall this just sounds like people crying that their hostile takeover of an existing project is being met with resistance.
> Not just 'a few R4L folks', these are basically the spearhead of the effort.
A "spearhead" is by definition a few people.
> As an aside, would it really be so horrible for kernel maintainers to learn (some) Rust?
If they want to contribute to the Linux kernel, would it really be so horrible for these Rust programmers to learn the language the kernel is written in?
> There's a reason Rust has passed Linus' sniff test where no other language has so far.
Doesn't seem it has, really.
> the plan is probably to rewrite more important parts of the kernel
So just fork it and rewrite it all in Rust.
[1]: https://news.ycombinator.com/item?id=42993961
That's just manipulative. Maybe it's just a moment of frustration and they'd take it back eventually, but blackmailing people with social drama is not cool. That's what X and Reddit is for.
> Rust folks: Please don't waste your time and mental cycles on drama like this [...] they know they're going to be on the losing side of history sooner or later.
That sounds very cult-like, doesn't it?
I'm amazed that Hector is doing this fully in public using his real name.
That might reflect my environment, but all of the things I’d consider C variations for I’d use Rust for as well…
An example is Muratori from handmade hero, who publicly stated he dislikes Zig and pretty much sees it as a confused mess[1]. He thinks Odin is kind of OK, because it has metaprogramming (which other languages do too), but is way below Jai. Between Jai and Odin, he thought Jai was the one with potential and could get him to switch/use. Odin's slight popularity, as a kind of Jai-lite, is often attributed to Jai being a closed beta. But, it appears that might change soon (Jai going public or opening up beta use more), along with an upcoming book on Jai.
Programming languages like Go and V (Vlang), have more of a use case for new programmers and general-purpose, because they are easier to learn and use. That was the point of their creation.
[1]: https://www.youtube.com/watch?v=uVVhwALd0o4 (Full Casey Muratori: Language Perf and Picking A Lang Stream)
C programmers (and C++ programmers) who don't like Zig or Odin can simply use C (or C++), it's not really the case that they have to switch to anything, much less something as overwrought as Rust. My point is that it is natural for someone who is at any proficiency level above 0 in C to want to apply that proficiency in something that allows them to make use of those skills, and C, C++, Odin and Zig all allow them to do that, pretty much immediately.
You contend that "It's an investment to become as proficient in the other language" but I would argue that this is a very wide spectrum where Rust falls somewhere in the distance as opposed to all of the languages I mentioned instead being far closer and more immediately familiar.
The counter, in regards to "any proficiency above 0", is there are other alternative languages (that are easier to learn and use) where knowledge of C can be put to immediate use too. Getting up to speed in those languages, would likely be much faster, if not more productive for less proficient or experienced programmers.
I work full time with Odin and I wouldn't put too much stress on this point as I've found that whatever issues we have with Odin are simply issues you'd have with C for the most part, i.e. C knowledge will help solve it. It's not a complex language, it doesn't need to do much and language-specific issues are few and far between because of it. Tooling is a bit of a mixed bag but it's about 80% solved as far as we're concerned.
Odin day-to-day for working on 3D engines (which I do) is not beta quality, whatever that means. I would rate it a better net fit for that purpose than I would C++, and I wrote the kind of C++ you would write for engine work for about 10-11 years (at least what we knew to be that kind of C++ at around 2001). For server software I'd rate it worse, but this is mostly because there are a few missing FFI wrappers for things that usually come up, it's not really because of the language per se.
As for Jai, I can't claim to know much of anything about it because I've never used it, and I wouldn't take many peoples' word for much of anything about the language. As far as I'm concerned Jai will exist when it's publicly available and until then it's basically irrelevant. This is not to disparage the effort, but a language is really only relevant to talk about once anyone with motivation and an idea can sit down, download/procure it and use it to build something, which is not the case with Jai.
You cannot claim this when even codebases with veteran C developers will be virtually guaranteed to have memory safety issues at some point.
Also, I know this may shock a lot of people who don't regularly use sharp tools: The possibility (and even occurrence) of memory safety issues and memory corruption doesn't tank a project, or make it more costly than if you'd used a GC, or Rust. Memory bugs range from very easily avoided and solved to surprising and very, very hard to solve.
I never said this. The Linux kernel and any other project will thrive with or without Rust. But it is a certainty that the higher the ratio of C-to-Rust in the world (or well, any memory-safe systems language), the higher the amount of CVEs we will see. It would seem reasonable to me to assume that we want as few CVEs as possible.
To be honest, I also don't understand the dogmatic stance a lot of C developers have against Rust. Yes, it does cause some friction to learn a new language. But many of the correct idioms Rust enforces are things you should be doing in C anyway, its just that the compiler is a lot more strict instead of just nagging you, or not even nagging at all.
Social bubbles can work like that.
Some people in that community reflexively see a conspiracy or invoke the CoC or use whatever other non technical tools they find to derail the discussion.
It's not even that they're always wrong or that I directly oppose the culture they want to have, but the shotgun blast of drama that this comes with is just so much effort to navigate that i decided to just never contribute to rust again.
And please, stop using the concept of ad hominems to selectively justify blatant abuse. That's not what the term is about.
It was a move of frustration due to having exhausted all other avenues. It wasn't his first action.
I've had to remove Hector's postings from my feeds because he just constantly bitches and complains about pretty much everything. He's capable, smart, and is doing more than anybody ever will for Apple hardware. But he desperately needs to Stop Posting. Without anybody he works with regularly to give him a reality check, I don't think he's going to change course.
I think Hector has some valid complaints about the contribution process to the kernel, I know. It fucking sucks ass and I've given up on trying. But screaming the way he does is counter productive to improving it
Linus should have stepped in long before a maintainer blew their stack and started throwing out ultimatums. Once that happened, Linus could have still stopped everything with one sentence -- "Let me look into this.", but he did not.
Linus only got an opinion once things blew up on social media which proves that social media works which is the exact opposite of what he says he wants (and will just encourage more of the same).
That is really an apt point. You can't condition people one way, and tell them to do the opposite.
10 years back, Linus _was_ "that guy". And it worked, extremely effectively, if you measure success by the ability to stamp on someone else's technical contribution by ridiculing them in public instead of making a convincing technical defense of his position in the discussion.
https://github.com/corollari/linusrants
You can certainly imagine ways an authority figure could have defused a situation of a maintainer blowing their stack, but your framing kinda absolves the maintainer of any accountability for their actions.
A team member who needs a lot of defusing is doing something wrong, and needs to learn how to defuse themselves.
Going to have to disagree on that one.
Not in the sense of "he wants the mailing lists private", but in the sense that "he doesn't want public complaint about private discussions", which feels like an evolution of "technical merit should win", as a position.
That shouldn't be too surprising - I mean, its an old project with a whole lot of technical baggage. Projects tend to slow down over time. And that is legitimately really frustrating when you want to shake things up or push for change. I would be rubbish as a linux kernel developer. I have the wrong temperament for it.
There's a reason why some tech companies interview for both technical skill and culture fit. Sounds like he's got the technical chops, but he's not a good fit for linux.
And when you're in a situation like that, your choices are essentially Voice or Exit. Voice is to do what he's tried to do - kick up a fuss about the problems to try and get them fixed. Thats a skill on its own - and it sounds like he's not been super effective at that. The other option is Exit. Which of course - sensibly, he's now done.
> he has gotta Stop Posting and keep those kinds of thoughts away from his keyboard.
Nah. Bottling this stuff up is a bad long term play. You end up getting bitter, cynical and resentful. I think we've all worked with people like that, and its miserable - both for the person and for their coworkers. I think its better to shoot your shot. Even if you miss - as he has here - you learn a lot about yourself and the world. And there's no shortage of interesting projects out there to work on. Pick something that matches your speed.
You're right.
To fit with historical "linux culture" he needs to be much more aggressive and rude.
He needed to lead with something more inline with linux project leadership's examples, perhaps something like: Christoph " ... should be retroactively aborted. Who the f*ck does idiotic things like that? How did they noty die as babies, considering that they were likely too stupid to find a tit to suck on?"
https://github.com/corollari/linusrants
First of all because we're talking about the kernel community here, which was incredibly toxic and dramatic long before Rust even existed. Linus has chilled out in the past few years but that legacy isn't entirely gone.
C++ drama has nearly come to fistfights at conferences, and the only reason that doesn't get talked about more is that the toxicity stays mostly on private (not public) mailing lists as a result of the more insular nature of that ecosystem. Nowadays you have a lot of people just quitting over things like the fact that a member of the standard committee was convicted on CSAM charges.
There are plenty of "C supremacists" in the tech influencer community and the maintainer mailing list of every distribution.
And streamers like PrimeTime that eagerly jump on every opportunity to shit on Rust and actively dump gasoline on every flareup of drama for ad revenue.
In general, programmers seem to love being elitist about languages and tools. Remember how everyone used to dump on PHP constantly?
He's not a fan of Rust for totally legitimate reasons.
There seems to be an entire second world of “Rust community” and Rust zealots online who are heavy on the drama, though. It really does feel like an alternate Rust universe.
Although when I think about it, several of my other interests and hobbies are exactly like this. Great in the real world, but as soon as you step into certain online spaces it’s drama and toxicity.
In this specific case, I think this is more about kernel drama than Rust drama.
You can lie to yourself and say that the same security problems exist in other languages, but that isn't true.
When I check the vulnerabilities marked as HIGH on a JVM based project, it's often banal stuff like a denial of service in Spring. The consequences of an attack are a few days of downtime until we patch the library, but the truth is that while downtime on our application might be profitable for a competitor, it's not profitable for a black hat hacker working alone. They can't blackmail us, because we can update the library without paying them to stop.
Meanwhile the average C vulnerability is usually some form of RCE that would let the hacker install ransomware.
That stackoverflow survey rust folks so proudly crow about shows it’s the #1 ‘admired’ language, well #2 was closure and Zig over the years which clearly shows the value of the survey. Just marketing slop.
The rust produces safe code claim is also marketing garbage. The rust standard library has over 7.5k (of 35k) unsafe functions in it. The core library has 7K (of 21k) unsafe functions. So any Rust program that claims not to have “unsafe” code is most likely not true since any program that doesn’t use the standard library is a toy.
https://aws.amazon.com/blogs/opensource/verify-the-safety-of...
The rust community unearned arrogance is only surpassed by the Haskel folks. It’s breathtaking. Yes yes not all in the rust community are like this, but the social media amplified squeaky wheels one sure are loud.
> To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code.
That was 2022. I am aware of at least one security bug in their Rust code, but it wasn't a memory safety issue. I'll be interested to see what they say when they post updated numbers.
"it’s important to understand that unsafe doesn’t turn off the borrow checker or disable any other of Rust’s safety checks"[1]. Using the Rust keyword 'unsafe' doesn't make the code inside it the Wild West or automatically an exploit or a problem, it is a limited-scope relaxing of only some checks.
[1] https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html
Why does any of that imply that Rust doesn't produce safe code? There's no argument here - just some numbers and unjustified conclusions.
Yes, there was a popular logger library that was written badly that tried to interpret log messages as potential source for fetching code dynamically from remote locations. Something that was thought to be the future 25 years ago, but had mostly been abandoned in all modern code.
It get pushed with the argument for better memory safety but then wants to change the entire world as well.
From shaming everything else as either slow or unsafe to rewrite the universe, the Rust community makes it hard for new comers to consider the language by its merit.
But the good thing is, the hype has settled down and Rust has found its niche. It’s not tackling Go or Python anytime soon and competes in a different plane.
Zig is another great alternative for someone like me who never found Rust a pleasant language to work with.
If rust ends up being mainstream successful, those people will move on to something else and start attacking rust for whatever they feel their new language is superior in
Someone should have hugged them when they were kids
Just hate the fact that quite often people get judged or even treated differently just based on the languages they choose to use. It is just a tool, nothing different from a screwdriver.
They have been trying for years now to integrate Rust in the Linux kernel they could have made some good progress on a rust only OS by now. If only just a kernel that can run server like application without a gui shell.
Surely it should be easy if you're asking the Linux people to do the same thing for drivers written in Rust?
This was never about the languages primarily though. The C programmers here would react the same way towards any other language, be it Zig or Swift, its not Rust specific. They just don't want to partake the additional headache they'll have to deal with to for making the Linux kernel more accessible to languages other than C.
Despite than, Rust devs kept on pushing it after all that was clearly stated, just to make things more and more annoying. Maintaining a software as huge and widely used as the Linux kernel is a huge responsibility that can't be relied on words like "leave it on our shoulders", especially when real time, immediate response is demanded. Development of something like the Linux kernel in Rust will be left unmaintained eventually, unless millions of dollahs are constantly invested into maintaining it because Rust is not as simple as C and the need to avoid accidental copying, memory leaks and almost all memory related issues will add more work because you can't escape "unsafe" when dealing with low level hadrware and C, making the usage of the Rust programming language for Linux kernel development utterly pointless.
The hardware is outside of Rust's safety guarantees. This is truly a fundamental issue.
Also, there is nothing wrong with any "unsafe language". Memory safety is a skill issue, not a language issue. All functional languages are safe and procedural languages are unsafe by nature. Its better to settle on a functional language and compromise on performance if memory safety is of utmost priority. The additional complexity and performance overhead of any supposedly safe procedural language is not worth it for doing low level stuff but it sure could be a fun choice when doing high level stuff.
There are softer ways to work with abrasive attitudes that can ultimately accomplish your goals. A key part of that is knowing which battles are worth fighting. Sometimes, it's better to let a suboptimal solution in to appease an ego.
I think Hector's change is the right one, but I also think with the dma maintainer being unwilling to budge the next move is to hack in a location with less resistance, potentially making more work and churn, but ultimately achieving the goal of rust in Linux.
Two people being abrasive to each other with code involved is a disaster.
This one. The code in question, AFAIK, is a rust wrapper around the DMA subsystem. I think that does best belong in the DMA subsystem but with the maintainer unwilling to accept it the next place to put it is either in a new rust-dma subsystem/wrapper or to pull out the parts needed and integrate them directly in the drivers in question (certainly nasty and a lot of duplicate effort).
The goal for such code should ultimately be to cause as little friction as possible with the DMA maintainer.
If it comes up in the mailing list that "this is dumb and you shouldn't do this" that's when you loop in the DMA maintainer and request their suggestions on how to proceed with whoever challenges the change. Put them in the seat of making the decision of where the code should go.
He's a known, certified, card-carrying obnoxious rebel coming pretty close to violating a "Code of Conduct" himself pretty well every other day then his beef with Christoph about wanting to "mix languages" (C and Rust, of course) and Christoph said "I'm maintaining it and I'm not doing it, it's like a cancer" (I'm paraphrasing and he was notably not talking about Rust itself but "mixing" C and Rust) then Martin exploding and screaming that Christoph said "cancer" and that he had violated a Code of Conduct. Please.
A serious case of the pot calling the kettle black.
You don't even take time to figure out who's the commit author.
Some Kernel maintainers are absolutely against Rust anywhere in the kernel tree [0]:
> The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language complely breaks this. You might not like my answer, but I will do everything I can do to stop this.
This is from Christoph Hellwig, the DMA maintainer. And is in fact what started the thread that led to Hector Martin quitting Linux. You can see other comments by Hellwig in that thread as well, he is extremely explicit - any Rust anywhere in the kernel is a big problem, and even if he can't stop it everywhere, he will do what he can to make it harder to use Rust by blocking it from the pieces he maintains.
[0] https://lore.kernel.org/rust-for-linux/20250131075751.GA1672...
If a maintainer of a major subsystem has those objections, it is a good chance to try to convince them otherwise.
If something is not clear, ask him to elaborate.
But blackmailing with a social media campaign is not productive. Even more it’s anti-productive. This just adds to rust=drama=stayaway feeling.
What about the part quoted in GPs comment?
> > The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language complely breaks this
Wouldn't adding another language add an internal boundary? I don't know enough the kernel or kernel development to say it's an good argument or not, but it doesn't seem to be tribalism. I do know Rust already seems to be in some/few places in the kernel, but adding more would add more internal boundaries, as it'll get more and more divided. But again, maybe I don't understand clearly.
However, I don't think it is in any way acceptable to insert this in discussions about a random Rust patch. It's disrespectful to the time and expertise of the people who submitted these patches to first nitpick various technical items, only to later make it clear you were never going to accept their patch in the first place, because you dislike and oppose the decision that you know has already been made, to allow Rust in the kernel.
If he instead was (1) upfront about the fact that he would never allow Rust code in the subcomponent he maintains, and (2) stepped out of the discussion of this patch once it was moved out of said component, and then (3) started a completely separate thread on changing the kernel's stance on Rust to block all future patches and consider removing it entirely, that would all have been normal respectable behavior.
Wait what? Thought I saw somwehere that he's the DMA maintainer, and wasn't this a DMA patch?
> he is simply being obstructionist out of tribalism.
Or is it the Rust people who are being intrusionist out of their tribalism? Looks at least as much like that to me.
Although it was a DMA patch, it was not in the DMA subsystem that Christoph maintains. More specifically, it was not a file in the kernel/dma directory, but rather a file in the rust/kernel directory, which is where the Rust subsystem lives.
The Rust code is essentially a consumer of the DMA public API, much like many other subsystems in the kernel that consume it.
This is why some people are upset and confused about the situation; he added a Nacked-by tag to a patch that is outside his area. He had good reasons for it, but it was hard to see them based on the way he wrote his replies.
I was just pointing out that the positions are much more binary and un-nuanced than the previous poster was claiming, even in the thread in question. I'd bet the DMA maintainer is not the only one who holds this dogmatic position, either.
I'll also note that the complaints from this maintainer aren't even social though. He is very explicit in his reasoning: two+ languages bad, single language good. There's clearly little that will change this, other than working around him (though, again, I agree that social media blackmail certainly won't improve anything).
I see you're not even considering the possibility that he might be right, so working around him would be bad.
___
ETA: I see on further reading that you are indeed acknowledging that possibility, good for you! I just didn't see that in this comment.
Perhaps rusts potential benefits are worth it, but it's certainly possible to disagree with that
I'm 100% behind Christoph, the last thing Linux needs is the extra complexity that Rust brings. I'm fairly optimistic that Rust will never be a hard dependency for the foreseeable future.
That ship could come back to port anytime.
Basically, it's an obstructionist, uncivilized thing to hold up every discussion about a topic that you get to participate in by insisting the topic shouldn't be discussed in this forum. It's perfectly OK to advocate for the removal of Rust from the kernel, it's not ok to bring this up in every random Rust patch while the consensus is that Rust has a place in the kernel.
This drama included the dma maintainer saying he is categorically opposed to any Rust in any part of the kernel.
>Every additional bit that another language creeps in drastically reduces the maintainability of the kernel as an integrated project. The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language completely breaks this. You might not like my answer, but I will do everything I can do to stop this.
I think that clearly means he is out to sabotage any other language than C making it into Linux.
> I do not want it anywhere near a huge C code base that I need to maintain.
Link to mailing list: https://lwn.net/ml/all/20250131075751.GA16720@lst.de/
This was also on a patch that did "keep the wrappers in [rust-folder, not DMA] code". Arp242's interpretation isn't just belied by the direct words of the maintainer, it's belied by the fact that the code the maintainer rejected was exactly what Arp242 is suggesting the maintainer was asking for.
The fact that he is using his powers as maintainer of the DMA module to prevent Rust code from being added, with the explicit goal of making it harder to develop Rust drivers so that maybe the Rust-for-Linux project might get abandoned is an explicit act of sabotage against the R4L project (no one is saying he is sabotaging the Linux project itself).
In contrast, even accepting the "two languages bad" perspective, you can't call the R4L project "sabotage" in the same way, because they are clearly not intending to prevent or break anything in the Linux kernel, even if you think they will end up doing so as this maintainer does.
This is a misinterpretation of the facts. It's not actually up to Hellwig whether or not the patch gets accepted; the relevant maintainer that would merge the patch is somebody else.
He's totally within his right to express his opinion in a NACK.
When it became clear that wasn't an option, they decided to put it somewhere else, but since he'd been consulted, he still wanted to make it clear he isn't ok with the patch regardless of where the files go or any other aspect of it; but you're right that he is not the final authority on what code goes into that new subpath.
I never said in any way that he doesn't have a right to his opinion. Just that he is explicitly and vehemently opposed to Rust in the kernel, and to anything that makes that easier to happen.
If any of
> Every additional bit that another language creeps in drastically reduces the maintainability of the kernel as an integrated project. The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language completely breaks this.
is correct, he is actually fighting against sabotage.
edit for readability
> The common ground is that I have absolutely no interest in helping to spread a multi-language code base. I absolutely support using Rust in new codebase, but I do not at all in Linux.
[0] https://lwn.net/ml/all/20250204052916.GA28741@lst.de/
I think Hellwig is against moving the wrapper into the DMA project that he's forced to maintain it.
It's a great question. I mean, my read of it is he hates the idea of Rust4Linux and is using his position to obstruct.
> He has no control over an independent library outside of C DMA?
Apparently not.
> Just that the maintenance of such including any wrapper cannot fall into C DMA's lap.
The patch he rejected did not add any code to C DMA, nor C DMA's directory (kernel/dma). Just:
(Nor does any Rust4Linux code add any maintenance burden to C -- C maintainers are allowed to break Rust code at will.)Here is a link to this explicit claim: https://lore.kernel.org/rust-for-linux/20250131075751.GA1672...
That is the crux of the entire drama and why R4L developers got upset at Christoph in the first place, and asked Linus to intervene.
By the way: I don't agree with Hellwig, insofar I can judge things, I'm just saying his opinion is valid, and that "Linus agreed on Rust, so therefore we can merge this patch" is not really a valid argument.
If you start with the assumption of a), there are no valid technical challenges to merging it. It's just better for everyone. Before Hellwig put his foot down as "not merging because rust sucks", he made a series of technical arguments against the patch, which were all transparently bullshit. It was those arguments that really raised such a furor, instead of all the other ways some C devs have disdained rust in the kernel in the past, because they were obviously made in bad faith. And when he was called out for them, he just went full "no rust in kernel".
He didn't say this at all. He explicitly and repeatedly said he has no problems with Rust as a language.
And you can't just assert "there are no valid technical reasons". Just because you don't agree with the objections, or even think they're dumb, doesn't mean you can just dismiss them and start ascribing bad faith motives.
Okay, sorry. He just said there should be no rust in the kernel.
You can ascribe bad faith motivations when someone presents technical objections that are already fully answered in the patch that was submitted, and when this is pointed out, they admit that, but don't retract their objections.
The original objections are specifically not a case of differing values or design ideas. They are nonsensical, the equivalent of 1 = 2.
That's also not what he said; it's "no Rust in kernel/dma". He pretty much explicitly said it's okay for drivers to do their thing in Rust, but with their own wrappers. You can consider that dumb, but you can't shorten that to "no Rust in the kernel".
And "I replied to your objections, therefore the matter is settled" is arrogant beyond belief. People can disagree, you know, because they have different priorities, different preferences, different perspectives, etc.
https://lwn.net/ml/all/20250204052916.GA28741@lst.de/
> Every additional bit that the another language creeps in drastically reduces the maintainability of the kernel as an integrated project. The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language complely breaks this. You might not like my answer, but I will do everything I can do to stop this.
https://lwn.net/ml/all/20250131075751.GA16720@lst.de/
Have you actually taken a look at the patch?
There was NO RUST CODE ADDED TO kernel/dma, they wanted to add a dma wrapper to a rust/ folder.
https://lwn.net/ml/all/20250204052916.GA28741@lst.de/
I'm sorry for not being clearer, but that is specifically not what is going on. The objections were of factual, technical nature. As in, "do not do X". The problem is that the code in question was not doing X, and it was not doing anything that could be construed as doing X. The objections did not arise from differences in priorities, preferences, or perspectives, they were just factually wrong.
"And I also do not want another maintainer. If you want to make Linux impossible to maintain due to a cross-language codebase do that in your driver so that you have to do it instead of spreading this cancer to core subsystems. (where this cancer explicitly is a cross-language codebase and not rust itself, just to escape the flameware brigade)."
Stop spreading this kind of misinformation.
And no, I don't think he came off very well here, but please, give it a good faith reading.[2]
[1]: https://lwn.net/ml/all/20250128092334.GA28548@lst.de/
[2]: https://news.ycombinator.com/item?id=42977720
rust/bindings/bindings_helper.h | 1 +
rust/kernel/dma.rs | 271 ++++++++++++++++++++++++++++++++
rust/kernel/lib.rs | 1 +
rejecting such patch is the exact cancer that need to cured. stop misleading people.
And this cause problem. When someone make any change to Linux kernel they suppose to fix all the code they break across all kernel. And if said wrapper accepted then maintaner of DMA will have to make sure that all patches he accepts also fix Rust parts.
So he just dont want extra burden for himself.
if multiple rust based drivers all need to have DMA support, what should they do? each come up with their own little magic?
> And this cause problem. When someone make any change to Linux kernel they suppose to fix all the code they break across all kernel.
this has been explained like 10+ times in this thread - it was made crystal clear to the DMA maintainer that he/she doesn't need to maintain the rust stuff, it is totally okay to break it.
> So he just dont want extra burden for himself
he can just resign. simple and period. no one is ever forcing him/her to be the maintainer when he/she is literally forcing other people to stop developing Linux support for the only powerful & affordable ARM machine for home use.
Sorry to ask, but couldn't it be solved with cargo? I hear all the time about the benefits of Rust tooling and zero-cost abstractions.
Why can't a driver just pull/include the latest-dma-bindings crate and glue the gap with zero-cost abstractions?
If kernel DMA code/API changes, then nothing breaks in the kernel (hopefully) and the "Rust devs will quickly solve the changes" theory can be really proven and tested by quickly updating the bindings AND the updating the drivers.
No, he didnt refer to Rust as cancer, but to Rust in the Linux kernel / the R4L project.
The sooner politicians are outright banned from using it for anything connected to their office the better.
Dude, this was literally caused by a stubborn maintainer, Hellwig, saying he wants NO second language in the kernel at all, and his explicit vow to do anything he can to stop it.
The rust for linux project exists because Linus approved it. It's that simple. Linus thinks it a good idea to at least try Rust in the kernel. If he didn't, then none of this would be happening.
Pepople can change their minds; after a while, they may come to think that what they once thought was a good idea wasn't actually so.
With stuff like this going on -- and I gather this is not the first time something like it has happened -- how long do you think Linus will continue to think so? Do you think stuff like this is likely to make Linus more convinced, or less convinced, that setting himself (and all the other Linux kernel maintainers) up to have to interact with Rust people on an ongoing basis really was a good idea?
I totally disagree that the other contributor is "a bit" abrasive though.
It's like a religious war. Brings the worst out of otherwise smart and not asshole people.
Would you consider that a healthy way of disagreeing? I think if i actually did that, you would probably feel like shit and be more empathetic to the harm that marcan causes.
Exactly the point. IMHO the one and only thing that made Linux successful as a project is Linus' strong leadership - which has been criticized ad-nauseam over the years; yet it's the only thing that yields results.
So in the specific instances (like this one) where he's not decisively, unequivocally, and even harshly saying "yes" or "no" to something, the community shows a very clear incapability of reaching a decision.
Reminds me of a similar scenario that happened years ago with GVR stepping down as BDFL for Python - just after a tiresome and wasteful fight with the community's opinions.
"Community" is just a very naive ideal for me. There's a finite number of people that can do the job, and even a more finite number of people that can make a decision and stand by it.
The more I hear about "community" the more I roll my eyes
It can be great at doing the work but it is awful at setting direction, evolving with the times and focusing on what's important
Going by another story on the front page, I have my long list of criticism about systemd but the "get things done" attitude needed to be commended
Maintainers do steer direction of development though. A lot comes from maintainer saying "we are not accepting XYZ".
Today we only have proper open source GPU drivers because people like David Airlie who stand for their principle against likes of Nvidia and AMD.
I wear garlic every day and have yet to be attacked by a vampire; clearly this is due to the garlic!
Tang/ballpoint pens/velcro never would have been invented if it weren't for the Apollo program.
etc.
I guess you are safe to say this now. But from 2014 to 2024, open source is not about code licensing but about the Community.
Naah, I don't think that's the only thing that did it. It was that, and the fact that people dared rely on it -- dared trust it to stick around, and to stay a single thing in stead of splintering up. And the thing that made it Open Source that stays Open Source -- that made it, in fact, Free Software -- is the license.
The two things that made Linux successful as a project are Linus' strong leadership and the GPL.
Just look at BSD: It had the backing of a whole darn university near Silicon Valley, not a single student somewhere North of The Wall. It had a head start by several years. And it had name recognition far beyond its home country[1]. And look where it is now: There are (at least?) three of them, and even together they're a marginal phenomenon among operating systems. I think that's because of the too-permissive BSD license.
___
[1]: The first I heard of "Open Systems" was well before I got into working with computers for a living, as a student at another university in the Frozen North in the late 1980s. My fiend and neighbour, a computer student, raved about how cool Unix was: "And you can even get it for free! It's called BSD!"
You can be a strong, opinionated leader and still be kind (or at least neutral) to the people you're working with.
A good leader is someone who can deliver hard messages while still keeping your team inspired. It doesn't do any good if the people working under you feel like trash.
It's the difference between telling a contributor "you're an f**ing idiot" vs "this code isn't up to standards, try again". Same message, but completely different impact on your team.
Do you have examples of this? The only "good" leaders that are strong and opinionated I can think of always comes across as leans towards being an asshole.
> Same message, but completely different impact on your team.
Let's change it from "you're a fucking idiot" to "this code is fucking trash". It's not insulting to the specific person, but it definitely gets the point across that the code is no good and much less ambiguous to "it's not up to standards".
I'm not sure how "this code is not up to standards, try again" is ambiguous? That seems pretty direct to me.
Ultimately it's about showing empathy. Especially when you're dealing with employees who are struggling with anxiety, impostor syndrome, or burnout - all of which seem to be overrepresented in tech.
It's not line Linus was prone to using flowery prose against random novices - the rant he's known for were mostly addressed at senior maintainers who really should have known better.
It’s sad that this even needs to be called out.
In my opinion Linus was never abusive or disrespectful - just blunt and direct.
Unfortunately, there seems to exist people (like me) that would prefer such individuals instead of nice empty words just in case someone gets offended.
The way he spoke with Alan Cox was "not apropiate".
https://github.com/corollari/linusrants
One of the main issues Torvalds says the kernel has is not being able to find maintainers. People don’t want to be abused while volunteering could be part of that.
Another possibility is that he gets paid over a million dollars a year by an employer, who will have some concerns over legal risks, reputation, etc.
As for his relationship with his employer — they both have the freedom to terminate it when their interests do not align anymore.
I genuinely struggle to understand where all the high expectations come from. Somehow people think that an open source project leader is obliged to be kind and polite and humble and understanding. None of these obligations exist as far as I can tell.
This is tragedy of the commons stuff, everyone is sitting quietly on the commons in a shared space, respecting the other people, and you drive your modified pickup truck through the middle rolling coal and blaring dance music and jeering "if you don't like it you can always move to another city" as if toning it down a bit is unreasonable but telling people to uproot their entire lives is reasonable.
> "Somehow people think that an open source project leader is obliged to be kind and polite"
Everybody is obliged to be kind and polite[1], that's one of the foundational parts of society - saying please and thank you, 'don't stare', consider the effect of your actions on other people - is kindergarten teachings; we all live in a shared space, and politeness is the grease that smoothes all the interactions between different peoples.
In any other situation, if a person has some power, authority or influence over people who can't leave or won't leave, and they immediately turn to abusing them just because they can, we would say that was bad. If a husband abuses a wife who can't leave, if a manager abuses employees who won't quit, if a religious leader abuses devotees, if a child abuses a pet, if a teacher abuses students, if a government mistreats illegal immigrants, we (society, possibly the legal system) would object quite strongly. Why does invoking the words "open source" excuse anyone from these expectations as if 'leading an open source project' makes someone above everyone else and outside the normal expected behaviours?
It is also a thing that you can't separate "don't scream abuse at people" with whining "why do I have to be polite?" as if those are the only two options, there's quite a range of rude responses which are not abusive - saying the code sucks, saying 'I wont read all that' - and there are polite responses which are blunt and not saccharine - saying 'I have the decision making authority and do not want to do it that way.', 'nope, PR rejected, do not try again', 'I am not taking PRs of any kind, I do not want to'.
Aside from that, as mentioned, this is not just any open source - he's a paid employee, this is not him sharing his work on his own server with the scope of him being rude or abusive limited to a few people; this is a hugely important worldwide system. The Linux Foundation is funded by companies who use Linux such as Amazon and Google. They employ people who work on the Linux kernel and have to be subscribed to lkml to do their jobs. The Linux Foundation benefits from the work they do and the changes they upstream. The companies donating money have shareholders and expectations of the companies they work with and charities they donate to. And presumably they have some ability to lean on their donations to ask for favours. All this happens under US employment laws and regulations on several sides. This presenting it as a trivial "if you don't like it, leave" is a deliberate and bad-faith oversimplification. It's the race to "person who cares less wins, and I'm a cynical nihilist so I care about nothing, hah!".
[1] https://www.penny-arcade.com/comic/2004/03/19/green-blackboa...
> This presenting it as a trivial "if you don't like it, leave" is a deliberate and bad-faith oversimplification
This is not an oversimplification, this is a fact that you don't like and prefer to ignore. It doesn't disappear when you close your eyes though.
A grumpy person made an open source project that by chance became successful. He didn't force all these people and corporations to use it and fund it, it was a free choice on their part.
What is he supposed to do now, change his personality to please random people on the internet? Why? How do you even see this happening? Or you think grumpy people should have been prohibited from writing code in the first place?
Furthermore he does not hold anyone hostage as you try to present this. Linux is not Linux Foundation. You can use and develop Linux without funding the Linux Foundation. It's just more convenient like that but again you are free to exchange patches outside of it.
People who walk in and say "nice project you have here, now you comply or we take it away from you" don't have my sympathy.
A quick sweep through recent messages in LKML shows that there's a healthy return to form for him, maybe with less curse words, but as succinct and impactful as it should be nonetheless.
A directive from Linus on the technical roadmap isn't going to solve anything. It could declare someone the "winner" in this particular thread or this particular issue, but lets the personality issue fester.
It's probably best for Linux to work through its technical issues in boring email threads which never get any attention on social media. And its organizational issues and its personality issues, for that matter.
So it's probably good all around that Martin has bowed out. If you reach for the nuclear button whenever the people you're working with don't give you what you want, it's time to go work on your own (nothing wrong with that, BTW). It's not really a question of who's right, but whether people can find a way to work together. That's quite difficult in a big project, so you have to both really want it and be good at it or it's just not the place for you.
Video isn't out yet, hopefully soon.
https://news.ycombinator.com/item?id=42968782
There's an average of 1000 messages per day, we get news of a drama-fueled thread like, three times on a bad year?
My ballpark estimate is probably low.
From what I saw, the project of writing the graphic drivers for ARM Macs was quite a success, so the door for those projects shouldn't be closed.
There will be fewer and fewer new C programmers with people instead taking up newer systems programming languages like Rust or Zig.
Or... Maybe it's good that they add a new (still 10 years old) language with security and DX improvements occasionally. 50 years ago, that language was C...
Momentum and legacy is hard to displace, when the new fangled thing attemping to be an improvement is not proven, and has unknown unknowns.
Is it? Do you think it's hindsight to use the only "successful" story as "the only way forward?" Look at the gas vs electric vehicles. Yes, displacing legacy is hard but not insurmountable when there is a clear improvement. I don't think anyone can argue in good faith the Rust is NOT an improvement in C.
so it is not about technical merits, but just some language religious thing? nice.
You're reading way too far into this. Linus has been publicly positive about the R4L project plenty of times.
Why spend all this energy on conflict and drama to no end? If one language/technology/group is so much better then just fork the thing and follow their own path.
I'm actually not defending the C guys, I just want to leave them alone and let "Nature" take his course, if they die on obsolescence, then they die. who cares..
If the Asahi team focused their efforts on Redox, with all the genius talent they they have, we could see an actually practical, usable implementation of Redox on real hardware; a potential daily-driver which would catapult the development of whole ecosystem - and that can only be a good thing.
I am sure most people involved with the Linux rust effort are also not problematic; these would be very welcome there.
OTOH, please don't let Redox be taken over by problematic people.
Hard to have too much drama if you have a handful of developers that do code changes, and no users to complain about any of your decisions.
There have been UNIX systems implemented, Pascal, Ada, Modula-2, Modula-3, as the most relevant ones.
All gone.
Also note that POSIX/UNIX certification requires a C compiler presence.
Note that many folks even forget that C++ was equally developed on the same Bell Labs group, and is probably one of the first examples of guest languages, making their best to fit into the platform, taking advantage of the ecosystem with almost zero friction, but never being able to control where the platform goes.
I don't think I can go with that one. C was created in the same period as people were trying to find a way to create a common platform, but C was more about trying to solve the problem of having a higher-level language that wasn't available for the low-end hardware (ie PDP-11, etc) of the time. Richie wasn't trying to reinvent the wheel.
He would have been happy to use other languages, but they were either design for large platforms which needed more resources (Fortran) or looking to be locked behind companies (IBM's PL/I). Richie considered BCPL, which at the time had a design that made it pretty easy to port if your computer was word-based (same size of bit-width for all numbers regardless of purpose). But, mini-frames were moving towards byte-based data and word or multi-word-based addressing. Plus, mini-frames had poorer hardware to make it cheaper, so typing on them meant more physical work.
A lot of UNIX design came from trying to use less: less memory, less paper, less typing. Richie tried to simplify BCPL to be less wordy by making B, but ultimately decided to jump to the next thing by making a language that would require as few keystroke as possible. That's why C is so symbolic: what is the least amount of typing to perform the concept? That made it pretty easy to translate to a fixed set assembly instructions; however, it hasn't had a symbiotic relationship with assembly.
If anything, it is the reverse. Just look at the compiler for all of the memory addressing it has to know. Look at any reasonably complex program of all of the compiler directives to see all the platform exceptions. C++ really took failure modes to the next level. My favorites is "a = b/*c;" Is that "a equals b divided by value pointed at by c" or "a equals b" with a comment? I left C++ a long time ago because I could take code that would compile on two different platforms and result in totally different behavior.
I think all of this drama has to do with the simple fact of there a bunch of people content to live in a one-langauge dominated environment and the head of Linux doesn't want to decide if that is or isn't the mandate; however, by not taking sides, he has effectively taken the one-language mandate. Rust needs to reimplement Linux.
That is a really bizarre comment, especially including a comment that is perfectly valid K&R C, and just as "ambiguous" in that. The answer is of course that it is an assignment of the value b to a variable called a, followed by a comment. "/*" is always the start of a block comment.
Since C99 (and since forever in C++) there is also the new style comment, //, for commenting out the rest of the line, and this in fact broke certain older C programs (`a = b//* my comment*/ c;` used to mean a = b / c; in C89, and means `a = b` in C++ or C99).
As for the actual syntax itself, I do wonder why they didn't use ## or #{ }# or something similar, since # was only being used for the preprocessor, whereas / and * were much more common.
Or maybe he just didn't care about having to use whitespace to disambiguate. The other piece of similarly ambiguous syntax in B is the compound assignment, which was =+ =- =* =/ rather than the more familiar C-style += etc. So a=+a and a= +a would have different meaning.
You surely aren't advocating that hardware predating PDP-11 for a decade are more powerful.
There is enough material that show had UNIX been a commercial product instead of free beer source code, most likely C would have been just another systems language in the mysts of time.
That's correct. The PDP-11 used for the first Unix system had 24KBytes of memory, and no virtual memory. The kernel and the current running process had to both fit in 24KB. This PDP-11 minicomputer was vastly underpowered compared to ten year old mainframes (but was also far less expensive). The ability of Unix to run on such underpowered (and cheap) machines was a factor in its early popularity.
BCPL was first implemented on an IBM 7094 running CTSS at Project Mac at MIT. This was one of the most powerful mainframes of its era. It had 12× the memory of the Unix group’s PDP-11, plus memory protection to separate kernel memory from user memory. One of the historical papers about C noted that a BCPL compiler could not be made to run on the PDP-11 because it needed too much memory. It needed to keep the entire parse tree of a function in memory while generating code for that function. C was designed so that machine code could be generated one statement at a time while parsing a function.
Linux was at the correct place at the correct time. It was the only free version of Unix-like OSes that didn't have legal bullshit to deal with. IBM and Intel's support also made GNU/Linux ecosystem successful, without them it would stay as an academic project. Being free meant that it had an advantage where price sensitivity mattered and dotcom boom and VC explosion is very sensitive to cheaping out and preffers suffering with less-than-ideal software. So Linux stayed popular while other ones died slowly.
C had a huge following and all OSes had to support it. Simplicity made it popular when average hardware at the hands of many academics and young professionals was very weak. Being written in C may have made things marginally easier but neglecting it for Ada or Pascal was a terminal mistake. Windows isn't Unix at all but it also had to support C well.
Had AT&T been able to sell UNIX, and naturally C, at the same price points as VMS, System 360, and many other contemporary OSes, and none of us would be talking about them today, other than history curiosities.
Instead we are left with UNIX haters handbook, and still trying to fix the security issues across the industry caused by C's adoption, the JavaScript and PHP of systems programming languages, both in adoption scale, and code quality.
Second, while OS X, and NeXTSTEP before it, are technically UNIX, they aren't seen as such by either NeXT, nor Apple.
The focus of the whole userspace experience is on Objective-C frameworks, nowadays also a mix of Swift and C++.
Steve Jobs was famously against UNIX culture, there was even a famous attendance of him at USENIX.
NeXTSTEP was based on UNIX, because Steve Job wanted to win the workstation market against Sun, using UNIX compatibility as EEE, bringing folks into NeXTSTEP and keeping them there with Objective-C development experience, Lotus Improv, Renderman and such.
So Embrace, Extend and Extinguish?
As for C compiler presence in POSIX, only existence of C-accessible APIs with specific structure are mandated, C compiler is optional just like Fortran runtime and compiler are.
https://pubs.opengroup.org/onlinepubs/9799919799/nframe.html
https://pubs.opengroup.org/onlinepubs/9699919799.2018edition...
https://pubs.opengroup.org/onlinepubs/015967575/toc.htm
And copying this from UNIX 03, the most widespread certification,
"A single configuration of the system shall meet all of the conformance requirements defined in the following mandatory Product Standards:
The product must be registered as conformant to the Product Standards prior to, or concurrent with, the UNIX 03 Product Standard registration."From POSIX 2017 edition https://pubs.opengroup.org/onlinepubs/9699919799.2018edition...
> On systems providing POSIX Conformance (see XBD Conformance), c99 is required only with the C-Language Development option; XSI-conformant systems always provide c99.
If XSI conformance is not asserted, only requirement is that C APIs and runtime libs for use by C programs exist on the system, and presence of C compiler is optional,
2017 POSIX had done away with including Fortran 77 in the same category as C, only providing an option for Fortran runtime libs but no longer specifying a Fortran development environment.
Also, I do not have relevant systems on hands to check, but as far as I know multiple Unix systems including behemoths like SunOS/Solaris shipped as POSIX compliant without C compiler.
Naturally UNIX Home users are also using a UNIX, and UNIX Pro, users have anyway a C compiler.
Also to note, exactly because nothing else is required, there used to be UNIX vendors, like Sun, that only included C and C++ on their base SDK. Fortran and Ada compilers were additional products to acquire on top of the SDK. Naturally most folks didn't even bother.
Aside from that, there are other benefits to Rust than safety: it's better at modelling data and states, as the now-infamous filesystem talk [0] outlined.
[0]: https://lwn.net/Articles/978738/
Maybe. 1. It may not have to be "Rust-level of safety" to be good enough to make Rust benefit less compelling. 2. Linux C is already a different languag than C, continued incremental changes might be a better way to get there than adding Rust even if it does become very different in the end.
> Also, if you're already doing codebase-specific patches to the language itself, many of the arguments around codebase portability that justify the use of C fall apart.
Sure, but Linux never had a "codebase portability" argument. It always had to be GCC C. It eventually made some relatively small changes to allow clang to compile it, the far bulk of that work being changing of clang to behave like GCC.
> Aside from that, there are other benefits to Rust than safety: it's better at modelling data and states, as the now-infamous filesystem talk [0] outlined.
Yeah, it's not only safety improvements that are in Linux-C.
cough* Cargo cough* /s
You cannot have safety or security when you download your code from the internet and this code is a moving target.
There is, and this is how Rust naturally works. If you look at its standard library, you will see a lot of unsafe code or libc calls hidden away under safe interfaces.
In fact, this is how all memory safe languages work, including Java, Python, etc: A small trusted base written in an unsafe language that exposes a safe interface (i.e. the interpreter, the JVM, etc), with the large majority of the code written over that safe interface (i.e. the Java/Python code).
Rust is used to make kernel drivers secure by providing a safe interface for them to use.
Its exactly what Linus said.
That is actually quite well put together. May be The language that introduce absolute control also induces zealotry and produce zealots.
However that doesn't happen with Ada. So that cant be the full explanation.
For that matter the C of Linux 10 years ago was not there to stay either, it has changed and certain features and practices are deprecated and dropped and others adopted. It's not the same C.
Take, for example, an 8-bit/byte store. Without BWX the sequence would be something like:
But with BWX, it becomes:People use and maintain them and they have very little impact outside arch/ nowadays so they're on the happy side of cost/benefit I guess.
I'm not sure if Alphas are even being made anymore, even 15-20 years ago.
Alpha's memory model has problems with providing atomic access to single bytes, which i'd imagine in a kernel is a bit annoying :-)
And then there's just the social aspect, m68k was used in the Amiga/Atari/Mac/QL/x68k, so there is a whole generation of us m68k fans who are willing to keep it alive.
Alpha has it's fans (me included!), but it's not exactly the same. So in a way it's no surprise it's slowly bitrotting away.
That required this smp_read_barrier_depends() through the kernel, but actually in recent years that has basically been subsumed by other concurrent access primitives that all the core kernel must use, so I think alpha is no longer much of a problem outside arch/alpha
And let's not be obtuse, some of those subsystem maintainers are staunchly opposed, so "it's up to them" is obviously an indirect way of saying "no rust". I don't blame those maintainers for balking at a whole new very different language, but Torvalds has a choice of telling them either "suck it up, buttercup" or "I hear you; rust is gone". Instead, he's just letting things fester.
> "suck it up, buttercup" or "I hear you; rust is gone".
where various levels of compromise happens.
Maintainers are people and people can change their mind over time. If rust was a huge success in large parts of the kernel and you still had a few holdouts, sure, you could tell them to adapt or go away. In this early stage, it's kinda up to rust people to show that both they and rust can work in this setting
So people are not allowed to hold positions and argue for them in public, or take actions that align with that position?
> I don't believe that was what the rust guys thought they'd be signing up for
It's not like there wasn't any existing precedence with C++, and many of the arguments I've read seem consistent with that history.
And that's a perfectly resonable position.
The maintainers of core subsystems are the people he trusts, at least trusts as much as you can in this space. He'll take their opinions before anyone else, since they know best about the subsystems they maintain.
To get Linux to overrule them you not only need to come up with very very convincing technical argument, you have to make sure you also posses the depth and competence required to maintain any such subsystem if the maintainers rage quit. Because you see, maintainers of these subsystems resigning is the bigger blow
But there were no technical arguments against the Rust wrapper. And in any case, the Rust wrapper isn't in that subsystem, it just uses that subsystem. Hellwig's argument was nothing more than "there shouldn't be a second language in the kernel". He had nothing specific about the DMA wrapper. And Linus has already approved Rust in the Linux kernel, so what's the problem? Why can't Linus put his foot down on an issue that he has already decided on?
Which is a valid viewpoint. Let's not pretend that's not a technical argument.
Having different technical views from yours isn't a crime, legally or morally.
> And Linus has already approved Rust in the Linux kernel, so what's the problem?
As an experiment, as clearly stated in the kernel docs. It's still up to the whole community to figure out how exactly to proceed with it.
https://docs.kernel.org/rust/index.html
> Which is a valid viewpoint. Let's not pretend that's not a technical argument.
So if Linus shouldn't overrule his deputies, and one deputy can completely block something in a subsystem that isn't theirs and has explicitly stated to do "everything in their power" to stop it, what exactly can the community "figure out" to get it to proceed? His decision not to get involved literally makes it impossible for the situation to change, so the confusion is why it's being phrased as if it's anything other than that.
If Linus were to come out and say "I changed my mind, I no longer think it's worth pursing trying to integrate Rust in the kernel due given the issues at hand" or even "regardless of my personal views, I don't have any desire to change the current system we have for how code gets merged into subsystems or who has the ability to block it, so I'm not going to overrule this", it would make a lot more sense to me, but by making it sound like there's anything left to figure out when someone with veto power has a stated intent to stop things from moving forward is just going to let the issue fester and produce more frustration on both sides. It almost seems inevitable that any future discussions will spiral out of control; there's no other way for it to conclude than either Linus overruling his deputy or the experiment just ending as a failure at this point, so he might as well just make that decision now rather than later.
It's valid for maintainers to reject a patch even if you disagree with the reason. Repeatedly causing social media storms to "shame" them for doing so, Marcan's own word BTW, isn't.
Rust is young and efforts to use it in kernel programming is even more so. It's completely understandable for wanting to take things slow and not be too quick to put it in places where there would be no going back. Everyone should at least be able to recognize that this concern exists, regardless of their opinions on Rust.
This is not what's happening.
Have you even seen the original thread? It wasnt about "taking it slow", he was trying to block R4L permanently.
Arguably, I've used it only once to contribute a kernel bugfix, and I was lucky enough that my patch got accepted as is. So I found the process pretty straightforward.
But even with iterations and revisions factored in, kernel work itself feels orders of magnitude more complex and cumbersome to me than a patch process based on a mailing list could ever be?
Just read the email.
> Maybe he knows he should, but he fears the shitstorm it will cause.
I always felt that the Rust community is creating a huge social pressure on lots of projects. Rust was more forced into the Linux kernel than being welcomed by Linus and many core maintainers. The pronounced evangelism (not a compliment!) in the Rust community is not only off-putting by being a form of non-violent aggression but creates real problems like wasted energy and resources. This is not generally true, as there're great examples of Rust being adopted from within projects. But also others where Rust was pushed from the outside, like curl.
In my opinion it's a failed experiment. The reason for the failure might not be on the technical side, but on the social side. On the other hand, if Linus wants Rust in the kernel as a way to get new, young, enthusiastic devs into Linux core development, than he should use his role and make a very clear statement as he's done before, like: "Everybody shut up and accept and welcome Rust as first class citizen."
- Endorse Rust with little reserve and over half of the C++ devs will feel betrayed and quit supporting the Linux project. They've been working on C++ for Decades and things mostly worked, so they won't pivot for a new language and way of developing for something that exists for less than 30 years.
- Ban rust contributions and the entire Linux foundation goes directly against some big players, like DARPA and other departments of the American government[1], which itself is a trend setter. Some big sponsors might also pull out and that ALSO removes devs from the project.
So, which decision would be so overwhelmingly more advantageous that's worth taking all the negatives of the other on the chin rather than trying to minimize harm and wait to see if either Rust software proves to be not so magically immune to memory leaks and vulnerabilities or if some tool makes the transition less contentious?
[1] https://stackoverflow.blog/2024/12/30/in-rust-we-trust-white...
You mean C? C++ has been dead and buried for years and there are 0 kernel devs thinking that C++ will ever be allowed in (that idea was killed in the 00s if I recall correctly).
I don't think the situation is quite as extreme as you're making it out. For example, the employers of Linux kernel devs are getting pressure to use Rust because of the push from within & without the industry. I think push comes to shove, most people have a stronger preference for their paycheck than for the language they work in.
https://lore.kernel.org/lkml/3465e0c6-f5b2-4c42-95eb-2936148...
https://bosslinux.in/bossmool
And I still think the culture clash angle should be taken more seriously.
An accomplished senior C dev can find good jobs writing drivers or microcontroller code more easily than starting over into a junior rust dev and being talked down by whomever joined the rust wave before them.
(which would be even more aggravating if the C dev is doing it since before the rust adopter was born).
LOL, lmao even.
Eh, that White House link is dead right now and I would not be shocked if whole department is purged soon, so who knows anymore…
Also, letting rust in doesn't seem to stop the personal attacks, case in point
I don't see it that way. Linus is conscious of not becoming a bottleneck on every topic; he doesn't want to baby-sit overly grown adults. I read most of the relevant LKML thread[1]. Martin did the unwise thing of escalating it on social media:
"If shaming on social media does not work, then tell me what does, because I'm out of ideas."
That is not the way to build bridges and relationships in a community! No matter how frustrated you are. He reaped the whirlwind for taking that destructive approach.
Also, Christoph Hellwig, as an established maintainer, totally missed the mark by using the highly-flammable word, "cancer", to describe Rust. It scorched the LKML and the internet. He should have showed more restraint and wisdom.
[1] https://lore.kernel.org/rust-for-linux/Z6YPfsDSNdRUskvp@phen...
And his viewpoint at the time seemed fairly agnostic - he enjoyed the passion on both sides but said nothing about what his thoughts were. This leads me to believe that he hasn't spent the time to think about the important issues on either side and make a decision (the failure of leadership mentioned in the parent comment).
Personally, I'm surprised Linus hasn't gone 100% in on Rust as he is normally very forward-thinking, so perhaps that has added to the frustration from so many kernel developers like Hector.
If there's a lot of people sceptical to rust, doing a limited experiment is one way to figure out if it's going to work. Rust people working in the kernel should act accordingly. Drama like this is not helpful
It feels like over the year he has been sort of beaten into submission both for his outbursts (which I've always found more funny than offensive) and the lobbying of the zealots of a certain relatively young programming language (which sometimes has a little taste of propaganda) against "memory unsafe languages".
At a minimum, all prominent developers would have to be convinced and ready to put a lot of effort into this.
As this was never the case, Linus should have put his foot down with a clear No, thus preventing the conflict and overall waste of resources we're seeing.
Rust devs would still be able to fork or otherwise (much better idea imho) work on their own kernel, hopefully with a much better design.
Redox is doing this, with a microkernel multiserver approach.
I have been thinking for years that the reason why Linux dont attack Rust like all other languages is that his close friend or close subordinate like Greg actually like rust. So rust as a language has huge leverage within the Linus decision mental model.
Not to mention the huge Rust gang both on the internet and around him. Friends that support Rust. Having the usual strong opinions of Rust like he had for C++ will obviously damage friendship.
We don't have a Rust-killer language yet. The closest one is SafeC++ (Circle), but it's still a single-dev proof of concept, and the C++ leadership firmly rejected it. Zig went in a different direction. Swift is adding Rust-like features, but it's unclear if that's going to be compelling. Ownership and borrowing is spreading to Mojo and Ocaml, but they're not kernel languages.
Even if there's a Rust-killer tomorrow, it will go through the same growing pains of rewriting everything and being treated as just a temporary hype. It will have to prove why use the new language instead of Rust that's already here, and had even more time to establish itself.
The type-system analysis of Rust is smart, but not restricted to the language per se, see https://github.com/ityonemo/clr. One merely has to have proper namespacing and necessary type info from generic code to do annotations and solve them. These things are solved in Rust via trait system.
Retroactively patching C to have namespaces will not work and same holds for generics, meaning concrete how to attach lifetimes to generic code.
> Zig went in a different direction.
There is stuff cooking for debugging comptime and better than lsp infos, but this is only wip and hearsay. Might be enough to write external static analysis or not.
Correct me, if wrong etc.
It's not enough to have just a proof-of-concept compiler that could match Rust's checks — that's where Rust was 10 years ago. Rust had time to polish its compiler, expand tooling, integrations, platform support, attract contributors, grow userbase, create learning materials, etc. To displace Rust of today you don't need to just match the old starting point, but offer something better by a margin large enough to offset the cost and risk of switching to a less mature language. That's the same problem that Rust is facing when trying to displace even more established C and C++.
We don't even have a C++ killer language yet. These things move very slowly.
C was better than assembly. C++ was better than C for GUI applications. JAVA has garbage collection and usually won't force you to fix your machine after a bad crash. Python is better than Perl for quick and dirty stuff. PHP lets you build a web service without much pain. C# is a better Java that also gives you better integration with Windows. Go does a good job with small quick running services. Lua is easy to integrate into programs.
I look at existing C codebases. They're usually well worn and work okay.
C++ codebases would probably be better rewritten in Go or C#
Go codebases? Switching to Rust so you can what exactly?
PHP? Keep using it or us Go.
I also feel like Go, C#, and Python are designed to be fairly easy for a noob to come up to speed. Where Rust is the opposite.
Yes, unsafe, as the name says, allows unsafe parts. But it is trivial to audit code for the usage of unsafe. Which means, everything else isn't. And it is there where the most common mistakes are made.
This is exactly the mistakes we also have in C and Rust people would do a little dance and take such bugs as argument why C is really dangerous and needs to be avoided. But rather obviously, mistakes can also happen in Rust and Rust does not "eliminate a class of errors" except when completely avoiding unsafe blocks. Maybe Rust is still more memory safe than C, I actually also believe this, but it is nowhere as safe as people like to claim and whether this is worth all the complexity is entirely unclear.
My point rather was: wherever you don't use unsafe, you are protected by the compiler from certain errors. Which I consider extremely important, that is why I am a strong proponent of memory-safe languages.
Now, if there is a question whether Rust requires you to use unsafe to often, that would be a valid technical critique of Rust, but that didn't seem to drive the Linux discussion.
The way I heard it, the Rust's type system, async implementation(s), they way lifetimes just keep propagating once you start, and its macro languages are way more engaging, thus Rust must be superior.
No because its Rust, but because it's a bad idea to use more than one single language across the entire code base.
I also am surprised that Linus has not ended this folly.
If Rust wants a Linux kernel it should make one.
The problem with Rust in the kernel is that the kernel has historically eschewed strong internal abstractions. The Linux kernel has no principled abstract architecture in the same way that Windows NT does; it has evolved very organically and even some of the most foundational subsystem APIs regularly see refactorings that touch almost every corner of the kernel.
The latest dispute (if it could be called that) regarding Rust was Rust building abstractions around the DMA interface. There's nothing wrong with this, per se. For Rust it's a necessary chore. But when you build complex abstractions atop something, you're either ossifying the interface or building a sand castle. If we're being charitable, some Linux developers felt like this was pressure to ossify the existing abstractions. Rust developers, OTOH, promised that they'd take full responsibility for any future refactoring, implicitly admitting that they understood they were building a sand castle.
How do you bridge that divide? Because of the lack of hard architectural line drawing in how Linux is developed, the norm is that both redesigns and refactoring are in many respects highly cooperative (notwithstanding the bickering and friction). A subsystem maintainer contemplating a redesign takes into consideration the burdens on other users, and how a redesign might be incrementally rolled out, if at all. Conversely, users of interfaces know--or should know--to take into consideration future potential changes in an interface when relying on an interface for their subsystems. It's a constant back-and-forth, give-and-take, but also messy and chaotic. Transparency in source code is key--this kind of development would never work in commercial projects across binary interfaces. Yet in important respects that's what the interface between C and Rust is like--opaque--especially when developers on one side aren't intimately familiar with the semantics of the other and how they translate, if at all, across the boundary.
Now here comes Rust, which has spent years putting into place the infrastructure just to get some drivers going. Rust as a language demands careful architecture and line drawing. It's no surprise that much of that initial infrastructure effort, excluding the build, was expended on building towers of abstraction. Refactoring can be painful in Rust when it involves very low-level changes in semantics (the kind that are common in kernel development), and while there are tools to help address that, they don't work well, or at all, outside of Rust. There's a huge impedance mismatch between Rust and historic Linux kernel development. In user land, developers' experience is that Rust is relatively easy to interface with C libraries. But that experience is primarily interfacing with public APIs, those public APIs have always been quite stable, and user land libraries (at least the good ones) are designed to be, as much as possible, blackboxes from the outside. Abstractions that leak tend to be fixed abstractions, like file descriptors, etc, that are typical for the environment and rather predictable.
That situation with user land C FFI is utterly incomparable to how interfaces evolve in Linux. The clash between these worlds, at both a technical and cultural level, was inevitable. Heck, it was evident from day 1. This doesn't make either side right or wrong, and I'm not trying to suggest that the Linux developer community can't figure out a path forward. But it's a difficult problem on many levels.
I don't know what this is about. In my experience, refactorings that change the semantics of APIs are much easier in Rust than in C. E.g., change assumptions about the lifetimes of pointers passed into APIs: the Rust compiler will tell you where you need to change anything; the C compiler will happily compile your code and you'll corrupt memory at runtime.
And there are more subtle issues. From the perspective of C code, Rust looks and behave as if it assumes strict aliasing, a consequence of the borrowing rules--a mutable pointer can never alias. But the Linux kernel uses -fno-strict-alias (i.e. any pointer can alias, regardless of type), so a subtle change in C code which works fine for the kernel could silently break Rust code if the C-side developer wasn't aware of these subtle nuances in memory models and how they were expressed in the unsafe wrappers. This might be a totally contrived scenario[1], or it could be very real given the tower of abstractions built on the Rust side over the C APIs, which might overspecify certain semantics to fit "cleanly" (i.e. best practice) into the Rust model.
Which points at another issue: all of these hypotheticals might be (probably are?) overblown. But over the past 2-3 years, with the exception of a couple of high-profile drivers not yet mainlined (AFAIU), the vast majority of the effort on the Rust side has been building towers of abstraction. In almost any open source project, C or otherwise, a newcomer who starts writing towers of abstractions rather than concrete, usable code would be shooed away. There are reasonable justifications for why Rust has been doing this, yet its also understandable why this might draw suspicions about the practicality and utility of mixing C and Rust in the kernel. But either way it means that after all this time people are still largely arguing over hypotheticals.
[1] Or entirely wrong. Maybe kernel Rust is using flags to ensure aliasing optimizations can't happen. clang (and thus LLVM) supports -fno-strict-alias, but AFAIU alot of Rust code massaging happens on the Rust (MIR or equivalent) side.
Is this wrong? https://doc.rust-lang.org/nomicon/aliasing.html Specifically
> In the previous example, we used the fact that &mut u32 can't be aliased to prove that writes to output can't possibly affect input. This lets us cache *input in a register, eliminating a read.
C/C++: behavior for which this document imposes no requirements
Rust: is not bound by any specification
But that's just a wording difference, not a semantic difference.
There are some instances where Rust and C/C++ use similar words to mean different things, but that's also changed over time. For example, Rust used to use rvalue and lvalue, but has moved to
"place expression", defined as "lvalue" in C and "glvalue" in C++
"value expression", defined as "rvalue" in C and "prvalue" in C++
The only reason to not use the C++ terms here is that these are the only two value categories in Rust, and it's unlikely to need all of the other three that C++ has.
You're not wrong that there's stuff called the same but has different meanings, for example, "reference," but what can you do.
And this is the reason why it's always regressing and never moves beyond alpha.
One language per repo rules makes sense when you can have many smaller repos, but for something as immense as the Linux monorepo it's really limiting. Especially considering the lack of desire to add stable interfaces from which other repos could operate independently.
His reprimand is a clear signal that he won't tolerate brigading. Marcan was making a pretty blatant attempt at using social pressure to influence decisions.
Oh and I got this quote for you:
> Linus Torvalds admonished the group that he did not want to talk about every subsystem supporting Rust at this time; getting support into some of them is sufficient for now. When Airlie asked what would happen when some subsystem blocks progress, Torvalds answered "that's my job".
Source: https://lwn.net/Articles/991062/
Do your job then, Linus!
No, never! That's actually one reason I don't use Mastodon, it's extremely common. Isn't this the guy that blocked HackerNews links to the Asahi Linux homepage because the moderators wouldn't do his bidding?
Yup, that was Hector Martin (marcan) as well.
> Added some clarifications in bold, because Reddit users having enough reading comprehension to understand what Christoph said and why it's exactly* what I described with other words is apparently a Lv.100 impossible challenge boss.*
https://web.archive.org/web/20250206022420/https://social.tr...
> And if you're wondering why you didn't realize this: It's impossible to change people by telling them they're wrong. What does tend to work is explaining different perspectives, so that they can figure it out themselves. And sometimes that's just way too subtle to ever register.
https://chaos.social/@sima/113961285815637787
> when you're that harmful with your calling out, eventually I'm going to be fed up, and you get a live round shot across your bow and if that then causes you to ragequit, because you can't actually deal with the heat you've been dishing out coming back around the corner: fuck off
>or as Dave put it "Being toxic on the right side of an argument is still toxic, [...]"
(that second comment made apparently without any sense of irony re: the first)
The meaning of
> "Being toxic on the right side of an argument is still toxic, [...]"
Is very straightforwards. Toxic behavior is toxic behavior. Sima shouldn't lash out in "toxic" ways even if she thinks she's right.
Otherwise shouldn't Hector be given grace because "his buttons were pushed until he exploded"?
Like, you fundamentally can't have it both ways. Excuses for Sima's comments work for Hector. Condemnations of Hector's comments apply to Sima. Anything else is a double standard.
Sima's responses can be excused. Even Hector's initial frustrations and his reactions to it can be excused. Hector's continued public reactions and escalations, however, are a different story and the reason folks are piling on him.
Maybe the problem IS marcan, as Linus suggested.
If you do things that are in the public interest, people are going to have opinions about what you do and on a wide spectrum. If you can't handle that, you probably shouldn't be doing work that's so public and visible. Especially something like maintainer work that is inherently social.
[0] probably: https://news.ycombinator.com/item?id=33789940 , though you could look at any of the big 2022-2023 asahilinux.org discussions and find something flagged/dead
Or is it just cause someone said so.
To respond to that by trying to cut of access to any place where many people exists is a questionable approach.
And judging people simply by from where they arrived in a place is also questionable tactic one that we should not tolerate in real live.
Otherwise I would suggest that it says a lot when downvoting of comments is not understood as disapproval. And that it is a big warning sign when public devs/maintainers hallucinate hostile intentions to other communities as a whole.
This is something you have to put up with some amount of if you do work in public, just like if you were a public figure or celebrity. Being a kernel or even package maintainer is like being a politician.
It sucks, but if your response is to cut off that channel of opinion _entirely_, that says more about you than the people you're silencing.
If something violates HN Guidelines, flag it and dang will see it. If there's anything that should be blatantly obvious by now it's that HN's moderation staff does not have the kind of alt-right bias suggested by your quote.
Also denying links to their site isn't equivalent to "leaving the room". It's more like demolishing the room entirely, given the way that HN works. If your site can't be linked to it can't be the topic of discussion.
It has nothing to with "not letting assholes in". Asahi Linux doesn't have a discussion board.
To your third point, also no. HN guidelines keep the content of our posts relevant to the topics they are in. They also guide us to link to original sources, not archive links. Both of these mean that if you can't link to Asahi Linux content, it can't be the topic of discussion unless for some reason it's otherwise newsworthy and was posted elsewhere.
How does blocking HN from linking to a site silence discussion on HN? Because, as you say, "100% of the discussion was happening on HN" which seems to imply that blocking HN from linking didn't actually silence the discussion.
> Both of these mean that if you can't link to Asahi Linux content, it can't be the topic of discussion
You can link to it - you just get the "HN referer" block page just as other people get other block pages (eg. [0], [1]. Haven't noticed people moaning about how those sites are silencing discussion on HN, mind.)
Copy and paste the URL and you can read the link perfectly happily[2].
[0] Much like many of us in Europe get block pages for sites in the US who can't be bothered with GDPR or the cookie law.
[1] Or those of us who aren't subscribed to the various news sites which show a paragraph before putting up a blocker.
[2] Or someone pastes an archive.ph link.
People whine about GDPR blocks and paywalls all the time. But also, clearly, those sites are not specifically targeting HN. It's not the same thing.
And to answer your question of "who?", marcan themselves based on marcan being the one to block HN links.
But more generally, the majority of people posting online (especially streamers, content creators, even just twitter posters) these days seem to be very thin-skinned and will claim that any amount of pushback that they get for their words or actions is an organized harassment campaign.
Granted there are acceptable methods within that, and not acceptable.
i.e. no one would consider it acceptable for me to go on reddit and start ranting about a Hacker News username, link the thread and argument, and imply either implicitly or explicitly that they should go and join the argument.
Imagine if the discussion would have started with an article like this. Patch probably would be merged already:
https://lwn.net/SubscriberLink/1006805/f75d238e25728afe/
Not really. It's one thing to discuss these things directly in the proper channels, namely the mailing list, but it's another thing entirely to make childish, passive-aggressive posts on not-Twitter about how anyone who disagrees with your actions is trying to "sabotage the project" and trying to rally your followers to cancel them on the grounds of "Code of Conduct violations" (once again proving that "Codes of Conduct" are little more than tools to enable cancel culture).
He himself acknowledged the fact that what he did was childish and embarrassing by deleting his entire Mastodon account.
Edit: For further context for Linus's reply, there's http://web.archive.org/web/20250206022420/https://social.tre...
> As for how to move forward, (...) Either Linus takes the pull, and whatever Christoph says is irrelevant, or he doesn't, and R4L dies. Everything else is a waste of everyone's time and energy.
It does look like maintainers should have a "disagree and commit" mentality at some point, whatever decision they end up making.
I thought Rust in Linux was evaluated, discussed and agreed upon years ago. The fact that there are people still trying to sabotage it shows that they don't follow the "disagree and commit" principle.
They are more like "disagree and make the others lives a living hell until they bend to my will".
I've seen Linus talk about it in one of his public chats with Dirk Hohndel as an interesting experiment that might succeed or fail, or that's the impression I got. I'm not sure everyone else got that memo.
It is not some million dollar RSUs getting vested by year end either way. A lot of them working for the love of craft and prestige. If they can just rollover on a technical disagreement then corporate office job is more suitable than open source OS kernel.
Edit: related email by Hector: https://lore.kernel.org/rust-for-linux/c5a49bcb-45cf-4295-80...
Marcan goes full nuclear every other time someone disagrees with him. He's very much the "if it's not my preferred way then we might as well not do it at all"-type of engineer (many of us have worked with those people).
DMA is needed for an overwhelming number of useful drivers.
If you can’t use DMA from Rust, then you can’t really properly evaluate the usefulness of Rust, hence the effort is basically dead.
Whether that's a good or bad approach is besides the point. It's what was suggested as an alternative, and clearly it's something that would work. "You can't use DMA from Rust" is just not true.
Everyone knows it would increase maintenance burden, decrease reliability, and increase the amount of apparent churn of rust code in the linux kernel.
There is zero good reason to duplicate that code and refactor it later.
Regarding the context:
> A redundant wrapper is such a trivial mechanical problem to solve or work around,
The DMA maintainer explicitly NAKd a wrapper. He insisted that each Rust driver copy and paste the needed Rust code.
He even explicitly stated the reason was to ensure he did everything possible to keep C the only language in the kernel.
And after that driver is in use for a while and a million users all depend on it because it works so good, other developers will all on their own start asking "why are we diing this this stupid way? I think the original argument is no longer valid, or we can see now that it never was valid. We should revisit that."
Or as more rust devs work on more modules that each need some similar redundant boilerplate, a larger number of individual devs who each ask the same "hey, can we please get at least this level of concession to have a shim somewhere we can interface with instead of all this fragile tight coupling?" When that grows to become a respectful request from many, including users, instead of a disrespectful demand from a few, you get a different result.
But that is step 2. The opportunity for step 2 sometimes simply will not exist without first going through a step 1.
You want in? Yes but the terms are shitty. Yeah, so, you don't want in? It's obviously OK with most of the kernel devs if the rust devs decide this is not rewarding and go away. They are not eagerly welcoming to this particular development. And they don't have to be. How welcoming would rust developers be to c developers demanding to rewrite cargo in c? Go work on redox and make it so great it takes over and replaces linux by simply being the better choice while being equally free and at least as well managed and clearly visioned.
"Congratulations, you're right, and nobody cares."
Now what? Just complain that the kernel isn't hospitable to Rust, and hope 15 years from now we're all using some Linux-compatible kernel built ground-up in Rust?
I genuinely want to know where you go from this position.
I think Rust in Linux makes sense, but honestly, Rust doesn’t need Linux to be successful, and I barely use Linux personally. If they decide Rust for Linux is not a thing, that’s for the folks who work on and care about Linux to deal with. This isn’t my fight, I am just observing.
I’ve been primarily a Windows user for many years now, but I do use some WSL. My main OS is already shipping Rust, and in the actual kernel, without all of this wailing and gnashing of teeth. (That said I respect the approach Linux is taking here, I don't think it's inherently bad.)
Oh, and honestly, what I believe is happening here is just that, from Linus's perspective, folks should know that because this isn't in Hellwig's part of the tree, his NACK doesn't actually matter, and he'll just end up pulling this patch in anyway. There's no need to intervene because there isn't actually obstruction going on. The internet is just going wild about this drama because they fundamentally misunderstand how kernel development works, and because people are slinging mud on the LKML. That's why he only commented on Hector's behavior.
I can see that perspective, though I would prefer a different management style, but that's also why (among other reasons) I don't care to contribute to the kernel.
https://lwn.net/ml/all/20250131075751.GA16720@lst.de/
Maybe you can try to read what Christoph Hellwig said first.
Efficiently collaborating on large distributed open source projects like Linux is as much social activity as technical. For people like Kent Overstreet or marcan and many before them this is apparently a hard thing to grasp and they have been failing badly at following the process, building consensus, earning respect and trust of people from other subsystems, that kind of things. To me it looks like that for Linux big part of R4L experiment is to specifically understand whether Rust people can convince key stakeholders that R4L is good idea and get their buy-in and that is why he doesn't attempt to force it. Also, what is he gonna do to the reluctant but key maintainers? Refuse to accept anything from them until each of them shows him a repo with all Rustlings exercises solved to ensure they are ready for Rust or what?
> And it's quite out of character for Linus not to have a blazingly clear opinion.
Linus tends to have clear opinions on things he is world class in. He is technically brilliant and very knowledgeable in most of the low level systems things but likely not in Rust, so it is understandable for him to just keep being open minded about it and let the chips fall where they may.
> As a pilot program, R4L should have graduated or ended a long time ago. After several years of active development, its status remains unclear.
Which is absolutely normal for the kernel. You can have a driver spending years in staging or RTLinux taking 20 years to get there. It is totally expected for such a disruptive change as introducing new (and quite complicated) programming language to take a few more years to reach maturity.
> Arguably his reprimand of Martin is a clear signal that he will never show Rust any favor, but he hasn't said anything explicitly.
Not it isn't.
> decision has backfired horribly
> place responsibility for the drama on Martin's shoulders
> Imagine how much time and energy (even just Martin's alone) could have been saved if Linus had just said "no, keep it downstream".
HN crowd and random JavaScript-kids on Reddit are only hotly debating this because the "drama" has the word "Rust" in the title. For Linux maintainers it is just another day at the office, nothing much to see here honestly.
This is the entire point. This has been DONE. First its "lets see if you can build a good driver", now its "ew rust". The maintainer of the DMA subsystem is showing how they're actively trying to make sure Rust doesn't make it in. .
Blatant NIMBYism is the problem here and you cannot reduce it by accepting everything.
- Send the series directly to Linus since there is no code that Hellwig is maintainer of is actually being changed by it and let Linus decide whether to ignore Hellwig's nack. Linus may have done so before, but likely not after marcan's public meltdown.
- Copy/paste the code to every driver that will be using it. If it becomes useful, it will cause more pressure on Hellwig down the road because people will question why every change in code that is being wrapped by this is causing a fix in 10 different copies.
People here and on Reddit who are unfamiliar with the Linux development process but are attracted to the "drama" because it involves Rust somehow keep missing it.
Which Chris did doubt, as a way to gatekeep Rust (as you misrepresented, and which is clearly visible in the LKML thread).
regardless, back to the other stuff: First point: Which is what was suggested as well in the LKML and still does not really solve the problem, which is not TECHNICAL but POLITICAL. Second point: Obvious, and wasteful, and again is thus a political move which is the entire point of this entire saga. It isn't about drama, its about the political aspect of the kernel dev being tiring and wasteful.
Can you provide the exact quote where Hellwig is suggesting that it is impossible to write a driver in Rust? No, you can't? So who exactly is misrepresenting here?
> regardless, back to the other stuff: First point: Which is what was suggested as well in the LKML and still does not really solve the problem, which is not TECHNICAL but POLITICAL. Second point: Obvious, and wasteful, and again is thus a political move which is the entire point of this entire saga. It isn't about drama, its about the political aspect of the kernel dev being tiring and wasteful.
You are shifting the goalpost from this making R4L "dead" to the way forward being "tiring and wasteful". It doesn't look like you are arguing in a good faith so I won't participate in the discussion with you anymore.
It's a failure of leadership to not intervene when discord threatens the group. He should weigh in, or make sure that someone else who has mutual trust weighs in.
In youth sports, something similar happens when referees fail to call fouls on rough play. Players naturally test the limits and then others recognize the lack of protection and retaliate until it gets really out of hand.
Nothing in that particular "drama" threatens Linux kernel maintainers as a group. Multiple solutions were proposed, like just sending the change directly to Linus bypassing Hellwig or copy/pasting the code to each individual driver for now. Marcan having public meltdown in that thread probably makes option 1 no-go though and doesn't improve R4L standing with the skeptical group of maintainers.
> In youth sports, something similar happens when referees fail to call fouls on rough play. Players naturally test the limits and then others recognize the lack of protection and retaliate until it gets really out of hand.
For better or worse the social contract in LKLM is not like what a lot of Rust people used to where you come in with furry avatar and pronouns in your profile, then cry for mommy to enforce CoC on first signs of conflict. Basically, extending your analogy, you don't come to an American football match expecting the referee to enforce basketball no-contact rules.
This is actually not limited to youth sports, you can even see it happen with professional athletes.
It's a very common human reaction when participants feel like the rules aren't getting enforced. For all ages. Which only reinforces your point.
Yeah, but that's because Linux was actually built with g++ for a few versions! The opinion was informed by experience, not an a priori thing. And it was likewise extremely controversial at the time. And eventually they rolled it back out and gave up.
Maybe that will happen with Rust too, or maybe not. But The Process, such as it is, is working today the same way it always has. They try stuff and fight about it, and eventually a winner is clear and a consensus emerges. And, yeah, there are losers, too.
He probably didn't want to end up like Stallman.
People change. As you get older, you might find you no longer care that much about subjects you previously had very strong opinions about
https://github.com/subsurface/subsurface/commit/1b16d570a1b6...
For example: https://gist.github.com/rayvoelker/c5f480f46c80a7a3c22386b29...
Disagree. These things take time. Linus knows that, and as I see it, he's giving it the time it needs. "After years of active development" we've only recently arrived at a point where actual driver development in Rust is possible.
> We all know [Linus'] stance on C++
Yes. And looking back I think that was a good stance. C++ is not for kernels: the language is too big, containing features that don't fit well with kernel development, thereby inviting all kinds of discussion not conductive to kernel development.
Rust is another story. Rust has potential to bring benefits to the kernel. I think Linus knows that.
Off-topic: I'm looking forward to an --largely automated (maybe with use of LLMs)-- port of the kernel in Zig. Just because I think the developer ergonomics of Zig are so much better than C. Not holding my breath: in 10 years or so would be nice.
That's a broad generalization to make.
Nintendo's custom OS (Horizon OS, used on Switch and a previous version on 3DS) is almost fully written in C++, including the entire kernel and all drivers.
I agree with you that C++ has plenty of misfeatures. Fortunately, compiler vendors make it fairly easy to dodge the bad parts of the language.
I'm not sure if we can still call it C++ in those cases. C++ is more/less a superset of C: we need to know what style of "C++" we're talking about.
Both OSes are huge C++ codebases. Features being disabled or forbidden is a non-userland thing (basically only because resources are constrained. 20KB of exception runtime bload isn't the same thing when you only have 200KB of available RAM vs. when you have 20MB+)
My opinion (and the opinion of people using C++ in such constrained envs.):
* C++ (the language itself along with stuff like <type_traits> and other freestanding headers) is the best thing since sliced bread. So many ways of reducing boilerplate while both writing safe code (RAII) and being mostly in control of produced asm
* most of the other parts of the stdlib are defective
* the committee process sucks, but fortunately compiler vendors allow us to dodge their bad decisions (making #embed available for C++, -fno-exceptions, etc.)
Imagine going to a project like Rails and trying to convince them they should use C# instead because its better than their language and everyone is wrong. Then if they refuse to change you start going on social media shit posting how all of them are wrong and and they should use the language you decided is king.
I think Linus was happy for people to use Rust peripherally, but then they needed changes to the kernel and slowly wants to infiltrate every other project to become rust dependent. This didn't sit well with other maintainers as they use C and arguably don't want or need to deal with Rust. The same they don't want to use Zig, V or C++. You're welcome to develop your driver in Zig, but don't expect others to change their code for you so you can be happy.
> How about you accept the fact that maybe the problem is you.
> You think you know better. But the current process works.
> It has problems, but problems are a fact of life. There is no perfect.
> However, I will say that the social media brigading just makes me not want to have anything at all to do with your approach.
> Because if we have issues in the kernel development model, then social media sure as hell isn't the solution. The same way it sure as hell wasn't the solution to politics.
> Technical patches and discussions matter. Social media brigading - no than\k you.
> Linus
The difference is that he is a little bit more diplomatic than he used to be.
But why someone want to push a language into someone else's kernel? Fork your own, if you want.
Further, this attitude of "Rust is clearly superior, so what's the holdup" is itself a holdup. You can't expect people to just spend their time learning a new language just because it's there, especially professionals with personal lives. These people do serious work, on a codebase that millions of people around the world, including virtually every tech company, relies on in some fashion. That's not a game. It's "serious business."
Serious business doesn't just chase something because it's new and hot and solves a certain class of problems (while simultaneously introducing its own set of problems).
Nothing is a panacea (yet, I suppose). This ship has been sailing for 30+ years. So many millions of man-hours have been put into it that people are justifiably cautious.
Now, all of that being said, I read the DMA maintainer's comments a few days ago and I thought he was being unreasonable, however, he is correct about the external dependency on his code. Even if the Rust DMA wrapper is kept completely separate, under a separate tree, he would still have to contend with the fact that any changes he makes might influence that wrapper and all the code that depends on it. So now, even if they claim to maintain the wrapper 100%, he is still beholden to all those downstream developers that rely on the Rust DMA wrapper's functionality, because if he breaks their code, he knows it'll cause a shitstorm. It's easy to say you'll maintain something 100% and the upstream guy doesn't have to worry, but time passes, things change, and all of a sudden, his hands get tied because it'll impact too many people. That's just reality.
Truth be told, I would eventually suspect some (or maybe many) Rust developers will migrate to a new project, because the rate of change is not going to be fast enough to ever satisfy them. And that's understandable. People want to make an impact, especially when contributing to an open source project (and doubly so on an unpaid basis).
Unfortunately I don't think Redox is the answer. UNIX and its clones/derivatives have had a long run, but anyone who wants to create the next big thing is not going to want just another clone of UNIX, even if it is in Rust.
We have seen the enemy. We understand the threat models and know far more about virtualization, containerization, sandboxing, etc., just by virtue of having had to dogfood these technologies for the last 25 years.
The next big thing (if there is one), will likely be something more like a cross between the Windows world (where ACLs rule the roost, and centralized management is built-in), UNIX with its CLI focus, process composition & command familiarity, and something like L4 which has unforgeable capabilities built in and a formally verified kernel.
Or we'll just go back to a modern day version of the UNIX wars, lol. Something, something about history rhyming.
It is the explicit policy of the project, and was repeated in the thread, that the Rust folks are solely responsible for fixing any breakage. There will be no shitstorm.
I understood/understand the representations, and I am sure they are made in good faith.
At the same time, I also understand the reality of having the things you do seriously impact the work of others and the types of issues that can cause.
I did state that I was leaning on the side of him being unreasonable, but also that I understood the concern. Nothing more, nothing less.
It was a fine position to take back when introduction of Rust into the kernel was still very much a discussion point. However, the discussion is over, Rust has been accepted into the kernel. This entire struggle has been kernel developers sabotaging other kernel developers.
This infighting is only going to hurt the kernel in the long run. Every time this "discussion" comes up, I walk away with the feeling that Linux kernel developers are unreasonably hostile and impossible to work with. It makes me wonder why new people would ever bother trying to contribute anything.
That said, using social media to cause drama when a Linux maintainer is being an ass is just as stupid, if not worse. Both sides of the conflict are in the wrong here.
Suppose you want Rust, just not a single Rust driver using PCI. But CONFIG_PCI and CONFIG_RUST both selected will cause the PCI abstractions to get built anyway, even if not a single driver using them is selected. Then if the PCI subsystem introduces a change but the Rust counterpart fails to follow it fast enough, the build will break for the kernel as a whole.
This was illustrated with an example in that email thread.
I have some sad experience with polyglot projects. Unless you enjoy pain and drudgery, it’s an extremely unrewarding thing requiring very careful treading.
It's not. Certainly not until Linus says it is.
> Rust has been accepted into the kernel.
As a limited experiment. This kind of drama may be an indication that the experiment has failed and should be rolled back.
Well, this is your take, as you explicitly wrote "I walk away with the feeling". My take is: The kernel developers are the ones doing the actual work, which legitimates their opinion of doing things. If too many people aren't happy with the way the linux kernel is developed, they are free to fork it and develop in the way that they see fit.
Luckily, the kernel seems to be doing fine.
Both sides of the argument are kernel developers here, though.
And that particular side was told by Linus Torvalds himself that his way of Social Media brigading is inappropriate for kernel development, and that the current process works.
I choose to believe Linus. His work on and guidance of the kernel used to and still does work pretty great.
edit: I may have gotten some things confused, please see below
We're talking about a developer, and a persona they created. Yes, they haven't outwardly said they were one and the same but it's pretty obvious. There's nothing to joke about and no feelings to be hurt here.
The DNS for asahilina.net points to the same servers as marcansoft.com.
Their KDE setups are oddly similar (the same).
The list goes on. Is it circumstantial? Sure...
If it quacks like a duck...
The first line of your Google document, written by "Asahi Lina", confirms it straight up:
> Unfortunately, on August 1st, Luna publicly: Doxxed me with a real-world identity
You should verify that reference for yourself, archives of what Luna said are readily available on the internet. I can confirm that what Luna said on August 1st, 2024, is the same thing she's saying today: Hector Martin is Asahi Lina.
The dossier corroborates Luna's claims.
(Also, what kind of person has a dossier ready to go if their contributor goes rogue? A controlling and manipulative person, that's who.)
We don't know who "Jia Tan" is, nor "Jigar Kumar", but we know that the person, or group of people behind these identities and others, used sockpuppetry to bully Andres Freund into giving them control over xz-utils, and we know what they did with that access. Even if pseudonyms are accepted, there should be zero tolerance for sockpuppetry in the Linux Kernel. If Hector Martin quits (https://lore.kernel.org/lkml/20250207-rm-maint-v1-1-10f069a2...), the personas/pseudonyms/avatars/characters of Hector Martin should quit too, but "Asahi Lina" continues to post on LKML.
When your argument is "a person said it so it's probably true", the natural next step is to ascertain whether that person is credible or not. That's not an instance of the ad hominem fallacy.
You know this.
You also know the document you linked affirms that "Asahi Lina" (not a real person) did not like being "doxxed" on the date that Luna said Asahi Lina was Hector Martin.
What I take from that is Hector Martin wrote the document. Do you disagree?
The document you brought up says "Unfortunately, on August 1st, Luna publicly: Doxxed me with a real-world identity". On that day, Luna said Asahi Lina was Hector Martin. Discuss.
It doesn't refer to providing the WRONG identity, as that wouldn't break their pseudoanonymity. You, hananova -- are the QUEEN OF FRANCE! Did I doxx you or not? I don't believe I did.
You can't have it both ways. Either Hector Martin is Asahi Lina (which he is), and Luna revealed this to Martin's chagrin, and Martin published a document to try and trash Luna's reputation as a clumsy attempt at damage control, or Luna didn't reveal Martin's barely-concealed secret and no need to publish the document.
By publishing the document, we know which interpretation is correct.
Eventually a lot of these people are going to age out, retire, or otherwise move on. I do think there will be a crisis moment at some point in the future.
I used to know C. It was my first language, and I spent a fair bit of time in it, but that was before compilers started to treat undefined behaviour as an excuse to break reality.
Arguably I'm not smart enough, or disciplined enough, to write C. This may be the case, and therefore I have naturally focused on other languages. Rust, to no-one's surprise, is my current favorite. I've never contributed to the kernel — for more reasons than just the language — but the language would be reason enough on its own.
C programmers are getting rare...
There’s plenty of people who write C, there’s plenty of newcomers who start writing C and if they’re willing to, they can find guidance, mentoring, and tooling to improve their skills. If that’s not the path you want to pursue, that’s fine. But C isn’t going anywhere soon and if you go to any university/college, there’s lots of C being taught and lots of people eager to learn.
the issue here is whether or not the broader community would ever seriously consider using an alternative, and whether contributors, particular commercial ones writing drivers for products, would ever agree to maintain two versions.
You need some extraordinary evidence to claim things like that.
To stretch things a bit, it's like saying, while male dominated the field of engineering in the 60s (and still do), it was exactly that kind of environment that made it possible for humans to get to the moon. Can you actually prove it? Really?
It's hard for me to imagine using git will slow down kernel development compared to sending patches in emails.
No. It's a legitimate possibility. Maybe it wont happen. But maybe it will. There's a reason that military training is meant to be hard though, and not filled with comfort and affordances for personal feelings.
> To stretch things a bit, it's like saying, while male dominated the field of engineering in the 60s (and still do), it was exactly that kind of environment that made it possible for humans to get to the moon. Can you actually prove it? Really?
No human has been back to the moon since that male dominated field sent them there. And when they added women, they couldn't produce a shuttle that could work without huge budget overruns, or reliably. And the only example of a real surge in a return to space, is run by an asshole dictator at Space X.
> It's hard for me to imagine using git will slow down kernel development compared to sending patches in emails.
No, that definitely worked out great. It was created by a gruff guy who was an asshole to everyone, and wrote the basics of Git by himself in a week.
After that, Greg KH stepped in (since he was soft asked to help earlier in the thread with an @) to reconfirm that what seems to be the general policy for r4l is followed (aka it'll be a separate file with its own maintainer), with the subtle implication that it would probably just get merged as a separate patch to Linus directly, the complaints of the maintainer be damned.
Marcan's sudden outburst and forcibly adding Linus and Greg to the thread he was responding to came afterwards. You can even see some other rust4linux devs asking him to please not do this, since the situation is under control.
Does it do much of anything to solve the fact they've publicly declared that they are going to do everything they can to stop the project, and that there's a history of them doing just that going on for years now?
Marcan's response clearly wasn't the most productive way to raise these issues, but the issues are there and are not being addressed.
Hellwig is a jerk, yes (probably crosses a few lines), but there's a procedure that sidelines him and his mention for this patch was a mere courtesy (since r4l maintains the wrappers and they're not even kept in his folder).
Marcan's insertion in the thread is extremely overblown and as someone in the thread notes, comes across more like a several hours late cavalry to appeal to his social feed. I have a slightly "nicer" interpretation of it than that (in that I don't think Marcan is that kind of person) since it reads like it's probably just the sort of rage best reserved for a private message to a friend, but he's making it everyone else's problem by threatening social media brigading (which is plain and simple: harassment and unlike Hellwig's rudeness, extremely easy to identify as something to push back on).
About the Rust code itself; the primary issue was code duplication rather than preventing the use of Rust altogether. Since the suggested code is not merged, every driver needs to write the same code over and over again. That was also something that the maintainer suggested himself (?). There is of course a big downside, but I am not sure if this justifies all the hate.
The Rust code is not in the area he was currently maintaining. Christoph didn't even look at the patches before objecting to them. Once it was pointed out that they were not in his area, he rejected them anyway.
Note that, because they are not in his area, he does not actually have the authority to do this. He was CC'd in an advisory sense, it's not really his call to accept them or not, and as a longtime kernel maintainer he surely knows this.
Once the wrapper is written, any breaking changes he makes in the DMA subsystem will, by their very nature, percolate downstream to the Rust wrapper and then to any Rust code that relies on it.
So basically from that point forth, he will always have to consider the ramifications of his changes on another group of developers, and deal with any backlash those may cause.
Is he being unreasonable? I tend to lean on the side of "yes," but I can certainly empathize with his point of view (not necessarily his approach, however).
They reiterated that in the thread too.
Obviously the maintainer does not trust the Rust people, but they also did nothing to gain his trust, but the opposite.
Just saying "Trust me, or else I will shame you" is not a viable strategy.
The default position of any code maintainer who sees some people coming and saying that they would maintain from now on some parts of the code and that there should be no worries about that, is to not trust them immediately, but only after enough time passes during which they demonstrate that they are really competent and not just claiming to be so.
Besides, none of this was said. Hellwig did not say "I do not trust you enough". He said "you are cancer, go away". First is harsh, but at least somewhat reasonable (in the sense that it _can be reasoned with_); second is not reasonable at all. Your interpretation is excessively charitable to an obvious bad-faith actor.
> If you want to make Linux impossible to maintain due to a cross-language codebase do that in your driver so that you have to do it instead of spreading this cancer to core subsystems. (where this cancer explicitly is a cross-language codebase and not rust itself, just to escape the flameware brigade).
https://lore.kernel.org/rust-for-linux/20250128092334.GA2854...
That's totally, utterly different than your characterization of it.
(So many other people were also falsely claiming that he said it like that, I initially assumed it was true, so I'm a little irritated.)
If I actively participate in and align myself with a community that is committed to doing the $thing, and you come and say to me that "$thing is cancer", or that "the fact of doing of $thing is cancer", then it's functionally equivalent to insulting this community, and by extension to insulting me. In other words, it's clearly supposed to make _me_ feel bad (for pushing $thing, or participating in the doing of $thing), regardless of the precise wording.
It's still an unprofessional, uncooperative, and _unreasonable_ thing to do.
But this is Linux kernel development. You just can't be such snowflakes, and so quick to be outraged. My mom died young, of cancer. I don't like cancer. I know that using "cancer" as a metaphor is a very negative way to characterize anything.
But the qualifier he added in the original statement is absolutely enough to make it a fair comment.
He really, really doesn't think using multiple programming languages is a sane approach. Would you really feel better if he said, "I think a multi-language approach is a very bad idea, it will inevitably spread, and it will end up causing systemic problems far away from this initial usage, and make the kernel increasingly frail and unhealthy over time" ?
If so, ... weird?
If not, then I think you are overreacting to the blunt (but technical, if perhaps motivated from some more emotional response) that he really doesn't like this idea at all.
"Cancer" is an appropriate shorthand to refer to a practice that you think causes systemic harm that compounds or grows worse over time. (I'm afraid I myself may have used it to describe PowerPoint presentations as the basis for meetings.)
I think his comment meets the minimal etiquette bar for a serious technical discussion. I mean, it wasn't nice. But the fact that he doesn't agree with you, or like your work, isn't an insult.
> He said "you are cancer, go away".
I find this absurd mischaracterization of what he said a lot more unacceptable than what he actually said. He's bluntly stating his technical opinion (which, again, I don't agree with). But you're not paraphrasing; you're basically lying.
Yes, I absolutely would. Because this statement is neutral, specific, and technical (if unfounded, so I'd feel even better if such a statement would have been supplemented with justifications), therefore it can be attacked, argued, and refuted point-by-point on a technical basis. No such thing is possible when technical concerns are replaced with emotionally loaded metaphors.
So yes, I stand by my belief that saying "$thing is a cancer" when talking to someone who is good-faith committed to doing $thing is 1) unreasonable (because it cannot be reasoned with), and 2) an insult (because it is designed to appeal to emotions rather than facts).
> You might not like my answer, but I will do everything I can do to stop this.
You might not like the response for being strongly worded but it is indeed backed by a technical stance and not a political or social one as has been repeatedly suggested. Already overworked maintainers are not willing to sign up for additional maintenance to what has been a solved problem. Objectively, no one should disagree with that stance.
It is not a technical stance. It is a project management one.
> Objectively, no one should disagree with that stance.
That is exactly why the maintenance burden is not his problem. He is under no obligation to take any additional work here.
Will you feel this way when the ruling eventually comes down that the Rust for Linux experiment has been declared a failure? Referring to what is currently an experiment as a decision is a rather bold misrepresentation of the current state. You want to present Rust in the kernel as a foregone conclusion when the reality couldn't be further from that.
> It is not a technical stance. It is a project management one.
Unstable infrastructure becoming a bottleneck is project management? Maybe a working implementation of Coccinelle for Rust should have been among the criteria before the experiment should have been allowed to proceed. That would have precluded the years of furor this has otherwise caused.
> That is exactly why the maintenance burden is not his problem. He is under no obligation to take any additional work here.
This highlights the crux of the issue and the reason your bias is clouding your view of the issue objectively. You are operating on the belief and trust of the small amount of Rust developers. Reality is proving otherwise time and time again.
Yes. What Linus says goes. That's how Linux works.
> Referring to what is currently an experiment as a decision is a rather bold misrepresentation of the current state.
It has been decided that having Rust in tree currently is acceptable. That is not a misrepresentation.
> Unstable infrastructure becoming a bottleneck is project management?
That is not the argument, it is a reason the argument is being made. The argument being made is "Linus should not have allowed Rust in the codebase." That there are technical consequences to project management decisions is not surprising, and they can be good or bad, but it's not the direct objection here, it's a reason why the objection is being made.
> That would have precluded the years of furor this has otherwise caused.
He himself said that he is unilaterally opposed, full stop, and nothing will change his mind. The state of Coccinelle wouldn't make any difference.
> You are operating on the belief and trust of the small amount of Rust developers.
I am taking Linus at his word.
But he didn't say "rust is a cancer", "you are a cancer", "your work is a cancer", or the other permutations of that I've read in this long thread; that's what I was replying to.
His technical assessment doesn't make sense, and apparently isn't even his to make. So that can, and should be, rebutted and refuted. But not by distorting his words, by attacking the substance of it.
(Which I do acknowldge that you have been doing; I've read the entire HN thread, so kudos for that.)
> (where this cancer explicitly is a cross-language codebase and not rust itself, just to escape the flameware brigade).
Where the cross-langauge in this case is Rust. Rust for Linux is creating a cross-language codebase. That means Rust for Linux is cancer.
> and not rust itself, just to escape the flameware brigade
is like when people say "I'm not trying to be rude, but" and then says an incredibly rude thing. Saying "I think this abstract idea is cancer, and you're the specific instance of this abstract idea, that doesn't mean I'm saying you are the thing" is incoherent.
And yet you keep defending Hector.
That doesn't sound like he's only talking about in his area to me
This leads to two situations: the C maintainer has to also update the Rust binding, or the patch has to wait for a Rust capable maintainer to fix them up.
For the first solution, the C maintainer is claiming he has enough work on his plate just keeping up with the C code that he doesn't want to work on Rust. He also believes it is unfair to force every C maintainer to learn enough Rust to keep their integration points working.
For the second solution, the C maintainer is pointing out that Linus has a history of refusing to merge C patches that break Rust builds. So even though the Rust advocates promise they will handle all of the Rust stuff and they are OK with their stuff being broken after C changes until they get around to fixing it, Linus doesn't seem to actually allow for this in practice.
I can see the maintainers point. Sooner or later Rust bindings on critical systems will be essential and changes to the C code will be gated on changes to the Rust code. It is a fantasy of the Rust maintainers that they will have to shoulder that entire burden. But even if they did, it would give them some pretty hefty leverage over the C maintainers in those essential cases. And it also introduces a requirement that someone with enough Rust and subsystem knowledge is even available for the job. People making promises today may disappear tomorrow, leaving the maintainer with an essential binding to a language he doesn't want to support.
edit: as has been said elsewhere, Linus could make some of this go away by committing to let the Rust builds break. I don't know if that could be done in a way that wouldn't be a de facto fork.
Linus already did that. This is the state of things today. C code is allowed to break the Rust, and it's the Rust for Linux people's responsibility to get it working again, not the C folks.
To be fair, I think another valid solution to this problem is just to bite the bullet and tell the grumpy C developers to deal with it. At some point the fallout from an exodus of grey beard Linux maintainers will actually be less than fighting this battle. As many point out, they are going to exit the project one way or another eventually.
From what I understand, this is correct, or at least that is, this was a build system bug that caused accidental breakage, not a deliberate change in the policy that the kernel must be able to be built with Rust support turned off, and that that is the build that matters. Exceptional in a "rarely happens" sense and not a "deliberate choice to create an exception to a rule" sense.
I don't think this is proven: what we have is a specific group of Rust developers, but they are there by virtue of that group existing. There are numerous more kernel contributors today who work in C, and since the greybeards are happy to keep up the work it's not like anyone else is going to easily step in to replace them (since it would be a coup not a handover, if they didn't actually want to step down).
An equally plausible future is some such Rust mandate happens, you drive off the existing C developers, then it turns out the Rust developers aren't actually numerous enough or committed enough (or even good enough at long term project social management) to keep the project going and it dies (or forks into CLinux or something).
Linux itself was a "hobby project" which ultimately succeeded because it did the work which needed to be done, while everyone else was still completely sure the microkernels were the way of the future.
As an outside observer, literally no skin in this game, I can see his point. If his C code changes breaks other C code then he is at an advantage compared to if his C code breaks a Rust binding or Rust drivers. The degree to which this adds to his burden of maintenance is up to him to decide.
As for less work, that is alternative two from my original post which states the maintainer now has to wait for someone else to do the work or risk his change being stalled (worse case: indefinitely). It doesn't matter if the R4L team promises that they are OK with broken Rust code since the only person whose decision matters is Linus. Until Linus clarifies his stance on broken Rust builds the promises of the R4L team are promises that they are literally incapable of delivering on.
> he will still be contacted for information regarding these things.
Just like any other user, and he is free to ignore them just like any other person doing so.
There’s 2 kinds of scenarios here:
- Rust code involved: C code change breaks Rust. ~Send~ ~an~ ~email~ ~and~ move on.
- C code involved: inform other C devs, either work with them or wait for them to fix.
The way I see it, either way, the “Rust stuff adds unacceptable amounts of workload” doesn’t really check out.
Edit: turns out he doesn’t even need to inform the Rust devs.
This isn’t blocking any drivers. Just adds duplicate code.
The R4L says they will make sure the Rust code is fixed when the C code is, and that's admirable, but the concern it means a developer now has to wait for that, holding up their work for release/submission. The bus factor is now on the R4L team.
Meanwhile, everyone involved in development for Linux already knows C.
They do not have to wait.
My assumption is that it's easier to train someone on rust then to train someone to be a kernel subsystem maintainer
Much like the “don’t rewrite from scratch” mantra was written in blood and tears.
Linux is free software and there's really nobody stopping people from forking it and doing things the way they want. It used to happen all the time once upon a time, nowadays people seems to be afraid of doing it.
If all the latest commits in C are so useful, even to a Rust fork, perhaps the Linux C devs are not off-base that Rust isn't worth it for now.
I wouldn‘t expect a grand Rust announcement anytime soon, above what has already been said. Rust in the kernel seems to be fine, but it will have to adapt to longstanding kernel processes. And if it means there won‘t be Rust in some maintainers‘ subsystems, so be it. The kernel won‘t be 100% Rust next year anyway.
That said, I'm going to agree with Linus there: Cancel culture ("social media brigading") isn't the solution.
(Edit: Ok, reading some other context, it seems like this is indeed what's happening, which does make this reaction a little less justified. I can certainly see why it's no fun to have people in the project saying they will do whatever they can to stop an initiative, but if they aren't actually able to block it, then it doesn't seem worth quitting over)
That said there's an outstanding question about whether Linus would accept something that breaks Rust builds for merge. Linus hasn't commented on this yet, but I'm sure he will.
I think people who write C should stop unless it's to fix security bugs and should do something else, anything else, maybe even learn about programming. But even with this mindset Linux is a C project and the R4L folks promised to thread the needle, if it cannot be done this time, then it cannot be done this time. They need to wait.
That's pretty harsh. C has provided so much value to the world and security isn't the most important thing in the world - functionality is. Not saying security isn't important overall though.
And also, imagine another Rust competitor comes up in 5 years called "Moose" and M4L comes up, competing with R4L?
... but I'm aware that it's simply not realistic. These are raw thoughts not "working policy" . My problem is that old software is just barely functional (huurah, we achieved the barely standing equivalency from civil engineering) and we are not spending enough resources on that, nor on security.
And probably my Linux honeymoon period ended after ~10-20 years of work (and/or personal) use, and I feel every point of Marcan's letter, even though I never did kernel development, only the usual troubleshooting and trying to figure out which bug/patch/feature has what status.
But, of course, as long as this blessed circus continues to deliver every ~3 months a new version with this velocity it'll keep going. And Linus is right, if we don't like it maybe (:p) it's on us to accept that. And also maybe Drew's humble suggestion will be the prescient one.
https://lore.kernel.org/rust-for-linux/208e1fc3-cfc3-4a26-98...
https://drewdevault.com/2024/08/30/2024-08-30-Rust-in-Linux-...
If Moose is better I expect people to fairly consider it, and when the consensus forms that yes it's at least as good as C then I want the C people to realize their own responsibility in maintaining critical infrastructure, and I want them to at least have a plan on how to improve, because even in civil engineering the baseline for "barely" has increased a lot over the past decades. (And of course in many cases arguably society has overshoot that, for example with the 2-stairs requirements and so on, where these concerns drastically disincentivize evolution of population centers and transportation networks.)
> Simona Vetter: (addressing Hector) ...Now I'm left with the unlikely explanation that you just like thundering in as the cavalry, fashionably late, maximally destructive, because it entertains the masses on fedi or reddit or wherever. I have no idea what you're trying to achieve here, I really don't get it, but I am for sure fed up dealing with the fallout.
> Dave Airlie: To back up Sima here, we don't need grandstanding, brigading, playing to the crowd, streamer drama creation or any of that in discussions around this. The r4l team and drm maintainer team have this sort of thing in hand, it's not like we don't understand the community of the Linux kernel, and having this first reaction to blow shit up and dramatise it just isn't helpful.
(Obviously I am taking things a bit out of context here, I recommend giving this thread a read.)
Seems to be pretty level-headed, on point, and damning. So yeah, I don't know if I am on marcan's side this time.
https://lore.kernel.org/rust-for-linux/2b9b75d1-eb8e-494a-b0...
Quoting
> Being toxic on the right side of an argument is still toxic, [...]
unironically, immediately after saying @marcan
> and if that then causes you to ragequit, because you can't actually deal with the heat you've been dishing out coming back around the corner: fuck off
...is quite tonedeaf at the very least. Especially given what Marcan said about dealing with this not being his paid job.
Nobody comes off looking good here.
> Currently I work at Intel’s Linux Cloud SE group, mostly creating havoc in kernel driver’s given my more than a decade of work in the graphics subsystem. I’m also co-maintaining the graphics subsystem. I also have been drm/i915 kernel maintainer for a few years, but handed that all off to a great new team.
No doubt that is a flawed summary so feel free to correct
Hector wasn't the developer of this patch. However, he is a user of it. He has had some rough interactions over the last few years. And so seeing this happen (even though it's happening to someone else) is a "the straw that breaks the camel's back" kind of deal.
Marcan is probably a little acutely upset not just because he was told off, but also because Linus hasn't waded into the actual issue at hand (which he needs to, not even Greg K-h can answer it). But that issue is less urgent and it's probably reasonable for Linus to:
a) Mull it over before making a rash decision b) let tempers calm.
I would guess Linus will wait til Monday and is probably also having some off-list chats anyway.
The statement that they were going to maintain this without the support of the DMA maintainer was made 22 days ago [1]. That statement was rejected 11 days ago [2]. Linus was explicitly asked to intervene 10 days ago [3]. (Too complete the timeline Hector Martin first got involved 4 days ago, Linus intervened about that yesterday).
I don't know why you think Linus will suddenly choose to address this Monday.
[1] https://lore.kernel.org/rust-for-linux/Z4kG5AcVeQKegLnb@poll...
[2] https://lore.kernel.org/rust-for-linux/20250128092334.GA2854...
[3] https://lore.kernel.org/rust-for-linux/Z5qeoqRZKjiR1YAD@poll...
https://lore.kernel.org/rust-for-linux/20250110083955.GA5395...
https://lore.kernel.org/rust-for-linux/20250128092334.GA2854...
https://lore.kernel.org/rust-for-linux/Z5qeoqRZKjiR1YAD@poll...
https://lore.kernel.org/rust-for-linux/20250204052916.GA2874...
https://lore.kernel.org/rust-for-linux/20250131135421.GO5556...
Note: I did not intend to particularly link to Christoph Hellwig comments, it just so happens that these contain enough quoting form previous answers to trace out something coherent.
For the complete context, you should walk up/down (and laterally) the thread to get more details and make your own opinion of it. It doesn't take very long.
I read it as “look at this shit” and general frustration with the likes of DMA-guys behaviour.
I'm not disagreeing as I don't know what exact things you're talking about, but I find "virtue signalling" and "communication" to be very similar terms these days. From statement to statement I'm not sure what anyone means by that phrase anymore.
But generally I do like to wait to understand specifically what someone means before assuming.
It's easier to name the major Linux FOSS projects that DON'T have drama and virtue signaling than the ones with.
If you read the Github comments on System-D, GNOME, etc, it's like watching children bickering on Sega VS Nintendo.
Turns out FOSS devs are humas just like everybody else and suffer from the same flaws.
Hell no. FOSS communities, as other spaces created by permanently online individuals, definitely have higher-than-average number of mentally unhinged snowflakes.
It is rather anticlimactic. I had always imagined FOSS to be this free exchange of ideas, thoughtful consideration, and intentional action. Seeing what it has become though… Maybe closed source is better.
I've had similar pissing matches in closed source development, instigated by me and not...
Often, these things get resolved or left simmering without any public visibility, so that's nice as a user. And there's usually a somewhat clear heirarchy of authority, where the boss can say I don't care who's right, do X; which resolves issues in ways that sometimes a technically minded open source project can't; that can often help with bikeshedding between usable options.
But sometimes you just keep working somewhere because deep in your heart of hearts you want to do it your way, and once that other person quits or maybe even goes on vacation, you can. And sometimes people endeavor to actively push that person out, which I guess I've seen on FOSS drama too, but office politics have a way of lurking under the surface more, IMHO.
You thought it was better in the past? Read up on the great ncurses maintainer drama. Or the NetBSD/OpenBSD split. Or FreeBSD/DragonflyBSD split. Or the Emacs forks, GNU libc forks, GCC fork, etc. etc. etc.
This kind of drama has always existed. Difficult people have always existed. And even good people have always been struggling with their emotions.
And in all my closed-source $dayjobs I've had to deal with all of that too. Sometimes significantly worse than I'm seeing here.
At least in some cases this is plausible. The money people get for working on closed source software irons out some issues, for example:
Some people who voluntarily work on open source code do it for self-actualization, which indicates that they have a strong desire to push their wishes through. This implies that a lot of drama gets involved if these people don't get their way.
Was it ever different? Not as far as I can remember at least. I think one of the main strengths of open source development is that it works despite the drama.
With open source projects, everybody is free to start their own fork over disagreements, and if the fork actually turns out to be objectively better it will replace the original project.
> Maybe closed source is better.
It's the same and worse over there, the drama just isn't public.
Of course, with notable exceptions. See Apple Car, Android tablets etc.
At least you’re getting paid. What’s the point of spending one’s free time arguing with strangers on the internet over some code that will be refactored anyway ten years from now..? Life is short, have fun, enjoy it. If you’re spending time or money on something that sucks, walk away.
I assure you it isn't; it really, really isn't. You don't see the drama because 1) it's behind closed doors and 2) because the people involved know their job is at risk if they cross the line.
Is your theory that rust makes people dramatic? Or that dramatic people like rust? What other options are there, if not coincidence?
There is a cognitive bias called "loyalty to the brand", in which it says that people prefer the things they have because they rationalize their choices to protect their sense of ego. When they invest time (or a lot of money) to something, they create an emotional connection, especially if that was a choice and not something imposed on it. It is choosing one thing about the other that leads to narratives about why you have done a certain thing, something that is usually connected to your self-image.
There are a number of cognitive trends that converge to create this behavior. This assignment effect appears when you feel that the things you have are superior to things you don't have. Another bias is the fallacy of irrecoverable costs. This happens when you spend time or money on something you don't want to have or don't want to do, but you can't avoid. For example, imagine that you spent time studying Rust. You will be "hooked" on the idea that given the time spent in this, it is better to defend the language, even if you imagine that it is not for all things.
To combat post-decisional dissonance, the feeling that you committed to one option when the other option could have been better, you strive to feel justified as to what you selected to reduce the anxiety created when questioning himself. All this forms a gigantic group of neurological associations, emotions, details of self-image and trends around the things you have.
Both, really. As a language that was designed from the ground up to be a replacement for C and C++ (thus implying that it's superior to these established languages), it positions itself as inherently "dramatic" and anti-establishment.
This obviously attracts these political activist types who love to insist that their way of thinking is the way forward, that everyone else was simply doing it wrong before they came along, and that anyone who questions their beliefs is an obvious enemy of progress who should be silenced at all costs. It's a cult, basically.
I think it is a human trait to like to win arguments. In some card games, there is a thing called a trump card [1]. The trump card has this special ability to beat all other cards.
Rust has a kind of trump card: memory safety. If you get in an argument about code it is often possible to maneuver the argument in the direction of memory safety at which point the Rust advocate gets to default win the discussion.
I think this "trump card" aspect attracts a particular kind of person to advocate for Rust simply because they like to feel technically superior to others. Whenever they are in an argument, no matter what the context, they simply have to play the game: how can I make this technical argument about memory safety so that I can win by default.
1. https://en.wikipedia.org/wiki/Trump_(card_games)
Thus, instead of drama, we get meta-drama, i.e. nothing has changed.
Aren't these diametrically opposed? Virtue signaling is loudly claiming to have some virtue in the absence of that virtue. Hector has receipts, in the form of commits, as proof.
Virtue signaling would be me appearing on the mailing list and spouting my beliefs.
Sometimes the nuance of appealing to maintainers emotions is more work than writing the software yourself and maintaining your own private fork.
If someone could find that blog post (and subsequent hacker news ref) it would be a fun way to compare this discourse to Rachel’s discourse.
Edit:
Found it: Choosing to stay out of the community.
https://rachelbythebay.com/w/2018/10/09/moat/
https://news.ycombinator.com/item?id=18181409
EDIT Wrong one sorry
https://lore.kernel.org/rust-for-linux/CAHk-=wi=ZmP2=TmHsFSU...
So the smackdown from Linus is what motivated it. Honestly though if you read the email Linus is replying to, it was deserved. To be fair, Hector Martin may be one of the smartest hackers alive today. His fame goes way back to hacking the Playstation 3 with geohot and Hector has even found security vulnerabilities in Apple Silicon. He's done great work with Asahi Linux by weaponizing his keen penetrating mind to support open source freedom. But like his buddy geohot he can be a bit childish. Right now Hector seems to be laying low. His social media accounts are no longer accessible. It seems even archive.org and archive.today have no recollection of him. That's impressive.
So what triggered him to act out of character? It seems like he wrote his Apple GPU driver in Rust and he needed Rust DMA support in the kernel. I know, a curious thing for a Rust developer to want more power to do things that are memory unsafe. So the DMA maintainer Christoph Hellwig hates Rust. He thinks Rust is a cancer in the kernel. Cristoph refused to help Martin create Rust APIs for DMA. That's why he went ballistic.
Chances are they'll all make up when this blows over, or someone will just rewrite his GPU driver in C. There's not going to be as big of a push for Rust with this recent government. For example, the White House recently took down its paper about the future of programming being memory safe. The money for Rust is going to dry up. It's becoming socially acceptable to push back against efforts to convert everyone to Rust.
No, he tried to prevent other people from doing the work to create Rust APIs, and said that he would do everything in his power to prevent anyone from doing it.
They took down all of https://www.whitehouse.gov/oncd/, what makes you think they gave any thought to this paper in particular?
Did he really NEED it? Why he couldn't use the C API?
It's a quite clear case of "what you accuse others of is what you yourself resort to". He was calling out others for unreasonableness, flaming and sabotage — and did exactly that himself.
He closed the account himself:
> I actually wasn't sure if I wanted to delete my Mastodon entirely or not, but as I intended to fill in my password for confirmation and decide whether to click the button, my password manager auto-submitted the form for me. Call it fate, I guess. I mostly don't regret it. Maybe I'll be back some day, maybe not.
https://old.reddit.com/r/AsahiLinux/comments/1ijvq7y/asahi_l...
It is gone now and gives a generic "nothing here"; I have no idea whether the "suspended by moderator" display was some kind of bug, transient state, or whether he's just lying, or both things are true and he just deleted his account after it was suspended.
(Well, his Reddit post doesn't claim his Mastodon account didn't get suspended, so it'd "only" be the omission kind of lie…)
FWIW, I don't understand the logic of deleting the Mastodon account but continuing to post on Reddit… those are both "social media" in my mind…
This is obviously just a Mastodon bug (backend treats suspension and deletion as the same thing, for example). I'm not sure why one would entertain the idea of marcan making up a lie about being suspended from an instance he's an admin of.
1. go to https://social.treehouse.systems/explore
2. type @marcan in the search box
3. select "go to profile" from suggestions
Feels like a problem with the dynamic/partial JS content loading.
(Apologies for the confusion, there's no indication that made me suspect a bug... and I hadn't at that point seen anything about him deleting his own account yet.)
I would've liked to link a post or two of his to show just how little flexibility and tolerance there was from his end regarding his social interactions, even when being questioned about them in an outside context and in a reasonably neutral manner. Ohwell…
I suppose it's possible that that could turn out well.
The situation with Apple hardware feels a bit like the early days of Linux (including the fast pace of development). There was a time when if you wanted broad hardware support it was better to run an Alan Cox kernel than a Linus kernel. And the whole point of git was to have a system that didn't require one central blessed tree.
I struggle to follow the LKML through the web-interface. LORE seems to provide a better view:
1. https://lore.kernel.org/lkml/a869236a-1d59-4524-a86b-be08a15...
Maintainer of DMA wants to keep the code clean and not mixing languages[1]. And tries to avoid dangerous offers like "we will maintain it for you".[2]
2. https://lore.kernel.org/lkml/a869236a-1d59-4524-a86b-be08a15...
Somebody references social media posts.
3. https://lore.kernel.org/lkml/a869236a-1d59-4524-a86b-be08a15...
4. https://lore.kernel.org/lkml/a869236a-1d59-4524-a86b-be08a15...Torvalds reaction.
My impression, while still struggling to follow the message flow:
I think social media and shaming are harmful and understand the reaction of Torvalds. The position of the DMA maintainer seems also to make sense for me, to keep code maintainable over decades it must remain in a nice and tidy state. That is the hard work.
PS: I want to avoid actual names of persons.
The Rust bindings are not in his tree. They do not touch his code. They are effectively no different than any other subsystem or driver which uses DMA. If he tried to veto some random driver that needed DMA from using DMA for no reason other than because he didn't want to have to deal with it if he changed the API in the future, that maintainer would be told to F-off because that's not his call.
Christoph is throwing NACKs around that he doesn't actually have the authority to NACK.
Perhaps so, but that discussion was two or three years ago. Stalling other contributors' work now is counterproductive, especially for changes that do not touch files maintained by them.
This does not justify any brigading behavior, though.
Is that a typo or he indeed intended to escape that 'k'?
(Sorry, I know this doesn't add to the drama or what's going on there, which really doesn't interest me one way or the other, but this tiny bit had me curious)
All I want to know is what's the long term viability of Asahi Linux or Linux for that matter on M series chip'd Macs? What's the burden going to be for Fedora Asahi if the work remains out of tree? Has Redhat/IBM stated they'll support it via the Fedora project going forward? What if they pull support?
I am reminded of the Beeper messenger stuff. Like it's cool when people hack these things together to do stuff, but the community as a whole has seen this episode before. We probably shouldn't be making any choices or compromises to make Apple stuff work, because they are adversarial.
What really gets me is the whole leadership vibe. If Linus had just clearly said, “Alright, Rust is in, but only in these specific parts and under these conditions,” a lot of this back-and-forth and social media shouting would’ve been avoided. Instead, we’ve got a bunch of maintainers arguing about process and even threatening to use social media to shame people, which just adds more fuel to the fire.
At the end of the day, it’s not as simple as “Rust or no Rust.” Some parts of the kernel might really benefit from Rust’s safety, while other parts might be fine sticking to C. The real challenge is figuring out how to integrate Rust without turning everything into a maintenance nightmare. We’re all aiming for a better, more robust kernel here, but if we keep getting bogged down in personal drama and endless debates about process, nobody wins. Maybe it’s time to take a deep breath, set some clear rules, and move on instead of letting all this online drama derail progress.
See https://lkml.org/lkml/2025/2/7/15 for example.
https://github.com/torvalds/linux/commit/1b3291f00013c86a9bb...
So the title is factually correct. But I wouldn't be surprised if he tries to add Lina as a maintainer once things calm down.
People’s donations to Asahi Linux have decreased, according to Hector from this thread [0]
Here’s how to donate: https://asahilinux.org/support/
[0] https://lore.kernel.org/rust-for-linux/c5a49bcb-45cf-4295-80...
If the upstream maintainers don’t want to adopt it, the Rust folks can gradually rewrite the bits they want to and let the market decide. Use the Ballmer “embrace, extend, extinguish” model.
With the complexity of systems engineering, for a single driver, it takes months to build one from scratch. Plus, there is not enough expertise within the rust community to take on a project like the linux kernel to match the rate of development by many large corporations with hobbyists.
They may not match the rate of upstream development, but doing their own thing is going to be a faster path to their goal of Rust in the kernel than trying to convince everyone else to do something that they don’t seem to want.
> ABSOLUTELY NO C++ in the kernel EVER. But Rust is totally fine.
stance? It seems pretty absurd when you consider the closer similarity between C and C++ (and the more straight-forward migration path from C to C++), and the fact that GCC supports C++ (even recent vintages) natively on many more architectures.
https://www.redox-os.org/
Here's the thing, in the next couple of years languages like Carbon, Zig, even Jai, will come of age. They will have their proponents and people who want to introduce them into kernel code.
If there is a rust developer out there who doesn't resist the introduction of these languages as ardently as the chosen people (C) are resisting rust, then I will show you someone who lives in some kind of alternate reality.
Personally, I'd be pressuring the C committee to introduce defer, tout suite, otherwise Zig looks favourite. But the reality is that your preferred language is just that, your preferred language, most have seen this drama before and will choose not to participate.
As to whether Linus is failing in his leadership role? Nah, Then again, I wish Sony would open source the PS OS and we can be done with this juvenile debate as to which OS should rule the world. Either that or let's have an exokernal and move on from this monololithic story, surely that would meet the needs of the MY FAVOURITE LANGUAGE isn't appreciated crowd!!
The Rust ecosystem never clicked for me the way Go or Zig did. But I work with I/O-heavy distributed systems, where Go outshines Rust in most cases, so that’s what I use the most.
Systems programming is a different beast, though, and I’m glad the push for rewriting everything in Rust has lost its initial momentum while Zig is emerging as a strong contender. Even then, I wouldn’t want Ziggers to start pushing things upstream into the kernel anytime soon.
There are other big Linux forks that met a similar resistance, best example is probably Realtime Linux / RTLinux that was not welcome in the Kernel for what, 15 years? Yet they still continued in their own fork and now most of their patches have finally gone in.
The way they're going to work now should have been the default. Just as RTLinux was a big change to the Linux kernel, Rust will be a big change. You cannot expect the Kernel community to welcome such a huge change with open arms and deal with all the fallout (build system, interfaces, etc.)
Just be ready for your project to take a decade, instead of trying to force it in "now or never". Until then, maintain some out-of-tree modules written in rust that every Linux distro/user can try and test without much fuss. For example, I don't think it will be a huge problem if Mac users have to get their DRM driver at some other repo (or if distributions would have to package some `linux-module-drm-apple` package separately from the Kernel)
Is there anything outstanding? I thought they recently reached the point where everything from -RT is in mainline.
This was to be expected, many of their anti-C++ complaints also apply to Rust, given that both languages share many common ideas, even if presented in different forms.
I was genuinely surprised when Linus opened the door for Rust in the Kernel for that reason. And the real waste is there: had Linux said a straight “no”, then nobody would have lost their time trying to make this work against all odds.
Or maybe Linus really thinks Rust is the future, but he doesn't want to enforce its inclusion in the Kernel against his senior maintainers because he's afraid of an uprising.
I absolutely get emotional about my work. I have absolutely sabotaged myself by not having the presence of mind to step back and take a deep breath. I had a moment of clarity reading Hector's post on Mastodon, and I'm sad that my suspicion that this was going to just make things worse was correct
Those who are nervous about embracing Rust further are just fine. Rust is still a young language. It shows an awful lot of promise, but it isn't a magic cure for safety and security concerns, especially at the kernel level. It is entirely possible that Linux is a bad fit for the language, and the real way to get ta Rust kernel is for a team to come together and implement a kernel in Rust, from scratch, perhaps with POSIX compatibility.
On the flip side, Hector is entirely correct that the overall process of maintaining and improving Linux is incredibly baroque and grounded squarely in some tooling that just stinks in the modern ecosystem. It has worked for Linux for ages. It is also increasingly making working on Linux a specialized project space because nobody else manages projects like this. Hector is fine leaving if he finds that process two owners to be worth his volunteered time. And it is entirely possible that there will come a day when the value of the project itself is outweighed by the cost of interacting with the project and Linux will get supplanted in the common ecosystem by something else.
In short, Hector is probably making the right move here. If he wants to continue working on a problem like this, a new operating system might actually be the right solution.
This is based on my limited experience with rust, but I believe we really need to give rust more time to mature it enough to see where we're going with the builds to actually decide on this matter, even personally. Plus, Linux has been keeping the Linux Kernel project alive for so long that he probably already has got the experience of knowing the repercussions of a wrong decision. Being hasty in this scenario doesn't solve the problem
care to elaborate on that?
P.S I don't have skin and skill for the kernel game. I'm just a curious bystander.
Even ignoring the driver problem, it's not really an economically viable amount of work. Right now everyone benefits from everyone else's bug fixes, from everyone else's security improvements (like introducing rust!), etc. Going it on your own means you have to redo everything everyone else has done (unless you just fork linux), and that you don't get the benefit of everyone else working on the shared codebase (I suppose unless you fork linux and keep merging in upstream... which is actually what projects like Android do).
A complete rewrite also means a huge time lag before you start seeing payback in terms of faster development speed and a more reliable/secure operating system. Unlike introducing rust in new work to the existing kernel which sees relatively immediate payback.
I suppose I wouldn't be too surprised to see a project like Android just maintaining a whole series of rust changes in their own branch if the RFL project continues to be impeded by the maintainers. That's what Asahi linux (Linux on apple computers) is already doing (and poking at the android-mainline branch it looks like there are some rust additions that aren't in Linus's tree... but I'm not sure what the extent is).
https://www.redox-os.org/
https://tockos.org/
Also note that many of Rust 4 Linux contributors are Microsoft and Google employees that would like to upstream their changes, they already have plenty Rust on their own Linux derived systems.
Because their primary goal is to widen the community and reach of Rust, with "preventing memory error class bugs in the kernel" a secondary objective.
After all, the Rust additions, if properly designed, can be maintained in an out-of-tree fork that tracks the main Linux repo. If they did that, there'd be no one to block their patches but themselves, and yet they don't do that.
Rust is more about community than Linux is. Within the Rust community they make it very clear that it is vital that everyone goes the same way, while the Linux community has had, for decades, people each doing what they or their employer are interested in.
These two communities are not going to mix well, TBH. A community in which every member is a vocal prosyletiser isn't going to mix well with a community which prides itself on "Show Me The Code".
Mainlining whenever possible is highly incentivized by technical and organizational aspects of linux[1], nothing about rust changes that. Obviously R4L introduces complexity and tradeoffs but I don't see why a rust kernel dev whose only goal was preventing bugs would do anything differently in this regard. Linux is a consensus project and opting out of the process of building consensus would mean not actually preventing any bugs.
[1] https://docs.kernel.org/process/1.Intro.html#the-importance-...
No idea what the particular bit of drama discussed here is about, but that's my impression of the Rust "community".
And if they need evangelists, it's a safe assumption for me that they don't have other merits.
You are free to either take over maintenance of the Subsystem or do a fork
But throwing a tamper tantrum on social media is definitely the wrong way forward
(This is a shared link to a subscriber-only LWN article, please consider a paid subscription to LWN if you liked it!)
> But Christoph Hellwig … turned this submission away with a message reading, in its entirety: "No rust code in kernel/dma, please" (despite the fact that the patch did not put any code in that directory)
> Already overworked kernel maintainers will have to find time to learn Rust well enough to manage it within their subsystems.
Frankly, this article feels like it’s steps away from social media brigading.
The first quote of yours edited out the part where it says he does a lot of work in the DMA subsystem. It’s saying “someone who does a lot of work in the kernel turned the patch away”, which is absolutely true.
The second quote is understanding of the maintainers’ side, saying that they’re already overworked and now they’ll have to find time to learn rust on top of that. Not so much “I think these people ought to learn Rust”, but “accepting these patches means they will now have to learn rust”. This seems true to me? If anything it’s overly partial to the maintainer’s side, admitting that rust patches put more work on the old guard maintainers who are already overworked. It’s interesting that you feel this is too partial to the Rust side.
Edit: I'm not super invested in the topic at hand I use all 3 OS's and only use Mac to develop with/for using MacOS
But kernel-level dev is hardcore and especially for open source, I've experienced that with the Pine64 devices which are almost worthless without the devs contributing to its software
It's fine to say no to any other language but C in the Linux Kernel on a global basis.
What's not fine is caprice and depotism.
Either Rust is allowed, or it is not.
Stop wasting time.
And stop C-zealotry, it's as embarrassing as Rust zealotry, if not more so.
And as additional context, developer A has a history of causing drama on social media. So much that he even has his own page on KiwiFarms.
The Linux kernel is part of so many different things, projects, products, companies, etc. A change can really duck things up.
Being conservative, and slow, in adopting new things is good for the main line.
You have idealistic developers who have seen a way to do something better, that is great. I know the feeling.
I have never done anything with the Linux kernel, but I have worked on some large legacy codebases. and it is to come in, look around, and just go "Gosh, this here is just slow, I'll just fix this". and it will be a good solution right there, but it might be suboptimal overall.
Chances are really good that you dont understand the entire picture when you "fix something", and someone who does, may not like the change. and even if the technical solution is clearly better from one angle.
I am glad I will never be involved in blessing or passing on 1.000.000 different changes being proposed as improvements to Linux every week.
It seems like big enough of a sticking point that if a forked alternative with a less insular contribution model appeared, it could gain enough steam to keep itself afloat. All it’d take is for someone with deep enough pockets to fund a few founding engineers to be the subject of this kind of frustration.
https://www.redox-os.org
Well, with AGI...
If ever integrated Swift might change the whole paradigm
Let him fork!
Jokes aside: I hope he forks and establishes a CoC and if what he does is more effective we will all benefit by it.
Whoever owns DMA or whatever and rejected rust out of hand like this should frankly be _forced_ to resign. This is truly arrogant and egotistical behavior, almost certainly contingent upon FUD and insecurity and laziness about not just learning Rust.
Good grief, last time I feel excited about submitting a kernel patch; what a ridiculous situation.
It's hard enough to get a single programming language to work right. C is old and stable.
Rust is new and mostly stable, mostly stable isn't going to cut it when billions upon billions of devices depend on your work.
At the same time this type of ego driven drama keeps me out of the open source community. I have enough people telling me how to code during my 9-5.
I open source most of my projects, but it's not a collaboration. I'll even admit, I get really annoyed when someone puts in a PR that's literally just a bunch of spacing changes in a readme. I think there was some influencer who was claiming that you should go through GitHub, and submit as many changes for things like grammar as possible to a bunch of different projects .
And then on your resume you can put that you contribute it to all these projects. Not fun.
I think it's a noble goal worth working towards, but Marcan's smug as hell "ill merge and y'all will fix all your broken shit" attitude predictably backfired
I need to get paid to deal with stuff like that. No one is going to tell me how to write code without writing me a check.
Even at work I have my limits, although now that I'm older I'm much more inclined to just go with the flow. But if I'm not getting paid what's the point.
I do enjoy game jams though. We only need to work together for a weekend. Plus at least in my circle we only care if the code works.
Could that be relevant to this story, or is that a complete sidetrack?
Edit: Asking because the timing is curious.
Rust has never as far as I'm aware or can tell via google recieved money from USAID. Though amusingly there has been money invested by USAID to combat it's namesake - a category of fungus - from destroying coffee plants.
What you're probably thinking of with regards to the US government is that the Trump administration has been deleting all sorts of websites and guidance, and one of the things deleted was a report by the White House Office of the National Cyber Director calling on developers to use memory safe languages [0]. Various other similar documents (e.g. randomly picked via google [1]) still exist and it's unlikely that this document was deleted because of its contents and not because the white house was just destroying the entire category of things related to the ONCD - even the landing page 404s [2].
That report was just a "this is a good idea", I don't believe it ever came with any funding or support.
It wouldn't surprise me if other similar things were deleted too, that's just the one I saw hit the news, so I'm guessing that's the news you saw.
[0] https://bidenwhitehouse.archives.gov/wp-content/uploads/2024...
[1] https://media.defense.gov/2023/Apr/27/2003210083/-1/-1/0/CSI...
[2] https://www.whitehouse.gov/oncd/ - Link from https://en.wikipedia.org/wiki/Office_of_the_National_Cyber_D...
Not possible to have rust without the "" community"", it seems.
Martin's patch should not be delayed or rejected because of the rust language, it is an approved language. If some maintainer has issue with such rust language approval, they should address that particular issue not patches using that language. They can also choose to resign.
Edit: eh, hadn't seen that your root comment is now flagged. Don't even remember what you had written initially, but it did feel rather uninformed. You should probably check a bit more that you have enough information before forming an opinion?
2. The upstream fight had always followed the Cash Flow. If you have so called "problems" you either act yourself, or let other people do something about it, the way it won't result in more long-term issues. Deliberate Detraction IS a Sign of Corruption and Abuse of Power.
3. An ambiguous Point of Conflict may not be Conflict at all, but just an outcome of the Lack of Proper Communication and Transparency. Detraction is Accountable, social dynamics and social incline with explicit or implicit motives is Accountable as well. The lack of Effective Code of Conduct, and absence of Proper Punitive Action, for everyone, will cause Authoritarianism (or just Genocide of Engineering Thought).
I do feel bad about the state of Linux Kernel development, but we'll have either to move on, and learn from This Mistake, or do something about it.
This "we're viral" behavior when "it's really not" is very childish.
wsl ‘DOES’ have a rust toolchain, nobody is saying rust is going viral (what on earth…), you tried to install the python packages’ sdist rather than the wheel.
Get it together.
Was your comment wrote by a junior javascript developer?
This is plainly false.
Regarding the point of "community" being difficult to manage in "open source" projects, I would argue managing a large group of developers on any project is difficult and full of drama.
I'm personally not an advocate of the "open source" obfuscation term myself, but the public license of the linux kernel has little to do with the drama.
Maybe the fact that linux developers have some kind of say at all, as opposed to some proprietary dev projects where every decision is handled by fiat (and Linus has certainly served this role at times), causes it to have more drama.
But no matter what model is followed, people do love their drama, and a large dev group is a social activity regardless of the licensing of the software itself.
Its like every social issue ever: the thing all participants have in common is that they are all humans...