> post exposure vaccination is a thing?? does it work for everything
I believe in this discussion the context is specifically rabies.
> and why is it called vaccination not treatment?
It's both, really. You get a shot of rabies immunoglobulin (at the site of potential infection, i.e., bite) _and_ an extended course of vaccine at the same time.
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.
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).
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.
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.
> 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).
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.
> 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.
> 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 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.)
> (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.
This strikes me as entirely missing the idea of Radicle.
What you are saying is basically "why automate things if you can just do them manually". But worse is not better; there is value in having the P2P transport layer work _transparently_. If you intend to force user to manually (or semi-automatically) juggle remotes for every single device on the network, you have already lost.
TL;DR What you describe is just Git on top of a generic P2P overlay network. I'm sure it can be done (and I might even believe it could be enough for some limited use-cases), but it is not Radicle.
+1. Also GitHub is more than a git storage, it’s a forge [0]: people use it to store their code, manage changes, track issues, publish releases, and so on. That’s what Radicle wants to be.
> What you describe is just Git on top of a generic P2P overlay network
That would be the most widely useful functionality, upon which other features can be layered. If the simple functionality can't be used alone, and you have to buy into a more complicated model, then it makes the tool less broadly useful.
Git actually provides a pretty good experience if you have a remote that's always online. I can push and pull branches around to get between all my different devices. GitHub is usually up.
What I would be interested in, is a remote I can host from my house, instead of the cloud. I could leave the public key on my profile and others can checkout the repository.
> I admit I haven't really seen a huge advantage to using systemd-networkd over NetworkManager yet
I don't think there is one. systemd-networkd is explicitly not for dynamic environments like personal laptops or workstations; it has a scope and NetworkManager is largely outside it.
Ahh the vocal minority in support makes its appearance!
I wouldn't call the opposition tiny, although the vocal portion of any group tends to be the smallest. This would be my first online comment on it so I'm certainly part of the non-vocal group you ignore, that in my experience is significantly larger than the vocal side of group you dismiss.
I believe in this discussion the context is specifically rabies.
> and why is it called vaccination not treatment?
It's both, really. You get a shot of rabies immunoglobulin (at the site of potential infection, i.e., bite) _and_ an extended course of vaccine at the same time.