Debian's /tmpest in a teapot

Debian’s /tmp-on-tmpfs and cleanup policy

• Debian is switching the default /tmp to tmpfs and enabling timed cleanup of /tmp and /var/tmp via systemd-tmpfiles.
• Some see this as overdue alignment with other distros and a net win: fewer disk writes, automatic cleanup, consistency across installs.
• Others stress it breaks long-standing expectations: /tmp as large, disk-backed scratch space; /var/tmp as “temporary but persistent across reboots,” per FHS and historical Unix practice.

Performance, RAM, SSD wear

• Proponents: RAM is fast, SSD wear is finite, and temp data is ideal to keep off SSDs. For many desktops with ample RAM, /tmp in RAM is beneficial.
• Critics: RAM is “precious,” especially on smaller/cheaper laptops and servers. Large temps in tmpfs force swapping and can destabilize systems; for big builds or ISOs, disk is faster than swap-thrashing tmpfs.
• Some argue modern filesystems and cache already keep hot /tmp data in RAM, so explicit tmpfs brings little speed benefit.

Usage patterns and breakage concerns

• Many users and tools already rely on /var/tmp or even /tmp as semi-persistent storage (long simulations, browser profiles, caches, tmux/ssh-agent sockets).
• Automatically reaping files while the system is running (based on last access time) is seen as risky; fear of partially deleted app state and subtle failures.
• Others counter that using temp dirs for important or long-lived data was always fragile; affected users should move to proper cache/data paths or site-specific dirs.

XDG directories and ~/.cache on tmpfs

• XDG base dir spec is widely discussed: half-adoption leads to cluttered $HOME and inconsistent behavior.
• Some put ~/.cache on tmpfs to save SSD wear; others say this breaks workflows that rely on persistent caches or large ML models stored there.

Swap, memory policy, and tuning

• Extensive side discussion on swap size, zswap/zram, swappiness, and early OOM killers.
• Opinions split between preferring slowdown with swap vs. aggressive killing to avoid thrashing.

Backwards compatibility, configurability, and systemd’s role

• Some argue changing long-standing semantics violates user expectations; defaults should favor compatibility, with new behavior opt-in.
• Others emphasize Debian’s configurability: /etc/fstab, masking tmp.mount, and tmpfiles.d allow reverting behavior, and admins are expected to adapt.
• There is unease about systemd owning more policy knobs (mounts, tmp handling), but also acknowledgment that its tmpfiles mechanism is powerful and central to this change.