[HN Gopher] Debian's /tmpest in a teapot
___________________________________________________________________
Debian's /tmpest in a teapot
Author : jwilk
Score : 80 points
Date : 2024-06-04 20:05 UTC (2 hours ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| candiddevmike wrote:
| /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-...)
| was supposed to solve all of this...
| zbowling wrote:
| 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 wrote:
| > Let's move to containerizing most apps
|
| I was sort of with you until this, when I realized you have
| no idea what you are talking about.
| zbowling wrote:
| Guess you have never used https://snapcraft.io/,
| https://flatpak.org/, or 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 wrote:
| 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.
| cwillu wrote:
| Yeah, I had upvoted the comment, and retracted the upvote
| when I got to the last sentence. Nobody who has anything
| kind to say about snaps has any business anywhere near my
| desktop.
| NekkoDroid wrote:
| /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".
| shadowgovt wrote:
| While I generally appreciate Debian's careful approach (it is my
| go-to distro if I want things to be predictable with minimal
| upgrade frequency), it always blows my mind to watch open-source
| communities bury topics like this in committee for twelve years
| while commercial OS's just tend to go "It's better for the end
| user. Here's some money. Make it work. If it breaks some key
| software, make _it_ work. "
| codetrotter wrote:
| In fairness it did say:
|
| > Red Hat Enterprise Linux (RHEL) and its clones, as well as
| SUSE Linux Enterprise Server (SLES) and openSUSE Leap, still
| default to /tmp on disk.
|
| So at least some commercial OSes, if you will agree that we
| could refer to the first two of these distros as such, are also
| staying with old decisions for a long time.
|
| And even though RHEL in particular is know for its insane
| dedication to keeping API compatibility with backports of
| software, they still are in a position to change things around
| between major versions. And I believe they do do that quite a
| bit, which is why they also give so long time before EOLing old
| versions so that enterprise has plenty of time to adapt to the
| changes with major version upgrades.
| pantalaimon wrote:
| But how is it better to have /tmp on tmpfs? Those files are
| hardly performance critical
| shadowgovt wrote:
| Flip the question: most storage these days is some kind of
| solid-state. Why is it better to commit /tmp to a solid-state
| device (decreasing its operational life) when those files
| are, by definition, transient and must not be required for
| future correct program operation?
| pantalaimon wrote:
| Because the alternative is more precious RAM
| neilv wrote:
| In addition to `/tmp`, you can put your `~/.cache` on `tmpfs`.
|
| Laptops have ridiculously large amounts of RAM nowadays. My Linux
| laptop setup barely makes a dent in the RAM, even when running 3
| different Web browsers and other gluttonous desktop programs.
| `tmpfs` is a great use for excess RAM, reducing wear on SSD. (I
| also disable swap.)
|
| I've also done things like build an entire large ecosystem of
| packages in `tmpfs`, when the build server happened to have
| mirrored 10krpms drives, and I didn't want the tons of
| intermediate files to eventually be synced to disk. (Even though,
| with disk, they would also probably hang around in Linux
| filesystem buffers, not reads hitting disk each time.)
| zbowling wrote:
| This would break a bunch of little things in annoying ways.
| Like I have shell script tools that store shell scrollback logs
| in .cache, and I want that past reboot.
| neilv wrote:
| FWIW, I've been doing it for many years, and not noticed any
| problems.
|
| If something is supposed to persist past reboot, I wouldn't
| put it in `.cache`. Though I don't know offhand what the
| official documented behavior of `.cache` is, and I can't
| immediately find that documentation (maybe some open desktop
| cabal thing?).
| elpocko wrote:
| If my ~/.cache was on tmpfs, I would need to download tens of
| gigabytes of stuff every day. I wouldn't be able to work. There
| are lots of huge files stored in there, mostly required by
| Python packages for Stable Diffusion and other ML stuff that
| insists on downloading huge model files and putting them into
| ~/.cache.
|
| Edit: du -hc ~/.cache says it's 25G.
| person4268 wrote:
| You can set HF_HOME to move the folder it downloads those to
| elsewhere (or well, the HF transformers/diffusers stuff at
| least), iirc.
| exe34 wrote:
| how do you hibernate without swap? or do you just sleep?
| pantalaimon wrote:
| Standby is usually enough and much faster anyway
| tjoff wrote:
| No. Thinner laptops often max out at 32 or even (!) 16GB. And
| defaults at incomprehensible 8GB.
| mort96 wrote:
| 8GiB is still very common, and it's not hard to find cheaper
| laptops with 4GiB... I don't think your average person's laptop
| has as ridiculously large amounts of RAM as you seem to think
| Aurornis wrote:
| > I don't think your average person's laptop has as
| ridiculously large amounts of RAM as you seem to think
|
| Your average person isn't running Linux or compiling things.
| The comment was in the context of developer laptops.
| pantalaimon wrote:
| Not every developer always has the biggest and latest
| laptop.
| iforgotpassword wrote:
| I prefer /tmp on disk. Nvme disks are fast enough, wear is not an
| issue nowadays. I occasionally extract large files there. So
| either the tmpfs would be too small or the machine would
| eventually start swapping random things to disk, for which I'd
| have to grow my swap partition first - it's only 1GB.
|
| I mean I could start using /var/tmp or make a directory in $HOME
| and clean that up occasionally, but that would mean I have to
| change old habits. ;) so I guess masking tmp.mount it is.
| JonChesterfield wrote:
| Tmpfs is great. If you're a compiled language person and the
| build dir isn't in a tmpfs yet, give it a try. Faster than nvme
| and less prone to burning out from lots of writes.
|
| Defaulting to /tmp in tmpfs means I can remove a line from my
| post install setup script. That doesn't matter much. But it also
| means less divergence between my system and the default, so there
| should be a reliability improvement from other people stumbling
| over problems with the ramdisk before me. So a win all around,
| happy to see it.
| tombert wrote:
| What's especially fun is using tmpfs as root on NixOS. That way
| your root partition gets cleared out on any reboot, so cleaning
| up your mess is never really more than a reboot away.
|
| I've never thought about mounting a tmpfs folder for compiling
| stuff, but that's actually a pretty good idea.
| Aurornis wrote:
| > I've never thought about mounting a tmpfs folder for
| compiling stuff, but that's actually a pretty good idea.
|
| Using tmpfs (or RAMDISK) for compiling and discovering that
| it's not actually faster is a virtually rite of passage for
| every developer. :)
|
| If you do try it, at least benchmark it. You'll probably
| discover that you spent more time setting it up and copying
| files around to volatile storage than you'd ever gain back
| via minuscule compile time speedups. Compiling is not IO
| bound and your files are already being cached in RAM by the
| OS after the first read.
| tombert wrote:
| It's actually not really about speed in my particular case;
| I mostly just don't want lots of tiny intermediate files
| being written and rewritten on my SSD all the time. I would
| sleep better if I knew that they wouldn't have any negative
| effects on the lifetime of my drive.
|
| I have a tmpfs folder mounted for my downloads folder for
| my browser for similar reasons; not for speed but to reduce
| drive wear and automatic cleanup so that it doesn't pile up
| for forever.
| JonChesterfield wrote:
| It's faster. I don't move the source code around though,
| the intermediate build directory cmake writes binaries into
| is under a tmpfs mount and the install dir is back on disk.
| Currently has 10gb in it with 30m of uptime. The gain would
| be less if I was more willing to trust ccache, or if the
| cmake dependency graph of the project was trustworthy - my
| default build deletes all the files from the last one.
| toast0 wrote:
| > If you do try it, at least benchmark it. You'll probably
| discover that you spent more time setting it up and copying
| files around to volatile storage than you'd ever gain back
| via minuscule compile time speedups. Compiling is not IO
| bound and your files are already being cached in RAM by the
| OS after the first read.
|
| You shouldn't need to copy files to volatile storage, just
| storing the outputs there. Maybe only storing the
| intermediate outputs there. Some build processes just dump
| intermediate outputs all over the place, but a lot of them
| have a directory for those, and it shouldn't take much to
| make that directory be on tmpfs or similar.
| Aurornis wrote:
| > If you're a compiled language person and the build dir isn't
| in a tmpfs yet, give it a try. Faster than nvme
|
| What are you compiling that's actually faster in tmpfs?
|
| A decade ago, people were surprised to discover that going from
| HDDs to SSDs didn't impact compile times very much. The files
| are quickly cached in RAM anyway and the bulk of build time is
| CPU, not I/O.
|
| Going from NVMe to tmpfs feels like an even smaller difference.
| saagarjha wrote:
| Keep in mind that on macOS /tmp is some very cursed link to
| /private/var/tmp and some projects will get very confused by
| this.
| NekkoDroid wrote:
| > But it also means less divergence between my system and the
| default
|
| This is one reason I like Arch. It is almost as vanilla as can
| be (some exceptions may apply) while still being a "build it
| yourself Lego set" (build not in the compile sense).
| tombert wrote:
| Yeah, it's kind of hard to go back once you've embraced the
| "build your own distro" distros.
|
| Arch, Gentoo, and NixOS Minimal are all pretty wonderful in
| that they give you the tools to build whatever system you
| want, without a bunch of extra crap that you'll never use.
| JonChesterfield wrote:
| Wouldn't that be the opposite? I like the base userspace to
| be very boring, where broken things have been stumbled over
| and fixed before I run into them. Everyone having their own
| bespoke set of pieces makes the divergence between what
| you're running and what other people are running greater.
| influx wrote:
| I was really impressed how Boccassi "project managed" this
| change, gathering feedback, addressing feedback where necessary,
| and continued to push the ball forward even under lots of
| objection. Many people would have just given up and the status
| quo would have remained for another couple years.
| dsr_ wrote:
| Excepting a General Resolution or a Policy violation, every
| accredited Debian Developer can do whatever the heck they feel
| like in their own packages.
|
| This can pose problems. Boccasi steamrollered, but relatively
| politely.
| IshKebab wrote:
| Yeah so much naysaying. Especially the people storing important
| files in `/var/tmp`! It's like complaining to the council for
| collecting bins because you like to keep your keys in them.
| Wtf.
|
| Good work pushing through it Boccassi!
| akira2501 wrote:
| It's my bin. I paid a lot of money for it. I can keep my keys
| in it if I want and if it's convenient for me. I don't work
| for the council and I don't care what their agenda is.
|
| Why not just have the installer _ask_ me what configuration I
| prefer? Is there some reason you have to force the change,
| announce a victory, then make me to go mucking with
| "defaults" after the fact?
| chuckadams wrote:
| You can already change the configuration in the installer,
| it's called manual partition setup. The installer doesn't
| need a clicky screen for every setting that may have
| changed over the last 30 years.
| akira2501 wrote:
| So if I do the manual partition setup it's not going to
| run the daemon that automatically deletes files off those
| partitions during runtime for me? It sounded from the
| article like this change is more comprehensive than just
| the partition.
| chuckadams wrote:
| I doubt it'll change the auto-cleanup. It probably is
| configurable with dpkg-reconfigure, or maybe it's just a
| service that needs to be disabled. Post-installation
| configuration is still a thing, and it changes every
| version. That's what versions are for.
| lolc wrote:
| Eh I've lost files because I was working in a ramdisked
| /tmp when the computer lost power. That's what one gets
| when working in a dir called "tmp".
|
| Some people will see their stuff vanish from /var/tmp and
| that will be their day of learning. I guess they won't have
| a backup of files in there either. They were one misfire
| away from loss anyway.
|
| Sure it feels different when the distro just ran over your
| misconceptions. On the other hand, when I encounter a stray
| tmp dir, I assume everything in it can be deleted with
| negligible consequences. So I tend to rm them without even
| a glance inside.
| teruakohatu wrote:
| According got the article Boccassi wanted concrete scenarios
| where things might break, but his justification for making the
| change was "upstream and other dists".
|
| Systemd now essentially control Debian both the OS itself, and
| though Boccassi, the development.
| pm2222 wrote:
| Oh really I thought my arch should only clear /tmp upon startup.
| No wonder I lost files in /tmp The upstream
| defaults for systemd are to mount /tmp as a tmpfs and delete
| files that have not been read or changed after ten days in /tmp
| and 30 days for those stored in /var/tmp.
| ars wrote:
| It's a _lot_ slower to write a large file to a ram based /tmp
| and let it swap out, vs writing that file to disk directly.
|
| If they want to do this they need to modify tmpfs to do a better
| job of shifting data to disk when full, instead of letting swap
| handle it.
| probably_wrong wrote:
| I've had cases where /tmp was full, usually by some runaway
| program that didn't clean up properly. The first indicator is
| usually that Bash auto-complete fails, followed by no one being
| able to SSH into the machine. I suppose mounting /tmp in RAM
| means this will happen more often (as RAM is usually smaller than
| hard drive space), but I don't see this becoming a giant issue.
|
| Now, auto-cleaning /var/tmp... that's going to cause SO MUCH data
| loss across people I know. I see a parallel with keeping files in
| your Desktop: yes, that's not what it's there for and ideally
| you'd store things properly, but you don't go around deleting
| people's documents just because you don't like it!
|
| Time to start sending warning E-Mails, I guess.
| camel-cdr wrote:
| I quickly ran a backup just now, but I would've been one of the
| people slightly effected.
|
| I symlink some of the desktop cache files to /var/tmp, but
| since that never got deleted for me (on Debian and Manjaro) I
| also started linking things like my browser profile there. I
| kind of knew that /var/tmp may not be the correct folder for
| it, but if it works, it works you know.
|
| A bit of background on my setup, for why I even want to create
| such symlinks. My home folder is on an automatically mounted
| USB stick that I transfer between systems (laptop and desktop).
| On shutdown, I rsync the home folder to a local backup folder,
| which gives me a small distributed backup system. Using the
| same home directory between systems with different
| distributions and CPU architectures (I'm using the pinebook pro
| arm laptop) works surprisingly well. But I'd rather not stress
| the USB stick with a bunch of frequently accessed cache files,
| hence the symlink. I end up also symlinking the browser
| profile, because that caused version incompatibilities between
| systems, and I'm ok with having local browser settings/history
| on each device.
| somat wrote:
| I sort of do the same thing, See, I like my homedir on a nfs
| share. (my philosophy is build one really good drive, raid,
| backups etc, then everything can use that, rather than try
| and put a good drive into everything) However there is stuff
| I don't really care about but would like to be fast and don't
| want eating my bandwidth, caches mainly, Now unlike you I
| tried to stay out of tmp so I made a /var/home/ on a fast
| local drive that vaguely mirrors /home and symlink the caches
| into it. That way it makes a good dedicated space for when I
| do want a fast local filesystem.
|
| As an antidote I had a hard time for a few years after I
| stopped using irix, I wanted(or at least my fingers wanted)
| the home directories to be under /usr/people
| aftbit wrote:
| The discussions about swap in the LWN comments are interesting. I
| wasn't aware that at the "swap should be 2x RAM" tip was actually
| a hard requirement at one point (allegedly around Linux 2.4). I
| also wasn't aware that common recommendation was to run with swap
| again.
|
| I have some systems (usually VMs) where RAM is much bigger than
| the root disk. For example, 500+ GiB of RAM and only 100 GiB of
| disk. I have other VMs where the disk is orders of magnitude
| slower than the RAM (e.g. EBS on AWS EC2).
|
| I wonder what I should be doing for swap and vm.swappiness.
| Usually I just run with either no swap or a tiny 4 GiB swap file
| on /.
| lionkor wrote:
| On real machines I run with a super low swappiness of 1-5 or
| so, which effectively means it will always use RAM, basically
| until its too late. That way its difficult to accidentally get
| OOM killed, instead everything just slows way down when swap
| gets involved when RAM is full.
| IshKebab wrote:
| Yeah the trouble is in my experience it slows down to the
| point that the system is unresponsive and you have to reboot
| anyway. I don't think Linux has a good answer to RAM
| management other than "buy lots and lots of RAM" (I already
| have 32GB and it's nowhere near enough).
|
| I wish it worked like Windows - I've never had to reboot due
| to lack of RAM there, and even when the system is
| unresponsive ctrl-alt-del is very reliable.
| Spivak wrote:
| > instead everything just slows way down when swap gets
| involved when RAM is full
|
| I have literally never wanted this and so I'm curious why you
| do. This is why earlyoom is a thing precisely because
| grinding your system to a halt is often worse than killing
| and restarting some processes.
|
| High swappiness so you run slower but never lock up or low
| swappiness with an aggressive oom killer so you don't lock up
| are to me the only sane options. Why do you want your servers
| to be up but thrashing?
| pdw wrote:
| I think they must be referring something in an unstable-series
| kernel. I don't remember anything like that, but I only ever
| used the stable kernels. (Back then, there were separate stable
| (2.2.x, 2.4.x) and unstable (2.3.x, 2.5.x) branches. "Linus
| forced a swap rewrite" sounds like an unstable branch thing.)
|
| I always heard that the "2x RAM" thing came from some
| primordial BSD release.
| NekkoDroid wrote:
| I guess the best I can give you is this:
|
| https://chrisdown.name/2018/01/02/in-defence-of-swap.html
| bdjsiqoocwk wrote:
| Very OT, but I don't know where else to turn to because the
| Reddit community has been of no help.
|
| I used i3 and I absolutely love the way it feels. However I would
| like to configure it in a way that I can press a button and every
| app turns into dark mode. My main apps (Firefox, vscode) have an
| option to say "use system theme" i.e. if the os is dark, theme
| this app dark. Great! The problem is I don't know how to set the
| system theme. And every time I've asked around, I see people
| respond with GTK, QT and what not. I don't have those, I have i3.
|
| Help?
| Arnavion wrote:
| What those people told you is correct, and "I don't have those,
| I have i3" is incorrect. Stop ignoring them.
| bdjsiqoocwk wrote:
| I'm not ignoring. I still don't know how do I enable dark
| mode. If you have the answer, would you kindly help?
| singron wrote:
| i3 is just a window manager. It's not a UI toolkit. It
| doesn't control how apps render UI.
|
| GTK and QT are UI toolkits and do control how apps render
| UI. Your apps will use GTK and QT even if you use i3 to
| manage the windows.
|
| You might be confusing GTK with Gnome and QT with KDE, each
| of which has its own window manager.
| smegsicle wrote:
| so you're saying to get gtk apps to switch to dark mode,
| you'd find the gtk setting for dark mode? and the same
| for qt?
| pantalaimon wrote:
| I don't like it, I tend to use /tmp for large files or
| directories that are just that - temporary.
|
| Now they will either fill up my RAM or require a large swap
| partition (which I usually don't have as it's otherwise wasted
| space).
|
| I really like making /tmp the default destination for downloads,
| so either I need the file and move it elsewhere, but usually it's
| an archive and I just want a file from it. Saves me from an ever
| growing Download folder.
|
| Those files are most dispensable and should not consume precious
| RAM.
|
| Some file systems are even adding specific tmpdir support where
| fsync() is turned into a noop. So they have all the advantages of
| tmpfs without eating into precious RAM/Swap.
| stouset wrote:
| It's a default. You can change it.
| pantalaimon wrote:
| Only on my personal machine. If I'm logged in elsewhere and
| keep my habit of working on large files in /tmp, I will be in
| for a bad surprise
| stouset wrote:
| So... don't keep large files you want to control the
| lifecycle of in directories you don't own? If you care
| about it, stop putting it in /tmp. You were always setting
| yourself up for a bad surprise by doing this, and now
| you're surprised?
| pantalaimon wrote:
| I might download an ISO or check out a repo I want to
| build just once. Or copy some (large) files there because
| I run a script on them and persevere the original in case
| something goes wrong.
|
| I don't care about those files once I'm done with them -
| so far they would only be gone with a reboot, which
| aligns well with my definition of done.
| NekkoDroid wrote:
| There is still /var/tmp if you want a disk backed temporary
| file storage.
| pantalaimon wrote:
| But is this also cleaned up on boot?
|
| The reason I'm doing this in /tmp is that I can just shut
| down the computer and have all those staging files gone.
|
| (Same reason I shut the computer down at the end of the day
| instead of suspend - I want to start with a clean slate the
| next day)
| NekkoDroid wrote:
| It isn't cleaned up at boot IIRC. Unless you leave your
| computer off for 30 days and then come back [1] :).
|
| But it shouldn't be too hard to write a relativly simple
| systemd.unit file that does that at boot. After all the
| main part would be `Requires/After=local-fs.target` and
| something like `ExecStart=bash -c 'rm -rf /var/tmp/*'` I
| think (you'd need to double check what exactly to do if you
| want to do this).
|
| [1] https://github.com/systemd/systemd/issues/33162
| rwmj wrote:
| What's the point of putting /tmp in RAM when a competent disk-
| backed filesystem will do that with the most heavily used files
| anyway?
| kasabali wrote:
| Change for the changes sake, of course.
| pjerem wrote:
| You gain writing cycles that are not going to wear out your SSD
| for files that are going to be erased anyway.
| silisili wrote:
| It's A) much faster, B) causes less wear, and C) automagically
| cleans itself, so to speak.
| pantalaimon wrote:
| What about tmpdir as proposed by bcachefs? [0]
|
| That keeps the file in the page cache until it's evicted, but
| instead of being written to swap it's written to the fs. With
| the swap partition usually being quite small and the fs today
| being all the storage there is on a personal machine.
|
| [0] https://bcachefs.org/Roadmap/#tmpdir_support
| walrus01 wrote:
| Less write wear on SSDs, which are by far the standard now for
| OS/boot disk compared to 10 or 15 years ago.
| dopylitty wrote:
| I believe I speak for all when I say I keep all my most important
| files in /tmp and ~/Downloads
| camel-cdr wrote:
| Is there a easy/non hacky way to configure /tmp to only delete
| files on regular shutdown? I sometimes have the occasional crash,
| and have been bitten by doing some temporary work in /tmp before
| such a crash 2-3 times.
| silisili wrote:
| You could do this pretty easily I think with systemd, it has a
| shutdown target that covers reboots and poweroffs. It would of
| course meaning not having tmp in RAM which is pretty common
| these days.
| hsbauauvhabzb wrote:
| In the article there's some mention of the implications of ram
| and swap - this has caught me before - if you wget an iso to
| /tmp, you may be consuming more ram than expected. And sure,
| that'll get swapped out to disk, but that might be unexpected if
| you're intending on using ram for virtual machines etc, you may
| end up OOM because of this behaviour.
|
| I did this on Fedora, and it left a bad taste in my mouth.
___________________________________________________________________
(page generated 2024-06-04 23:00 UTC)