What an objectively terrible, counter-productive take on what is an otherwise simple and solved problem.
Use an appropriately named folder (hi Nvidia, I hate your ".nv") in XDG_CACHE_HOME like every well behaved program in the past decade and let the disk space utilities solve the visibility issue.
It's because of articles like this that computing is an inconsistent mess. When you make a technical proposal in public like this, it's your responsibility to ask yourself "What would it look like if everyone did this?". If the answer is "a personal kind of hell", don't make the proposal.
What software should be doing is using XDG_CACHE_HOME, if it is set (along with the other XDG environment variables). That way cache directories will be where the user expects.
1. short and easy to read,
2. good for users, and
3. can be implemented in five minutes.
If we can't have programs follow this simple decades-old convention, we have no hope whatsoever of voluntary consistency in our computing world. It's literally because of the mentality espoused in this article that we can't have nice things.
Unfortunately, we have nothing but social pressure and incensed HN comments to get developers to follow it. That's why the mobile world adopted a "you shall" model: a developer won't spent five minutes to save a million years of user time unless there's some social or technical guardrail forcing his hand.
Agreed. What op wants in this case, is for XDG_CACHE_HOME to default to ~/cache when unset.
The idea is quite reasonable: suddenly all tools that show disk usage will show this directory clearly and you can easily find what’s eating up you space with the same usual tools as always.
I think they'll find they're in the minority on that opinion, so they should just set XDG_CACHE_HOME, and maybe symlink ~/.cache to ~/cache for those programs that have just hardcoded ~/.cache
Are dot folders actually a problem? I have show hidden files turned on globally everywhere always. I don't really understand how people operate otherwise.
> Dear everyone writing Unix programs that cache things in dot-directories (.cache, .local, etc): please don't. Create a non-dot directory for it.
If it doesn't live inside ~/.cache or ~/.program/cache then I won't know if I can delete it or not.
If you are not putting your cache in one of those folders, I'd expect the application itself to have a clear-cache option or for it to do it automatically from time to time.
To me, on OpenBSD that kind of breaks the purpose of unveil.
Firefox and chrome on OpenBSD is patched to use pledge and unveil. That restricts where these programs can read/write data. I would not want a program to have access to all cache data for every program.
To me, if you see dir cache, you can clear it. In fact, I have a cron job to clear cache data older than a week for Firefox. No issues doing this for many years.
> I would not want a program to have access to all cache data for every program.
Then XDG_CACHE_DIR doesn't change anything?
The path is going to be $XDG_CACHE_DIR/$PROGRAM which is what would get allowed (and neighbour subdirs disallowed); no program would get to see the others' cache.
I just checked and I have a ~/.cache/firefox right there.
Having it at a single root point means it's trivial to make all cache ephemeral in any way one chooses.
How do you know it's a cache dir and not configuration or something else? I don't say programs should have access to the cache directories of other programs just to their own inside ~/.cache.
> I'd expect the application itself to have a clear-cache option or for it to do it automatically from time to time.
Android has this. Though, the reason they included a "cache partition" back in the day was to make sure there was always enough space to download flash system.img over-the-air (as wiping clean the cache partition would provide enough room).
I don't think that putting cache in .cache is bad, as long as everyone does it. But some programs (like VS Code and Chromium) decided that .config is a good place for their cache and local files, which I think is a bigger problem.
XDG_CACHE_HOME, as mentioned by numerous other posters, is a good remedy to deal with this kind of cached-artifacts-sprawl - but it does need a will to cooperate and care from the original software developer in the first place, which ain't a given.
I went on GitHub to see if anyone was using this cachedir tag signature. Found many results so that’s cool :)
But ironically, if I’m reading correctly the command line ncurses based disk usage tool ncdu seems like it will intentionally ignore any directory that has this cachedir tag.
If your users are not fluent enough in Linux/Unix tools and conventions to be able to figure out how large a single standardized dotfile in their home directory is, I really don’t think the problem is “application developers are following a well-known standard.”
Readit News
Use an appropriately named folder (hi Nvidia, I hate your ".nv") in XDG_CACHE_HOME like every well behaved program in the past decade and let the disk space utilities solve the visibility issue.
Heck, you could even display a warning or the top directories consuming space upon login.
Not a great take - this is a operations problem, not a design problem.
Unfortunately, we have nothing but social pressure and incensed HN comments to get developers to follow it. That's why the mobile world adopted a "you shall" model: a developer won't spent five minutes to save a million years of user time unless there's some social or technical guardrail forcing his hand.
The idea is quite reasonable: suddenly all tools that show disk usage will show this directory clearly and you can easily find what’s eating up you space with the same usual tools as always.
If it doesn't live inside ~/.cache or ~/.program/cache then I won't know if I can delete it or not.
If you are not putting your cache in one of those folders, I'd expect the application itself to have a clear-cache option or for it to do it automatically from time to time.
Firefox and chrome on OpenBSD is patched to use pledge and unveil. That restricts where these programs can read/write data. I would not want a program to have access to all cache data for every program.
To me, if you see dir cache, you can clear it. In fact, I have a cron job to clear cache data older than a week for Firefox. No issues doing this for many years.
Then XDG_CACHE_DIR doesn't change anything?
The path is going to be $XDG_CACHE_DIR/$PROGRAM which is what would get allowed (and neighbour subdirs disallowed); no program would get to see the others' cache.
I just checked and I have a ~/.cache/firefox right there.
Having it at a single root point means it's trivial to make all cache ephemeral in any way one chooses.
Android has this. Though, the reason they included a "cache partition" back in the day was to make sure there was always enough space to download flash system.img over-the-air (as wiping clean the cache partition would provide enough room).
For starters, ~/.cache was invented because everyone was doing their own thing and the previous situation was FAR worse.
I don't agree with eliminating the concept of dot directories in unix just because some people haven't learned about them yet.
And of course he acknowledges that their environment is unique.
What I would do: run a script to symlink '.cache' to 'cache' in entry users home dir. Then it's not hidden anymore.
So does another standard that I've come to appreciate in all software that supports it: CACHEDIR.TAG (https://github.com/LineageOS/charter/blob/main/device-suppor...) - I'm just here to spread the word! ;)
For posterity: https://bford.info/cachedir/ is what I was meant to link to above. Sorry for the inconvenience.
But ironically, if I’m reading correctly the command line ncurses based disk usage tool ncdu seems like it will intentionally ignore any directory that has this cachedir tag.
https://github.com/rofl0r/ncdu/blob/a216bc2d35b6edf4dadf5535...
https://github.com/rofl0r/ncdu/blob/a216bc2d35b6edf4dadf5535...
Which is the very sort of thing the original post was complaining about that happens with invisible .cache directories too :^)
The number of programs that would silently or cryptically fail was too much. Had to cave in and allow them free reign.