Similarly, I’m following the thread for a couple of days now, and wondering about its implications.
When I consider server scenarios, pushing /tmp to RAM looks highly undesirable from my perspective. All the servers I manage use their whole RAMs and using the unused space as a disk cache is far more desirable than a /tmp mount. When servers are virtualized, RAM is at premium, and a disk cache is way more usable rather than /tmp in the RAM. The other scenario I think is HPC, where applications use all the RAM available, squeezing the hardware dry. Again, /tmp in the RAM is very undesirable, because /tmp/$USER is also heavily used and an OOM situation creates a lose-lose situation where you either delete runtime files, or lose the executing job, which results in job failure in any case. On the other hand, I personally use my desktop computer as a development workstation and use tons of RAM either with software or with VMs. Again a /tmp in RAM is an inferior scenario to my current setup. The only useful state where /tmp is in RAM is single board computers where temp is both lightly utilized and maximizing SD/eMMC life is important. These systems even mount /var/log to a tmpfs and sync on boot/reboot/shutdown, reducing flash wear. Deleting /var/tmp has the same problems since long running tasks on the servers might need a file once in a month, but it can be crucial for functions of the software. I can’t see any scenario where these two are useful in typical or niche installations of Debian. FWIW, RedHat family doesn’t mount /tmp as a tmpfs on its default installation. Cheers, H. > On 7 May 2024, at 12:42, Peter Pentchev <r...@ringlet.net> wrote: > > On Tue, May 07, 2024 at 10:38:14AM +0200, Carsten Leonhardt wrote: >> Luca Boccassi <bl...@debian.org> writes: >> >>> Defaults are defaults, they are trivially and fully overridable where >>> needed if needed. Especially container and VM managers these days can >>> super trivially override them via SMBIOS Type11 strings or >>> Credentials, ephemerally and without changing the guest image at all. >> >> That argument goes both ways and I prefer safe defaults. What >> you/upstream propose are unsafe defaults, as was shown by several >> comments in this thread. Whoever wants the unsafe defaults of deleting >> old files and risking OOM situations can than "trivially and fully >> override" the safe defaults. > > So I've been wondering for a couple of days now, following this thread... > ...would it be a good idea to make this a debconf prompt, high priority, > default "yes", so that it is activated on new automatically installed > systems, but people who upgrade their current Debian installations can > choose to keep the old behavior? > > I do realize that more debconf prompts are not always desirable, and > such decisions must be taken on a case-by-case basis, so... yeah. > > G'luck, > Peter > > -- > Peter Pentchev r...@ringlet.net r...@debian.org pe...@morpheusly.com > PGP key: http://people.FreeBSD.org/~roam/roam.key.asc > Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
