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

701–710 of 1001 posts

Re: A Sad Day for Rust

#701

Post by oaiey »

mottosso wrote: post #468
ckdarby wrote: post #441

Earlier quoted context omitted.

> Open source participants are volunteers and owe you nothing. Equally, someone gets hit by a car while crossing the road. I don't owe them anything to go help them but society, morality and being decent are these unwritten rules that kind of do force you into owing something. Yes, I agree, volunteers don't owe anything but there are some unwritten rules that when broken should be frowned upon and I'd probably go as…

Here's another one. 1. Someone writes a library 2. Library becomes insanely popular 3. Users receive value out of library 4. One day, users stop receiving value from library Is the author not responsible for the value generated by this library? At what point does the author become required to continue providing value? "Just fork it" is an excellent response to (4), anything else is what entitlement looks like.

There should be a "then take over maintenance" option. A good maintainer also steps back and hands over the project. That is less troublesome for the community I think this is a good practice.

But ignoring good practice: a unpaid maintainer owns nothing to anyone.

Re: A Sad Day for Rust

#702

Post by temac »

deng wrote: post #155
cforrester wrote: post #129

Earlier quoted context omitted.

That doesn't mean it's wrong to criticize his choices, so long as it's done without being insulting.

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.

> he didn't have to do any of that

Of course he didn't, in the legal sense of the term. And then people didn't have to stop criticizing him, in the legal sense of the term.

And obviously for the ethical / moral point of view, people have vastly different opinions, otherwise there would not be this debate.

Re: A Sad Day for Rust

#703

Post by ambrice »

TuringNYC wrote: post #562
ambrice wrote: post #531

Earlier quoted context omitted.

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

I think his advice is to purchase a licensed product with a paid support package if you need an SLA.

In my experience licensed products with paid support packages aren't any more secure, they just let you pass the buck when things go wrong.

Re: A Sad Day for Rust

#704

Post by zymhan »

sigstoat wrote: post #655
PhaseLockk wrote: post #569

Earlier quoted context omitted.

> You could (and perhaps should) take the opinion that one should care about security, but there is no obligation (legal, financial, or moral) that requires an open source maintainer to care about anything. I was taught that part of being an engineer taking a moral responsibility for the safety of your creations. I know that the field has changed quite a bit, and that people in open source come from many different ba…

> I was taught that part of being an engineer taking a moral responsibility for the safety of your creations. almost certainly in the framework of being employed or contracted to do engineering work. go back and ask your teachers what they felt they owe people asking them to design things unpaid, in their free time.

If I build something in real life, like a playground, and ask people to come use it, but then through my own negligence it falls apart and becomes a hazard, it is my fault for having created this situation in the first place.

Idk why this keeps getting tied back to paid/unpaid. I can think of many a situation where someone gets paid, and also doesn't care at all to help.

Re: A Sad Day for Rust

#705

Post by oaiey »

There is a Code of Conduct. Question: is there a Code of Maintainership.

A document describing the principles the maintainer tries to uphold?

Re: A Sad Day for Rust

#706

Post by danmg »

You can submit patches upstream all day long, but you can't browbeat the maintainer into applying them if they don't really care about it. It's their project at the end of the day.

Likewise, it's just as annoying when you submit a PR on some random thing because you see a legitimate bug or unhandled case and the maintainer starts demanding you do more free work for them to do 100% they way they would have done it. Just say "thank you", accept it, and make those superficial edits.

The price point here is free. This is essentially a gift economy. Just because some random strangers on the internet have an interest in the same few bits of code, doesn't mean there is an obligation to do free work or twist someone's arm.

Re: A Sad Day for Rust

#707

Post by UncleMeat »

makomk wrote: post #176
deng wrote: post #157

Earlier quoted context omitted.

> 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 n…

Yes. I would expect there to be vulns and inconsistent patching for all OSS that I depend on and where I don't have a professional contract with its maintainers.

Re: A Sad Day for Rust

#708

Post by AnonymousPlanet »

UncleMeat wrote: post #397
AnonymousPlanet wrote: post #143

Earlier quoted context omitted.

> It's not like he was getting paid to work on this, was it? That is completely beside the point. Do the Debian maintainers that were responsible for famous security slipups regarding SSH keys got paid? No. Would the backlash if they had been unwilling to fix the issues been warranted? Absolutely. Once you are a part of people's infrastructure and these people rely on you to not be irresponsible, you can't afford to…

Some floss developers choose to work for free. That’s fine or even admirable. That doesn’t mean that everybody needs to. If a dev isn’t being paid then they should have the absolute right to refuse all maintenance or even just destroy the project. I’d keep my code closed source if there was a risk that it would start getting used and suddenly I’ve got an extra job for zero pay.

> Some floss developers choose to work for free. That’s fine or even admirable.

Uh, yes. I agree.

> If a dev isn’t being paid then they should have the absolute right to refuse all maintenance or even just destroy the project.

Where in my post did I say they cannot quit?

> I’d keep my code closed source if there was a risk that it would start getting used and suddenly I’ve got an extra job for zero pay.

I'm with you.

I have the feeling, you are replying to a different post or didn't read mine fully.

Re: A Sad Day for Rust

#709

Post by jpab »

jpab wrote: post #434
btrask wrote: post #188

If your language promises some kind of new feature (e.g. "safety") but offers a back door you could drive a truck through (e.g. 'unsafe'), then ensuring that back door is used appropriately and in good taste comes down to culture policing , which, as we've learned in other areas, is something the internet does not handle well. As the Rust community grows, how can it ensure that people use 'unsafe' tastefully? Well, i…

I would prefer to see a positive badge for "this project doesn't directly use unsafe" or similar, which maintainers can choose to put in their README in the same way that they currently put build-status, test-status and other badges. The actual badge state is produced by tooling (a CI system) so it stays up to date and you can follow a link to a (tooling generated) report with more info, so it's relatively easy to ve…

Oh, and apparently there is something vaguely along these lines already:

https://github.com/rust-secure-code/safety-dance/

Post reply on HN