6 ms·

/var/tmp, IMO, shouldn't exist--the idea of temporary files that should persist beyond a reboot is tech debt, those files should exist under a proper /var/{cach

/var/tmp, IMO, shouldn't exist--the idea of temporary files that should persist beyond a reboot is tech debt, those files should exist under a proper /var/{cache,lib} directory. Podman uses this directory and it drives me nuts. The XDG base directory spec (https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html https://specifications.freedesktop.org/basedir-spec/basedir-...) was supposed to solve all of this...

deleted 2y ago
[deleted]
zbowling 2y ago
Nah. XDG base directory was supposed to solve a ton of things 18 years ago, except none of them are hard-hitting user problems most folks really care about most of the time unless you are really anal about hidden folders in your home directory polluting things up (most people aren't), so it fails with partial support from apathy from some package devs on Linux to implement it. Honestly, we should probably abandon the hope that we will ever get full universal adoption. It stinks even worse with the half-adoption state we are in now, with some apps writing to those directories and other apps not. If it wasn't for arch Linux folks trying to drive apps to adopt it more, I don't think it would be. Hell, default Debian/Ubuntu still doesn't set XDG_* directory ENVs by default (some flavors do), and some apps ignore the prescribed "if not set, use this default" nonsense in the spec and do what they have always done because it doesn't break compatibility for users. Part of the spec stinks, too, like the spit between cache/config/data config where the spec has no written rules specified on when anything is expected to be cleaned up and when or what can or should be backed up by the user. Let's move to containerizing most apps, putting everything in little jails so we don't have to deal with where they want to write to. They can have their own consistent and expected behaviors on their own island. Snapcraft, flatpack, or any of a bunch of other solutions are already available to solve this problem. Don't have to worry about what some app left behind or wrote to your system when it's all contained.
- 38 2y ago
  [flagged]
  - zbowling 2y ago
    Guess you have never used https://snapcraft.io/ https://snapcraft.io/, https://flatpak.org/ https://flatpak.org/, or https://appimage.org/ https://appimage.org/ because all of these do exactly that. Snap apps are straight linux containers and the others root like chroot jails I believe still. Or even go take a look at Nix/NixOS and how they pull it off in another way. They have hermetic isolation down to a science. Or heck, just look at what Android does, running each app under its own uid/gid, sandboxing 3rd party code, and keeping each app from reading and writing outside their little jails. Can't pollute a user directory or even write to /tmp if your user can't even enumerate it. Hell, even built a whole sandboxing capability-based security model inside of Fuchsia at Google, which I worked on for 5+ years. I've been building OSs for 20+ years, between Fuchsia and Android at Google and mobile/embedded products at Texas Instruments, so I hope I know what I'm talking about.
    - fragmede 2y ago
      Or Qubes, which goes further and features per-app VMs. Snaps was foisted on the community which was then unwelcoming of it, but per-app isolation isn't the worst idea.
    - Brian_K_White 2y ago
      Android is a thoroughly managed appliance, not a general purpose OS. Snaps should not exist. Flatpak and appimage should exist, but should not be used except in extreme cases. You can have bad judgement for 20+ years easily.
      - zbowling 2y ago
        Nah. Your objections are rooted in the very limited definition of what an OS is and what a user application model is that fits it. There is no reason why each process/app can't be sandboxed. In fact, it should be for security (we did it in fuchsia). It's actually the way things work with apps from the app store on MacOS in a lot of ways where you can't escape your jail except through what is explicitly entitled. General purpose just means that it's generally useful for a wide range of applications. Android is that. Hell, you can find Android running small appliance server infrastructure and powering IoT devices. Even in 2024, iOS/iPadOS is general purpose at this point, and they have VERY different application models from legacy app models you find on Windows and Linux. You wouldn't not call NixOS a general-purpose OS, and it's like flatpak for literally every process down to things like bash, grep, and vim. Snaps are fine. Aversion is only from how it was introduced to people in Ubuntu, but conceptionally, is great. cgroups wrapping user processes to box them is not only good for security but also for stability and solving dependency versioning issues. It's brilliant. It's similar to what we did in Fuchsia at Google (we took it to another level because we had no legacy to deal with). And sure, maybe I have bad judgment on some things. I contributed a ton to GNOME in the early 2000s both code and ideas that were horrible in hindsight, but I'm not still stuck in an outmoded mental model for thinking about my user environment.
NekkoDroid 2y ago
/tmp/ is the ram-backed version for small files, while /var/tmp/ is the disk-backed version for large files and I also think both should be clean at bootup. In my personally opinion the reaping period is way too long, especially for /tmp/ as only few people really have an actual uptime that long but it does make somewhat sense for /var/tmp/ as it currently is "persistent".
- deleted 2y ago
  [deleted]
- hda111 2y ago
  Depends on the distro. In Debian /tmp is backed by the disk.
  - bayindirh 2y ago
    > In Debian /tmp is backed by the disk. In Debian /tmp was backed by the disk. Trixie will come with RAM based /tmp. Update is pushed.
  - jkaplowitz 2y ago
    The article we’re discussing is exactly about Debian changing that for the next release. (The only thing that will be changing in this respect is the default, and possibly the configuration at the moment of upgrade to the next release. Debian has long allowed users to configure both RAM-backed and disk-backed /tmp, and both will remain possible.)
- Terr_ 2y ago
  > I also think both should be clean at bootup. I'm OK with a RAM-backed /tmp getting cleaned every boot simply because that's part of the technical tradeoff, however "on boot" is a bad trigger because its behavior is unreliable and can easily backfire and harm a user. A classic example would be if the power is interrupted and the computer restarts. Unless the user is present and savvy enough to block it somehow, all of their short-term "throwaway" project/data just got deleted before they actually finished with it. In other words, the difference to users between "I won't need this after tomorrow" versus "I won't need this by next boot" can be very important.
throw0101c 2y ago
> is tech debt Or it's useful system behaviour. To-MAY-to, to-MAH-to. > […] should exist under a proper /var/{cache,lib} directory. Are these directories available to regular users like the tmp dirs are?
- Smar 2y ago
  /home/.cache/ is for regular users.
  - thayne 2y ago
    System users often don't have a real home directory, but need somewhere to write files too.
    - karmarepellent 2y ago
      If feel like this is the moment where these discussions about old filesystem layouts start to go in circles. Yes, system users tend to not have a home directory. But you are fully able to create one for a new system user if this is what you want to do. You are also able to create all kinds of temporary directories and read-only filesystems for a process (e.g. using systemd) if this is what you want do to. Yes there is a lot of fragmentation and no real standard, which is a little disappointing, but you sure have options to work with. And these options do not have to involve any legacy-ish filesystem components like /var/tmp that nobody knows the purpose of.
      - thayne 2y ago
        > filesystem components like /var/tmp that nobody knows the purpose of The purpose of /var/tmp is temporary files that should survive a reboot. A potential example where that would make since is a partial download file. It is only needed temporarily but if a reboot happens while the download is in progress, you probably don't want to have to start over. Also if /tmp is or might be a tmpfs, it is probably desirable to use /var/tmp for larger temporary files that don't fit in RAM.
  - 2y ago
pjmlp 2y ago
As someone that knows Linux since Slackware 2.0 in 1995, the adaption of XDG has been quite flexible across the Linux/BSD landscape.
belorn 2y ago
They could merge /var/tmp and /var/cache, with the intention to discourage future use of /var/tmp. With users, programs and admins already using /var/tmp as a persistent cache, a name change seems like the best solution.
tremon 2y ago
Actually, no. The XDG specifications are intended for desktop environments, the focus is on end users throughout the specs. System services and their locations are out of scope. The standard for filesystem layout was the Filesystem Hierarchy Standard [0], which predates the XDG by about a decade. Although Debian-before-multiarch was the distribution that most closely adhered to the FHS, it was not a Debian-only document. That being said, all my systems have /var/tmp as just a symlink to /tmp, regardless of what the FHS may have to say about it -- and it's cleaned weekly, not just on reboot. [0] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s15.html https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s15.htm... is the current home, apparently

deleted 2y ago

[deleted]

zbowling 2y ago

Nah. XDG base directory was supposed to solve a ton of things 18 years ago, except none of them are hard-hitting user problems most folks really care about most of the time unless you are really anal about hidden folders in your home directory polluting things up (most people aren't), so it fails with partial support from apathy from some package devs on Linux to implement it. Honestly, we should probably abandon the hope that we will ever get full universal adoption. It stinks even worse with the half-adoption state we are in now, with some apps writing to those directories and other apps not. If it wasn't for arch Linux folks trying to drive apps to adopt it more, I don't think it would be. Hell, default Debian/Ubuntu still doesn't set XDG_* directory ENVs by default (some flavors do), and some apps ignore the prescribed "if not set, use this default" nonsense in the spec and do what they have always done because it doesn't break compatibility for users. Part of the spec stinks, too, like the spit between cache/config/data config where the spec has no written rules specified on when anything is expected to be cleaned up and when or what can or should be backed up by the user. Let's move to containerizing most apps, putting everything in little jails so we don't have to deal with where they want to write to. They can have their own consistent and expected behaviors on their own island. Snapcraft, flatpack, or any of a bunch of other solutions are already available to solve this problem. Don't have to worry about what some app left behind or wrote to your system when it's all contained.

38 2y ago
[flagged]
- zbowling 2y ago
  Guess you have never used https://snapcraft.io/ https://snapcraft.io/, https://flatpak.org/ https://flatpak.org/, or https://appimage.org/ https://appimage.org/ because all of these do exactly that. Snap apps are straight linux containers and the others root like chroot jails I believe still. Or even go take a look at Nix/NixOS and how they pull it off in another way. They have hermetic isolation down to a science. Or heck, just look at what Android does, running each app under its own uid/gid, sandboxing 3rd party code, and keeping each app from reading and writing outside their little jails. Can't pollute a user directory or even write to /tmp if your user can't even enumerate it. Hell, even built a whole sandboxing capability-based security model inside of Fuchsia at Google, which I worked on for 5+ years. I've been building OSs for 20+ years, between Fuchsia and Android at Google and mobile/embedded products at Texas Instruments, so I hope I know what I'm talking about.
  - fragmede 2y ago
    Or Qubes, which goes further and features per-app VMs. Snaps was foisted on the community which was then unwelcoming of it, but per-app isolation isn't the worst idea.
  - Brian_K_White 2y ago
    Android is a thoroughly managed appliance, not a general purpose OS. Snaps should not exist. Flatpak and appimage should exist, but should not be used except in extreme cases. You can have bad judgement for 20+ years easily.
    - zbowling 2y ago
      Nah. Your objections are rooted in the very limited definition of what an OS is and what a user application model is that fits it. There is no reason why each process/app can't be sandboxed. In fact, it should be for security (we did it in fuchsia). It's actually the way things work with apps from the app store on MacOS in a lot of ways where you can't escape your jail except through what is explicitly entitled. General purpose just means that it's generally useful for a wide range of applications. Android is that. Hell, you can find Android running small appliance server infrastructure and powering IoT devices. Even in 2024, iOS/iPadOS is general purpose at this point, and they have VERY different application models from legacy app models you find on Windows and Linux. You wouldn't not call NixOS a general-purpose OS, and it's like flatpak for literally every process down to things like bash, grep, and vim. Snaps are fine. Aversion is only from how it was introduced to people in Ubuntu, but conceptionally, is great. cgroups wrapping user processes to box them is not only good for security but also for stability and solving dependency versioning issues. It's brilliant. It's similar to what we did in Fuchsia at Google (we took it to another level because we had no legacy to deal with). And sure, maybe I have bad judgment on some things. I contributed a ton to GNOME in the early 2000s both code and ideas that were horrible in hindsight, but I'm not still stuck in an outmoded mental model for thinking about my user environment.

NekkoDroid 2y ago

/tmp/ is the ram-backed version for small files, while /var/tmp/ is the disk-backed version for large files and I also think both should be clean at bootup. In my personally opinion the reaping period is way too long, especially for /tmp/ as only few people really have an actual uptime that long but it does make somewhat sense for /var/tmp/ as it currently is "persistent".

deleted 2y ago
[deleted]
hda111 2y ago
Depends on the distro. In Debian /tmp is backed by the disk.
- bayindirh 2y ago
  > In Debian /tmp is backed by the disk. In Debian /tmp was backed by the disk. Trixie will come with RAM based /tmp. Update is pushed.
- jkaplowitz 2y ago
  The article we’re discussing is exactly about Debian changing that for the next release. (The only thing that will be changing in this respect is the default, and possibly the configuration at the moment of upgrade to the next release. Debian has long allowed users to configure both RAM-backed and disk-backed /tmp, and both will remain possible.)
Terr_ 2y ago
> I also think both should be clean at bootup. I'm OK with a RAM-backed /tmp getting cleaned every boot simply because that's part of the technical tradeoff, however "on boot" is a bad trigger because its behavior is unreliable and can easily backfire and harm a user. A classic example would be if the power is interrupted and the computer restarts. Unless the user is present and savvy enough to block it somehow, all of their short-term "throwaway" project/data just got deleted before they actually finished with it. In other words, the difference to users between "I won't need this after tomorrow" versus "I won't need this by next boot" can be very important.

throw0101c 2y ago

> is tech debt Or it's useful system behaviour. To-MAY-to, to-MAH-to. > […] should exist under a proper /var/{cache,lib} directory. Are these directories available to regular users like the tmp dirs are?

Smar 2y ago
/home/.cache/ is for regular users.
- thayne 2y ago
  System users often don't have a real home directory, but need somewhere to write files too.
  - karmarepellent 2y ago
    If feel like this is the moment where these discussions about old filesystem layouts start to go in circles. Yes, system users tend to not have a home directory. But you are fully able to create one for a new system user if this is what you want to do. You are also able to create all kinds of temporary directories and read-only filesystems for a process (e.g. using systemd) if this is what you want do to. Yes there is a lot of fragmentation and no real standard, which is a little disappointing, but you sure have options to work with. And these options do not have to involve any legacy-ish filesystem components like /var/tmp that nobody knows the purpose of.
    - thayne 2y ago
      > filesystem components like /var/tmp that nobody knows the purpose of The purpose of /var/tmp is temporary files that should survive a reboot. A potential example where that would make since is a partial download file. It is only needed temporarily but if a reboot happens while the download is in progress, you probably don't want to have to start over. Also if /tmp is or might be a tmpfs, it is probably desirable to use /var/tmp for larger temporary files that don't fit in RAM.
- 2y ago

pjmlp 2y ago

As someone that knows Linux since Slackware 2.0 in 1995, the adaption of XDG has been quite flexible across the Linux/BSD landscape.

belorn 2y ago

They could merge /var/tmp and /var/cache, with the intention to discourage future use of /var/tmp. With users, programs and admins already using /var/tmp as a persistent cache, a name change seems like the best solution.

tremon 2y ago

Actually, no. The XDG specifications are intended for desktop environments, the focus is on end users throughout the specs. System services and their locations are out of scope. The standard for filesystem layout was the Filesystem Hierarchy Standard [0], which predates the XDG by about a decade. Although Debian-before-multiarch was the distribution that most closely adhered to the FHS, it was not a Debian-only document. That being said, all my systems have /var/tmp as just a symlink to /tmp, regardless of what the FHS may have to say about it -- and it's cleaned weekly, not just on reboot. [0] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s15.html https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s15.htm... is the current home, apparently