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

561–570 of 1001 posts

Re: A Sad Day for Rust

#561

Post by notyourday »

fragmede wrote: post #516
notyourday wrote: post #437

Earlier quoted context omitted.

The level of entitlement here is absolutely insane. If the community cares about security then should this happen: > Sure, but once you’ve forked, now you have a fork only you use, but which you know is more secure than its upstream for reason X. That’s an unstable equilibrium—you want others to know of your fork, and to switch to it, so that other downstream projects can also be more secure. The community would move…

Following Dave Rand's framework, the conversation went something like: "Atrix-web should not use unsafe" "Thank you for volunteering - you are now in charge of making atrix-web not using unsafe" "Thank you for delegating responsibility of making atrix-web not use unsafe, to me. I accept responsibility for this piece, but you are still the leader of $PROJECT." "Here is a PR that makes atrix-web less unsafe." "I don't…

None of the people made it safe because it is not in the code.

Fork it, make it "atrix-web-safe", post about it on whatever rust announcement list/forum/group is and have people move to the "atrix-web-safe". That's leadership. The rest is moan-fest.

Re: A Sad Day for Rust

#562

Post by TuringNYC »

ambrice wrote: post #531
zzzcpan wrote: post #507

Earlier quoted context omitted.

Everything you ever used in production is "production-ready". The bar is super low, there is no deception here. The security thing is particularly interesting here. If you care about security even a little bit, you absolutely cannot rely on a random third party to provide timely updates or at all, especially for free. A lot of software doesn't even provide basic security necessities to the point, where OS packages ma…

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.

Re: A Sad Day for Rust

#563

Post by mratsim »

compiler-guy wrote: post #376
wbl wrote: post #141

Earlier quoted context omitted.

Do you think we get software like zlib and libjpeg and BLAS and linpack by people shrugging off working for the community and failing to fix bugs? Otherwise we get dozens of half broken forks all over the place. That's no fun for anyone. This wasn't a drive by beg. This was a patch solving real demonstrable problems and at minimum there should have been a transition plan due to basic decency.

"The maintainer owes the community something, simply because the community decided to adopt the project." Doesn't work that way, I'm afraid. The maintainer already gave the community something, and doesn't owe them anything more.

They owe people who write PR basic courtesy, not refusing patches on ground that it is "boring".

Re: A Sad Day for Rust

#564

Post by cfv »

The guy has absolutely 0 obligation towards anyone. There was 0 money exchanged, there were 0 contracts signed, he's free to take his ball home.

Hope the people who caused this are happy now.

Re: A Sad Day for Rust

#565

Post by ryandrake »

landtuna wrote: post #114
rhodysurf wrote: post #79

Earlier quoted context omitted.

As someone who works for a dod contractor this whole situation sounds crazy. Just because something is available as a crate doesnt mean you are to assume it safe or appropriate for your use. The onus of verifying the dependencies should always be on the consumer.

Haha - also a dod contractor, and sometimes wonder whether I'm the insane one who can't handle the wild west behavior of HN people surrounding npm packages...

No, you guys aren’t the only ones. Not currently a defense contractor but was one in a previous life. Whenever I read articles and comments here on HN about dependency management I break out into sweats. It’s shocking how cavalier people are about pulling in third party dependencies, and this dismissive attitude about risk management: what exactly it is that the dependencies do, how suitable they really are for the project, what happens if they become not suitable (contingency plans), how auditable and traceable changes are, etc.

It’s just “npm install” and YOLO for a lot of developers!

Re: A Sad Day for Rust

#566

Post by dcolkitt »

ddevault wrote: post #38

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

This is a nice idea, but in an era of one-button package managers it just doesn't work like that. You're trying to fight against New Jersey style. Which in the entire history of software has never been a winning approach.

The reality is that for 95%+ of active software developers, done is better than perfect. Yes there may be a small subset of developers working on super-critical defense systems or nuclear reactors. Who have the time, resources, know-how and organizational support to meticulously and carefully audit all of their dependencies.

But the vast majority of developers are not in these types of environment. The mantra of the entire tech industry is "move fast and break things". Try being a Silicon Valley startup engineer and trying to justify to your manager that you could standup functionality with one call to "npm install", but that's not sanitary and you need to audit the entire dependency tree. Now assume that the next round of VC funding for your cash-strapped startup is on the line. How well do you think that concern will go over?

The reality is that if something can be instantly installed in 30 seconds, then it will be. We can give as many "caveat emptors" as possible, but convenience trumps safety every single time.

The way to solve this is to enforce consistency on an ecosystem level. The best example of this is the Debian project. There's very firm guidelines about QA and safety before a package is allowed into stable. The Debian people are probably right about another thing too: language-level package managers should be considered harmful.

Many of these problems could be avoided if we strictly used apt-get instead of pip, crate, and npm. For one distro maintainers tend to have a lot more experience and competence at evaluating stability and safety. Two, since a system only has one distro package manager, but potentially many runtime environments, it prevents a race to the bottom. Harried developers will just gravitate towards the least strict runtime with the most low-quality packages.

This lesson is probably very tough for the Rust community to swallow. Crate is considered one of, if not the most, compelling features of Rust. If we acknowledge that it was a mistake, it really undercuts the argument for adopting Rust.

Re: A Sad Day for Rust

#567

Post by mratsim »

mlthoughts2018 wrote: post #198
ddevault wrote: post #38

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

> “ 2. Open source participants are volunteers and owe you nothing.” Absolutely not. They are compensated with prestige, enjoyment, decision-making power, future employment rewards, and sometimes even money, all of which was their choice to pursue through their labor and time spent on the open source project. The users of open-source projects, upon which the projects themselves depend, are also not obligated to anyth…

I didn't think I would see a "I will pay you with exposure" argument.

Re: A Sad Day for Rust

#568

Post by braythwayt »

floatingatoll wrote: post #458
braythwayt wrote: post #274

Earlier quoted context omitted.

My viewpoint is as follows: 1. Just because a thing exists, does not give you the absolute moral right to criticize it, especially in a way that is toxic for the person or persons that created it. Criticism affects both the people criticized and the community/universe at large, and not always in positive, productive ways. 2. Just because a thing is free, does not grant the thing or its creator absolute immunity from…

#1 is imprecise to me in one respect. Critiquing someone's actions and choices is a founding principle of open source software, politics, and in general most human culture. "I think it was wrong to delete the GitHub issue because my belief structure XYZ" is acceptable. Critiquing someone personally based on their technical choices is not acceptable. Reddit allows it, and thus Reddit is unusable as a social platform f…

I agree with your point. Personal criticism should be extremely rare, and very carefully handled. A thread in a public forum is almost never the right place for it.

Here is an entire essay touching on the subject:

https://github.com/raganwald-deprecated/homoiconic/blob/mast...

And the HN discussion at the time:

https://news.ycombinator.com/item?id=589200

Re: A Sad Day for Rust

#569

Post by PhaseLockk »

cmsj wrote: post #530
logophobia wrote: post #475

Earlier quoted context omitted.

It was advertised as a production-ready web-framework, and it was very popular. When do people get to complain? "Oh, my credit card information was stolen due to memory issues in this web-service, it's fine though, we didn't pay the guy, so we can't blame him.". Web-frameworks are cornerstones for security, and if you write one, advertise one, you need to care about security. Features, code-style, ad-hoc PRs, bug-fix…

> if you write one, advertise one, you need to care about security The word "need" there is wrong. 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. If you want those obligations, get a contract and pay some money. What's happened here, and you seem to have fallen…

> 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 backgrounds. But I think it's reasonable to hold as an ideal that there is a moral responsibility to at least make sure people using your stuff understand what they are getting into. And that such a moral responsibility would require more than disclaiming liability.

Re: A Sad Day for Rust

#570

Post by eropple »

virtue3 wrote: post #455
eropple wrote: post #380

Earlier quoted context omitted.

> I would be very unlikely to accept a patch that simply changed the internal typings for the abstract goal of “fewer any”s. Why would you possibly not? Increased correctness, no change in runtime behavior, and a resistance to code rot and mistakes on your next concrete change. Passing up on such a PR would almost immediately disqualify a library from further use unless I could manage a fork.

> Passing up on such a PR would almost immediately disqualify a library from further use unless I could manage a fork. It's a bit disingenuous that you can accuse someone of being absurd for not doing something, and then mentioning in the same breath that you "might not want to" as well. I'm merely saying that for the sake of pointing out that maintaining a project is a PITA and we should all really accept that.

It's not disingenuous; I have a number of open source projects on my plate already. I probably can't take on more. But if somebody hands me, for one of my projects, a set of typings that compiles clean in TypeScript (and, seeing as how it's a compiler, that's a really trivial thing)? I'd be literally-not-figuratively out of my mind to not say "thank you" and take them. Failure for another maintainer to do so means that they are a business risk for me that I should not entertain.
Post reply on HN