You assert that ECC RAM being necessary for ZFS is just a myth but provide no justification for why that is untrue.
Is it not the case that if you don't have ECC memory, ZFS could end up writing a checksum that does not match the data if you get a bitflip in just the right (wrong) spot?
This seems to store the zfs send stream. That's a bad idea.
> Incremental ZFS send streams do not have any of these properties and full ZFS send streams only have a few of them. Neither full nor incremental streams have any resilience against damage to the stream; a stream is either entirely intact or it's useless. Neither has selective restores or readily available indexes. Incremental streams are completely useless without everything they're based on. All of these issues will sooner or later cause you pain if you use ZFS streams as a backup format.
One pitfall of this is that the decompressed contents of your initramfs must fit within half of your physical RAM since Linux decompresses it into a tmpfs.
Or if you set rootfstype=ramfs, then you can take up to all of physical RAM, but ramfs isn't swappable.
I'm very confused by your comment. The grandparent comment talks about using the gitrevisions syntax in a GitHub URL to search the reflog stored on GitHub. Nothing to do with your local clone of a repository.
> They're the ones who have normalised constant churn and thus needing to keep drivers for hardware, sometimes many years old, up to date year after year or even month after month.
That's exactly why you should mainline your code. Then people refactoring other subsystems will fix your code for you.
> A patch is a patch and the author should be credited as such.
But the patch was not taken. The maintainer fixed it a different way. So credit is given for reporting the issue and suggesting a fix, and that is what is represented by the Reported-By. Is that so hard to understand?
No, that's not what "Reported-By" means. The kernel community has different conventions.
This entire HN comment section is ridiculous with everyone acting as if the author wrote an entire subsystem and someone else took attribution.
The author here figured out a bug and suggested a fix. It happens that they conmunicated their fix in the form of a patch, but that happens very regularly in kernel land.
In the end the author got a Reported-By, which is entirely appropriate for what happened. If the maintainer accepted the author's patch as-is or with minimal modification then yes, they should get Author attribution. But the patch that was taken was substantially different.
Isn't this just how mounts work? If you have a something mounted to /apex/whatever and each app has a separate mount namespace, then mounting over /apex/whatever in your namespace wouldn't change anything in any other mount namespace. You'd need to either just alter the filesystem directly, or enter the other apps' mount namespaces and mount your tmpfs there too.
Shared mounts might be useful here. Not sure. I'd need to take a closer look at what is going on here.
But I would say this result is probably a byproduct of whatever namespacing/containerisation Google is doing, rather than an intentional effort to prevent users from changing the root CAs even as root.
Is it not the case that if you don't have ECC memory, ZFS could end up writing a checksum that does not match the data if you get a bitflip in just the right (wrong) spot?