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

531–540 of 1001 posts

Re: A Sad Day for Rust

#531

Post by ambrice »

zzzcpan wrote: post #507
logophobia wrote: post #475

Earlier quoted context omitted.

It was advertised as a production-ready web-framework, and it was very popular. When do people get to complain? "Oh, my credit card information was stolen due to memory issues in this web-service, it's fine though, we didn't pay the guy, so we can't blame him.". Web-frameworks are cornerstones for security, and if you write one, advertise one, you need to care about security. Features, code-style, ad-hoc PRs, bug-fix…

Everything you ever used in production is "production-ready". The bar is super low, there is no deception here. The security thing is particularly interesting here. If you care about security even a little bit, you absolutely cannot rely on a random third party to provide timely updates or at all, especially for free. A lot of software doesn't even provide basic security necessities to the point, where OS packages ma…

So, your advice is that if you care about security even a little bit, you should write all your software from scratch yourself?

Re: A Sad Day for Rust

#532

Post by jasondclinton »

kungtotte wrote: post #510
jasondclinton wrote: post #456

Earlier quoted context omitted.

You're lumping a few bad apples (apparently recruited from Reddit) in with "they". The users who found the bugs and provided patches were largely courteous considering the circumstances.

Steve Klabnik makes this point in his write-up, but I'm restating it here for clarity. You don't get to cherrypick who is part of your community or not when these situations arise. Those "bad apples" are part of the Rust community, and the Rust community needs to take responsibility for them the same way any community needs to take responsibility for their bad apples even if it's just to denounce their behaviour. Goo…

Should a politician be held responsible for every unhinged, vitriolic tweet by one of their supporters?

Re: A Sad Day for Rust

#533

Post by TrueDuality »

velcrovan wrote: post #211
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…

Backing up another level...it’s concerning to me when a language relies heavily on single-maintainer libraries for commonly needed functionality. If actix-web was this important, it should have been adopted by the community before now. Maybe languages need a way of setting the expectation to that if your library becomes essential to the community (and if licensing allows) the core developers are going to fork it and…

The developer actively fought against this for a very long time, even before the reddit shit storms. Yes the community could have forked the project and started independent development.

I'd argue that forking and developing independently of the developer is as big of a middle finger as a developer taking their ball and going home. It just depends on who is on the receiving end.

I don't think either side is right here, but I don't think creating a public fork and building a community around that is an unbiased and neutral response either and should only be done in extreme circumstances... Which is does seem like what happened here.

Re: A Sad Day for Rust

#534

Post by username90 »

This is the reason why Rust will never go mainstream. People say "You can get the same performance and features as C++ with unsafe!", but as happens in every language such hacks gets ostracized by the community and therefore basically unusable. So instead we just write our code in C++ which is unsafe by default so nobody complains.

Re: A Sad Day for Rust

#535

Post by anaphor »

juped wrote: post #509
anaphor wrote: post #492

Earlier quoted context omitted.

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.

Why even have the read-only mirror?

CI integrations, other tooling, etc can still be useful

Re: A Sad Day for Rust

#536

Post by mratsim »

virtue3 wrote: post #450
NewsAware wrote: post #361

Earlier quoted context omitted.

Well, from my perspective it seems common practice in most open source projects which are hosted on GH that maintainers at least consider PRs and typically only reject if the PR is flawed, incomplete or somehow adds feature creep. Of course any maintainer is free to handle it differently, but if going against usual expectations, it would be benefitial for all involved to note reluctance to PRs prominently to the Read…

It takes time to validate a PR, to test it, to verify it. He is not being paid for his time, he does not owe -anyone- his time. If you don't like the way a project is being run, fork it and own it yourself. I know that's harsh, and not idealistic, but it's the way people should really think about this. People take FOSS for granted, CONSTANTLY. And maintainers even more so.

The PR contributor was not paid either to investigate the bug, reproduce it, write a patch and test it.

However instead of raising a "don't work, please fix" bug s/he took the time to do all that.

Anyone that went to such length deserve basic courtesy, whether the code is accepted or refused.

Refusing a patch because it is "boring" is not respecting the time people dedicated to your project.

I would understand refusing because the patch makes an unwanted compromise on performance and the maintainer considers performance regressions as bug.

Re: A Sad Day for Rust

#537

Post by iudqnolq »

NewsAware wrote: post #361
aprdm wrote: post #337

Earlier quoted context omitted.

Where does it say he has to accept patches ? Couldn't they simply fork it instead of acting like entitled kids ?

Well, from my perspective it seems common practice in most open source projects which are hosted on GH that maintainers at least consider PRs and typically only reject if the PR is flawed, incomplete or somehow adds feature creep. Of course any maintainer is free to handle it differently, but if going against usual expectations, it would be benefitial for all involved to note reluctance to PRs prominently to the Read…

I thought basic etiquette was issue to discuss before PR?

Starting with a PR seems to me like saying "you have nothing to tell me about how your code works, I know exactly how your code should be changed and if my changes conflict with what you're working on you should throw your code out because mine is better".

Is that wrong?

Re: A Sad Day for Rust

#539

Post by rckoepke »

Turing_Machine wrote: post #508
logophobia wrote: post #475

Earlier quoted context omitted.

It was advertised as a production-ready web-framework, and it was very popular. When do people get to complain? "Oh, my credit card information was stolen due to memory issues in this web-service, it's fine though, we didn't pay the guy, so we can't blame him.". Web-frameworks are cornerstones for security, and if you write one, advertise one, you need to care about security. Features, code-style, ad-hoc PRs, bug-fix…

Holding people legally responsible for bugs in their FOSS code would be a good way to ensure that no FOSS code got written. Ever.

Legally, absolutely agree with you. GP's playground analogy was a particularly bad choice in that context.

Socially though - I don't see an issue with holding major projects socially responsible for egregious failure to fix security flaws. Public criticism is part of the open source model, it's the "many eyes" defense in action. Social pressure would be appropriate if Ubuntu just said "ahh, so, a worm is stealing every user's keystrokes. There's a fix for it but we won't merge it because we'd rather spend our time working on PulseAudio and systemd. If users want to use a forked version that will stop the keylogger, they are free to do so, but we make no guarantees our future changes won't break those forks."

Re: A Sad Day for Rust

#540

Post by rumanator »

logophobia wrote: post #475
BowBun wrote: post #343

Earlier quoted context omitted.

> Having a project maintainer then call those patches boring or otherwise disregard them? That's childish So what? Along the same lines, it's not a maintainer's responsibility to follow best-practices, respond to feedback/PRs, or respond in any coherent way to anything asked of them. The fact that you call them childish for not acting they way you want them to makes me think you are the childish one. With those PRs w…

It was advertised as a production-ready web-framework, and it was very popular. When do people get to complain? "Oh, my credit card information was stolen due to memory issues in this web-service, it's fine though, we didn't pay the guy, so we can't blame him.". Web-frameworks are cornerstones for security, and if you write one, advertise one, you need to care about security. Features, code-style, ad-hoc PRs, bug-fix…

> "Oh, my credit card information was stolen due to memory issues in this web-service, it's fine though, we didn't pay the guy, so we can't blame him.".

This is a good opportunity for you to read up on the license you explicitly agreed to in order to use said software in order for you to discover that that's precisely what you agree to when you use said software.

You don't owe the maintainer anything, nor does the maintainer owe you anything at all. The project maintainers donated their work to be used freely as is, and that's the full extent of what you are entitled to.

Post reply on HN