scsh

It does not control for commit complexity, security intensity, or bug severity. It does not distinguish between a one-line typo fix and a CVE patch. It is a blunt instrument. But the critics' accusation is also blunt: "Claude is making things worse." A blunt instrument is the fairest response.

If by fairest you mean to say that this analysis and response is sufficient, then I'm sorry but I have to disagree. We really need to understand if the nature of the bugs are worse from a user's perspective. Even if the rate stayed unchanged, if the result is the perceived quality of the software declined then I would personally consider that worse, especially if I were a project maintainer.

That's not meant to be wholly dismissive either. But in general, I don't think quantitative analysis alone is enough to fully answer this type of question.

If you have an internal CRM and are maintaining a Zendesk integration to create support tickets within your product, you've likely already done half the work needed to instead create those tickets in your own internal CRM tool yourself. This makes a lot of sense.

As someone who's had to maintain a Zendesk integration such as this for a large app it's hard to understate the benefit of having all that support info so close to the rest of your user's data. I have seen a huge amount of effort go into trying to get just the right balance of data in and out of ZD. Also helps alleviate concerns with sharing too much customer data with a third party.

This definitely isn't the right call for everyone, but there's a lot of upside if it can work for your organization.

Agreed, this got me thinking maybe I should try something similar with my own old macbook pro. They did mention that this was the first time they had soldered anything, so it's great that they went for it and it worked! So now it's just a matter of improving technique.

Long term, that may need to be redone. Really want less exposed wire in the final product, tin the tips of the wire first so they don't suck up the solder and trim to the appropriate length(only a bit bigger than the size of the pads at most). This is a good example on tinning: https://www.youtube.com/watch?v=pRPF4wpXX9Q And if you need to expose a lot of wire then just use some heatshrink so it's not exposed once you're done.

In a perfect world, you'd want to remove all the existing solder and then re-solder everything. But de-soldering can be its own skill and isn't always strictly necessary. Just something more to work toward.

No it's not strange. As someone who enjoys playing music I have heard a lot of music that doesn't suite my particular tastes, but appreciated the artistic talent of the people creating it because I truly believe they are talented. If you dig below the surface level you can find plenty to appreciate about how something is created, even if the product isn't for you.

You can find something to like about a lot of things. I also enjoy watching videos about wristwatch repairs and seeing the construction of them. However, I do not want one and would never wear one.

It wasn't just him making such quotes, as I indicated before, and I made no attempt to make an exhaustive account of such statements which can be easily found elsewhere. It's very reasonable to conclude that that is an issue at play here. That is all I attempted to convey.

Direct quote:

“Venezuela is completely surrounded by the largest Armada ever assembled in the History of South America. It will only get bigger, and the shock to them will be like nothing they have ever seen before — Until such time as they return to the United States of America all of the Oil, Land, and other Assets that they previously stole from us.”

This along with other direct quotes from officials is what led me to the conclusion that, yes, oil is a large factor.

I think these are valid concerns for a project maintainer to think through for managing a chosen solution but I don't think there is a single correct solution. The "correct", or likely least bad, solution depends on the specific project and tools available.

For bug reports, always using issues for everything also requires you to evaluate how long an issue should exist before it is closed out if it can't be reproduced(if trying to keep a clean issue list). That could lead to discussion fragmentation if now new reports start coming in that need to be reported, but not just anyone can manage issue states, so a new one is created.

From a practical standpoint, they have 40 pages of open discussion in the project and 6 pages of open issues, so I get where they're coming from. The GH issue tracker is less than stellar.

They open themselves up to a lot of risk, but more likely they only comply when CA residents are concerned or stop collecting for CA residents. Good question about outside the USA. Makes me wonder if there may end up being some sort of data broker safe havens setup, like we've seen with banking.

Absolutely. What sound pretty cool, and different, here is CalPrivacy would be required to build a request mechanism that's one request sent to every data broker.

The GDPR lets someone request deletion of their data and there are legal teeth to force a business to comply, but that's 1:1. Maybe I need to dig deeper, but this specifically applies to data brokers it seems. That's great and it being a one to many request is fantastic, but sounds like it may not apply to just anyone who has data on you like the GDPR...

The gist of the GDPR in that respect is it allows someone to request a record of what data a particular business has gathered about them as well as request deletion of that data. It also introduced a lot of restrictions around what can be done with a particular subject's data, like sharing with third parties.

The BQ dataset is only ~17GB and the free tier of BQ lets you query 1TB per month. If you're not doing select * on every query you should be able to do a lot with that.

It's available on BigQuery and is updated frequently enough(daily I think).

Probably just forgot to make it public.

Oh yeah, totally agree with you on that one.

Yes, but the elf who created them is quite a tragic character himself. To the extent that his own mother chose to die after giving birth because she knew how much sorrow he would eventually bring. So I'd be careful to not paint them as a good thing either.

That's also a totally fair take!

Independent of any feelings about the use of AI, I find that specific style of formatting to be extremely visually distracting and tend to click away because of that. Emoji, imo, are very information dense per character so it makes the rest of the info hard to parse.

While someone does have to be the first to experiment I think you've implied a bit of a false dichotomy here. Experimentation can be good for sure, but it also doesn't have to involve such extremes. Sucks for the people left who now have to make up for the fact that someone's experiment didn't work out so well.

Veritasium has some of the worst horseshit "clickbait"

This really isn't a defense of Veritasium, but this has become the case with most videos where the creator makes a living off their channel. Everything is poorly named like this just so they can at least continue getting the same amount of views, because most views come from Youtube recommendations. It's only anecdata I have, but I've heard a lot of creators say that these days recommendations is the only way they get views, even channels with tons of subscribers. I personally rarely get recommended content from channels I actually subscribe to. It's really a lamentable state.

That is completely ok in my opinion. It's just most discourse I come across treats the developers as complete amateurs who don't know what they're doing. As someone who's a professional dev myself I just can't get behind bashing the people doing the actual work when I know we're all dealing with the same business realities, regardless of industry.

It's because shitting on game devs is the trendy thing these days, even among more technically inclined crowds unfortunately. It seems like there's a general unwillingness to accept that game development is hard and you can't just wave the magic "optimize" wand at everything when your large project is also a world of edge cases. But it seems like it should be that simple according to all the armchair game devs on the internet.

I hear a lot of encouraging but not requiring. Having something that is required would go a long way imo. If you know you have outstanding work to complete it can be hard to give yourself permission, or feel like you won't be seen as neglecting your responsibilities if you go to something that's only encouraged. That's a struggle I have anyway.

Some sort of customer panel where you ask questions of your users about their business, how they use your software, what it enables them to do and what doesn't it do I imagine would be helpful. You can't take your whole org to you customer(s), but if you have the budget you can bring the customers to you. Also, if you have a good support org, have them work one week in support.

If the project you're working on vendors dependencies it's pretty easy to end up with that many files being changed when adding or updating, even when trying to make as narrow updates as possible in one PR.

And that's why he paid them in shoes.

The point is, whether intentional or not, the submitted title is ambiguous and possesses the capability to mislead. When talking about data we should strive to use as accurate language as possible.

I wouldn't be surprised if someone's interpretation of the title tended toward their own experience, or lack thereof, with Steam.

I don't disagree and think that that is something people should be more concerned about than they already are/have been. I think the difference is how opaque the influence of the middleman is.

It's like the difference of someone handing out printed tour guides vs an in-person tour guide. It's typically can be easier to tell which are the ads, the extent of the curation, etc. with the printed guide(but not always!). While with the in-person guide you just have to just have to take everything they say at face value since there's no other surrounding information to judge.

It didn't seem like they were suggesting otherwise?

I actually feel very strongly that code is very much written for us humans. Sure, it's a set of instructions that is intended to be machine read and executed but so much of _how_ code is written is very much focused on the human element that's been a part of software development. OOP, design patterns, etc. don't exist because there is some great benefit to the machines running the code. We humans benefit as the ones maintaining and extending the functionality of the application.

I'm not making a judgement about the use of LLMs for writing code, just that I do think that code serves the purpose of expressing meaning to machines as well as humans.

Yes in this particular case, where I'm trying to install fastapi, I'd rather it direct me to https://osv.dev/vulnerability/PYSEC-2024-38 which is more fastapi specific and mentions that the fixed version of fast api is 0.109.1. Or even better, give the link and print the fixed version from the advisory yaml https://github.com/pypa/advisory-database/blob/main/vulns/fa...