261–270 of 1001 posts
LOL rust is a shit language that will never replace C, and this situation was entirely predicted by doubters, despite the assurances of rustophiles who claimed unsafe was not a problem, won't be abused etc. The emotion unveiled by this incident shows a deep anxiety in the rust community that the doubters are correct. C forever!
Perhaps you'll be better received in another forum, but this is unwelcome here.
If you think loading your expectations on to an unpaid volunteer and then harassing them over it will work out, hopefully this moment is a good learning experience for you.
(Unfortunately, I can see from reading the comments that not everyone is getting it.)
Perhaps someone should create an OSS contributor agreement where contributors explicitly agree to work long hours, for free, in perpetuity, prioritizing issues based on reddit heat, and see how many developers agree to those conditions. Those are the expectations that appear to have driven this developer to quit their project.
BTW, for those that don't know: acting on bug reports and accepting pull requests is often a lot of work in its own right. Bug reports are often vague, incomplete, contain incorrect assertions and assumption, lack clear steps to reproduce or even a clear description of what happened vs what was expected. It takes time a effort to clarify these things. Even then you may need to, e.g., build an environment to reproduce or correct the issue. Changes from developers that aren't highly experienced with the project typically have gaps, new bugs, misunderstand requirements, don't build, ignore style conventions, lack unit tests, and have various other issue that have to be ironed out before the change can be accepted. It's all a lot of work.
> “Why Reddit is like this” is a whole other essay; I think it’s built into reddit’s structure itself. Classic Eternal September. Around 60k subscribers, the cultural identity starts degrading, as the amount of "old guard" is outmatched by "new blood." Therefore, the old "monkey see, monkey do" phenomenon, where new users would slowly mimic the culture of the prevailing older users to "fit in," is replaced with new u…
It might not be just reddit though. The author's summary points to a volatile combination of elements in Rust itself: 1) [T]he Rust project saw Rust as more than just the language... 2) unsafe... is a really important part of Rust, but also a very dangerous one, hence the name. If a project is considered to be not just a project, but something closer to a cause, people are going to defend their understanding of that…
Is it really a value judgment? Coming from a formal PL background, I had just assumed that the "unsafe" keyword was referring to the PL concept of "safety", AKA "soundness", which has a specific technical definition, and not that it was necessarily a value judgment. In that context, "unsafe" just means "the compiler can't guarantee the behavior that it can normally guarantee".
Earlier quoted context omitted.
IANAL but I'm fairly certain this protects you against legal action and not negativity on the internet. Furthermore, if we're to interpret this clause as "do not place any trust in this software whatsoever" then I guess that's really bad news for the security community at large.
From the grand parent: "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." The reply: "THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING ... FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT." Furthermore, from the GP: "No one expects you to wri…
If you have voluntarily assumed the role of maintaining an open source project, it's perfectly reasonable for people to expect you to address merge requests and issues on the issue tracker. It's reasonable to expect a maintainer to process technical arguments and justify their technical decisions.
The maintainer of course has no legal or moral obligation to perform any of these tasks. If he should ignore these assumed responsibilities, the users of the software can react in multiple ways. They can fork the project or use something else. In both cases they are also completely and utterly within their right to put into question the reliability and credibility of the aforementioned maintainer. Especially where it concerns software that people rely on for critical processes.
All the "as is" clause means for security concerns (apart from its legal implications) is that the burden of making these guarantees lies on the community, and not the emitter of the software. It does not mean you should have no expectations of it at all and to suggest so is, frankly, nonsense.
Lastly, I think if anyone is "entitled" to anything, it's respect. If the developer of actix truly felt like he was not getting the respect he deserved then his reaction is completely justified.
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.
> 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.
The problem wasn't the criticism, but the expectation that said criticism invokes a certain behavior of the maintainer.
You can criticize open source maintenance by creating a fork in which you outline your vision (e.g. "much less use of 'unsafe' in the web package") - and deal with the burden of being a maintainer.
Everything else is just trying to force people to do stuff for you, and that's rude.
LOL rust is a shit language that will never replace C, and this situation was entirely predicted by doubters, despite the assurances of rustophiles who claimed unsafe was not a problem, won't be abused etc. The emotion unveiled by this incident shows a deep anxiety in the rust community that the doubters are correct. C forever!
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…
> 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…
I'd consider it to be social norms. It certainly isn't entitlement.
Earlier quoted context omitted.
I'm not sure which license was used by actix-web, but let me quote the last section of the MIT license as a reply: > THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILIT…
> I'm not sure which license was used by actix-web, but let me quote the last section of the MIT license as a reply This is a really bad answer because the most reliable and robust free software projects out there all use this same boilerplate license warnings. This is just for legal protection.
Think of MIT’s warranty disclaimer as the “free tier” of service.
Earlier quoted context omitted.
Of course you can criticize, but people are continuously demanding things, like "he should have labeled it as a toy project", "he should have given reasons why he didn't accept the patch", etc. And Drew is very right to say: No, he didn't have to do any of that.
You are right that he didn't have to do any of the things people pointed out but that doesn't mean choosing not to do them isn't fair game for criticism and "he should have labeled it as a toy project" and "he should have given reasons why he didn't accept the patch" seem more like fair criticisms than making demands.
Those are demands. The toy project one is relatively low cost, but "he should have given reasons" brings with its lots of effort to do right - and then you get to do it over and over again, because the masses can fling shit at you faster than you can reason about it.