[moe]

That's interesting, and sort of disturbing.

My box is not a desktop, so that's probably the difference. I still find that scheme an atrocity.

When going to that length they could at least have settled for one directory (~/.appdata or whatever). Half-baked is the most polite description I can come up with.

[mcpherrinm]

But all those folders are different, so a single one would be annoying (or: require two layers.)

.config can be posted online, and shared with others (like the many "dotfile" repos you'll see on github)

.local needs to be backed up, and may have private data.

.cache can be blown away (or tmpfs.)

.run MUST be blown away on restart.

This is simple, sane, and works well.

[moe]

Yes, if you push me like that I'll say it: it's incompetently overdone.

When your goal is to "reduce clutter" then 2 layers would be the minimum. You make another 4(?) folders in my home-directory and call that reducing clutter?

And when I delete an app then I have to look in all of them? That is just utterly backwards for no conceivable reason.

Due to the semantics you now suddenly need a cronjob or similar abomination that traverses all home-directories and picks out stuff ("MUST" be blown away). This will by definition be fragile and have funny corner-cases in the first few iterations. Also what happens when ".run" is not blown away, like on a system that does't implement this nonsense?

The definitions are blurry and complex, many apps will get them wrong (.local vs .config etc.).

Unix already has a location for temp files. It's called /tmp.

And what the heck is going in .local anyways? When the user saves a file then he pretty surely doesn't want it buried under some dot-directory.

[saljam]

When your goal is to "reduce clutter" then 2 layers would be the minimum. You make another 4(?) folders in my home-directory and call that reducing clutter?

I can see a clear and very useful difference between RUNTIME_DIR, CACHE_DIR, and CONFIG_DIR. Consider a scenario where $HOME is on a networked filesystem. RUNTIME_DIR has to be outside that, and local to the machine's namespace. That's because it references things inherently local to the machine. That is, pids and pipes. These wouldn't make sense on any other machine and will just make the application's job harder.

I also set CACHE_DIR to be local (/tmp/$USER.cache.) That's because caching performs terribly when it's flying over the network. Chrome is the main culprit for me. It also fills my file quota with hours of using it. However, it's still useful to keep that data in the medium term.

CONFIG_DIR and DATA_DIR, however, don't seem to be very different to me. I can't imagine a scenario where I want one but not the other. I might be using the wrong sort of applications. (For the record I have 8 files in .config, 10 dot files, and just 1 in .local/share.)

Due to the semantics you now suddenly need a cronjob or similar abomination that traverses all home-directories and picks out stuff ("MUST" be blown away).

Having RUNTIME_DIR on a tmpfs, like what most distributions do with /var/run, solves that problem. I map mine to /var/run/$user, even though I've yet to see an application actually use it. The spec BTW doesn't even specify the default value!

And what the heck is going in .local anyways? When the user saves a file then he pretty surely doesn't want it buried under some dot-directory.

I agree, the default values are silly. This, like most of Modern Unix, is an ugly hack which makes dealing with the rest of the ugly hacks a bit easier. If you want an elegant solution you'll probably have to throw away most of what was added during last 20 years. May I suggest starting with sockets?