Oddly specific question, but can anybody confirm whether the AX210 (no vPro) wifi works with the AMD motherboards? I've seen some pretty bad reports about the realtek chip they're defaulting to on the AMD systems, and I already have the AX210, so if I could just keep using it, that would be ideal.
I haven't seen issues bringing over an AX210 but I've barely used it so I'll have to keep an eye out for that.
I think just in its own right there are some AX210 Linux driver issues, particularly with 6E connectivity; I don't have a 6E network so I haven't really noticed.
Speaking of snapshots, are you planning to have analogs to ZFS's send/recv and diff? I didn't see any mention of them on the snapshots page or the roadmap, but I could be looking in the wrong place. Already having reflink support is exciting though; a ZFS replacement that can also do reflinks would be amazing.
Yeah but it's not really designed yet. We have the main pieces - all metadata exists as keys in various btrees, and keys all have version numbers so we can easily do a protocol to transfer all keys newer than x - and then your remote filesystem will be up to date.
To make it efficient and fast we'll want to be able to do it without scanning all filesystem metadata, which will require auxiliary indices, and that'll probably need some careful design to make it fast. But we've got transaction layer triggers, so we've got the model for that stuff in place.
Also reflink support is plenty solid at this point. I can't really recommend snapshots for production use yet - in particular, we're missing per snapshot/subvolume disk space accounting, which you kind of need. But reflink's been in use and getting tested for ~2 years now, and there's no known issues with it anymore.
Okay, good to know it's being considered. For a non-optimized diff then (zfs-diff, which just prints which files have changed, not what about them have changed), it would be the same approach? Scan all the metadata looking for keys with versions between the two snapshots, and print out the associated file names? Would that simple approach be likely to be faster than whatever rsync does to find updated files when doing a backup?
If you just want to know what files have changed, there's no reason to scan all metadata - you'd just want to scan all the inodes (and we'd need to add a version number field to the inode itself that covers all the contents; easily done). And since just prior to snapshots inodes have backpointers back to dirents, so given an inode we can easily get a path.
So yeah, that would be easy and a lot faster than what rsync does. Dunno about plumbing to anything in userspace, that's outside the scope of what I can think about right now. But if anyone wanted to work on such a feature, I'd happily help them get started.
I've personally seen as low as 30ms, but also up to 60ms. I also have a bit of packet loss, but my dish is just sitting on the ground in my wooded back yard right now. Once the weather turns back towards just being cold, I'm going to move the dish to my roof and see if that helps the packet loss. Maybe being able to see more of the sky will help get a more consistent latency too, but I'd guess more satellites are really going to be the fix there.
A specific safety article was written up by tweag.io, who wrote a pretty slick set of java bindings. Managing resources between two garbage collectors (ghc and jvm) is error-prone, so they used linear types to help prevent a bunch of the things a person can easily mess up. Their article is pretty good: https://www.tweag.io/blog/2020-02-06-safe-inline-java/
I don't personally do this, but if you're taking scheduled snapshots of your ZFS filesystems, you could also have a scheduled job (say, nightly) that emails you a "zfs diff" [0] between the current snapshot and the one from 24 hours ago. It won't tell you that you've been hit by malware, but an unexpected spike in changes could be something worth investigating.
Somewhat; if your system boots through EFI (as opposed to the ancient BIOS boot), then you can compile your kernel with the EFI_STUB option[0]. That kernel can be placed in EFI/Boot/bootx64.efi (or whatever you've configured your EFI to boot), and the EFI boot loader will run it without any other boot loader. IME, this goes very well with a built-in initramfs (INITRAMFS_SOURCE[1]), so you have a single-file kernel and ramfs that boots directly from EFI.
I'm curious why there kernel needs to be specially compiled for this. Is it somehow impossible to build an EFI program that boots whatever is concatenated to the end of it? Is it similarly impossible to have the kernel boot an initramfs concatenated to the end of it? This would make it trivial to swap out the individual components without recompilation.
It's not much tinkering at all. Once you've installed powertop (probably just "dnf install powertop" or "apt install powertop", or whatever your favorite flavour is), you can just run "sudo powertop --auto-tune"[0]. If you do like to tinker, you could maybe write your own init script to run that on boot, but your distro probably included one already.
