chrsjxn

I saw (after posting) that all the tool specific pages do link specifically to each project's documentation about what telemetry data is collected.

Those categories feel a little too broad to me, especially without clearly stated definitions. "Environment" in particular made me second guess if dev tools were leaking secrets. But, thankfully, the projects I looked at were very clear that they don't collect anything from the shell environments.

Maybe all it really needs is some detail for what's in the category. "Device (OS, core count, available memory)" or "Usage (command, plugins, timing)"?

Lawyer or Doctor AI feels like it's going to need some fundamental shift in the way these AI tools are built and used, though.

AI companies take zero responsibility for the output of their models, which is not a quality you'd want for this kind of work. That's one of the points of this reddit post.

And that's not even considering how expensive it could be to build a system that preserves attorney-client privilege or patient privacy.

This site would be a lot more useful if it talked about _what_ data was collected, rather than just assigning 25 for "Data sensitivity".

It's also pretty interesting to see the comments here, in a privacy focused thread, and contrast them with comments elsewhere about software performance. If you like faster software, developers need to measure it.

That's where I'm at, too.

And the platform is really showing its lack of moderation, even compared to how little it was moderated in the past. I don't really want to click on webdev tweets and find replies full of hate speech and weird pornography.

OP referenced benefits from accommodations for employees who aren't recognized as disabled, so it seems pretty clear we're outside of the legal framework for workers with disabilities.

And, generally, they do buy those things for themselves. Though plenty of employers will allow employees to expense these sorts of things, along with tools like ergonomic keyboards. They're cheap, in comparison to the cost of employees.

Hell, maybe that's the example I should have led with. Some non-disabling health conditions might put someone at a heightened risk for carpal tunnel syndrome. Ergonomic tools seems like a no brainer, compared to hardship and learning to work harder.

"Accomodations" in this case could be something as simple as noise cancelling headphones for employees working in an open plan office. Or a woman wearing a sweater because the office is cold. We don't tend to think of these as a disability measure because the problems are obviously caused by the setup of the work environment.

Expecting people to suffer hardships and learn to work harder instead of using simple tools to improve their productivity is just bizarrely cruel.

It is genuinely hard to imagine this could have gone any other way.

Copying an entire work, with no changes, and then distributing the copy is pretty archetypal copyright infringement.

IA's lawyers had to have known this was a long shot, right?

That makes more sense. Thanks!

Creating and adding DOM nodes is definitely not free, but I can see how this is very low overhead compared to VDOM diffing.

I am very curious about "zero-cost" here? Is this some standard technical term in the rust space?

Sentry rate limits pretty heavily unless you spend a significant amount of money. And even when a website is working properly, there's usually a baseline volume of error traffic due to things like bad wireless or cellular connections.

I wouldn't read too much into those 429s during an actual outage.

I can't disagree with you about that. The article here is about a misconfigured zoom meeting, which is shockingly easy to do. And if you've ever seen technical people struggling with Jira, you'll know it's not just an issue for non-technical users.

But I think it is a different quality of the software. Contrary to other people in these comments, I think we make software that actually does work in the vast majority of cases. "Working" isn't really the same as high performance, feature rich, or intuitive software, though.

That's the crazy thing, right?

I'm a software engineer. I've seen how poorly software is written, how badly it's tested, and how many stupid mistakes developers make. I've been the one making staggeringly stupid mistakes!

And yet... the vast majority of the software we use just kinda works. And if it's broken, it doesn't tend to stay that way for long.

It's easy to see problems as a developer, but our software could be so much worse.

The article talks about how GraphQL is "flexible" a lot, but I kind of wish they'd spend more words talking about why that matters.

Eg, if you're working on a new product, the odds are very good that your front ends will change pretty rapidly. At the very least, we're way more likely to A/B test application features than we are API schemas, regardless of what methodology or technology our APIs are using.

Because that's why I would pick GraphQL. It's a choice that reduces the barrier to rapid iteration in the clients, but it does add backend and infra work to support it.

Wikipedia has a telling graph of the murder rates: https://en.wikipedia.org/wiki/Crime_in_New_York_City#Murders....

40% up from pandemic lows sounds concerning, but we're still down near the bottom of a 30 year decline.

And from: https://www.criminaljustice.ny.gov/crimnet/ojsa/stats.htm, NYC had anywhere from 120,000 to nearly 300,000 arrests each year from 2012 to 2021. 10 people abusing bail reform? 716 shooters? These numbers are many orders of magnitude lower than the number of people affected by crime and the criminal justice system in New York every year.

In New York, as in many places, crime is still at a pretty historic low. Depending on your sources and your categories, down as much as 50-75% since peaks in the 80s and 90s.

It's definitely not that we currently live in a country with rampant criminality.

Adding onto that, Google says the NYPD budget is over 5 billion dollars a year. If there really are less than 1000 people responsible for so much violent crime, this seems like institutional ineptitude on a pretty staggering scale.

It's fun to look back on the success of SPAs from the perspective of someone who learned to build websites pre-jQuery.

jQuery allows for websites to be interactive with minimal latency, but it's pretty low level so it leads to a lot of common problems. Like locking the main thread, undisciplined architectures, and a ton of issues with back/forward navigation.

SPA frameworks are developed to solve jQuery problems, but they introduce some new ones. Everything being JS is a big win, compared to split apps. But you have to deal with the up front cost of loading all the JS and a higher memory footprint.

And we iterate. SSR frameworks tone down the up front cost of SPAs in favor of more complex infrastructure. Frameworks that deploy to edge networks take another bite out of latency, but it isn't entirely clear what that will mean long term.

It feels so iterative that blaming framework popularity on malice is wild. There are real benefits to businesses, developers, and customers at every step along the path. Of course developers are going to follow along.

Long running sessions seems pretty straightforward. The cost of an SPA is heavily front-loaded, so the longer you have the app open, the more that cost can be spread.

Authenticated content is likely for a mix of reasons. It can't be indexed, so doesn't need to optimize for SEO. Users that log in are higher intention, so they're less likely to bounce if the page loads slowly.

It's definitely more complex than just these things, but the inverse (an app that requires SEO and minimal upfront costs) are often used as justifications for moving away from modern frameworks.

Even if the company that makes ChatGPT were completely amoral, I assume they'd want to have some control over the outputs.

Given all the workarounds people are testing elsewhere in these comments, it seems like it'd be pretty easy to get it to give you illegal or dangerous instructions. And then you get into liability questions, bad publicity, lots of legal fees...

I'm not sure I get the issue people have with autofilling passwords, instead of making the user copy and paste.

Every password manager I've used associates those credentials with a URL. One of my accounts used to get them confused, because the company offered a dedicated login page and login via the home page on separate subdomains.

So that feature might make it harder to get phished by adding friction. And if an attacker has malicious code running on the legitimate website, how would you know?

If you were trying to help people be more inclusive with their language, categorizing them like this seems counter to your goals

Your own list seems to say that exclusionary language about someone's medical condition (lame) is more acceptable than other exclusionary language, because that stigma has a different history? Or because that language is more common?

Those words can still do real harm to real people, even if they're lower down in your ranking of these words

The first proof is basically just begging the question.

It says that having infinitely many composite numbers must mean infinitely many factors, and thus infinitely many primes.

But we can construct infinite sets of numbers from finite prime factors easily. [2] and the powers of 2.

Which might be a good starting point to teach someone Euclid's proof that there are infinite primes, but ChatGPT didn't get all the way there.