Story behind the daemon: a few weeks ago I noticed that I don’t have space in my /home. Investigation led to deleting ~20GiB of ancient garbage from the dot-dirs there. In too many cases I wasn’t been able to detect who created those files and if I need them. I didn’t like this situation, so I present you with a solution.
Be careful, though: the code isn’t tested. It is more like working “proof-of-concept” than a real release. Code is ugly as hell too. Pre-release beta of the alpha version.
But it works on my machine and can be initialized through the CLI, without recompiling or manual DB-editing. So it is usable. So use it.
I would need to install it now to use it in the future. But I don’t have the problem now, hence I don’t install it. When I need it, it won’t be installed. I install it after I need it and then I don’t need it for another year or so and then I uninstall it again because I don’t use and need it.
Out of curiosity, would it make sense to tag each (home dir) file with the creation/modification process (id)?
If yes, why is it not tagged by default? Could this be implemented upstream? It sounds extremely useful. Is it not?
I don’t understand. Yes, this daemon “tag each (home dir) file with the creation/modification process”.
i won’t have it installed when I need it because I only install stuff when I need it. As soon as I need it, it is too late. Hence it should be installed by default for all users - unless there is a shortcoming. Why is this not the default?
Because it isn’t THAT important tool. People lived for 80 years without this data and could live further without bothering. I bothered, though.
Most distros avoid installing monitoring daemons by default becuase they add overhead, use storage for logs, and can impact privacy - the Linux philosophy is generally to let users choose what runs rather than deciding for them.