#gentoolinux — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #gentoolinux, aggregated by home.social.
-
#TIL (Today I Learned) about Linux that it's a good idea to specify a maximum size for the directory /tmp in your filesystem table /etc/fstab.
In case you don't know, every file you create in the directory /tmp or move thereto, will be automatically deleted after 10 days or the next time you power off your computer. This is because the content of /tmp isn't written to disk but to RAM. This is achieved by mounting a tmpfs (temporary filesystem) to /tmp, a filesystem that lives in RAM.
Systemd does all that automatically for you, whether you know/like it or not. Systemd also sets the maximum size for /tmp to half your RAM. You probably want to set a lower value by specifying one explicity.
If you don't, you might add, for example, the 1.5 GiB Arch ISO to /tmp, thinking that it'll be outdated next month and should be removed without you having to think about it. But you thereby (unintentionally) remove 1.5 GiB of your RAM for all processes for the next 10 days or until the next reboot.
The directory /tmp should be used for small files only.
Execute this code to restrict /tmp to, for example, 1 GiB.
```
echo 'tmpfs /tmp tmpfs rw,nosuid,nodev,size=1G,mode=1777 0 0' >> /etc/fstab
``` -
#TIL (Today I Learned) about Linux that it's a good idea to specify a maximum size for the directory /tmp in your filesystem table /etc/fstab.
In case you don't know, every file you create in the directory /tmp or move thereto, will be automatically deleted after 10 days or the next time you power off your computer. This is because the content of /tmp isn't written to disk but to RAM. This is achieved by mounting a tmpfs (temporary filesystem) to /tmp, a filesystem that lives in RAM.
Systemd does all that automatically for you unless you tell it not to. Systemd also sets the maximum size for /tmp to half your RAM. You probably want to set a lower value by specifying one explicity.
If you don't, you might, for example, dowload the 1.5 GiB Arch ISO to /tmp rather than to ~/Downloads, thinking that it'll be outdated next month and should be removed without you having to think about it. But you thereby (unintentionally) remove 1.5 GiB of your RAM for all processes for the next 10 days or until the next reboot.
The directory /tmp should be used for small files only.
Execute this code to restrict /tmp to, for example, 1 GiB.
```
echo 'tmpfs /tmp tmpfs rw,nosuid,nodev,size=1G,mode=1777 0 0' >> /etc/fstab
``` -
#TIL (Today I Learned) about Linux that it's a good idea to specify a maximum size for the directory /tmp in your filesystem table /etc/fstab.
In case you don't know, every file you create in the directory /tmp or move thereto, will be automatically deleted after 10 days or the next time you power off your computer. This is because the content of /tmp isn't written to disk but to RAM. This is achieved by mounting a tmpfs (temporary filesystem) to /tmp, a filesystem that lives in RAM.
Systemd does all that automatically for you, whether you know/like it or not. Systemd also sets the maximum size for /tmp to half your RAM. You probably want to set a lower value by specifying one explicity.
If you don't, you might add, for example, the 1.5 GiB Arch ISO to /tmp, thinking that it'll be outdated next month and should be removed without you having to think about it. But you thereby (unintentionally) remove 1.5 GiB of your RAM for all processes for the next 10 days or until the next reboot.
The directory /tmp should be used for small files only.
Execute this code to restrict /tmp to, for example, 1 GiB.
```
echo 'tmpfs /tmp tmpfs rw,nosuid,nodev,size=1G,mode=1777 0 0' >> /etc/fstab
``` -
#TIL (Today I Learned) about Linux that it's a good idea to specify a maximum size for the directory /tmp in your filesystem table /etc/fstab.
In case you don't know, every file you create in the directory /tmp or move thereto, will be automatically deleted after 10 days or the next time you power off your computer. This is because the content of /tmp isn't written to disk but to RAM. This is achieved by mounting a tmpfs (temporary filesystem) to /tmp, a filesystem that lives in RAM.
Systemd does all that automatically for you, whether you know/like it or not. Systemd also sets the maximum size for /tmp to half your RAM. You probably want to set a lower value by specifying one explicity.
If you don't, you might add, for example, the 1.5 GiB Arch ISO to /tmp, thinking that it'll be outdated next month and should be removed without you having to think about it. But you thereby (unintentionally) remove 1.5 GiB of your RAM for all processes for the next 10 days or until the next reboot.
The directory /tmp should be used for small files only.
Execute this code to restrict /tmp to, for example, 1 GiB.
```
echo 'tmpfs /tmp tmpfs rw,nosuid,nodev,size=1G,mode=1777 0 0' >> /etc/fstab
``` -
#TIL (Today I Learned) about Linux that it's a good idea to specify a maximum size for the directory /tmp in your filesystem table /etc/fstab.
In case you don't know, every file you create in the directory /tmp or move thereto, will be automatically deleted after 10 days or the next time you power off your computer. This is because the content of /tmp isn't written to disk but to RAM. This is achieved by mounting a tmpfs (temporary filesystem) to /tmp, a filesystem that lives in RAM.
Systemd does all that automatically for you, whether you know/like it or not. Systemd also sets the maximum size for /tmp to half your RAM. You probably want to set a lower value by specifying one explicity.
If you don't, you might add, for example, the 1.5 GiB Arch ISO to /tmp, thinking that it'll be outdated next month and should be removed without you having to think about it. But you thereby (unintentionally) remove 1.5 GiB of your RAM for all processes for the next 10 days or until the next reboot.
The directory /tmp should be used for small files only.
Execute this code to restrict /tmp to, for example, 1 GiB.
```
echo 'tmpfs /tmp tmpfs rw,nosuid,nodev,size=1G,mode=1777 0 0' >> /etc/fstab
``` -
#TIL (Today I Learned) about Linux that the advice to configure zram for swap is bad advice. You should use zswap instead.
Using zram is likely to be actually counterproductive and can make your computer *slower* than if you didn't try to make optimizations.
The way zram works is that it first fills up the space in RAM until that's full and then it moves to fill the lower-prioritized space on the SSD. But: zram has no way to free the RAM. 😯 Therefore, once zram moves from RAM to disk, all the data you recently used and will thus likely soon need again, are guaranteed to be on the slow SSD, not in the fast RAM.
Zram is good for embedded systems, with very little RAM … systems that possibly don't even have disk storage … where you therefore have to make the most out of the limited RAM you have.
On typical machines though, prefer zswap and omit configuring zram entirely.
If you use GRUB, all you need is this line in GRUB's configuration file:
```
GRUB_CMDLINE_LINUX="zswap.enabled=1 zswap.compressor=lz4"
```Sources:
- https://chrisdown.name/2026/03/24/zswap-vs-zram-when-to-use-what.html
- https://wiki.archlinux.org/title/Zswap -
#TIL (Today I Learned) about Linux that the advice to configure zram for swap is bad advice. You should use zswap instead.
Using zram is likely to be actually counterproductive and can make your computer *slower* than if you didn't try to make optimizations.
The way zram works is that it first fills up the space in RAM until that's full and then it moves to fill the lower-prioritized space on the SSD. But: zram has no way to free the RAM. 😯 Therefore, once zram moves from RAM to disk, all the data you recently used and will thus likely soon need again, are guaranteed to be on the slow SSD, not in the fast RAM.
Zram is good for embedded systems, with very little RAM … systems that possibly don't even have disk storage … where you therefore have to make the most out of the limited RAM you have.
On typical machines though, prefer zswap and omit configuring zram entirely.
If you use GRUB, all you need is this line in GRUB's configuration file:
```
GRUB_CMDLINE_LINUX="zswap.enabled=1 zswap.compressor=lz4"
```Sources:
- https://chrisdown.name/2026/03/24/zswap-vs-zram-when-to-use-what.html
- https://wiki.archlinux.org/title/Zswap -
#TIL (Today I Learned) about Linux that the advice to configure zram for swap is bad advice. You should use zswap instead.
Using zram is likely to be actually counterproductive and can make your computer *slower* than if you didn't try to make optimizations.
The way zram works is that it first fills up the space in RAM until that's full and then it moves to fill the lower-prioritized space on the SSD. But: zram has no way to free the RAM. 😯 Therefore, once zram moves from RAM to disk, all the data you recently used and will thus likely soon need again, are guaranteed to be on the slow SSD, not in the fast RAM.
Zram is good for embedded systems, with very little RAM … systems that possibly don't even have disk storage … where you therefore have to make the most out of the limited RAM you have.
On typical machines though, prefer zswap and omit configuring zram entirely.
If you use GRUB, all you need is this line in GRUB's configuration file:
```
GRUB_CMDLINE_LINUX="zswap.enabled=1 zswap.compressor=lz4"
```Sources:
- https://chrisdown.name/2026/03/24/zswap-vs-zram-when-to-use-what.html
- https://wiki.archlinux.org/title/Zswap -
#TIL (Today I Learned) about Linux that the advice to configure zram for swap is bad advice. You should use zswap instead.
Using zram is likely to be actually counterproductive and can make your computer *slower* than if you didn't try to make optimizations.
The way zram works is that it first fills up the space in RAM until that's full and then it moves to fill the lower-prioritized space on the SSD. But: zram has no way to free the RAM. 😯 Therefore, once zram moves from RAM to disk, all the data you recently used and will thus likely soon need again, are guaranteed to be on the slow SSD, not in the fast RAM.
Zram is good for embedded systems, with very little RAM … systems that possibly don't even have disk storage … where you therefore have to make the most out of the limited RAM you have.
On typical machines though, prefer zswap and omit configuring zram entirely.
If you use GRUB, all you need is this line in GRUB's configuration file:
```
GRUB_CMDLINE_LINUX="zswap.enabled=1 zswap.compressor=lz4"
```Sources:
- https://chrisdown.name/2026/03/24/zswap-vs-zram-when-to-use-what.html
- https://wiki.archlinux.org/title/Zswap -
#TIL (Today I Learned) about Linux that the advice to configure zram for swap is bad advice. You should use zswap instead.
Using zram is likely to be actually counterproductive and can make your computer *slower* than if you didn't try to make optimizations.
The way zram works is that it first fills up the space in RAM until that's full and then it moves to fill the lower-prioritized space on the SSD. But: zram has no way to free the RAM. 😯 Therefore, once zram moves from RAM to disk, all the data you recently used and will thus likely soon need again, are guaranteed to be on the slow SSD, not in the fast RAM.
Zram is good for embedded systems, with very little RAM … systems that possibly don't even have disk storage … where you therefore have to make the most out of the limited RAM you have.
On typical machines though, prefer zswap and omit configuring zram entirely.
If you use GRUB, all you need is this line in GRUB's configuration file:
```
GRUB_CMDLINE_LINUX="zswap.enabled=1 zswap.compressor=lz4"
```Sources:
- https://chrisdown.name/2026/03/24/zswap-vs-zram-when-to-use-what.html
- https://wiki.archlinux.org/title/Zswap -
The Matrix screensaver is never going to be not sexy, even when running with plain terminal fonts.
(This is of the iMac G5 I'm currently bringing back with Gentoo Linux. Still working to get X running quickly enough...)