My users home directory is ephemeral as well, so this wouldn’t happen. Everything I didn’t declare to persist is deleted on reboot.
What I do use tools like these for is verifying that my persistent storage paths are properly bind mounted and files end up in the correct filesystem.
I use dust for this, specifically with the -x flag to not traverse multiple filesystems.
Who gives a shit about Nintendo?
Fuck those predatory bastards.
Unrailed!
ROCK & STONE, BROTHER!
Already played 500h+ of DRG with close friends that don’t live close by.
Great game to have fun, talk, but also challenging if you want it to be.
Can’t recommend it enough!
My / is a tmpfs.
There is no state accumulating that I didn’t explicitly specify, exactly because I don’t want to deal with those kind of chores.
I don’t think they meant forcing themselves because their RAM would fill up, but because their stuff would be gone after rebooting if they didn’t move it.
DDG and Mullvad are private search engines as they strip out your trackable metadata and don’t pass on your IP address.
Is that so? How do you know?
Edit: Yeah, that’s what I thought.
I’m not using it at all, I use the *DAV functionality of my paid mail provider.
I did research on what solution I would use alternatively – with requirements very similar to the ones you proposed – and EteSync checked all the boxes, which is why I recommended it.
I set up an instance once, and it seemed to work just fine, but I haven’t thoroughly evaluated it.
Doesn’t that apply to any search engine?
I’ve been using SearXNG and its predecessor for years and I have no reason to change that. Highly recommend you check it out.
They don’t support DNSSEC.
How about EteSync?
I meant like in general…
I do agree it’s worth investigating if it happens again. My best guess so far would be some kind of data written to a tmpfs. That’d explain it not being associated with a particular process, yet counting towards actual used RAM.
Why do you care so much about memory usage?
Unused RAM is wasted RAM.
You can use journalctl -b <index>, where 0 is the current boot session, -1 the previous boot session and so on.
You can see all sessions with journalctl --list-boots if you want to pick a specific one.
Antwort sieben ist mMn wirklich köstlich.