A Sad Day for Rust • Hacker News Board

Re: A Sad Day for Rust

#491

Post by carapace » Fri, Jan 17, 2020, 5:45 PM UTC

vunie wrote: 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…

("bear the brunt" It's one of those weird words that only exists now in that phrase. Brunts are borne but otherwise unmentioned. It's kinda like how you can be over- or underwhelmed, but never just whelmed.)

Re: A Sad Day for Rust

#492

Post by anaphor » Fri, Jan 17, 2020, 5:45 PM UTC

ddevault wrote: post #38

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…

This is a good reason to use Github only as a read-only mirror and just do all development elsewhere. That way you don't have to deal with drive-by issues / PRs from people who just want to complain or won't put in follow up effort.

Re: A Sad Day for Rust

#493

Post by blinzy » Fri, Jan 17, 2020, 5:46 PM UTC

tssva wrote: post #325

steveklabnik wrote: post #139

Earlier 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.

I completely agree with you, especially considering that comment was posted in reply to the maintainer's also dismissive comment "this patch is boring", which to me makes it seem not as bad as if it were out of the blue...

Re: A Sad Day for Rust

#494

Post by tssva » Fri, Jan 17, 2020, 5:47 PM UTC

shkkmo wrote: post #371

tssva wrote: post #280

Earlier quoted context omitted.

If someone poorly implements something, potential causes harm in doing so, doesn't accept that they have done so poorly and express a desire to learn and improve in future endeavors, it isn't even necessarily incorrect to express that they may not want to pursue that particular field anymore. Of course it should be done tactfully which I doubt most of the comments on Reddit did. I see this same sentiment expressed fa…

In what way is it correct or even helpful? Even if done tactfully, I have a hard time seeing that being taken by anyone as anything other than a personal attack. The correct response would be to organize the community to create a fork that is more focused on correctness and security than on performance.

It is correct and helpful because it can prevent continued poor behavior which impacts others. Trying to protect someone's feelings only goes so far. Sometimes you have to be straight and to the point with people whether they take it as a personal attack and it hurts their feelings or not.

Whether it would be appropriate in this I case I don't know but I disagree that it is never the correct response.

Re: A Sad Day for Rust

#495

Post by lostmyoldone » Fri, Jan 17, 2020, 5:47 PM UTC

quotemstr wrote: post #241

coleifer wrote: post #63

I am disgusted by the cultural phenomenon of making sarcastic call-out comments on twitter/etc., with an eye towards building up enough community outrage to force an issue. There are people who forget that open-source does not entitle you to anything (read the fucking license). Maintainers of large projects are not even allowed to have a bad day, to make a brusque comment, or to disagree with a majority -- without so…

I too am disgusted by this phenomenon. The key thing to remember is that outrage has power only because you let it have power. Twitter snark isn't the real world. Neither is Reddit outrage. If you totally ignore these hives and their angry buzzing, you'll have greater peace of mind and lose nothing.

I don't disagree, but it's also the fact that for some of us the option to learn to ignore people can be a decade long struggle, if possible at all. It's not that I don't think you get that, you probably do. I just needed to tell a bit of my perspective to someone, and that happened to be you, and the rest of HN.

My brain is, well, lets say "broken" in this respect.

I could have open sourced a fair bit of code over the decades, but I haven't, largely because the option of entirely ignoring people isn't really available for me at this time. While I obviously try to work to get to a point where it is an option, I don't know if I ever truly will be able to publish my own projects.

While I now won't get bothered much by people calling me an idiot, or being asses in general, the self righteous expectations people apply to open source maintainers still just breaks my brain.

People freely give out their labour of love and sweat, and other people have the gall to hold them to higher standards than we hold most of society?

It's just too obvious. As soon as the balance of power shifts, a sizeable fraction of the population becomes the tyrants of their "peers". Can't deal with that, unfortunately.

Re: A Sad Day for Rust

#496

Post by zpallin » Fri, Jan 17, 2020, 5:47 PM UTC

HorstG wrote: post #477

zpallin wrote: post #400

Earlier quoted context omitted.

I disagree here, but only within the confines of the language I used. A maintainer of open source code is willingly submitting their own work to be used for free by others. They have no responsibility to extend it at all, but to maintain it is to do so in the interest of the users... they have a responsibility to do it to the best of their ability, and if not, the maintenance should be given to someone who will.

No. Just no. They may do so to the worst of their abilities. Thats their prerogative. The only limit might be publishing something that is actively intended to do harm. But I can't imagine a plausible example of that...

You might not believe this, but I agree with you! Doing something to the best of your ability includes the right to be able to suck at it also. I am pressing for absolutely no standard of quality, yet you somehow think that's the case. It's not. I just think that if you're going to call yourself a maintainer of something, then you better at least pretend.

Re: A Sad Day for Rust

#497

Post by toast0 » Fri, Jan 17, 2020, 5:48 PM UTC

derefr wrote: post #303

deng wrote: 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.

Sure, but once you’ve forked, now you have a fork only you use, but which you know is more secure than its upstream for reason X. That’s an unstable equilibrium—you want others to know of your fork, and to switch to it, so that other downstream projects can also be more secure. Adding to this, you might still transitively depend on the upstream through your other deps in ways you can’t change without either forking a…

> you want others to know of your fork

If you fork on GitHub, they take care of letting people know.

I've forked a few abandondedish projects, and other people seem to find the patches. The best example I can think of is stud, which the people behind Varnish adopted and renamed to hitch; they surveyed the landscape and took good patches from most of the forks.

I might not look for forks from a more active project, but it's definitely something I look for when I run into problems with software without a lot of recent updates.

Re: A Sad Day for Rust

#498

Post by DarkCrusader2 » Fri, Jan 17, 2020, 5:48 PM UTC

A lot has been already said about this unfortunate situation. I would like to mention that pinning all this on brigading by reddit is very disingenuous. There was a lot of hate directed towards actix and Nicolay on twitter by some very prominent members of Rust community also who were discussing removing actix from the awesome-rust list so people stop using it. Let's not represent a community by their worst members.

Re: A Sad Day for Rust

#499

Post by rukittenme » Fri, Jan 17, 2020, 5:48 PM UTC

A word to the wise. Don't read the reddit thread around this. A lovely little snippet:

> > it's up to you as a developer to vet your dependencies

> This is effectively impossible on an individual level, and it's something that absolutely needs to be a community-level effort.

Don't hire this person... Dependencies are absolutely, FULL STOP, your responsibility. YOU are the one making the money NOT the maintainer.

Re: A Sad Day for Rust

#500

Post by Traster » Fri, Jan 17, 2020, 5:50 PM UTC

dbcfd wrote: post #369

coleifer wrote: post #63

I am disgusted by the cultural phenomenon of making sarcastic call-out comments on twitter/etc., with an eye towards building up enough community outrage to force an issue. There are people who forget that open-source does not entitle you to anything (read the fucking license). Maintainers of large projects are not even allowed to have a bad day, to make a brusque comment, or to disagree with a majority -- without so…

> Maintainers of large projects are not even allowed to have a bad day, to make a brusque comment, or to disagree with a majority -- without someone trying to stir up a lynch mob. It sickens me the lack of balance between the work done by the maintainers, and the expectations of random users. Sure they are. There's a number of projects out there with a massive caveat on the front page that says "Not for production us…

Sorry, it doesn’t work that way, come on github isn’t intended for production unless specified otherwise. The default assumption is “This is just some code I don’t own”. Even repos that do make some claim of support or quality should be treated with suspicion. The onus is on the person using the Open source project to do due diligence.