This whole thing fails at ""If you can describe what you want to do in natural language". Judging from the lack of quality documentation for most software products these days, plainly, people just start coding before doing any such thing.

No need to become a vampire. The "young blood" theory has been pretty comprehensively discredited by research at Berkeley. They found that any benefit from infusing young blood was undetectable compared to the benefit of just throwing out the old plasma and replacing it with temporary substitutes until it regenerates.

So basically if we're comparing quack therapies, leeching was closer to a treatment for senescense than vampirism, blood baths, or whatever else those medieval nobles got up to with their squires.

https://news.berkeley.edu/2020...

Hopefully human trials won't take intransigently long and hopefully we don't find out the stuff in our blood that contributes to aging is needed to keep us from growing mushroom shaped tumors out our pee-holes.

It'd be better if they just stopped providing services in Florida entirely. For the rest of the country, that would be no big loss.

I'll have to read their spec. Would not be very surprised if they just bastardized PoE++. I really don't understand the industry factors that let USB get away with this over and over -- produce a crummy thing, then upgrade by assuming the features of some thing that was superior, but do it in a crummy way to produce the next crummy thing, then wash, rinse, repeat. Thoeretically "market forces" should have thrown it in the dust bin ages ago but this standards set seems to be the teflon don of the peripheral bus.

At least the C connector is somewhat more sane than its predecessors.

Yeah, for most EV use cases current charging times are sufficient and what is needed is lighter, less expensive, more recyclable energy storage, not fast discharge.

If TFA's claims are true it hits some of these categories. As one poster pointed out, gravimetric/volumetric energy density vs Li-ion isn't elaborated on. There's also the potential for use as fast charge/discharge buffer storage between the main pack and the ultracaps in any case.

Well they do have a point, minus the rhetoric. I do save a lot of time these days not standing in front of a gas pump with my thumb up my ass. Especially appreciated in winter.

The APs I administer require a DHCP transaction before forwarding traffic from a client and then only accept IP traffic from that IP/MAC tuple (and handle ARP via proxy so there's no way to poison the table). Sure you could spoof a packet using the same IP/MAC tuple but you don't have the correct session key to encrypt it, so it will be thrown out if you do.

I administer enterprise class APs, but this can be implemented on home routers (even networks thereof) if they can run OpenWRT and I've done so. But it wasn't a pre-packaged option. See https://github.com/michael-dev...

WiFi has some advantages in that wired traffic doesn't usually require any authentication to access, just physical access to a port on the wall. The AP/router are more easily physically secured than tens of outlets scattered around the home. And nobody these days buys a switch with access security features for their TV room.

(Nor do commodity household APs prevent packet spoofing on the WiFi network to be fair, I had to go find a little-known github project that implemented it and graft it into OpenWRT myself when I was buiding a cheapo WiFi network for a friend.)

I don't even use an AP at home. Mostly because I work with them 9 to 5 and don't want to deal with the in my iiving room as well.

One of the demonstrated attacks does inject a forged packet into a WiFi router.

It's a WiFi driver thing. Depends on the hardware, firmware, and software.

(Except for the handling of the bit in question. That's being described as a standards flaw... though there is a feature in the standard to validate that bit it may be a while till enough devices support it to be able to turn that on. But fixing the driver problems makes it really hard to do much with the flaw.)

I'm not sure I'd put that one down to being security conscious they could just be way behind on feature set implementation.

Really it's down to the individual driver level. It's the driver implementation flaws that give these attacks their teeth. WIthout those, I think (?) the best you can do is launch an expensive attack to try to leak key bits. With them... well... injecting plaintext packets and having the device honor them is a bus-sized hole.

So each card/OS combination needs individual assessment.

Not all VPN protocols or options within the protocols are as secure as advertised though, so be careful there. Nothing protects against RF DoS of course.

But even with an IPSec interface up, you still have to trust the OS to just chuck all the cleartext garbage still arriving on the network. Not so easy with commodity devices. They loves them some multicast service discovery protocols.

This data is unlikely to contain anything sensitive and not really a prime target for tampering. So cloud components taking advantage of colocation with peering points are, for once, a perfectly viable component. As long as they can provide the reliability needed by the provider/consumer systems and they don't upchuck due to servers being live migrated behind the scenes.

Point taken as to managed services forcing unwarranted and sometimes dangerous upgrades. But you can always rent bare metal at one extreme, or something a little less bare but less subject to churn. There are a lot of providers with a diversity of offerings.

As far as leaking it to enemies... if an adversary really wants the data they could do so more easily by compromising an authorized consumer's system. If they don't want it bad enough to put in the effort to do even that, consumer account security should be sufficient.

All the news has been mentioning the white women, too, and addressing violence against women as well as against AAPI folks. You obviously don't watch the news and just assume it says what you thought it would.

I wonder if they'd be good enough for data-closet UPS use. Most of those UPSes are more there for surge/overvoltage/undervoltage protection and to keep equipment up over 1-15 minute service disruptions than they are there for extended runtime uses... people don't usually remain in office buildings during extended power outages.

The major UPS industry vendors seem stuck on lead-acid with no signs of adopting any other chemistry. I'd love to not have to replace those batteries as often as I do now, though I'd prefer if the chemistry was stable and not fire-prone, so like LiFePO or NiMH.

I'd like to see more from this company as to air quality measurements inside these units. Could be it's fine...could offgas something nasty for decades. They don't say much about what exactly is in their material, or at least it wasn't something I readily happened across on their website.

I live in a very old house (where I am no doubt being poisoned by some ancient no longer used construction material, but...) and I can still smell the glue drying just walking into 5-year-old buildings at work, because my nose is not numb to it.