I'm a bit confused. The point of this article is that the author used .NET Interceptors and TagWith to somehow tag his EF Core operations so that they make their own busy_timeout (which EF Core devs think is not necessary
https://github.com/dotnet/efcore/issues/28135
) or do a horrible global lock? No data is presented on how it improved things if it did. Nor is it described which operations were tagged with what. The only interesting thing about it are the interceptors but that's somehow not discussed in HN's comments at all.
Indeed, writing this on a laptop with Linux that cant sleep and gets random crashes with blinking caps lock about once a week. Whether its Realtek ethernet adapter can run at its nominal 5gbps on a 6.14+ or <6.10 kernel without CPU soft lockups is an open question
Not sure, if that's a reasonable possibility, but it's kind of irrelevant, since I would still consider a detected benign tumor a true positive for an MRI scan.
I have a ubiquiti 30w poe+ injector that somehow doesnt provide enough power for 20W aruba AP. When I plug it in a 120W switch it works unless the cable gets too twisted or something. I vote not awesome
Don't buy Ubiquiti. Personally speaking, anyone doing passive PoE (even if only on other device series you're not looking at) is automatically on my shitlist.
I'm not surprised they can f* up a basic PoE injector. The reason for doing passive PoE is saving a few bucks, on the back of safety and compatibility. Of course they would try to pinch hard on the PoE injector too.
Oh and I'd say they (together with Mikrotik) are responsible for 90% of the bad rep PoE gets. The IEEE 802 stuff really just works. And I say that having been part of rolling out 15000 people conference deployments with several hundred wifi APs in the span of a few days. The only real problem is broken cables, but the Ethernet link commonly fails before PoE is impacted.
Fwiw, I’ve had a few different PoE switches from Ubiquity and at least so far haven’t had any problems with the switches.
My current one is the 48 Pro-Max etherlighting , and I have around fifteen PoE devices and it’s pretty much plug and play always.
I did have issues with some of their other products - eg an old CloudKey gen1 that I had remotely in my parents place that I think ran out of space to the point it can’t update itself and can’t compact some old mongodb.
Ubiquity only did passive PoE in the very early days. Everything has been 802.11 variants for a long while wow. The injectors that shipped a decade ago with my APs were all 802.11af.
The UniFi line has moved away from passive PoE. The "UISP" line is almost exclusively passive PoE, even for brand new products. Ubiquiti has proven they know how to make devices that support both when they transitioned the UniFi line, but they actively choose not to and to enforce the use of bad nonstandard trash with their new products in their ISP product line.
The majority of UISP devices they sell are all relatively old products. For example the 'NanoStation 5AC Loco' is a great $50 product that continues to work well, but it was released in ~2019. And they continue to sell new models of products that have been unchanged for over a decade.
In the last 2 years they've released very few new UISP products and you're right that they continue to be passive PoE. I suspect this is for continued compatibility with their older product line. Upgrading from passive PoE to active 802.3 PoE requires replacing the injector and maintaining passive PoE makes it easier to upgrade. And the UISP product line is really meant for wireless ISP operators, not consumers, where the risks of passive PoE are smaller.
Anyway, I agree with the sentiment, but I don't hold it against Ubiquiti too much for continuing to use passive PoE for their UISP line, since I think it makes sense for their customers. As so-so work around you can get a 802.3 -> passive 24V converter: https://store.ui.com/us/en/products/ins-3af-i-g
> And the UISP product line is really meant for wireless ISP operators, not consumers, where the risks of passive PoE are smaller.
I'm afraid that's not how it works out in actual practice, it's the other way around:
WISP devices are installed in random people's windows, roofs and chimneys. The injector might end up behind their TV set. If their TV doesn't work, they unplug and replug random things. Which will fry whatever has the unlucky pleasure of ending up on the output side of the injector. I'm unfortunately speaking from experience.
Meanwhile, people buying and putting up a wifi AP beyond their CPE wifi router tend to have a bit of understanding. If you told them to never plug anything other than the given device into the output side of an injector, it'd probably go reasonably well.
Isnt the weakness here that there was nothing encrypting the actual key? On a laptop luks key stored in a tpm would usually be encrypted using your passphrase
The NTSB report noted that if the TrustZone secure enclave system was being used, then yeah this data would be toast.
But it speaks more to Oceangstrs negligence that this situation even existed: why wasn't any potential encryption keys escrowed ashore to ensure they could be recovered later? This shouldn't have even been an issue.
It seems the manufacturer of the camera didn't even know (at least in the part of the org communicating with the NTSB) that their storage was encrypted. In any case the media recovered were from testing/non-dive environments, and during an actual dive footage would presumably be recorded directly to the onboard computers (which were irrecoverably destroyed).
Oceangate should take the blame for a lot of things but probably not this.
reply