This is a sad day for open-source at large, as well. I think it's very important to keep having conversations about proper stewardship of open-source projects, until we eventually reach new models that are more fair/reasonable.
A Sad Day for Rust
351–360 of 1001 posts
Re: A Sad Day for Rust
#352I've written a lot of Rust code that's in production in web, messaging and telephony contexts. I considered using Actix early on, but as soon as I saw the large amount of unsafe code, I stopped considering it at all.
I did not go on the Internet and try to convince other people not to use it. I did not complain at the maintainer that he should manage his project differently. I just didn't see why a library doing what Actix does should use any unsafe code at all, so I didn't use it.
When I later saw the way the maintainer responded to well-meaning bug reports, including patches, that validated my decision.
There's no need to flame people for running their open-source project the way they want to run it. You can just not use the code.
Re: A Sad Day for Rust
#353> there’s this style of response
This type of reprehensible response will keep happening until society finally learns how the internet fundamentally changed the nature of fame. The best explanation of the problem is the video "This Is Phil Fish"[1] by Innuendo Studios. If you haven't seen it, please watch it. It's not about Phil Fish; he is simply a useful example of how fame works on the internet. Please watch the video!
The core problem is that fame used to be opt-in. Becoming famous required infrastructure. Gaining access to that infrastructure required the permission various gatekeepers, time, and resources. You had to work to become famous, because media access was a scarce resource.
On the internet fame became something that happens to you, because the internet IS media access. We're used to seeing fame as something that was chosen; if you didn't want to be famous, you could walk away from the media infrastructure and go back to your "normal life". The famous band could quit touring. Now that everyone has media access, that "normal life" can become famous directly. When that happens, walking away from fame means walking away from your normal life.
Re: A Sad Day for Rust
#354Earlier quoted context omitted.
> 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 anything in the slightest. I don't think the anger is directed at there being security issues, the anger is directed at the fact that even when security vulnerabilities where found and patched, there was major pushback even getting those patches merged into the library.…
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.
As a maintainer, I treat almost all PR submission with kind words.
What actix developer did was, to pardon my French, inexcusable. Deeming security patch boring? Making your own `Cell`, implementing it badly and misusing it, because it's faster on some stupid benchmark site?
If we designed cars like that, they would have no breaks, no gears and no cabin.
Honestly, I think it's better Rust abandons `actix` asap. Before it gets any real traction.
Re: A Sad Day for Rust
#355Earlier 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…
I reject the axiom. No one is above criticism provided the criticism is rooted in fact (i.e., defamation is not criticism).
Re: A Sad Day for Rust
#356The "unsafe" keyword should probably just be called "unchecked," otherwise it is a bit of a misnomer.
Re: A Sad Day for Rust
#357A 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…
> 1. YOU are responsible for your dependencies. They not only created issues, they also created patches. That is taking responsibility. They were contributing time and expertise back. Having a project maintainer then call those patches boring or otherwise disregard them? That's childish. He showed time and time again he would respond without civility when an issue was demonstrated in his code. Sadly, that led to some…
Did the patches obviously maintain the exact same behavior? If so, why should the author care about them? If not, it’s not the author’s responsibility to ensure they’re correct patches, but it is the author’s responsibility to ensure their package is correct. If it was correct already (not sure about this, but it seems it was very popular and used in production, so I imagine it worked well), they have no responsibility to vet incoming patches that do nothing besides change internal workings for the sake of changing internal workings.
I don’t write Rust, I write TS. If I produced a package that was had a clean and correct TS interface, but internally was filled with dirty dirty `any`s, I would be very unlikely to accept a patch that simply changed the internal typings for the abstract goal of “fewer any”s.
Re: A Sad Day for Rust
#358A 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…
> 1. YOU are responsible for your dependencies. They not only created issues, they also created patches. That is taking responsibility. They were contributing time and expertise back. Having a project maintainer then call those patches boring or otherwise disregard them? That's childish. He showed time and time again he would respond without civility when an issue was demonstrated in his code. Sadly, that led to some…
> 2. Open source participants are volunteers and owe you nothing.
The two rules work in concert.
Re: A Sad Day for Rust
#359I remember when people were claiming Common Lisp community is toxic, but I find that it is the languages which tend to focus on "building community" with Community Managers and Codes of Conduct that end up becoming truly toxic cesspools in the end. See also node.js. The focus on community attracts people who aren't interested in programming, but rather those who want a playground for gaining clout and trolling. You n…
There was incredible amount of Linux drama all the time and they did not focused on community.
The tor project was like, the most dramatic project on Internet for a while till they started to focus on community a bit more.
So I don't think premise holds.
Re: A Sad Day for Rust
#360This problem wouldn't exist if the people who wanted changes were willing to write a big enough check. If you get your code for free, you shouldn't expect anything of the person giving it to you. They have already given you more than you are entitled to.