That file format is Ogg (the combination is Ogg Opus) and since you may see it around I wanted to make sure JuK could play it and manage whatever metadata Taglib supports.

Example: Release, Debug, RelWithDebInfo

each need different build directories, install directories, enviornment options, build flags and such (though just supporting -DCMAKE_BUILD_TYPE= is usually enough)

I already accomplish the same thing with different rc files and the -rc-file option but it’s tedious, as I need to keep them in sync with each other on every change.
A better solution is to say

build-dir=/path/to/build-dir

is default build dir, whereas each of the following override:
build-dir[Release]=/path/to/release
build-dir[Debug]=/path/to/debug

and such. Supporting every variable like this seems like a good way to go.

I have to disagree on the complexity though. The xdg spec is one of the simplest specs on freedesktop.org imho. In shell syntax it’s nothing more than doing
XDG_CONFIG_HOME=”${XDG_CONFIG_HOME:-$HOME./config}”
XDG_DATA_DIRS=”${XDG_DATA_DIRS:$HOME/.local/share}”
to make sure those two are read and set properly. And if you already have code that reads stuff from several paths, it should only be a matter of appending the proper var onto it.

And yeah, I know that it’s too late for .xsession.

There’s no way to avoid having to locate ~/.xsession where it is but I’m not completely opposed to moving the other two files (even if it is just moving pollution from one spot to the other… :P)

The spec was created for a reason, you know.

The nice thing about specs is that there are so many to choose from. But in all seriousness, the spec increases the fragility of a solution to this as now it relies on environment variables being properly set, and on the script using correct defaults if they’re not set. And although I’m aware of the issue, that doesn’t change the fact that it is yet another possible failure mode, which is something you have to consider when deciding whether to pick up and adopt a spec or not.

However, barriers came about due to disks having their own caches, although, they do not guarantee that flush transactions happen in-order^[1].

If you use RAID you should consider getting a proper RAID controller *and* disabling the disk caching by the RAID firmware!

Also, you may like to also have a look at JFS. I use XFS and JFS almost exclusively on Linux (apart from /boot which is ext2). On Solaris & FreeBSD, I use ZFS, ZFS is however a very heavy handed FS and is only really useful on real iron imho.

Cheers,

[1] – http://xfs.org/index.php/XFS_FAQ#Q:_Why_do_I_see_binary_NULLS_in_some_files_after_recovery_when_I_unplugged_the_power.3F