My ISP enabled native IPv6 for me a few months back. It's pretty great. I don't have any windows machines, but I doubt my wife has disabled it on hers.
Anyway, our router is set up to drop incoming IPv6 traffic by default, sanely enough.
I can't recall. It's been well over ten years. I think I solved it two or three times. It was just tedious. Whatever cheap brand they had on dealextreme at the time.
Even-dimensioned cubes (4x4x4, 6x6x6, ...) are harder because they introduce some parity errors. Odd-dimensioned keep their fever center piece in the right spot.
Otherwise the size just makes it more tedious. I keep up with a 4x4x4. I had a gigaminx dodecahedron that I solved a few times, but it just made my hands tired from the weight and kept popping out pieces because of their tinyness.
Back when we met she looked me up on Facebook, where I had listed my faith. She thought it would be a deal-breaker for a minute or two until she read up on pastafarianism.
She has come to accept my faith and has even read the good book cover to cover.
No. It kind of falls on Dijkstra's old statement.
"Testing can only prove the presence, not absence of bugs."
You can prove logical correctness of code, but an abstract thing such as "is there an unknown weakness" is a bit harder to prove. The tricky part is coming up with the correct constraints to prove.
Security researchers tend to be on the testing side of things.
A notable example is how DES got its mixers changed between proposal and standardisation. The belief at the time was that the new mixers had some unknown backdoor for the NSA. AFAIK, it has never been proven.
On that level it usually falls on computer scientists. Formal methods can prove that any implementation is correct, but proving the absence of unintended attacks is a lot harder.
Needham-Schroeder comes to mind as an example from back when I was studying the things.
I'm sure it's great and all, but the hassle of having a filesystem that's not in the kernel is a no-starter for me. Maybe one of those fancy NAS-distros that are based on some *BSD.
Well, snapshots, too. I just consider them to be a special case of de-duplication.
I had an issue when I ran out of space during conversion between RAID profiles a few years back. I didn't lose any data, but I couldn't get the array to mount (and stay) read-write.
Been running BTRFS since 2010. Ext2/3/4 before that.
Using it for CoW, de-duplication, compression. My home file server has had a long-lived array of mis-matched devices. Started at 4x2TB, through 6x4TB and now 2x18+4TB. I just move up a size whenever a disk fails.
The routing is simple. Every node repeats everything it hears. A message goes out with a counter - defaults at 3, maximum 7. Every time it's repeated the counter is decremented. At 0 it won't be repeated any more.
You can DM nodes you've seen. You can create your own encrypted channels with a pre-shared key. You can link meshes over the internet through MQTT if you have an internet connected node on each mesh.
I don't think there has been huge issues with incompatible ISAs on ARM. If you'd use NEON extensions, for example, you might have a C-implementation that does the same if the extensions are not available. Most people don't handwrite such code, but those that do usually go the extra mile. ARM SoCs usually have closed source drivers that cause headaches. As well as no standardized way of booting.
I haven't delved super-deep into RISC-V just yet, but as I understand these systems will do UEFI, solving the bootloader headache. And yes, there are optional extensions and you can even make your own. But the architecture takes height for implementing an those extensions in software. If you don't have the gates for your fancy vector instruction, you can provide instructions to replicate the same. It'll be slower on your hardware, but it'll be compatible if done right.
I haven't heard of it before, but if Google bans it they must be doing something right.
I'll check it out.