NetEm seems to be rarely known and used traffic control feature available on Linux.
The linked script allows you to delay sending DNS requests (IP packets with destination port set to 53) on given interface. Normally it is useless, but it may be useful for debugging some hard network-related cases in your software.
Just out of curiosity (it's not my field), what are those 3 renderers that matter right now?
Somehow I read your comment as V-Ray is not among them as being last-gen. I remember that years ago there was a lot of buzz regarding Arnold (and it was justified to some extent AFAIR, at least judging by opinions of pleased 3D crowd), but maybe it's last-gen too now? Many years ago there was Brazil, but quick googling shows it's only for Rhino now? I haven't heard about Redshift till now, though.
The 3 GPU renderers that matter are: V-Ray RT, Octane, Redshift
CPU renderers are a different story but Arnold is right up there with V-Ray. CPU renderers are tried and true, reliable and robust.
V-Ray is the only company making both CPU and GPU renderers. The GPU version can render most of the same shaders but the backward compatibility requirements slow it's progress. It's OpenCL support is always behind CUDA as well.
He's author of great stuff out there, but I think his works should be treated more as showing the way of doing this or that than making you stick to his particular implementations (I'm not implying they're bad, though).
For instance I prefer runit over daemontools, but quite likely without daemontools there wouldn't be runit. (Actually I want to try s6 [1] soon, as it seems another step in evolution of process supervision tooling.)
But his "build system" is actually unnecessarily non-standard and clunky. I am against autohell, but carefully crafted handmade Makefiles are really nice.
And it's a base for other video editor, which is getting stronger each year, seems more stable than the others and already looks IMHO the best among FOSS video editors:
Drafts described there are not finalized and my view on some matters changed a bit. I'll try to update descriptions one day. metastore needs also some modularization to provide better OS-dependent stuff like xattrs.
All in all metastore will need more or less substantial reworking, to the point where rewriting it and providing converter from binary format may be a simpler solution and leading to cleaner (and thus more maintainable) code.
It was originally written as a supplement to git, which does not store
all metadata, making it unsuitable for e.g. storing /etc in a
repository.
metastore can also be helpful if you want to create a tarball of a file
tree and make sure that "everything" (e.g. xattrs, mtime, owner, group)
is stored along with the files.
You may use it to store stuff on filesystem that doesn't support perms, owner & group for instance, like FAT, yet still be able to restore it later. Well, FAT doesn't support lot of things, so it's maybe a bad example. Anyway, I did use metastore to store metadata of some ext4 filesystem tree before backuping it on NTFS. It worked quite well.
