3 ms·

Code and scripts should be well behaved and clean up after themselves. There’s zero reason to periodically go in there and wipe stuff out. Especially when some

Code and scripts should be well behaved and clean up after themselves. There’s zero reason to periodically go in there and wipe stuff out. Especially when some file systems don’t have a creation time attribute in the on disk inode and some archiving tools preserve the mtime when unpacking. A newly placed file can already be five years old. Also the tone of some of the included quotes is so offputting. Their statements and arguments for this change don’t even acknowledge the fact that there are different views on this. This change comes across as progress for progress’ sake. Makes me want to make a 500TB /var/tmp and never delete anything.

Izkata 2y ago
> There’s zero reason to periodically go in there and wipe stuff out. I swear I remember back when I first switched to linux (Ubuntu) back in the late 2000s, this was how it worked: Instead of a tmpfs or automated wiping on boot, a system crontab entry that would use "find" to delete files last accessed more than some time ago (a day? a week?). Except for the risk of filling the disk if files are created too quickly, this would seem to be the best of all worlds to me - stuff can't stick around forever unless it's constantly being used. A download you access once would stick around for a day, while a heavy project that's using /tmp/ would stick around for the week or month you're using it, even across reboots, then get deleted later.