> Arguably, principle of least surprise is very Apple.

Principle of least surprise is good engineering practice. The question is always whose surprise. Someone who expects tar to behave like other UNIX systems is going to be surprised by this. Someone who expects tar on Apple to have perfect fidelity would be surprised by not-this.

I increasingly feel like build systems should never be relying on any "native" utilities from the host system, and should instead be bringing them in via dependencies. You can't have this problem if your packaging system pulls in a specific portable `tar` library.

> I want that file system archived to tape. And so, tar does.

The traditional UNIX tar and cpio utilities cannot archive the modern Linux file systems without loss of metadata.

Most modern tar programs implement various file format extensions as a workaround for this, but the extensions may be incompatible between distinct tar programs and frequently they are very poorly documented.

Some years in the past, libarchive was the only archiver available on Linux that guaranteed lossless backups for the Linux file systems, e.g. xfs or ext4 (and also lossless file transfers between Linux file systems and FreeBSD file systems). Therefore that is what I have been using on Linux since then.

Presumably since then GNU tar and other tar programs should have caught up with it, but I have not verified this.

Whichever tar program was used in TFA, it was an obsolete tar program, and that was the real problem, not that the archives had been created on an Apple computer.

If you think that most people who run the tar command are assuming it will work like a tape archive, you'll probably be the one surprised

> That said, never seeing another .DS_Store should be a system-wide option!

Yes please.