I've personally wondered at credit scores + credit offered for a long time. The amount of regulation provides wonderful cover for these big institutions to really do whatever they want and lean back on "algorithms" / that they can't override the policy due to regulations, etc. Meanwhile, it's becoming more clear that the algorithms have encoded biases. In addition, the whole credit system is not one of those things you can opt out of (if you ever want a home or car, which I get, not everyone needs), and the whole thing is based on previous borrowing, so responsible (using cash) or underprivileged (never had the chance to start the credit bootstrap) folks are extremely disadvantaged.

The interesting twist in this story that I find damning is that Apple actually overrode the algorithm due to pressure -- this pokes a HUGE hole in this "cover" these institutions have created to date.

Comments URL: https://news.ycombinator.com/item?id=21291593

Points: 6

# Comments: 2

It should be noted that your example was not bad source, so rigorously reviewing source code would not have helped. It was an unpublish event which was unexpected but is now differently handled by the package managers + registries.

In this case, if the datastructure or algorithm were useful to your project, you could: 1. Not use the algorithm / data structure at all, resulting in worse performance. 2. Hand roll your own version which is more likely to have improper implementation issues than an OSS version, likely resulting in performance or security issues and wasting your time. 3. Use the OSS version which is likely to have bugs / errors / security issues already solved.

Comments URL: https://news.ycombinator.com/item?id=19730723

Points: 12

# Comments: 0

Figuring out which files change is relatively easy (as you've demonstrated). Figuring out what the impact of that is quite hard in non-compiled languages (tools like Maven, Buck, Bazel, etc do this well for compiled languages). I.e. In a repo which is primarily JavaScript, I can get the list of changed files, and hopefully have unit test files which are obviously linear to those. However, knowing if these are depended on by other files/modules (at some depth) is much harder. Same for integration tests -- which of these are related?

For small samplesets, going deep to understand unnecessary writes, tuning the clients and showing less SSD wear after tuning would be interesting. Or, assuming you have more than 1 client of each of these situations aggregating the data to show patterns would be far more useful. As has been mentioned elsewhere, for inspiration, Backblaze has really nice posts analyzing their device wear.

While it's easy to say "just trust apple, they're doing it for the shareholders," I think it's also fair to say that they're losing their touch in this venue.

It used to be the only reason you didn't buy a Mac for pro creative-type work was the price. Now there are many great reasons from ergonomics to computing power.