Hi Enrico.

Enrico Weigelt, metux IT consult - 13.06.24, 15:39:56 CEST:
> IMHO, it always should been in tmpfs, for many reaons.

One of course can argue that way and its completely understandable.

I argued that it indeed is a policy change for one thing and secondly *no
one* is really telling beginner Linux users who use Linux through a
desktop (environment). And yes… while back then I could not resist
laughing over it, I still remember someone in debian-user-german
complaining that data they moved from $HOME to /tmp or /var/tmp, not sure
which one it was, but I think as /var/tmp does not usually get cleaned by
standard in Debian / Devuan, it might have been /tmp, data they moved
there in order to make space in /home had been gone after the next reboot.

The desktop file manager did not tell them. Of course I thought back then:
You should have known. But really, should they?

It is implicit policy and as I argued before "/tmp" means temporary but it
does not detail on who is responsible for the temporary bit. It is not
"/regularly-cleaned" or "/autoclean" for something like this. On AmigaOS
it was called "Ram Disk". One can still argue some do not know that RAM
usually refers to Random Access Memory that only keeps data while being
powered… but at least IMHO it has been a bit more obvious.

The sheer amount of implicit policy within Systemd has been one of the
reasons for me to switch away from it on *all* of my systems.

> /tmp was invented for *temporary* stuff (things that usually should be
> deleted soon) and should be removed on next reboot. (actually, back in
> the 90s I've often been angry about long bootup times due rm'ing /tmp)

Was it? How was it handled in early UNIX variants? Has it even been there?

Actually I have not seen a Debian / Devuan system cleaning /var/tmp on
boot since a very long time.

> a) much lower load on disk/ssd (gets written out *only* when necessary)
>     and no extra write load for metadata (that a disk fs *must* do)

On good SSDs this is so completely irrelevant.

And for regular desktop use /tmp traffic it also is not "much lower" IMHO. A
bit lower yes, but not much lower. Especially with delayed allocation in
modern Linux filesystems that basically make created and quickly deleted
files stay in RAM anyway.

It matters for USB sticks and SD cards especially those of questionable
quality, but for a good SSD it is so completely irrelevant I don't even
have words for it. Especially if you leave some additional free space on
them.

Of course writing to memory can be power saving and of course why wouldn't
you save. And yes, /tmp is a tmpfs on my desktop systems as well, but not
on my server systems.

Anyway, again… I don't even think Devuan is affected. Its a Systemd thingy
cleaning up /tmp in Debian 13 aka Trixie. Devuan has no Systemd and I
think as long as its not in systemd-standalone-tmpfiles Devuan does also
not have the Systemd thingy that does the deletion in /var/tmp or tmpfs
mounting to begin with.

But I wanted to point out, once more, that for me this discussion is not
as black and white or as binary as it appears to be.

That said, I do not really care enough about this to make a bigger fuss
about it than writing down my thoughts here.

--
Martin