Not at all; standard IR procedure is scope -> containment -> eradication -> recovery. There is a fog right now; we don't know all the details. It seems to me that it's just as likely they weren't fully kicked out before or that the initial vulnerability wasn't remediated. You can't recover until the threat actor has been removed.
There is a lot of love in my group from years of MtG for drafting games, so 7 Wonders and Dune Imperium are consistent favorites. When we have the time, we'll do Twilight Imperium. We've enjoyed all three Nemesis games. We are currently also really enjoying Spirit Island. We've completed Gloomhaven: Jaws of the Lion and put in some serious time with regular Gloomhave as well. As LotR fans, we've also enjoyed the LotR LCG and War of the Ring.
A Technology Connections video recently changed my opinion on this. The land required to power the entire U.S. would be less than the farmland we currently use for ethanol production.
Per the article, the issue is with recalled batteries that are going to take 18-24 months to be replaced that won't allow the bus to charge pas 75% or below 41 degrees and because of the risk of fire and lack of suitable fire mitigation equipment, can no longer be charged in garages. Not seeing any mention of an issue with the underlying technology.
It sounds like you're describing Google's proposal, which I believe is at least feasible (though likely uneconomic) unlike, say, Starcloud's. I don't think you are correct about the orbit, though; Google's proposal lists the satellites at 650 km, which would give them approximately 20 years in orbit without boosts. They list estimated life at 5 years given radiation concerns, so they almost certainly would purposely deorbit them earlier.
I never said Google wasn't serious; I said they are hardly betting on it relative to their other capital expenditures. Google rightfully describes this as a "moonshot." To date, the only public hardware commitment is two prototype satellites in 2027 for a feasibility study. Compared to the billions pouring into Waymo, DeepMind, and terrestrial data centers, this doesn't yet qualify as an "enormous" financial bet, even if the engineering intent is serious.
Google is hardly betting on it; they are exploring the feasibility of it and are frank about the engineering challenges:
> significant engineering challenges remain, such as thermal management, high-bandwidth ground communications, and on-orbit system reliability.[1]
Not even a little; doesn’t pass napkin math. It doesn’t solve any problems while adding a litany of new ones: massive radiators for heat rejection, radiation hardening, and enormous launch + repair costs (assuming repairs are even possible). The idea exists to separate investors from their money; the product is the funding round.
Based on the comments in the thread, I sense I will be in the minority, but for most consumers this is a reasonable default. Broadly speaking, the threat model most users are concerned with doesn't account for their government. The previous default is no encryption at rest, which doesn't protect from the most common threats, like theft or tampering. With BitLocker on, a new risk for users is created: loss of access to their data because they don't have their recovery key. You are never forced to keep your recovery keys in Microsoft's servers and it's not a default for corporate users.
For password hashing, only short-output or broken hash functions have practical collision concerns. The odds of any random collision with a 256-bit hash, and not with a specific hash, is 50% at 2^128 inputs. Salting is a defense against precomputation attacks like rainbow tables and masking password reuse. Attackers crack password dumps by trying known password combinations, previously compromised passwords, brute force up to a certain length, etc. and using the hashing algorithm to compare the output.
You can check against the API with just the first characters of your hashed password (SHA-1 or NTLM), for example: https://api.pwnedpasswords.com/range/21BD1 or you can download the entire dataset.
Looking at the Statcounter report, it explicitly excludes mobile devices and separates out ChromeOS. I'm guessing that Statcounter uses UA strings and it is conceivable that HTTP requests are happening outside of explicit web browsing.