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

171–180 of 1001 posts

Re: A Sad Day for Rust

#171

Post by jeltz »

steveklabnik wrote: post #139
jimbokun wrote: post #108

Earlier quoted context omitted.

All of this is second hand, where are the mean comments "making" this person quit their own project? Were they actual personal attacks, or just criticism of the code? If you can't accept legitimate criticism of your work, that shows a real lack of maturity. (The article didn't give concrete examples, so I don't know which is the case here.)

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

Yes, that comment was not ok but as far as I have seen that is the only comment which keeps getting quoted. All but a handful of people seem to have been civil.

Re: A Sad Day for Rust

#173

Post by vmchale »

That's my experience too, particularly lately. Reddit/HN both is and isn't the Rust community, but everyone there is a disaster for all the reasons the wider programming world is a disaster.

Re: A Sad Day for Rust

#174

Post by clarry »

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…

Who is we?

People who write security sensitive toys and don't care enough to vet their deps?

Professionals who profit off security sensitive programs written on top of others' free work without paying a dime?

I don't think either group is in a position to make such demands.

Re: A Sad Day for Rust

#175

Post by jraph »

steveklabnik wrote: post #30
spamizbad wrote: post #25

Question: why didn’t the more safety-focused developers just fork the project? I feel like fork-o-phobia causes 90% of the incidents like this.

Forking is extremely aggressive, and just because someone has the time to write a patch doesn't mean they have the desire or time to run a project.

Forking can be friendly too.

I wanted SimpleProtocolPlayer to be in F-Droid. This requires the author's explicit consent. Unfortunately, the author had not been seen active on the project for a while and did not respond to our questions.

I forked the project so I could be the "author" and give my consent (yes, clearly a hack), told them about it, and my willing to merge back at any time. See [1] if interested.

They eventually told me they were fine with the fork, and preferred having a fork for the F-Droid version of the app so we did not have to rely on their responsiveness.

My fork included a fix that they merged.

Some situations warrant a fork, and if communication (about the intents, the means and the expectations) is handled as best as possible, the fork can be seen as friendly by everyone.

You are right though, I would not want to become the maintainer of projects I sent a patch to. And by the way, I did not really want to become the maintainer of the F-Droid version of SimpleProtocolPlayer at first, but this is fine.

[1] https://github.com/kaytat/SimpleProtocolPlayer/issues/21

Re: A Sad Day for Rust

#176

Post by makomk »

deng wrote: post #157
izacus wrote: post #145

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

> 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 now about the damage compromises can do and the resulting legal climate.

Re: A Sad Day for Rust

#177

Post by wgerard »

throwlaplace wrote: post #163
izacus wrote: post #145

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

no your argument isn't useful. the question is never about rights because we all know what the maintainer's rights are (so it's always a discussion of obligation). if you accept that the open source projects are voluntary as an axiom then you in fact cannot criticize choices made by the volunteer. here's an analogy: a homeless person asks for money. you don't give him money but buy him food. can the homeless person r…

Here's another analogy:

A homeless person asks for money. You don't give him money but give him some advice. Can the homeless person rightfully criticize you?

You can absolutely criticize choices made by volunteers. I don't think you need to think too deeply about this to imagine situations where few would object to criticizing a volunteer's behavior. An obvious one would be if an open source maintainer willfully included malware/etc. into their project - which, to many people, ignoring glaring security issues is vaguely equivalent.

I obviously don't think vitriol is warranted ever, but criticism obviously is from time-to-time.

Re: A Sad Day for Rust

#178

Post by steveklabnik »

duxup wrote: post #133

Help me out here is actix-web some sort of software that is integral to Rust? If not ... I get the idea he wasn't really welcoming of the changes but at the same time. It's his code man. I came from the world of networking and etc and the world of programming has a great deal of personal preferences / hypothetical problems / "we don't do that at my workplace" stuff pushed under the guise of technically correct ... so…

Integral? No. Used in production, by companies? Yes. Outwardly visible? Absolutely, due to Techempower.

Rust will survive without actix, but losing it is a setback for Rust in the web space.

Re: A Sad Day for Rust

#180

Post by boutad »

jwlake wrote: post #74
adar wrote: post #50

Earlier quoted context omitted.

From what sklabnik's post says, patches were submitted but the author wasn't really receptive to them.

I honestly dont understand people being mad at this. Every dependancy I use I don't like 100% I fork and modify and then upstream changes, and if they never get merged, who cares? If there was a big user community that wanted different things, fork and have a seperate maintainer structure. Why drama?

Then you might end up with a bunch of different forks each with different fixes applied.
Post reply on HN