This is seriously cool. Although the current specs are a bit funny - if you take the largest possible disc size (360 TB), then it would take a million hours to fully write it at 10 MB/s (more if the storage unit is actually TiB). That's over a hundred years.

Also if the goal is datacenter archival, then I wonder what the plan for practical use is - many individual discs with separate write "heads" (basically a RAID 0) to bring the speed up? And then maybe the maximum size per disc is a theoretical limit for the technology once we get faster access rather than something practical they intend to build anytime soon.

It didn't have to be this way

Yup, I know exactly what this video is going to be about, definitely not a click bait title, lol.

The topic is interesting, the video apparently not so much (if it needs that title to do well). So I think AI is acceptable here, given that no one else bothered to provide a summary so people don't need to waste time watching it.

Are you sure about that? DHL GLS (the shipping company Valve uses in the EU) has an app to move your delivery time or reroute the package, but it wouldn't allow me to delay my SC package because "the sender" blocked it. So it sounds like a Valve problem to me here in EU.

A roguelike written in my lisp, where the magic system is a lisp.

This is so much better and more eye catching description (first line of readme)

For some reason I can't get behind, this feature requires some virtualization mode with lowered security features.

The usual virtualized devices like network cards (that are already supported by Linux distributions like Debian) work by the hypervisor intercepting memory access to certain memory regions. Perhaps it's not viable to support these with the secure approach where the VM is protected from Android.

Absolutely agree with the fact that mAh should never have been used as a measurement of battery capacity, but increasing the voltage (while keeping the same actual capacity in Wh) makes the mAh rating lower, not higher.

1 Wh 1 V battery can provide 1 A (1000 mA) for an hour (1 V * 1 A = 1 W, 1 Wh / 1 W = 1 h) - that would be 1000 mAh.

1 Wh 2 V battery can only provide 1 A for half an hour (2 V * 1 A = 2 W, 1 Wh / 2 W = 0.5 h), and that gives you only 500 mA.

The headline is misleading if you are familiar with bloom filters.

TL;DR: the interesting thing here isn't decreased false positive rate (multibit bloom filters are common), but the idea to put the relevant bits together. Basically you use a hash to pick a chunk of bits (32 bits in this case), then use more hashes to pick the bits within this chunk.

It is a tradeoff between accuracy (completely independent hashes would be less likely to have collisions leading to false positives) and performance (all relevant bits for the object you're looking up will be together and the lookup will trigger at most one cache miss / memory access).

Maybe if ReactOS on RISCV becomes a reality

Do you mean RedoxOS by chance? AFAIK ReactOS is a clean room implementation of Windows/NT

For context, AirDrop is a proprietary communication between Apple devices, but the EU forced them to open it up and adopt an open protocol called WiFi Aware.

EU forced Apple to adopt WiFi Aware, but not to switch AirDrop to use it - the intended effect is that WiFi Aware is available to developers who can then create their own alternatives to AirDrop that are not locked to one OS.

Also Pixel 10 series can currently share even to iPhones that never got the new iOS with WiFi Aware support, so claiming this is thanks to EU is absolute BS (although often repeated, for some weird reason). This is just AWDL (which was reverse engineered long ago btw, and there has even been an experimental implementation on Linux for years) + some reverse engineering of the actual AirDrop protocol implemented on top of it.

Funny thing is that the same issue was resolved for me by switching the other way around - from HDMI to DisplayPort. So there's something weirder going on than a bug in DP implementation