Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I have to question your position from a moral standpoint though.

If you were a rollercoaster engineer, and you saw that a rollercoaster had an unsafe design, would you follow a similar approach? "I'm not going to ride that, but I'll let this line of people ride it without warning them." Obviously the stakes are wildly different, but still...



That is a false equivalence, roller coasters have far more material risk given human lives are at stake.


If you had discovered Heartbleed, would you have kept that knowledge to yourself so that you could minimize the maintenance burden on the OpenSSL develoopers?

Granted, no one died over Heartbleed but it caused lots of real people harm. We should start worrying about the well being of our fellow human beings long before their lives are at stake.


Well they didn't find any specific issues. Just the overall code looked not up to their standards as well as how the maintainer dealt with feedback. What do you suggest one does in such a case? Every time I stumble upon shitty open source code, am I supposed to fix it and if the maintainer refuses the patches, patrol the internet and try to prevent anyone from using it?


> they didn't find any specific issues

The linked article specifically mentions that a specific soundness issue had been found and a fix had been submitted as well. If they had done nothing, it would have attracted no comment. If they had allowed another maintainer to review and merge, it would have attracted no comment. But they went out of their way to denigrate the people who called attention to this issue, called the issue "boring", rejected the patch, then deleted the issue and all comments.

> Every time I stumble upon shitty open source code, am I supposed to fix it?

Your tone suggests that you don't want any part of this, so you continue along that path. I'm not going to convince you to start caring about your fellow men and women.


> But they went out of their way to denigrate the people who called attention to this issue, called the issue "boring", rejected the patch, then deleted the issue and all comments.

This is an unfair characterization of what happened. Here's another version: The maintainer did not denigrate anyone, he did call the patch "boring" (which isn't really an insult or anything?), worked on his own patch (without closing the previous PR mind you). People immediately starting shitting on the maintainer - within the hour - because the PR had not been merged. Maintainer chose to delete the issue to avoid it devolving into the usual mess. More shitting contest happened here on HN, on Reddit, and elsewhere.


I would like to believe you. But without access to the actual issue in question, I have no reason to trust your account of the events over nindalf's account of the events.

To me, deleting the issue instead of disabling comments or making read-only suggests mens rea on the maintainer that their actions were out of line and regrettable, and don't suggest an effort to de-escalate the situation.


> The linked article specifically mentions that a specific soundness issue had been found and a fix had been submitted as well.

True, but I (and I think the other comments) referred to the top level comment here, which is a guy who just felt the code was smelly and avoided it, without having discovered anything specific.

> Your tone suggests that you don't want any part of this, so you continue along that path.

Been there, done that. The amount of excuses and other bullshit is not worth my time and effort. If the project is on github I still do open issues providing repro or at least a stack trace if possible. But if you have your own bug tracker where I'd need to sign up first (most likely going through email verification) you've lost me. Same for when you start requesting I do a git bisect even though I provided steps to reproduce or start giving excuses for why this isn't an actual bug and I'm holding it wrong. I'll just stop replying immediately.


Yes, and you're making the same mistake that you're railing against: if you're going to invoke some sort of moral imperative to do something, you have to examine the risk of what can happen if you do nothing. In the case of something like Heartbleed, yes, the consequences of silence could be quite high. But I just can't see the same argument against remaining silent for this web framework.

It's also a matter of degree and thoroughness. There's a huge difference between "I've found a specific exploitable vulnerability in this security library and here is a proof-of-concept exploit", and "after a cursory look, I see this rust code uses a lot of `unsafe` and I'm uncomfortable with that".


There were specific issues found in this library. Soundness holes as a result of unsafe. And people submitted fixes. This person could literally have done nothing and it would have been ok. But they went out of their way to be terrible to everyone.


Seems like there was plenty of actual terrible to go around, and the language barrier made quite a few instances of not terrible seem terrible.


Agreed, we have a responsibility as a community to not cause harm and even take effort to prevent it. That is what I like about HN, it is a place where these things are discussed and as a collective, positive outcomes can manifest.


> Obviously the stakes are wildly different

This point pretty much invalidates your argument. When making a moral decision like this, determining the stakes and the consequences of remaining silent is a critical part of the moral evaluation.

In the case of the rollercoaster, silence could have deadly consequences for the riders. Not so much for the code. (Sure it's possible that someone might use it in a life-critical situation, and it could fail in a way that would cause loss of life, but assuming from the outset that this is a strong possibility is quite the stretch.)


Look up “Ergodicity”...


Okay... huh?


Failures of Actix will be “ergotic”; individuals experiencing the failure will be able to play again, experiencing the long-term average failure rate.

Failures of a roller-coaster are “non-ergotic”; individuals never experience the long-term average failure rate, since they’re, you know, dead...

This has got to be the most common and tragic type of mis-application of statistics I’m aware of; I know I used to do it all the time! Virtually nobody teaches/talks about it, but it is arguably more critical to understand than “causation vs. correlation”, or “post hoc ergo propter hoc”.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: