Why am I seeing this?You are seeing this because the administrator of this website has set up Anubis to protect the server against the scourge of AI companies aggressively scraping websites. This can…
Why am I seeing this?
You are seeing this because the administrator of this website has set up Anubis to protect the server against the scourge of AI companies aggressively scraping websites. This can and does cause downtime for the websites, which makes their resources inaccessible for everyone.
Anubis is a compromise. Anubis uses a Proof-of-Work scheme in the vein of Hashcash, a proposed proof-of-work scheme for reducing email spam. The idea is that at individual scales the additional load is ignorable, but at mass scraper levels it adds up and makes scraping much more expensive.
Ultimately, this is a hack whose real purpose is to give a "good enough" placeholder solution so that more time can be spent on fingerprinting and identifying headless browsers (EG: via how they do font rendering) so that the challenge proof of work page doesn't need to be presented to users that are much more likely to be legitimate.
Please note that Anubis requires the use of modern JavaScript features that plugins like JShelter will disable. Please disable JShelter or other such plugins for this domain.
Read the original article
Comments
My (minimally-informed) summary of the mailing list posts is that Hellwig thinks that the addition of Rust to the kernel is fundamentally bad because it [1]
> turns Linux into a project written in multiple languages with no clear guidelines what language is to be used for where.
And that
> Having worked on codebase like that they are my worst nightmare, because there is a constant churn of rewriting parts from language A to language B because of reason X and then back because of reason Z.
Torvalds' position is that Hellwig doesn't have to like Rust or accept it in his subsystem at this point, but he has does have to accept that it will be part of the kernel [2]:
> You can't have it both ways. You can't say "I want to have nothing to do with Rust", and then in the very next sentence say "And that means that the Rust code that I will ignore cannot use the C interfaces I maintain".
Hellwig appears unwilling to accept that.
I think this is a reasonable position on both sides. If Linus wants Rust in his kernel, that's his choice. Memory safe languages are pretty much motherhood and apple pie at this point, and Linus very probably realises that Linux has to adapt or stagnate. On the other hand, if Christoph doesn't want to continue in a role that he sees as becoming mostly churn and pain, it's hard to blame him.
[1] https://lore.kernel.org/rust-for-linux/Z7SwcnUzjZYfuJ4-@infr...
[2] https://lore.kernel.org/rust-for-linux/CAHk-=wgLbz1Bm8QhmJ4d...
> Memory safe languages are pretty much motherhood and apple pie at this point
For anyone else who never heard of this saying:
> The phrase motherhood and apple pie denotes a core principle, value, belief, characteristic, aspect, etc., of the U.S.A. or its citizens.
By rurban 2025-02-2615:33 > Memory safe languages are pretty much motherhood and apple pie at this point
Then they should use a memory-safe language and not rust.
The real issue how strong and stable does his C api need to be?
If I maintain a (code level) api used in a single codebase I typically have a lot of flexibility. I can make “breaking” changes as long as I fix all the uses as the same time. This is really big advantage.
If the codebase has multiple languages using my api I will need to make changes in these other languages if I want to do this. This is a very real cost to me. It will tend to force me to have a really stable api with no breaking changes since I won’t realistically be able to fix them all myself.
By Ukv 2025-02-2614:28 > If the codebase has multiple languages using my api I will need to make changes in these other languages if I want to do this. This is a very real cost to me.
Current policy, at least in theory, is that the C interfaces can change as before and it's on the Rust maintainers to fix any issues on their side. From Linus's response:
> So when you change the C interfaces, the Rust people will have to deal with the fallout, and will have to fix the Rust bindings. That's kind of the promise here: there's that "wall of protection" around C developers that don't want to deal with Rust issues in the promise that they don't have to deal with Rust.
I fail to see how this is a relevant question and "the real issue" with respect to Rust. How is this situation any different from a pure C kernel? There are already protocols on how this gets handled - maintain backwards compatibility and notify other maintainers of your changes, anticipated migration requirements, and any deprecations. To which the responsibility falls on the other maintainers C, Rust, or otherwise.
In practice (in general, not Linux specifically), you can make it all much faster and simpler by sending out the fixes for your change to impacted users. The ability to do this makes it much easier to change your api.
Except we are talking about Linux specifically, the "users" here in your analogy are people working in the collective kernel code, and there is a unique culture and set of practices around maintaining this because it's not some REST API where if something breaks you just shove a bug fix out for your part.
By lokar 2025-02-2614:27 Certainly APIs exposed to userspace can’t ever break. But if a change can be completely hidden by fixing everything all at once (as a trivial example, renaming something) that should be ok, no?
By mherkender 2025-02-2614:343 reply I empathise. It's important in any large software project try to converge on one right way to do something, because inconsistency is bad for maintainability.
That being said, change is inevitable, so this desire for maintainability can't prevent all change.
It's a shame they couldn't find a way to balance these things.
By jauntywundrkind 2025-02-2621:161 reply The kernel did find a way to balance these things. Nothing is being rewritten in rust (nothing core, some modest drivers have been). Hellwig didn't have to worry about Rust at all, could have kept doing his thing.
If we accept this as the core concern:
> Having worked on codebase like that they are my worst nightmare, because there is a constant churn of rewriting parts from language A to language B
Then he has no need to fear, nothing in the foreseeable would have affected him in any way.
He didn't like that he didn't have control over what other people elsewhere were doing. But there was an extremely generous balance offered him, to be utterly unaffected in any way. And that wasn't good enough for him.
By mherkender 2025-02-2712:08 You're not wrong, but if one of the main Rust proponents and one of the main anti-Rust proponents both quit, that doesn't strike me as them finding balance.
By gnfargbl 2025-02-2616:06 I also empathise, for the same reasons.
Co-incidentally, I was just listening to the radio, where a former BP strategy employee was pinning the failure of BP's "Beyond Petroleum" strategy squarely on the difficulty of a company that is built to do activity X pivoting to also do (competing) activity Y. The recommended solution there was to spin off a new entity focused entirely on Y. It's hard not to draw a parallel.
By wakawaka28 2025-02-270:541 reply Change is not inevitable in this lol. We all speak English here despite the fact that the language has many nits to pick. There's no inherent reason why C needs to be abandoned because some new thing came along and solves a few of the associated nits. C++ was never used for the Linux kernel despite the fact it solves many of C's problems and is far easier to integrate than Rust. Integration of Rust is a pet project that Linus and others have taken an interest in, not some absolutely groundbreaking or necessary change.
In a similar vein, there's no inherent reason to use a calculator over doing calculations on paper. Ever seen a paper run out of battery?
By wakawaka28 2025-02-272:57 The difference between C++ and Rust is more akin to the difference between a standard pencil and a mechanical pencil lol. Also:
>In a similar vein, there's no inherent reason to use a calculator over doing calculations on paper.
Improved speed and reduced mental overhead are the main reasons people use calculators, not accuracy. This is because you can use any tool such as a calculator (or programming language) incorrectly.
I used to hear that the difficulty of relating CPU instructions to lines of C++ was the reason it wasn't suitable for the kernel. Now, all that has gone out the window (as Rust is definitely no simpler than C++), and they're making changes to the Rust language to suit the kernel application (as opposed to using something tried and true). It's a bad idea, but I expect it to be carried out to the point of absurdity.
> Hellwig appears to be unwilling to accept that.
> I think this is a reasonable position on both sides.
I disagree. Hellwig is trying to dictate who/how uses his subsystem/code. Linus makes it clear, you don't have to use/accept Rust in your own codebase, but you can't tell others what they can do in their codebase.
Whatever it is, Hellwig has used his freetime to maintain these modules. Usually that means that he has seen some value in that. Maybe he liked it. Maybe he hoped that he was doing some good and beneficial.
Now this change caused the total net value become negative. It was perfectly okay to express his opinions. Opinion was disliked and it is pretty okay, while sad, that he stopped maintaining it. Nothing to do with dictating.
> Maybe he liked it.
Maybe he got a lot of professional mileage from being "the" Christoph Hellwig, Linux DMA maintainer. Independent consultants need publicity.
By subsistence234 2025-02-2615:391 reply For his day job he's regularly been coding in Rust since ~2020.
By toyg 2025-02-2718:02 That's irrelevant, we're talking reputation.
By gnfargbl 2025-02-2613:31 You can reasonably disagree with the direction of a project that you're involved in, and you can withdraw from that project if it refuses to change direction.
By subsistence234 2025-02-2615:341 reply Or am I missing something?
C subsystem patches have started to be rejected by Linus because they break Rust builds despite the agreement that this wouldn't happen. That's why Hellwig switched from ignoring Rust patches sent to him for review to NACKing this one.
Hellwig did it, from what anyone can tell, to get Linus to publish the actual policy which he still hasn't done yet.
By steveklabnik 2025-02-2616:12 > C subsystem patches have started to be rejected by Linus because they break Rust builds despite the agreement that this wouldn't happen.
No. There was one instance of a toolchain issue accidentally including some Rust stuff when Rust was configured off, this was fairly quickly rectified. Linus even said in one of his more recent emails that this happens infrequently, but also, this happens all the time in general, and that’s why linux-next exists.
Linus did reaffirm the policy of “C folks are allowed to fully ignore Rust stuff.”
By monocasa 2025-02-2614:10 It's not the resigning that was the dictating; it was the NACKing patches.
By woodrowbarlow 2025-02-2613:451 reply exactly; and i think Hellwig is on the wrong side of free software philosophy on this point. the fundamental philosophical core of free software is that the downstream user must be empowered to use the software as they see fit.
Well, no, the issue is that R4L isn't downstream. It's right there alongside the kernel, a part of the kernel, it's one combined project.
Someone can use your text parsing program to run a nuclear power plant, that's fine. The same person can't make you to accept the nuclear power plant control script as part of your repository, and support the "nuclear power plant controlling functionality" of your text parsing program.
By woodrowbarlow 2025-02-2614:331 reply Hellwig controls the DMA code. The Rust bindings use the DMA code. Hellwig is free to change the DMA code without considering whether or not it breaks the rust bindings. the rust bindings are not his problem, nor does he need to start maintaining any rust code.
from Linus:
> You are not forced to take any Rust code, or care about any Rust code in the DMA code. You can ignore it. [...] So when you change the C interfaces, the Rust people will have to deal with the fallout, and will have to fix the Rust bindings.
sounds like it's structured as a downstream user to me.
By subsistence234 2025-02-2615:401 reply > Hellwig is free to change the DMA code without considering whether or not it breaks the rust bindings.
The fact that he was not allowed to do that is exactly why he escalated.
By Ukv 2025-02-2617:38 He's allowed to reject Rust within DMA, which he maintains. What he wasn't allowed to do was veto code that was merely a user of DMA, on the basis of objecting to R4L in general ("I will do everything I can do to stop this"):
> The fact is, the pull request you objected to DID NOT TOUCH THE DMA LAYER AT ALL. It was literally just another user of it, in a completely separate subdirectory, that didn't change the code you maintain in _any_ way, shape, or form.
Here is the thread that likely sparked his resignation (if this is a resignation), and more specifically Linus’ response to Hellwig’s earlier comments regarding rust and the Linux kernel.
https://lore.kernel.org/rust-for-linux/CAHk-=wgLbz1Bm8QhmJ4d...
(Edit to include the correct name)
By flykespice 2025-02-2614:042 reply It seems his leave of absence has given fruits.
Old linus would have ticked off for even less, along with name calling and personal attacks.
By nxobject 2025-02-2622:27 I agree – I'll need to look this up myself, but I'd love to know what his self-reflection on his annoyance involved: I admit that I still need to do the same to learn restraint during disagreements with new collaborators, that I haven't had the experience to feel trust with yet. My anger's stopped me from productively working in informal standardization efforts within my org.
By theiebrjfb 2025-02-2614:17 [flagged]
The only person to get to have it both ways it seems is Linus. In the past he's railed against c++ and it would be cold day in hell to see c++ code in linux.
To be fair, it's his tree. On the other hand, I am a little worried that Linus has been hypocritical in the past few years, but most of us get soft as we age I guess.
By steveklabnik 2025-02-2616:04 What is both ways about it here? The argument against C++ was never about a multi-language codebase being unacceptable.
By Filligree 2025-02-2615:22 Linus seems to genuinely believe that Rust is superior to C++.
Having used both, I agree.
It's a real shame that the drama led to so much real-world fallout.
Even though I feel pretty strongly that Christoph was in the wrong in this situation, it's impossible to deny that he is one of the most prolific and experienced kernel maintainers, so this is a real loss and not something to feel any schadenfreude about.
I hope all those stepping back can get some space to reflect and figure out a way to operate more productively going forwards.
By dralley 2025-02-2613:40 Well someone already has, as per the title. But I would hope he at least stays on as a contributor.
By subsistence234 2025-02-2616:11 someone else always does and they always have the same knowledge and skills. except in this case, hellwig had more experience coding in rust than his replacement.
