brokentone

Sure it has, reputable news publications as well as scientific journals issue retractions and updates as a matter of course. E.g. NY Times: https://www.nytimes.com/2022/06/30/admin/new-york-times-corr... Additionally, your example of Wikipedia directly works against your argument as one of the core features of Wikipedia is the revision history of every single page. Being able to have an understanding of what it said over time is a feature which counterbalances the nature of it being sourced by pseudononymous writers.

I agree that it does feel a bit paradoxical, but reversing a product for repair purposes verses reversing it for duplication are treated fundamentally differently by reasonable people. One is "right to repair" the other is "counterfeiting" or violating patents. To your statement, "We have a right to repair, but you don't" -- this clearly is not what is intended by Taylor, to repair these Kytch diagnostic tools. If that were the case, I think that would carry.

I'm personally working on migrating a DB I've had for tracking some economic time-series data from Influx to TimescaleDB, and I have to say Outflux is the most savage tool name ever.

Just watched a Def Con video where Jmaxxz self-installs a remote-start system. Lots of interesting details about what could have gone wrong. https://www.youtube.com/watch?v=w8SG2V3n4-U

Wonderful post, so glad that Mrs. Hansson stepped out for this cause, as uncomfortable as it was.

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.

Sure, so you can represent the other far extreme. I certainly advocate for review, but we should be practical. No one reads all the code down to the proc to ensure nothing malicious is happening, and the average software dev wouldn't be able to understand something malicious at that level anyway. I could have used a more hyperbolic example than a practical one (have you read all the PHP source for the version you're on? Have you read all your PECL libraries? Those ones are okay but OSS in PHP is not? Why? Just because it's harder to read C, right?). Pretending we do review everything is disingenuous -- but we should do what we can. Review doesn't have to be reading lines of code, but it could be ensuring it comes from popular and trusted sources (part of my earlier comment).

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.

... yes, I am responding to a comment critical of the usage of composer, requesting for it to be published as individual, self-contained files.

This concept of reviewing every line of OSS and copy / pasting the ones you agree with is really holding PHP dev back. Embracing dependency management is an important way to focus your codebase on your application code and is just a modern practice in all languages (https://12factor.net/dependencies). This is part of why JS (particularly node / isomorphic) is continuing to take over previously PHP marketshare. The actual (vs handwavey) security risks are low especially for popular projects.

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.

That correlation is very frustrating -- people should take this more seriously, but those who discover things are punished... should be pretty obvious why security is way it is, right?

Why would we combine Whole Foods and Trader Joe's? Whew, at least it's not bigger than Target and Walgreens combined though! It is however about 40% the size of Kroger... so there is that.

Well this is the whole point of privacy, right? Individuals or teams may have a perspective, but the business ultimately wins.

Oddly I succeeded using the exact opposite strategy.

This is something I've been working on a bit myself.

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?

Very rudimentary explanation of what cookies are and a few of the things WordPress uses them for -- wrapped in a massively self-promotional post complete with attempted push notifications. This post should be flagged.

Sure... so, showing "here is a weird disk pattern -- they were running X on top of it -- consider not running X on SSD" with a sampleset of 1 is a logical fallacy and kinda a bizarre post.

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.

This article seems to have a trove of interesting data, but struggles to generalize many conclusions out of it.

Apple has notoriously aggressively focused on a future-facing scalable way. I.e. where they see enough of the market in say 5 years (i.e. firewire, USB-C). However, they have been wrong before, AND I don't think anyone can argue that they aren't focusing on non-mobile hardware right now.

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.

Not (really) on iOS web.

As a basic user of the platform (where my employer has Slack Enterprise Grid), I've always expected this is the case and planned my communication accordingly.

I don't think this is an explanation for the current status and gains of Twitter. Trump has been president for over a year, and has been a prolific tweeter for far longer. If anything, Trump tweets are less novel and more common place then they've been to date.

Your comment is pretty unashamedly self-serving and not entirely on topic. Storify was curated, yours intentionally doesn't overlap on the heart of this product.

That seems like a strawman and openly hostile to debate with people who do not vote like you.

I've been in some newsrooms where this becomes a slippery slope... they're saying the small daily articles are just there to fund the rest, but those get sensationalized headlines, misleading social images... but it's okay because it's just paying for the real journalism... which somehow just never seems to get prioritized.

It's posted on TPM on the "Editor's Blog" and the byline says "Josh Marshall is editor and publisher of TalkingPointsMemo.com." what else do you need on his credentials?

There are links scattered throughout, but part of the point of this post is that no one is really talking about this issue at least at the depth it deserves, so understandably it's light on references. In this case, I'd treat a lot of this as an original source.

I read that as well... good spot being left out of this article. Here is the link: https://www.wired.com/2016/05/forget-elons-batteries-fix-gri...

I believe my case was pretty clearly articulated as are some of the other comments on a thumbnail sketch of the tradeoff comparison we have and continue to do. I'm sorry you believe the worst in this community.

Because it provides a robust, consistent, isomorphic framework which many people have decided that certain benefits (for us common tooling, maintenance, consistent implementation across the org, write once run twice isomorphism) outweigh the costs (interactable time, download size, etc). Everyone has to make their own choices, but this news was not surprising and did not change our opinion.

It's less about component-level refetching (though you can), it's more about the strong data specificity and composition that is the point of this article. That said, it's up to your query builder to figure out intelligent refreshing / refetching. I use Relay, and it's pretty good at this.