ACLs on Linux can be a bit weird. If I remember correctly, the ACL mask corresponds to the group bit when using masks. Some more details here:
https://unix.stackexchange.com/questions/65888/setfacl-incorrectly-changes-group-permissions
As an aside, I’ve been watching bcachefs with some interest, as it seems to be getting faster with every kernel release, building on the data integrity guarantees of ZFS while pushing performance boundaries and being GPL compatible (i.e. in tree). Kent Overstreet et al. have done a fantastic job with this FS.
A combination of XFS and ZFS. I work in high performance computing (academic). While I love the reliability of ZFS for data archival and peace of mind that results provably haven’t suffered bitrot, sometimes I just need a 10 TB temp file(s) with fast mostly-sequential R/W. Appropriate selection of file systems lets me have both.
Yeah, but it’s had some actual data corruption bugs related to sending encrypted snapshots (off the top of my head).
I feel your pain on the CDDL (although I think it is still considered a “free” license), and while I love to hate Oracle, I think the CDDL decision was originally Sun’s, even if Oracle could “free” it now to be GPL.
Just to verify all permission-related things in one go, see if you can open the key as your user with an editor like vi or nano. This will let you separate out some behavior specific to OpenSSL vs some behavior purely permissions-based.
I’m not sure what’s happening here, but the above test can at least narrow the focus.
Here I was hoping that if you took the UTF-8 representation in bytes and decoded it as ASCII, you would get something interesting. But no, just Unicode characters. Almost interesting is that none of the bytes are valid ASCII characters (< 128), which you might expect for the first byte of every UTF-8 codepoint due to backwards compatibility for ASCII encoding, but perhaps not for the subsequent bytes that comprise the rest of the grapheme.
I'm finally starting to understand the appeal of numerology.
These formats are generally not very compressible by general purpose compression algorithms, as they are already compressed formats themselves, each with a compression algorithm specially tailored to their content type.
Been awhile since I've looked, but you might consider pixz:
Even Palo Alto notes that they can only effectively block DoH if you're MITMing all https traffic already (e.g. using a root certificate on corporate-managed devices). If not able to MITM the connection, it will still try to block popular DoH providers, though.