Honestly, it’s very likely just Salesforce since that cantankerous, janky beast is so easy to use poorly.

CRM is “customer relationship management” i.e. a system to manage interactions with customers such as tracking calls, marketing emails and collateral, meetings, quoting, support tickets, and more. It tracks the lifecycle/pipeline of a sale from prospecting, lead qualification and solution mapping, demos and meetings, proposals, negotiations and commitment, opportunity win/loss, license generation, onboarding, renewals, and a ridiculously huge number of other things.

It’s not just tracking the numbers but giving you a centralised system that all other business operations can hook into so you’ve a single source of truth about customer state so that various other operations can be triggered.

When you’ve hundreds of sales people, numerous systems, marketing people, support teams, and more all reading and writing to the same CRM system, if that “system” was a spreadsheet, you’d be constantly deadlocking and race conditioning the hell out of it, not to mention how absurdly huge that file would become with all that historical data (since a big part of CRM is also projections and other analyses across all the data you have).

Good bot

Technically they thought they might have introduced a bug that caused the delay / a regression and set about investigating it. Pretty sure it was a Microsoft developer too.

Thank you for the smug response however I did indeed read the article and going from 13 months to 10 days is not a trend but a complete rearchitecture of how certificates are managed.

You have no idea how many orgs have to do this manually as their systems won’t enable it to be automated. Following a KBA once a year is fine for most (yet they still forget and websites break for a few days; this literally happened to NVD of all things a few weeks ago).

This change is a 36x increase in effort with no consideration for those who can’t renew and apply certs programmatically / through automation.

Smells like Apple knows something but can’t say anything. What reason would they want lifespans cut so short other than they know of an attack vector that means more than 10 days isn’t safe?

AFAIK they’re not a CA that sells certs so this can’t be some money making scheme. And they’ll be very aware how unpopular 10 day lifespans would be to services that suck and require manual download and upload every time you renew.

You okay?

You’re not wrong. Research into models trained on racially balanced datasets has shown better recognition performance among with reduced biases. This was in limited and GAN generated faces so it still needs to be recreated with real-world data but it shows promise that balancing training data should reduce bias.

Let me guess, UltraAV whitelabels Kaspersky…

Eugene Jarvis made such awesome games. If you loved Smash TV back in the day, you should check out Nex Machina for a modern take on his classic twin stick shooters.

This slogan was from the 90s (1993/94 maybe?).

deleted by creator

Ship a new app then. Sonos already do this for older products.

Whoever the fuck thought a massive regression for every single customer was the perfect thing to deploy with no option for rollback needs to stop working in software.

Especially since, to calculate current location, it needs an input of initial location (i.e. it needs GPS coordinates to begin with so it can track direction and velocity relative to that initial position). You can’t replace something you depend upon.

We will find out when they push the update.

Only Google’s proprietary extension has encryption. The actual industry standard specification of RCS has no encryption defined at all.

Edit: It turns out Apple have refused to use Google’s proprietary encryption implementation and are instead working with GSMA to update the RCS Universal Profile specification to finally have encryption defined and standardised so that any RCS client can handle encrypted payloads (whereas only Google Messages today can do encrypted RCS and requires other users to be exclusively using Google Messages otherwise messages are sent unencrypted).

Because everyone is too distracted by “Apple bad” to realise how truly awful RCS is.

Bingo. RCS is yet another proprietary protocol, one controlled by Google (GSMA who originally designed it have practically forgotten about it for a decade) and without an open specification. RCS also doesn’t have a standardised approach to encryption as it’s designed for lawful interception.

So unless Apple have licensed Google’s implementation and extended version of RCS, this will be a shitty, insecure way to communicate between the Apple Messages and Google Messages apps and nothing more.

Google did an impressive job applying pressure and suggesting RCS was a perfect solution when in fact it’s just putting more control in Google’s hands. RCS is not an open “industry” standard. You nor I as individuals can implement it without paying license fees to see the specification and fees to have our implementations tested and accredited.

And Google have extended GSMA’s RCS with their own features (such as encryption) which is not part of the official standard and they haven’t made open either.

If Apple had been pressuring Google to implement the iMessage protocol or whatever, we’d have been up in arms (and rightfully so).

But instead of us all collectively hounding Apple and Google to ditch proprietary protocols and move to open ones such as Matrix, Signal, XMPP, etc (ones where we could all implement, use open source software clients, etc) we’ve got this shit:

Proprietary, insecure, non-private communication protocols baked into the heart of hundreds of millions of devices that everyone is now going to use by default instead of switching to something safer, private, public, open, auditable, etc etc.

BleachBit is a great alternative and it’s open sourced under GPLv3.