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

861–870 of 1001 posts

Re: A Sad Day for Rust

#861

Post by Uehreka »

AnonymousPlanet wrote: post #730
Uehreka wrote: post #451

Earlier quoted context omitted.

I’d argue that if a company has a larger than normal dependency on keeping a project running (like a cloud provider with 1 million VMs running Debian or Debian-based OSes) they should hire a full time employee whose sole job is to work on it. I think the basic rules still apply: You’re getting this software for free rather than paying for something expensive. Though you deal in the software, you get no guarantee of i…

> You’re getting this software for free rather than paying for something expensive. So open source is free as in beer, not free as in speech after all. And the reason a company might choose to use open source is solely because it's free, not because they can see the source code or alter it? Because that is why companies are in it, not because they were cheap for the small cash of a paid version. And they're in it bec…

> This "it's free so you get what you paid for, and if it's shit don't complain because it was free" really rubs me the wrong way. It's a very capitalist mindset that measures everything in money.

I mean like... yeah.

If I'm maintaining an open source project as a side gig or for fun, I might be able to review and merge some patches. But if the corporations that use my project submit a busload of PRs (or worse, just issues with no solutions) and I end up spending so much time on them that I have no time to work on my dayjob and make rent... that's not gonna work.

Now if those corporations each chuck a hundred bucks a month (less than the cost of a single Developer's Enterprise MSDN subscription) my way, then sure! I'll scale back my freelance web dev work and spend half my workweek dedicated to maintaining this project!

So yeah, I think the corporations who make money off open source projects should be kicking back a bit of money to those projects if they want an expectation of reliability. It doesn't have to be a ton of money either:

- If we're talking about a tiny header parsing library that needs occasional security patches, maybe expense a few bucks at the maintainer's Patreon so they can spend 10 hours a year on those patches.

- If we're talking about the web framework that underlies your big newspaper's CMS, maybe have a developer spend 20 hours a month pushing well made PRs to fix the problems you care about.

- If we're talking about an OS like Debian and you're AWS, maybe hire a 3 person team to work solely on keeping it secure.

Re: A Sad Day for Rust

#862

Post by School-Cotton »

zpallin wrote: post #691
School-Cotton wrote: post #579

Earlier quoted context omitted.

There are many possible reasons, and yes, one is because they might hope it's useful to other people. That's not the same as being "responsible" for such usefulness.

And I agree completely. Except when you claim you're a "maintainer." If you do, that is supposed to mean something. And I think it means you're going to maintain the code. That's the only responsibility I am talking about.

Maintainer is a term of art that just means you’re the person in charge of the project.

Re: A Sad Day for Rust

#863

Post by zzzeek »

fsckboy wrote: post #790
zzzeek wrote: post #713

Earlier quoted context omitted.

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…

> I say it this way because you talk about rationality "breaking down" as if it's some sort of default.

I'm sorry, can you please explain how you come to this conclusion based on what I wrote:

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

I'm not really arguing with you, as your first point seemed to be some kind of "but what about...!" that didn't really negate what I was trying to say. However if you think I was saying something completely different, that would make more sense for whatever it is you're attempting to "argue".

Re: A Sad Day for Rust

#864

Post by munificent »

zzzeek wrote: post #612
munificent wrote: post #512

Earlier quoted context omitted.

People are not robots, but in terms of reaching agreement between humans, "emotion" is more or less just a difference in priorities, which is one of the ways reasonable people can disagree. If we agree on the facts and we agree on their implications, but we still disagree, it's likely because we weight things differently. Emotions are simply a large component for how we weight things.

emotionalism is strongly linked to irrationality. once someone is irrational I'm not following how that can be reduced to a "difference in priorities". I'm an open source maintainer of some very popular projects. more in the early days, I was certainly irrational on a few occasions where someone called out things that I did wrong and I refused to see it. It wasn't like I had de-prioritized "making sure the code is no…

> I was certainly irrational on a few occasions where someone called out things that I did wrong and I refused to see it.

I don't think that's a problem with the emotion itself, so much as which specific events trigger that emotion and how you chose to process them and react.

Having fear does not make you lash out at users. We all have fear, often about similar things. It's having fear associating with a person calling you out, and then failing to process that fear in a healthy way that caused you problems.

Very rational people still have lots and lots of emotions. They are not robots. They can just handle their emotions in a mature, mindful way.

Re: A Sad Day for Rust

#865

Post by kragen »

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…

> Forking projects should be a last resort

No. This was kind of true in the days of CVS and SVN. Now with DVCSs like Git, it's easy enough to merge in changes from wherever; this was the whole reason Tom Lord originally developed the modern DVCS. Git workflows commonly make a new fork for every bug fix. If other people don't want to merge in your changes, they probably don't think they're good enough. But that doesn't matter; you can still use them. If they're wrong, it's their loss.

Re: A Sad Day for Rust

#866

Post by AnonymousPlanet »

kelnos wrote: post #838
AnonymousPlanet wrote: post #683

Earlier quoted context omitted.

> I think this approach leads to sustainability problems, and discourages individuals from sharing their work in open source form. I make a project because I need it, and maybe it's fun to build. I generally share it because I think others might find it useful too. I don't believe that every little open source project is automatically held to the rules I described. But once your exposure gets bigger, you suddenly ent…

> But once your exposure gets bigger, you suddenly enter different waters. I fundamentally disagree with this. Just because my exposure has gotten larger (possibly through no action of my own), it doesn't magically give me more resources, more free time, more motivation, a team of developers, etc. If people (or companies) want to depend on a one-person open source project for something important to them, then they sh…

>> But once your exposure gets bigger, you suddenly enter different waters.

> I fundamentally disagree with this.

Don't get angry with me over this. I'm just the messenger

> I really dislike the lack of charitable interpretation given here, and this just contributes to the "entitled user" image.

Again, I'm just explaining to you how the world is not how I want the world to be. So don't call me entitled! Just read my posts maybe?

Re: A Sad Day for Rust

#867

Post by trunnell »

steveklabnik wrote: post #793
trunnell wrote: post #668

This seems to be a case of mismatched expectations. Many want Rust to save us from our current nightmare hellscape of vulnerability-ridden foundations. So actix-web comes along-- a Rust web framework that is faster than everything else including the C and C++ frameworks-- and people are filled with hope. It's fast and safe, right? But the actix-web maintainer says he built actix-web just for fun and to see how high h…

I do think it's legit to avoid libraries with a lot of unsafe code. I myself started avoiding actix after these situations. If folks had simply stopped using it, that would have been a fine outcome here. That's not what happened though.

Thanks for the correction.

Re: A Sad Day for Rust

#868

Post by mcguire »

"It’s unfortunate that a well-known project had soundness issues. It’s unfortunate that the maintainer wasn’t receptive to fixing them."

What should you expect in this case? What is the best possible response?

Re: A Sad Day for Rust

#869

Post by kragen »

roca wrote: post #841
joeblau wrote: post #574

I want to give a heads up to everyone who runs, or is thinking about running an open source project. If your project sees ANY notoriety and you are the maintainer, you will quickly find yourself in this situation. In 2013, I started a little side open source project and put it on GitHub which now has 5.2k stars. I've seen tons of arguments in my PR's over the previous 7 years. My project isn't even that large and I'v…

It must depend on the project in ways I don't understand. Certainly while working on Firefox I saw tons of toxic behavior from users, and sometimes potential contributors. I've seen it in lots of other projects that I haven't worked on. But for rr (4.7K Github stars) I have seen none whatsoever. I wish I could explain the difference, but I can't.

rr is only useful to people with a minimal level of knowledge, and in most cases to people who have stood in your shoes. Firefox is useful to any six-year-old with a cellphone. Maybe that explains the difference.

Re: A Sad Day for Rust

#870

Post by jlokier »

iudqnolq wrote: post #690
jlokier wrote: post #648

Earlier quoted context omitted.

I agree that should be the basic etiquette. Perhaps it needs to be said more clearly on project pages and codes of conduct and participation. (Of course, it is not reasonable to demand that an already-overworked maintainer-for-free find extra hours to have the pre-PR discussion either. It needs to be exploratory and respect the maintainers' timescales. Luckily, if you don't get the response you wanted, you can fork a…

> Of course, it is not reasonable to demand that an already-overworked maintainer-for-free find extra hours to have the pre-PR discussion either. It needs to be exploratory and respect the maintainers' timescales I absolutely didn't mean to imply that. I also think that a pre-PR discussion can be useful because if the maintainer doesn't have time to say they want a PR that's a decent hint they won't have time to hand…

Sorry if you thought I thought you were implying pressure. Not at all.

I thought your comment was helpful and supportive.

I just wanted to clarify, for readers, that expecting anything at any stage from a maintainer can be expecting too much sometimes. It is time and work for them after all, and usually it's in their limited personal time, for free.

Sometimes, they have already exhausted all the time they could put into the project; even a brief "thanks" email is too much when you have too many for whatever available time and energy you have. People don't always realise that, when they say "the maintainer should just [...]". A lot of people wanting [...] adds up.

Post reply on HN