The expense will come when the backend grid needs to get upgraded to support the usage level... but by that time, really, it means people are actually using them, so, mission accomplished.

There are a good number of places where these won't even need to turn a profit... the local tourism board will be more than happy to subsidize the shortfall if it means they get the other business from sightseers and whatnot.

No. Tesla did us the disfavor of not bothering to serve other EVs. The federally subsidized ones in TFA will have to have universal compatibility. That's universal for major brands that have gone through some sort of approval process... some networks have removed support for home made kits and such, I guess a few of them were damaging the chargers. Dunno how they tell what's plugged in or whether that's just a legal liability matter.

There are several charging networks and many of them share their charger locations with each other and have reciprocal agreements. For example you can see a lot of existing locations on a map of the U.S. at chargepoint.com.

Many need chargers. I would not be able to "top off" my car during winter months because no outlet can deliver that much per hour, since I commute >100 miles round trip. (I spent a couple grand to get a line buried and a panel put in my landlord's garage, my state govt subsidized the charging unit itself... home units aren't horribly expensive since they have no UI. Totally worth it at this point, for all the inconvenience it has saved me.)

People who live in rental units with no off-street parking need to use the public infrastructure. They wouldn't be able to charge even if their commute was light enough to do it from an outlet.

Incentives for landlords to install chargers and reserve charger spots for as many EVs as they have EV driving residents would go a long way, I think. If I were trying to rent a place out I'd definitely get one in there, it's a great way to justify an above-market rental rate.

I'm not one who has any need for IDE functions whatsoever (you know, not all work done in text editors involves working in source code trees) I still use EMACS for daily stuff. If the system has only vim, I'll use nano instead. I don't often need to use EMACS features I just prefer it in a comfortable old pair of shoes sort of way.

As to TFA: If one thing was going to make me leave EMACS, it would be the attempts to modernize it. Every time I get on a fresh system they've done something to make it "modern" that screws me up. Like autodeleting trailing spaces off lines... do not want... and unified clipboard and kill-ring on -nox... also do not want. Usually there's a way to fix it in your .emacsrc, but man, the naming conventions used under the hood are pretty slapdash and I'm not so into it that I ever actually bothered to learn my way around (or even learn LISP), so it can be a chore to keep my comfy shoes comfy.

But, since absolutely no FIDO2 keys seem to have any way whatsoever of telling you what site/resource you are about to approve a login to, you have no idea if your fingerprint is being used to unlock just your zappos store account, or a request to access your master keyshare on lastpass launched from a javascript some site managed to trick your browser into running on the browser tab you have open on lastpass.

Some keys do seem to have LCD screens but it appears they are only for time-based OTP outputs.

Yeah that's the TLDR right there: depending on what they can and will do technologically during the mining process, this could either solve a looming environmental problem, or make it much worse and hasten it.

One could hope that rigorous scientific evaluation of the process would allow cleanup of the area to dovetail with mining.

Or more cynically one can expect this to be resolved with a rotten fruit fight between tree huggers and sociopathic CEOs in the courts with both sides making up shit as they go along and no inclination to actually express the facts of the matter rationally and truthfully.

Well, TFA suggests: "end customers will now require them to prove it via an audit of their software supply chains."

That is, until the audited SaaS provider gets compromised and you ave to question te competency of the auditors.

Then we'll have auditor-auditors. Turtles all the way down.

I'm skeptical of any actual improvement because I see a lot of the "hire someone to do it so that if it goes wrong they take the blame" mentality kicking around. Until there are consequences for choosing the wrong provider I don't see such audits being undertaken (or some SaaS use cases abandoned due to the cost of them.)

(On a more meta tangent: these security issues, and also the saga of our election systems, has got me wondering whether there is any game theory on the correct ratio of balkanization to standardization in an adversarial model.)

Ahhh.. for the days when you needed an app just to use your flash LED as a flashlight. Good riddance.

IMO I shouldn't have to download any apps at all to do basic things. And basic things are all I want my phone to do. And I shouldn't have to sign into an app store to get free apps I'm not payng for anyway. Just post the damn hash of the genuine unhacked apk on a public site.

Still plenty of room for "innovation" in the area of tet file editors apparently. Astounds me those are still not installed by default. You'd think they'd want to give you an unecesarily cloud-based one so they can get all that juicy aggregate statistical data.

I once got an Amazon package that had a knock-off chia pet still in plastic wrap included in it, apparently as filler to save on packing material. I guess if it is under the density of packing material, that's one way to deal with it.

Or "would you rather eat a randomly chosen mushroom from the forest floor, or a randomly chosen pill from the OTC aisle at the grocery store?"

You're probably more likely to get an autoimmune condition from catching a virus than getting vaccinated.

https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwww.ncbi.nlm.nih.gov%2Fp...

Since we control what types of vaccines we use to some extent, and collect data to detect problems, over time they'll be even less likely to cause any such issue. We don't control the makeup of viruses, so the odds of getting autoimmune diseases after catching a cold are probably going to stay about the same.

A good economy where nobody is scared to send their kids to day care makes it much more likely that we'll produce more doses, more efficiently. The less unvaccinated people we have walking around, the less everyone else has to worry.

Yeah it's unclear (as in probably intentionally not stated) from the warrant who caused the last transaction putting the coin in the wallet the FBI had the key to... If that wallet was under full FBI ownership that transfer would effectively be a seizure prior to getting the warrant. If it was a wallet owned by someone else but which the FBI knew the key to through other means, that would make more sense in the context of a warrant. IANAL tho.

This was ransomware-as-a-service. The sellers of the ransomware were the ones in Russia. Who knows who was buying. You think if you go to someone selling ransomware services and do foolish things with your wallet that the ransomware vendor is going to hold your hand and teach you to do it right? No, they'll just give you your cut and let you get busted, as long as they are confident that they have covered their tracks... or in this case, don't need to.

We have one that keeps track of connections and does fun things like dropping packets in the opposite direction preemptively. At its base I believe it's a BLUE queue but they call their proprietary implementation BROWN.

But it's really expensive and these days, bandwidth isn't, so the market's been a bit dry I'd expect.

It's actually a pretty privacy-conscious protocol, down even to the detail of employing countermeasures against correlating packets to individual connections.

(On that subject, a mostly insignificant nitpick is the clause "As a trivial example, this means the same connection ID MUST NOT be issued more than once on the same connection" which actually works against this interest, albeit in a way that would be statistically hard to exploit... if you see the same connection ID in different tie windows you've learned those two packets are on different connections. Naive implementations might actually make it easier to do such correlations as a side-effect of trying to follow that MUST clause, since it requires using an PRNG that does not repeat.)

I'm still only part way through reading the spec... and my main concern right now is it might be so protective that it prevents midstream packet shapers from injecting fine-grained congestion control based on infrastructure knowledge of congestion state.