Not even Chrome is blocking some of the add-ons...
is that something you know for sure? or has Google quietly complied with similar requests, without making a statement like Mozilla has here?
vvv
joined 2 years ago
I do this with my xreal glasses sometimes when washing dishes or whatever. Connected to phone in my pocket with a desktop mode, set a black wallpaper, and drag the video into a corner.
It's nice for situations like that, where you're doing something with your hands and can't reasonably place a screen in a way where you wouldn't have to constantly strain your neck to look at it.
Right. So why does my phone also need to be a part of surveiling others?
I use these two vim plugins for the same functionality without leaving $EDITOR:
I've also started dabbling with using fzf in scripts for the team to use. Don't sleep on the --query and --select-1 flags!
is that more or less cursed than cat image.img > /dev/whatever?
dd if=image.img of=/dev/disk/flashdrive is usually all you need
I personally disabled the feature on my phone when it popped up as available. I don't have much of an interest in contributing to a weird surveillance network.
Definitely not what you're talking about, but still: https://www.destroyallsoftware.com/talks/a-whole-new-world
it could explicitly be a reasonable deterrent. if you double your price, but lose half your customers, you've made the same amount of money for half the work.
"Hi, I just sent the ransom payment to the Bitcoin address you provided.
"Now you'll unlock my data, right?
"...... right?"
The two factors at an ATM are possession of your bank card + knowledge of your pin. (it also takes your photo, for good measure)
GitHub will happily accept a smart card or whatever, if an extra plastic rectangle jives with you more than an OTP generator.
Not sure what you're doing, but if we're talking about a bog standard service backed by a db, I don't think having automated reverts of that data is the best idea. you might lose something! That said, triggering a snapshot of your db as a step before deployment is a pretty reasonable idea.
Reverting a service back to a previous version should be straightforward enough, and any dedicated ci/cd tool should have an API to get you information from the last successful deploy, whether that is the actual artifact you're deploying, or a reference to a registry.
As you're probably entirely unsurprised by, there are a ton of ways to skin this cat. you might consider investing in preventative measures, testing your data migration in a lower environment, splitting out db change commits from service logic commits, doing some sort of blue/green or canary deployment.
I get fairly nerd-sniped when it comes to build pipelines so happy to talk more concretely if you'd like to provide some more details!