Honestly, I’ve worked with a few teams that use conventional commits, some even enforcing it through CI, and I don’t think I’ve ever thought “damn, I’m glad we’re doing this”. Granted, all the teams I’ve been on were working on user facing products with rolling release where main always = prod, and there was zero need for auto-generating changelogs, or analyzing the git history in any way. In my experience, trying to roughly follow 1 feature / change per PR and then just squash-merging PRs to main is really just … totally fine, if that’s what you’re doing.

I guess what I’m trying to say is that while conv commits are neat and all, the overhead really isn’t really always worth it. If you’re developing an SDK or OSS package and you need changelogs, sure. Other than that, really, what’s the point?

Lol that’s ridiculous. There’s nothing about ipv6 that’d make it any slower

There’s a massive difference between what “usage data” refers to in this context and the kind of data stored and analyzed by Recall locally.

Maybe I’m out of the loop, but afaik they always said that none of the data would ever leave the device.

Tbf that analyzing was happening on-device… But yeah

Assign a DNS name

I see this point a lot and I don’t get it at all. You can do something awesome, free and open-source but use tools that aren’t, especially when we’re talking about community building. Sure, you can do your outreach exclusively on Mastodon or Farcaster, but the most eyes just happen to be on closed platforms, so it’d just be self-sabotage. Doing the only thing that makes sense doesn’t make you a hypocrite.

As opposed to “sacrifice child” which sounds … Good?

Right, because non-technical people would be expected to understand what an “out of memory” error means

Source…?

Skimmers are not a thing for Google Wallet / Apple Pay, no. Both these services use tokenization for transactions, meaning that even with your phone unlocked, no-one could grab anything via NFC that would allow triggering a transaction later, let alone clone your card. Even in this specific scenario described in the article (which requires your phone to be in the hands of the exploiter), the CVV of the card wasn’t exposed, so no-one can actually trigger a payment with this info except if they also have your physical card to read the CVV.

Google Wallet / Apple Pay are a million times safer than using your physical card, because the most common skimming attacks either just grab the magnet strip info if available or literally just read the info off the card optically including CVV, which allows for online transactions. None of these things are a concern with Google Wallet / Apple Pay.

But hey you know best right?

I worked as a TPM in financial services for almost 5 years, so yeah I think I’d know.

It was specifically stolen from Google Pay and contactless payments.

It wasn’t.

Did you read the article? Unless someone had physical access to your (unlocked) phone and was able to pin an app, then tap it against specialized hardware (unlikely you could get a normal card terminal to run this exploit), it’s extremely unlikely that this is how your details got stolen.