All restoration choices are at least a little bit subjective.
That said, I agree with you!
1,424 karma · joined November 12, 2011
That said, I agree with you!
First, they can't attack a WiFi access point for which they do not know any password(s). Thus your multi-SSID access point with multiple passwords is "safe" from this particular attack.
However, second, they can attack an access point for which they know any password, gaining access to clients on the other SSIDs. This means your security is now effectively only the security of your worst SSID's password. It also may defeat your purpose in having multiple SSIDs/passwords in the first place.
Granted pronouncing the name is ambiguous, Wes-cam or We-scam. But they're known well enough in the industry at this point that it's not a problem for them.
https://github.com/apple/container
I've been experimenting with it in macOS 15, and I was able to replace Colima entirely for my purposes. Running container images right off of Docker Hub, without Docker / Podman / etc.
(And yes, it is using a small Linux VM run under Apple's HyperKit.)
Personally I consider Chrome to be one of the least-safe browsers available, because it sends my data to Google. Also it perpetuates a monoculture. However, others may define "safe" differently, excluding such considerations.
ETA: The above link is at the bottom of the original submission's README. (https://github.com/sst/opencode) I posted it without context, and I have no opinion on the matter. Please read theli0nheart's comment below for an X rebuttal.
> The researchers were surprised that when they activated VTA dopaminergic inputs into the aBLA they could reinstate fear even without any new foot shocks, impairing fear extinction.
That... seems like the first step in being able to literally induce fear without having to bother with pesky things like finding the subject's triggers. Although I suppose if one has direct access to the subject's amygdala, the point is somewhat moot.
Still, it's sort of like a reverse wirehead.
I guess the alternative is something like Passkeys synchronized via iCloud Keychain. Hopefully Apple is encrypting the Passkey key material within the Secure Enclave using each other Secure Enclave's public key. Otherwise it kind of defeats the whole purpose of having a Secure Enclave. (If I remove a YubiKey from a computer, I have some assurance that computer can't authenticate with YK-controlled accounts.)
No doubt it is revenue-related, but it's also a privacy problem.
https://www.theguardian.com/books/2002/feb/02/johnsteinbeck....
> "Advance Publications, which owns Ars Technica parent Condé Nast, is the largest shareholder in Reddit."
https://arstechnica.com/gadgets/2023/06/the-reddit-protests-...
(That article is a day old now, and I still don't think it includes everything that's happened late this week.)
They've made it clear they don't believe their own language about privacy and user choice. They've compromised one product to advertise another. And perhaps worse, they doubled-down about it in Bugzilla with corporate doublespeak, which to me is the tell that they'll absolutely do it again.
It's amazing how apt the trust-thermocline analogy is.
I run Vaultwarden on my LAN, with no public/Internet facing service, and sync only on my LAN.
https://github.com/dani-garcia/vaultwarden
Your password data, back under your own control.
So they're not certain they have found it, yet.
They could have found one of the other radioactive capsules lying about the Western Australia outback.
https://github.com/neoclide/coc.nvim
https://github.com/dense-analysis/ale
My impression with all of this running under MacVim... it's plenty responsive. It can take a while for Solargraph to index everything on startup if you're working in a big project; once it loads, it's snappy. (There's probably a way to cache that startup scan.)
(I'm available for QA testing.)
https://www.insideradio.com/free/fcc-slaps-birach-broadcasti...
On the same Mac, I get "Your browser is not supported" for Safari 15.6.1, and Safari Technology Preview R152 (Safari 16.0) with "WebGL 2.0" and "WebGL Draft Extensions" enabled under "Experimental Features."
Using Ungoogled Chromium 105.0.5195.102 (I refuse to use Chrome), the site actually seems to leave the GPU in a messed-up state, going on to cause severe rendering problems in other applications. I'm not sure if this is a Chromium bug or a macOS bug or both.
In order to get this to work on macOS, I needed to use Homebrew bash (5.1 instead of macOS' native 3.2) and the GNU date utility from Homebrew's coreutils, since macOS' native date binary uses different arguments.
Essentially, change the shebang to "#!/usr/bin/env bash" and use "gdate" instead of "date" wherever "date" is used.
Someone with some time could correlate that to failure rate. My hypothesis is of course it's correlated--but by how much?
...uses a neatly-defined mathematical term to name the company, then rejects the idea of neat mathematics in practice.