This implies that governments didn’t already have this ability, which appears to be largely untrue? To my understanding, many countries already had emergency messaging systems, and mobile integrations are just a way of modernizing them.
(It seems exceedingly good that the government can warn every civilian about natural disasters, etc.)
Governments had poorly thought out poorly secured barely functional systems involving the network operators and those were then integrated with default system apps that have terrible UX without fixing any of the problems AFAICT. Agreed that it's clearly necessary functionality but it's worse than useless when it's so far proven to be (at absolute best) a constant stream of irrelevant alarms.
This is not related to Google or Apple. And this extreme alert, it's sent even to cable TV automatically.
In a few countries, it's sent even on Fax lines.
I've yet to receive one of those that was useful. Meanwhile the 70+ year old storm sirens mounted on the nearby office buildings work perfectly in my experience, being audible even indoors from many miles away.
Even then. During a recent storm, they went off erroneously in Denver. (Looks like the other two erroneous alerts were via phone though.)
> Denver emergency officials say they are working to rebuild public trust after a mistaken tornado siren activation Monday became the third improper emergency alert issued in the city this year.
If you’re migrating a large MySQL database and you’re not
using mydumper/myloader, you’re doing it the hard way.
If you aren't using xtrabackup you are doing it wrong. I recently migrated a database with 2TB of data from 5.7 to 8.4 with about 15 seconds of down time. It wouldn't have been possible without xtrabackup. Mysqldumper requires a global write block, I wouldn't call blocking writes for hours a "zero downtime migration".
I have experience in migrating large DBs with replication and the article not discussing write blocks made my ears perk up as well.
Aside from the blocking you mentioned during the initial snapshot, you'd need to block writes to the old DB before the cutover as well. There's no way to guarantee in-flight writes to the old DB aren't lost when promoting the replica to a primary otherwise. I'm surprised the author didn't go into more detail here. Maybe it was fine given their workload, but the key issue I see is that they promoted the new DB to a primary before stopping the old application. During that gap, any data written to the old DB would be lost.
Correct me if I'm wrong, but done with a proxy in-between that can "pause" requests, you could have done the move with 0 seconds and no rejected requests, and I don't think mydumper/myloader/xtrabackup matters for that. The "migration" would be spinning up a new database, making it catch up, then switching over. If you can pause/hang in-flight requests while switching, not a single one needs to fail :)
The "making it catch up" is the tricky part. You need an initial backup for that. xtrabackup can take that backup "hot" without blocking read/writes. mysqldumper will block writes for whatever time that initial backup takes, for 2TB of data that's going to be hours.
Once you have that initial back up you can set your replica and make it catch up , then you switch. I choose to take the few seconds of downtime doing the switch because for my use case that was acceptable.
If you want a consistent backup that you can use to setup a replica you need to block writes while the backup is taken, take the backup while the database is shutdown OR use xtrabackup.
Thank you. I was confused that nobody pointed out that this "zero downtime migration" requires there to be no write to the original host for the time of the migration...
NPM is absurdly complex in comparison, it's just neatly abstracted. Maybe somebody will write a cross-platform reactive layer which can compile both natively and to the web?
It is still disgusting. There is no need for that fee to be there, because remember, it sits on top of the purchase of at least $1,500 (a decent Mac).
I tried to see if I could make improvements to Immich. No can do, as half of their entitlements require a team account (and even then begging Apple to get the entitlements).
Now, they do offer a private account, so I spent time removing those entitlements. Guess what? Starting over 3 times and you're hit with a 'you can only sign 10 apps / week'.
Why do apps built for my iPhone, which I explicitly need to put in Developer mode, need to be signed by daddy Cook?
Apple can charge you that because they have a platform which is a monopoly.
Granted, they did the work that built and maintain the platform, but at some point it's actually the countless developers who contribute value, not Apple.
On a computer click click is a lot slower since you have to come to a complete pointer stop in your release. If your pointer is still moving in the release square most interfaces would detect that as some attempt to start a drag
On Lichess, this isn't the case; if I set my movement preference to 'click two squares', a click on a piece is registered immediately on mousedown regardless of cursor movement.
(When I set my movement preference to 'either', it's a bit harder to test, but I think a brief click-and-drag always counts as a click provided the mouseup happens within the initial square.)
