Biggest change for me is /tmp behavior. In Debian 13 /tmp become RAM-disk by default (instead of files on the file system) and uses up to 50% of available ram. But as expected of Debian the release notes included an easy fix to restore normal /tmp behavior for people and applications that place many small or large files there.
>"You can return to /tmp being a regular directory by running systemctl mask tmp.mount as root and rebooting."
I kind of wish the distros had decided on a new /tmpfs (or /tmp/tmpfs, etc) directory for applications to opt-in to using ram-disk rather than replacing /tmp and having to opt-out.
This was discussed a ton in debian-devel. First, the tmpfs doesn't take much space already, and /tmp became a folder where persistence should not be expected over the years.
The problem with /tmp was many people and apps used it as an inter-user communication medium and expected persistency there, so it created both security problems and wasted disk space over time.
Since not many packaged apps used the /tmp like that and used the folder the way it should be used, the change was made.
I'm running Debian testing on one of my systems, and the change created no ill effects whatsoever. Not eating SSD write cycles can be considered a plus, even.
However, as I also noted in the relevant thread, the approach might have a couple of downsides in some scenarios.
What terminal emulators default to infinite backscrolling? Genuinely curious here. I've used xterm with a scroll buffer of 512 lines for three decades now and outside of large builds I can't imagine wanting more than that.
Isn't this the feature of /tmp? I set my default download location in Firefox to /tmp exactly for this reason, so that all the junk gets automatically removed after some time. Also, whenever I need a temporary Python script or test a package, I create a venv under /tmp.
On boot has been the standard for a long time and is still the most common. I am personally surprised to hear that now Debian and some distros do it via various automated ways at time intervals.
I think that superkuh's point is that it is not a systemd thing. Cleaning up /tmp by deleting old files has been around since before systemd was invented. Since before Linux was invented, even.
Outwith the world where only Debian and other Linux distributions exist, though, this isn't really systemd doing bad things to poor old Debian. To a wider world it is Debian and other Linux distributions exceedingly slowly reinventing things from Unix.
AIX had /usr/sbin/skulker from at least as early as version 1.2.
For AT&T System 5, Fielder and Hunter were popularizing a similar utility named rmtrash that is run nightly.
Fielder and Hunter exemplify traditional Unix thinking in their 1986 book on Unix system administration, which includes rmtrash:
> By putting all temporary files in one or two directories, it is easy to clean them all out at regular intervals. For this reason, it's a good idea to encourage users to use /tmp for all files they need only a short while.
skulker is not in the old comp.unix.aix Usenet FAQ document, but given the number of times "That's what skulker does, and you should be running it daily." seems to have been the answer over the years, it probably should have been. (-:
To old hands, this is not a systemd novelty at all. The novelty, to old hands, is the idea of doing this not using a script. I remember the war stories from the 1990s and turn of the 21st century when users did things like include LF in the names of temporary files, and administrators suddenly learned the utility of find -print0 and xargs -0 or find -exec rm {} +. Stéphane Chazelas for one has had a lot to say on the subject over the years.
That said, mtree (from 1989) already existed at the point that systemd-tmpfiles was invented, and already had the idea of working from a specification file with names and owners and permissions and whatnot. It is surprising that no-one ever apparently tried mtree for completely wiping /tmp. The BSDs are using find to this day in the several places with they auto-delete stuff in /tmp including the daily periodic, although they did spot that their own find had a -delete option in 1999. (-: Hell, even I am still using find.
Then I think you just don't have much imagination. I have recovered files in /tmp after turning off a machine by booting it back up in single-user mode and accessing the data before it would be cleared in during bootup. Given that "turning off a machine" can also mean "the machine lost power", I can definitely see why people would be surprised by this change.
It could be the 20+ years of using linux where it was standard for it to only have files there deleted on boot. Temp in this case means it's temporary for that boot. Recent redefinitions are surprising unless you've only come to linux recently or from unix 40 years ago.
I am going to assume you are used to tens of days wipings of /tmp. Imagine suddenly it was decided that the wiping needed to happen every tens of seconds for security reasons and to minimize ram usage. Do you think this would impact your workflows that used /tmp? This is 100% analogous to the current situation. Yes, tmp is ephemeral, but on what timescale?
No, I misunderstood the comment I was replying to, and thought they were assuming they could use /tmp as an un-curated dumping ground that was never deleted.
https://www.debian.org/releases/trixie/release-notes/issues....
>"You can return to /tmp being a regular directory by running systemctl mask tmp.mount as root and rebooting."
I kind of wish the distros had decided on a new /tmpfs (or /tmp/tmpfs, etc) directory for applications to opt-in to using ram-disk rather than replacing /tmp and having to opt-out.