Earlier quoted context omitted.
Exactly this. If it doesn't meet your standards, don't use it. Alternatively, go fork yourself.
But then you get drama about Not-Invented-Here, why are you creating yet-another-X-framework instead of improving the existing ones. Or you get drama like ffmpeg vs libav/avconv.
A Sad Day for Rust
751–760 of 1001 posts
Re: A Sad Day for Rust
#752Earlier quoted context omitted.
> Rust seems to be being used most by people who are interested in blockchain and crypto Where did you get that from? From what I've seen every single blockchain/crypto post on Rust's subreddit is downvoted into the negatives.
Probably related to the Reddit job ads when you read /r/rust. That said, blockchain companies using Rust take security very seriously. It also funds cryptographic research which has a huge need of memory safety, performance and the possibility to implement constant-time primitives. I don't see why the community of a language that focuses on safety and speed is not excited by having the language being adopted by commu…
My reasons can be summed up as: "public blockchain" aka cryptocurrency is toxic — it's horrendously inefficient in the name of achieving censorship resistance, so people are literally burning fucktons of energy to make perfect "crime currency" work. It has fueled the rise of ransomware (and extortion in general) and all kinds of scams. Meanwhile "private blockchain" is just like good old merkle tree/hash chain stuff, infused with hilarious/awful marketing fueled by cryptocurrency hype.
Good talk about this: https://www.youtube.com/watch?v=xCHab0dNnj4
Re: A Sad Day for Rust
#753Earlier quoted context omitted.
Here is an example of an actual comment. I believe the thread is deleted now: > "seriously? Please just stop writing Rust. You do not respect semver, you do not respect soundness, so why are you using a language predominantly based around doing these things right?" This is what I was thinking of when I wrote "far, far over the line."
Depending on the context that doesn't seem to be "far, far over the line." Just about any thread on HN regarding any aspect of systemd or Google will have comments which are much more vitriolic.
Re: A Sad Day for Rust
#754A lot of this thread has it wrong, and this wrongness contributes to the problem which led to this. I have two simple mantras which establish my philosophy here: 1. YOU are responsible for your dependencies. 2. Open source participants are volunteers and owe you nothing. It was never Nikolay's job to vet actix-web for you, nor did it become his job when the library became popular, nor does invoking "security" change…
> User entitlement is totally unjustified and will burn out maintainers faster than almost anything else. That's correct. Here's Rich Hickey's take on it: https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...
Re: A Sad Day for Rust
#755Earlier quoted context omitted.
Here is an example of an actual comment. I believe the thread is deleted now: > "seriously? Please just stop writing Rust. You do not respect semver, you do not respect soundness, so why are you using a language predominantly based around doing these things right?" This is what I was thinking of when I wrote "far, far over the line."
I think it's a cultural issue, but I honestly don't see what's so offensive about this comment (I was expecting something far worse), especially if it's factual assumptions are true. Honest question, can somebody explain the issue here to me, and how one would express these concerns otherwise? I feel as if I just don't get American culture of politeness and niceness to appreciate it.
Do you not see how that is (a) not related to the project and (b) rude in any context?
If you were, say, singing karaoke and someone came up to you and said "you're awful, never sing again, you're off-key, you don't know the words"... Is that not rude to you?
Re: A Sad Day for Rust
#756Earlier quoted context omitted.
Seems like there should have been some sort of response from the maintainer about the _philosophy_ of why he was doing things the was he was, and people could either get onboard with the connecting points of that, or get lost. So far, in all of this drama, I have yet to see where any of that might have been explained. I don't use Rust, but I understand the significance of the experiment, and I think I for one, would…
There is absolutely no obligation to even reply to mails. Otherwise you fall into the trap of having to explain everything to everybody and not doing your project.
The level of entitlement in the discussion astonishes me. Someone has done a lot of work and offered it for free along with a license that lets people modify it and redistribute it and that is not enough. Instead of being grateful for it, people are demanding that the giver also make the changes that these people need and take on the burden of maintaining them.
To all those people: Why should he? Do it yourself or pay someone to do it. It need not be any more complicated than that.
Re: A Sad Day for Rust
#757I don't know how to word this so I'll say it bluntly (and probably bear the blunt of this community as a consequence): If you're a developer of a project that is used in a security-sensitive context, you either be receptive to security concerns or you clearly label your project as a toy project. No one expects you to write perfect code, but we do expect you to fix flaws when you learn about them. Of course, you could…
> No one expects you to write perfect code, but we do expect you to fix flaws when you learn about them. It's not like he was getting paid to work on this, was it? And people do have a life beyond open source. People could have forked and worked on the issues themselves, but that's asking too much. Why do the hard work when you can just write a comment/tweet blaming someone else, right? Your comment is precisely what…
Forking projects should be a last resort. This is the "Taking my ball and going home" approach, and now we're splitting development efforts, potentially ending up with very different code paths where improvements can't be merged from one to another, etc. It might be the right thing to do in this situation - but people wanting to avoid it want to avoid it for good reason. It's a big hammer and not the first one you want to pull out of your tool bag.
>Why do the hard work when you can just write a comment/tweet blaming someone else, right?
Except, as the article mentions, the author wasn't interested in detailed bug reports or PRs that had code that fixed it. This wasn't a case of people just being nasty - the maintainer wasn't interested in people doing work to fix it, either.
>Your comment is precisely what entitlement looks like.
This isn't someone asking for a feature request or minor bug to be resolved and whining when it didn't happen. This is a security vulnerability in a popular package where detailed reports are provided and the maintainer has a history of not accepting feedback, PRs, etc. on similar issues in the past.
Security vulnerabilities are a big deal: They have implications for not just the user or company that is making use of the software, but also potentially any end users. This is a web framework - a good portion of projects using it are going to be public facing. A good portion of those are going to be storing user accounts and information about the users. A security vulnerability puts all of those people at risk too.
I maintain that any project that you make publicly available you have a moral obligation to resolve security issues if it is at all within your power, and to disclaim them prominently if it isn't.
If I've got a free lemonade stand, but every glass contains a toxic chemical that will activate in my body if a malicious person sprays me in the face with another chemical, people sure as hell can bitch about my free lemonade, even if they could go run it through a filter and remove the toxic chemical.
Re: A Sad Day for Rust
#758Earlier quoted context omitted.
So, how fast do people expect developers of open source projects to respond before someone is considered unresponsive? I'm not sure combining social media with code control is going to be such a good thing for a lot of developers who might not like to program in a fishbowl.
Expecting a reasonably-quick response to security concerns is certainly appropriate.
If you want to be able to place expectations on the author, pay them and get a contract.
Re: A Sad Day for Rust
#759Earlier quoted context omitted.
So, how fast do people expect developers of open source projects to respond before someone is considered unresponsive? I'm not sure combining social media with code control is going to be such a good thing for a lot of developers who might not like to program in a fishbowl.
Expecting a reasonably-quick response to security concerns is certainly appropriate.
Re: A Sad Day for Rust
#760Earlier quoted context omitted.
Appealing to "common decency" is just the same as "being owed". I think you're mincing words to avoid sounding entitled, and I don't think anyone is even entitled to two lines in a README, much less at the top.
All I am doing is saying that it takes very little effort to be upfront and hopefully avoid future confusion. You are free to disagree. ¯\_(ツ)_/¯