Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Sad Day for Rust

words.steveklabnik.com

Post reply on HN
Print view View original

781–790 of 1001 posts

Re: A Sad Day for Rust

#781

Post by bloodorange »

cthalupa wrote: post #750
bloodorange wrote: post #741

Earlier quoted context omitted.

Exactly! Everyone should demand a full cash refund for all that they paid for the maintenance of that piece of software.

This is a common snarky retort when any discussion happens with open source software, but it doesn't add anything to the discussion. There is a cost to using software that goes beyond money exchanging hands. The maintainer has no legal obligation to do anything, but acting as if someone having an issue with software having security vulnerabilities is someone being entitled is a childish reduction of the interactions…

Why do you think it adds no value?

It at least makes it very clear to those who have not paid for the maintenance that their position is silly if they make demands of the maintainer. It is his project and he does as he pleases. Why is that difficult to see?

One could perhaps persuade him to accept a patch but like any endeavour where you need something from another person, either you offer them something in exchange (which they value enough) or ask nicely and see how it goes.

In either case, it might still fail. In that case, one can of course try and do the same with _someone else_ who might be more receptive. This is possible with free/open-source software.

What you consider a "snarky retort" is just the same thing said in a different tone.

Re: A Sad Day for Rust

#782

Post by zpallin »

bloodorange wrote: post #765
zpallin wrote: post #386

Earlier quoted context omitted.

If that's the case, then why open source it at all? Just make people pay.

Why is it a problem for you if someone is willing to give their work to the world in a way that allows others to benefit from it? Why is that not enough? Why do they also have to keep doing more after that? If you disagree with the notion of someone publishing their work under a free software or open source license being useful for the world, then please post an AskHN about it and you will have _plenty_ of material t…

It is enough, and I don't disagree with "the notion of someone publishing their work under a free software or open source license being useful for the world." I have simply no idea where you got the idea that I would disagree with that.

What you are responding to is a rhetorical response I gave as an argument against the dismissive idea that an open source maintainer should have no responsibility unless they are getting paid. I don't agree. I find that it's a maintainer's responsibility not to extend, but to maintain. That's all I'm arguing.

If someone wants to throw OSS at the wall to see if it sticks with no obligation to maintain, then that's fine. But as soon as someone puts on the maintainer hat, I think it's reasonable to say they are accepting responsibility for that role.

Re: A Sad Day for Rust

#783

Post by tolmasky »

HorstG wrote: post #470
tolmasky wrote: post #362

Earlier quoted context omitted.

There’s an interesting gray area here: am I as a customer responsible for knowing the dependencies of a service I use? Most of the time that’s impossible. And things like GDPR seem to imply that people believe users are entitled to some degree to demand certain standards (privacy/security) from all web services. This is the potential problem with “just fork it”. If the library is used by a great many products, and yo…

GDPR binds an operator of a service. The developer can do as he likes.

My point is that GDPR raised the bar of our expectations of what a consumer can demand from a provider. As such, perhaps it is not unreasonable to expect that there would be an expectation from other services, especially if they are integral to the operation of many services that have personal information of millions of people.

As a pure hypothetical, imagine a critical bug was discovered in Rails that would potentially allow someone to attack any Rails website and extract personal information. Further, imagine someone quickly submitted a PR with a patch for this, such that Rails could then do a quick release and make sure it gets to every Rails consumer as fast as possible.

What if the Rails maintainers then ignored the patch, and said it was boring. Legally they are under no obligation to do anything really. And you could argue that it's on every one of the thousands of sites that chose to use Rails if they get hacked and expose user information. And further, you could argue that if people don't like this situation, they are "free to fork Rails" with the patched version. All this is fair, but I think others might say that the Rails maintainers at this point did fail in a responsibility. There are arguments for both sides, but I do not think it is as simple as "the maintainers owe people absolutely nothing" as at some point being the nexus of updates actually gives them an almost stopping or blocking power, not just the more passive refusal to fix the problem themselves.

This scenario is clearly different in magnitude from what happened with this project. That being said, my only point is that it is fair to expect a certain amount of activity in a project that bills itself as production-ready (and asks you to use it). I personally would be very weary before committing to telling someone something is production ready casually, regardless of whether the "fault" ultimately rests on them. That being said, this of course does not entitle anyone to treating others poorly, my only point is that the responsibilities and expectations are not well understood in this domain.

Re: A Sad Day for Rust

#784

Post by bpt3 »

aidenn0 wrote: post #669
bpt3 wrote: post #661

Earlier quoted context omitted.

> The license only frames the projects legal responsibilities. It is entirely unrelated in every way to how the project is run on a day to day basis. You completely missed the point. At the end of the day, the legal obligations are the only ones, and both the Apache and MIT licenses very clearly state that the creator of the software has no obligations to any user. Therefore, any other supposed obligations only exist…

> You completely missed the point. At the end of the day, the legal obligations are the only ones, and both the Apache and MIT licenses very clearly state that the creator of the software has no obligations to any user. There's a word for people who only fulfill their legal obligations: Assholes.

> There's a word for people who only fulfill their legal obligations: Assholes.

There's also a word for people who expect others to meet their expectations without contributing anything on their end: Assholes.

If you explicitly state up front what you're willing to do to support a project, and I come along demand you go above and beyond your stated limitations, who is being unreasonable here?

Re: A Sad Day for Rust

#785

Post by ncmncm »

zelly wrote: post #389
jsjohnst wrote: post #55

Earlier quoted context omitted.

I don’t have the full picture here, but the source article implies that folks weren’t just complaining, but also offering PRs to fix the issues, which were rejected. That feels less like entitlement to me and more like bad stewardship of the project, but again, most of my info is biased by source article.

I don't get it, why didn't anyone just fork it and outcompete the original one?

That would be like actual, y'know, work. Who wants to do that, when they can post nastygrams?

Re: A Sad Day for Rust

#786

Post by MrStonedOne »

Open source frees us from the tyranny of the maintainer, but only if people stop raging at maintainers and start forking shit, and other people stop raging at maintainers and start voting with their feet to other forks.

Who the fuck cares if the package maintainer does or doesn't do x,y, or z.

Either make the patch, submit it, and launch your fork when it gets rejected, or look for such forks. Anything else is just masterbation.

On another note: it seems like this entire mess was based around a bunch of peoples inability to see that "can" != "does". The fact that it can be vulnerable because it doesn't do something that makes being vulnerable impossible does not in any way mean that it is in fact vulnerable.

This is like the time somebody came to our repo with a bunch of pep8 linter warnings and treated them like high severity issues.

"good practice" != "must do".

Re: A Sad Day for Rust

#787

Post by bloodorange »

zpallin wrote: post #782
bloodorange wrote: post #765

Earlier quoted context omitted.

Why is it a problem for you if someone is willing to give their work to the world in a way that allows others to benefit from it? Why is that not enough? Why do they also have to keep doing more after that? If you disagree with the notion of someone publishing their work under a free software or open source license being useful for the world, then please post an AskHN about it and you will have _plenty_ of material t…

It is enough, and I don't disagree with "the notion of someone publishing their work under a free software or open source license being useful for the world." I have simply no idea where you got the idea that I would disagree with that. What you are responding to is a rhetorical response I gave as an argument against the dismissive idea that an open source maintainer should have no responsibility unless they are gett…

> I have simply no idea where you got the idea that I would disagree with that.

"If that's the case, then why open source it at all?"

This is the part which made me feel you disagreed with it.

However, may I ask if it is your belief something released under an open source license comes with an intent to maintain it (for others)? Or that releasing something under an open source license is a declaration of being a maintainer of said software?

(not trying to be snarky and am just trying to see why we appear to be in disagreement)

Re: A Sad Day for Rust

#788

Post by zozbot234 »

Traster wrote: post #775
zozbot234 wrote: post #420

Earlier quoted context omitted.

Being negative and snarky about crappy, hacked-together code that might cause security issues all over the place is not a bad thing. Yes, most of the snark there is about 'http' crate with its weird custom implementation of basic data structures.

'Crappy' and 'Hacked-together' are literally just insults, they don't carry real technical criticism and frankly they just continue to undermine the credibility of the author. The fact is that 'crappy' code is the most used http crate by far. Clearly everyone in the rust community must be an idiot to be using it. I'm sure the author went off and wrote a totally safe replacement for it. See, now we all get to be dicks…

The first step in working to fix stuff is being aware of the issues - there's nothing "insulting" about that. Unsafe blocks without any clearly-stated rationale and safety analysis is quite subpar quality. Just because it's common and a "most used crate" does not make it OK, leftpad was widely used too.

Re: A Sad Day for Rust

#789

Post by ncmncm »

cthalupa wrote: post #757
manish_gill wrote: post #26

Earlier quoted context omitted.

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

>People could have forked and worked on the issues themselves, but that's asking too much. 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 t…

No. Fork anytime you want to use something in production and don't consider it right.

Post pull requests if you care to, and post your fork, too, if you like, being careful to keep clear that it is a different project.

Some forks wither, some surge, some re-merge. It's all part of the dance. Any of it is better than flaming somebody who makes a thing and offers it.

Re: A Sad Day for Rust

#790

Post by fsckboy »

zzzeek wrote: post #713
fsckboy wrote: post #651

Earlier quoted context omitted.

But rationality (in the human sense) is completely governed by emotion. Curiosity about an unsolved problem? that's emotional regulation of the brain. Satisfaction that a problem is solved? also emotion. Beauty in a better solution? emotion. This has significance, it's not just a restatement of "the problem" using different terminology. It's significant because the brain, like every other part of the body, evolved pa…

this does not negate the fact that a breakdown in rationality is also caused by emotion. the human brain is emotional throughout. however the part of it that has "rational debates" is not an intrinsic behavior. that part is based on cognitive skill which will perform to a greater or lesser extent based on current brain state. if the amygdala is active in a state of fear or anger, "rational debate" skill will be compr…

now this time I will employ simple restatement to help convey the point I'm making--and for you to be rational is for you to first simply understand what I'm saying; arguing back is not entirely rational, it's actually an additional emotional step:

think of rationality of the brain like a signed vs unsigned char in most implementations of C, basically a byte: you could think of a byte as 0-255 or as -127 to +126. The brain is an emotional organ. Rationality is the best possible outcome, but it's not the default state; the brain doesn't function from 0 to 255 rationality, it functions from -127 to +128.

I say it this way because you talk about rationality "breaking down" as if it's some sort of default. I don't think of it that way. Rationality is something we hope to build up to and are lucky to achieve, but our default state is animal passion.

I'm not trying to convince you to change what you think, just using some restatements to open your thinking to the way psychiatry views the brain.

Post reply on HN