Unfortunately the binary packages are still only available upto x86-64-v3, so users on x86-64-v4 (which I reckon what majority of "advanced" users would be using) and even more so AMD Zen 4/5 users would be missing out on advanced instructions and other compile optimisations.
Luckily Arch/CachyOS users don't have to worry about this as CachyOS offers optimised packages for modern CPUs. Until Gentoo offers an equivalent - without manual compiling needed - I won't consider it.
The choice of tools depends on what you want to write.
For some applications, react/node makes more sense. For some applications, .net/angular makes more sense. For some applications, python makes more sense.
You have to consider ecosystem and language features.
Running a mailing list is too complicated. RSS and ATOM are infinitely simpler than maintaining a mailing list.
Or, just run a telegram announcement channel.
Overcoming email spam filter is a lost cause because of the spam issue of push notification systems like email. Push notification systems that allow anyone to send messages to you will not scale well beyond personal correspondence and receiving subscribed notifications from forums and github.
Pull notification systems like RSS, ATOM, telegram announcement channel, etc, ... are much better because they have zero spam issue, and there is no spam filter to overcome.
Not production ready. Not very usable right now. I need several more months to improve the tooling, error handling, and general compilation functionality. Stay tuned!
Yep, individual file checksums match in the destination filesystems, and they get scrubbed routinely to ensure overall durability. I've also been able to send incremental snapshots to a third system from either of the first two, interleaving where the snapshots arrive from, so I am pretty convinced that for my use case the raw snapshot transfer is sufficient. I was also able to change the wrapping passphrase on the origin system and propagate it to the destinations successfully (I can `loadkey` on the destinations with the new passphrase).
I am not sure if this is correct. The consensus seems to be, there are a number of related bugs pertaining to ZFS raw send and receive. There seems to be a set of very special circumstances that trigger it. In fact, it’s so rare, that ZFS developers don’t have enough reports and dsta to reproduce and fix it.
Moreover, those bugs have not led to data loss (someone may correct me if there are confirmed data loss reports among them).
Otherwise, software always has bugs that you can find their bulletins. Like I use restic and Borg and there are sometimes integrity errors. I have repositories in both with integrity errors in them.
I've had a few cases data loss related to ZFS encryption, causing a total loss of a dataset and all of its ancestor snapshots. The key used by this dataset is simply missing from the keystore, and so it fails mounting with I/O error. We have no idea why or how could it happen, but the pool also had a lot of these "innocuous* bugs, while ZFS never reported a single error from the backing disks. This happened on two different full rebuilds (from scratch, using zpool-create and manual recreation of all datasets with rsync) of the same pool, but on the same hardware and with the same workload. I am 99.999% sure that this is caused by the native encryption code, probably compounded by sending very regular snapshots (not raw, though).
Weirdly, this only happened on a few datasets that were not used a lot, the datasets that have lots of IO have only had the innocuous errors (the ones that refer to deleted files).
I did try debugging some of this with a ZFS developer, but we were not able to recover the data, and digged deep enough to see that something was very wrong with these datasets (it was not just a bitflip somewhere, rather that dataset used a key from the keystore that was supposed to exist, but didn't.
This is just repairing the index file, automating what used to be done manually: salvaging the rest of the data that has not been lost hopefully (not restoring lost data).
LUKS is okay in compariton to GELI. btrfs doesn't have RAID10. btrfs RAID10 is actually RAID1 with some performance optimizations. zfs makes lvm obsolete. mdraid is inferior to zfs.
I wouldn't say they are monsters. But, they are just not good enough.
Because zfs native encryption is still immature for send/receive, there's still some value in LUKS, and zfs native encryption doesn't yet support multiple key slots because it is essentially unmaintained.
You don't need to customize it, but you can still get packages from third party overlays.
The customizability is available when you need it or want it.
Learning to use gentoo's basic functionality doesn't cost a lot of time, and I recommend utilizing only the basic functionality in most cases.
Just stick to the basics, and you will be fine.