Live data from Hacker News

A Sad Day for Rust

words.steveklabnik.com

191–200 of 1001 posts

Re: A Sad Day for Rust

#191
post #6

I 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…

> If you're a developer of a project that is used in a security-sensitive context

Working in the context of Security does not grant you a blank check to be an asshole.

Re: A Sad Day for Rust

#192

Here's the reddit thread in question: https://www.reddit.com/r/rust/comments/epoloy/ive_smoketeste... I have no doubt it led to some github issue brigading, but it's not really that big of a deal. Ostracizing /r/rust in a mealy mouthed way probably won't make that community better...

Yeah, I feel people here attack /r/rust with even more vitriol than /r/rust attacked the author of Actix. Plenty of kettles here.

Re: A Sad Day for Rust

#193

A 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…

The best justification for this attitude is that it's the most encouraging of open source development. Other attitudes raise the cost of open source development -- considering that it's already a losing proposition (w.r.t. lost time + opportunity) -- and will result in less quality open source software. People just won't put the work in if all they get back is this entitled bullshit.

I feel as though there's a certain developer entitlement that also needs addressing though. Just because you made a software doesn't mean I have to use it or like it, and if you are actively trying to recruit me to use it then I am indeed entitled to complain about it.

I see it frequently in the FOSS community where someone will suggest some software they made to solve a problem, get told why their software isn't actually that good for the problem, become defensive about it, and then try to play the "entitled user" card.

Re: A Sad Day for Rust

#194

A 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…

I'm glad you said something because I felt like I was going crazy reading some of these replies. People sometimes seem to forget the phrase "Remember the human" when they interact with maintainers. It's a really frustrating situation to watch because one of the main reasons I make software is as a creative outlet. So, I can see where Nikolay is coming from being frustrated and upset. Sometimes people want to just go around kicking over other peoples sand castles.

P.S. Thanks for making Sourcehut.

Re: A Sad Day for Rust

#195
post #145
post #100

Earlier quoted context omitted.

As a maintainer, it is his choice which patches to accept. If you're not happy with his decisions, choose another project, fork it, or pay someone to do it for you.

> As a maintainer, it is his choice which patches to accept. If you're not happy with his decisions, choose another project, fork it, or pay someone to do it for you. Sure, but that DOES NOT mean you're immune to criticism, especially when it comes to security. Your type of argument could otherwise be used for pretty much everything - even large corporations. It's not useful.

>Sure, but that DOES NOT mean you're immune to criticism, especially when it comes to security.

But our society does not just openly accept giving criticism. There are rules. Unwritten and extremely vague ones, no doubt, but still social rules. This is especially so when criticizing something a person is providing for free. In this incident, did the criticism cross the boundary and violate those rules? It seems so. Many people likely gave respectful criticism that followed the rules but they appear to have been drowned out by those who did not.

Re: A Sad Day for Rust

#196

Earlier quoted context omitted.

Forking someone’s project because they won’t accept your PRs will definitely make them feel harangued by the community. I’m not sure if it necessarily has to be that way, but creating a hostile fork is conventionally considered very rude.

This should change though. That's the correct course of action if a maintainer won't mainline what you want them to. Or is absent altogether.

What makes it hard is that upstream users have no attention bandwidth to dedicate to your project's (meta-project's?) internal disputes. They're just going to decide which fork they think is the main one and use that. If you look at Presto, that's a good example of how hostile forks tend to go; both sides have to insist they're the real project, the main project, because otherwise nobody will use them.

Maybe there's a solution to that other than avoiding forks, but I'm not sure what it would be. It seems like a pretty fundamental challenge.

Re: A Sad Day for Rust

#197

Sorry to add yet another top-level thread, but my take on this is that, while it is correct that unsafe-blocks are a central and contributing factor to this incident, it is incorrect that languages doing what Rust does fundamentally need unsafe-blocks. As long as Rust both has such an easy way to circumvent the type system, and a desire to supplant C and C++ on the basis of code quality and safety, there will be read…

What is your alternate proposal?

Re: A Sad Day for Rust

#198

A 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…

> “ 2. Open source participants are volunteers and owe you nothing.”

Absolutely not. They are compensated with prestige, enjoyment, decision-making power, future employment rewards, and sometimes even money, all of which was their choice to pursue through their labor and time spent on the open source project.

The users of open-source projects, upon which the projects themselves depend, are also not obligated to anything, and can for example (very reasonably) become angry and complain if people prioritize pet features instead of community needs, or unilaterally take projects in unsupported directions.

There is compensation for the work, and there are still social norms. Nobody cares one bit about who is entitled or not entitled to what.

Re: A Sad Day for Rust

#199
post #176
post #157

Earlier quoted context omitted.

> Your type of argument could otherwise be used for pretty much everything - even large corporations. It's not useful. No, if you pay for things, you have a contract and things are immediately different.

So basically, if you use open source code in your code, you should expect there to be security vulnerabilities which people know about and are keeping quiet about because it'd be unfair to the unpaid creator to criticise them? Tbat sure makes it sound like it's morally irresponsible to use open-source rather than purchased commercial code in something like a web-facing service in 2020, especially given what we know n…

You can report on security vulnerabilities in a library without being vitriolic.

Find vulnerability. Already, awesome of you to have done. Issue patch request. That's 10x even better, you're a boon to the community. You submit it, it gets rejected, you find out why and it's the maintainer is just not feeling it or some other irrational reason. Fork, put in the readme why you forked, write a blog post without being a dick about it, done.

The article we're talking about is referring to the bloodbath of a Reddit pile-on. That's totally unacceptable behavior from an adult.

Re: A Sad Day for Rust

#200
post #118

Earlier quoted context omitted.

Yeah, I agree. “It’s all reddit’s fault” is not helpful at all and simply wrong from reading that thread.

You cannot get the full context from a single reddit thread; as I mentioned in the post, this situation is the product of multiple events. You'd at least need the posts from all of them, let alone that this is only one of the posts from this situation on reddit in the last day.

I think that's where some of the confusion comes in.

You say:

"Some people go far, far, far over the line."

So some people are assuming this is just the maintainer responding badly to people pointing out problems with his or her code, but you are saying it went far beyond that into personal attacks?

Post reply on HN