Both. It's just more flexible than two 1GbE NICs.
2,847 karma · joined November 10, 2007
WireGuard encrypted UDP packets have obvious signature due to the packet type field in the header being in cleartext. DPI can easily filter/drop WG traffic just by checking the first few bytes of each UDP packet and doing simple statistics.
To obfuscate in this context means to morph WireGuard encrypted UDP packets to look like something else (e.g. VoIP traffic).
Current kernel-based official WireGuard implementations leave no possibility of doing so while staying in-kernel.
Bluetooth peripheries suck in my environment: jumping mouse cursor and missing/lagging/repeating keystrokes. And the Mac's Bluetooth module occasionally freezes and disconnect ALL peripheries.
Logi's Unifying Receiver is very nice but it has a very bad track record of security. This new toy seems to address that.
This isn't guaranteed, depending on many factors.
> why would I want to remove the SD card after boot
It's unnecessary to remove it. It's more about reliability. SD cards are notoriously unreliable, and it could potentially fail after boot. Coupled with the previous point, it has happened multiple times that I wanted to login to troubleshoot the system, but cannot because the basic system binaries like `ls` are not cached in RAM (as you said these are not used for the normal operation of these unattended systems).
This is when RAM disk is very helpful: as long as the system is powered on, I have reasonable confidence that I can login and see what's going wrong. It's mostly because RAM is way more reliable, faster, and cheap enough to "waste" a few dozens megabytes for the entire base OS.
Also there're diskless PXE systems where you just load the OS from network only once upon boot.
I thought the animation was intentionally there to keep you engaged and hide the fact that Time Machine restoring is super slow, especially over network.
It used to be over Apple's proprietary AFP protocol. With the exception of Apple's now-discontinued Time Capsule product line, all NAS implement AFP using the open-source Netatalk, presumably with reverse-engineered AFP protocol. And it's unreliable.
With recent versions of macOS, Time Machine switches to SMB protocol. Apple has a custom SMB implementation, and all NAS use Samba. And it's still unreliable!
I guess the only reliable solution to use Time Machine over network is to use a Mac with File Sharing over SMB enabled. At least both ends run Apple's SMB implementation.
I guess there are significant differences due to flash wear-leveling and write-amplification but I'm not sure. What I know so far is that there's difference in wear-leveling because apparently cheap USB flash drives/SD cards might not do global wear-leveling but rather only limited local wear-leveling. This shouldn't be a problem for append-only logging because it's not writing to the same block repeatedly.
However for write-amplification I'm a bit confused. Does append-only logging to an existing NAND block require reprogramming as well? If so, small appends will leave to very large ratio of write-amplification and significantly shorten the NAND life time, right?
This is particularly important for devices like Raspberry Pi which rely on USB flash drives/SD cards for logging.
Completely native to Mac and iOS, and sync via iCloud.
Tunneling WG over SS would be inefficient for obvious reasons. Maybe there should be a more lightweight solution.
Unless you mean WireGuard over Shadowsocks UDP transport, but that is even less common.
(Disclaimer: I wrote the official Go port of Shadowsocks https://github.com/shadowsocks/go-shadowsocks2)
On the other I'm sad that once it's accepted into kernel, it won't be possible to add interesting changes (e.g. obfuscation, forward erasure correction, etc).
I'm torn apart :P
My mind is blown.
It's called ossification. Same reason why TLS 1.3 has to pretend it's TLS 1.2, and QUIC must be over UDP.