great point. After install I can certainly try them both. What tool/app would you recommend to see how hard the CPU strain is for swap file v. zram? And how would I know which is placing the overhead?
I suppose you would need to force some amount of memory use so that swapping is happening and observe the CPU load.
Various tools can be leveraged for these tasks - htop is a common utility for live resource use reporting, etc.
A number of them are listed here, as well as links to dedicated benchmarking tools;
1 Like
CPU load on this weak Atom CPU is exactly the reason why I use normal swap (not zswap)—it would probably bring this lil thingy here to a screeching halt… 
The good thing about Linux is the kernel uses much of the “free” RAM as a disc cache automatically, so wear & tear on SSDs is reduced anyway. Therefore the 8 GB can be a good decision. And don’t forget, you can always influence the kernel’s scheduler behaviour to use more or less “swappiness” (vm.swappiness, 60 per default). This will influence the ratio between anon_prio and file_prio memory pages. A lower value means less swapping (but more writing out to files). Good read on swappiness here:
Btw, nowadays modern Linux kernels handle SSD TRIMming pretty well themselves, usually no need for manual intervention anymore (like we had to a few years ago).
On Arch you still need to enable the fstrim.timer if you want it periodically trimmed.
And continuous trim ( DISCARD ) should still probably be avoided as a rule;
1 Like
Agree htop is always a good tool. Note that for CPU, memory and swap the values are color-coded, so you can actually see what’s going on:
In this example, only 5.11G of my RAM are “used” (green), but the blue (buffers) and brown (cache) bars go almost up to the 15.5G mark. Efficient use of RAM for file & disk caching! Swap is almost unused here. I only have that much since I use hibernation on this laptop (needs swap = total RAM + a bit).
F1 brings up the help that explains the color coding:
Just in case you didn’t already know. 
@cscs: As always, thanks for your pointers to the docs!
1 Like
I’m still using this ThinkCentre and like a couple others have posted I don’t do much other than web browsing email.I have a swapfile and it usually never goes over a few hundred MB’s and I have never noticed it slow down.
1 Like
the memory bar colors were revealing. this was nice. If swap was barely used what do you attribute to this efficiency? It’s a great thing.
[I have an M93 and I have to rewrite my config so fastfetch shows ‘thinkcentre’ for host. would love to see it. ]
Swapfile could be an option too. My use case is a little more than yours with music, video, office software, zoom sometimes but not too over the top.
1 Like
Let’s say Linux (actually UNIX too) does many things right from the start, like using available resources efficiently. Tbh, the Windows NT 4 kernel wasn’t too bad either, but they messed up later and needed to stay compatible with too much old crap.
In Linux, and Arch-based distros, almost everything is configurable, but the other good thing is that both Linux and EOS come with pretty good defaults. (Like, for instance, the EOS install process detects if you’re installing onto an SSD and auto-enables the fstrim.timer if the drive supports TRIM. And much more.)
The efficiency on this system is partly Linux and partly that I’ve not yet installed everything. Using 40 tabs in Firefox, running GIMP, LibreOffice, video editing and other apps that use much memory would eventually lead to using some swap (not too much though) if they were all open and doing something. Linux would still try to find the best balance between memory for the app(s), file buffers and general disk caching, and only resort to using swap if really needed.
Simply put, you could think of swap as a RAM extension if there is not enough real RAM. But since it’s on a disk and has to be written and read, it’s horribly slow compared to real RAM, and thus only used if really really needed.
Nevertheless, since many apps today are carelessly programmed (or just using other software as “building blocks”), or things like Flatpaks or Snap, which can bring massive amounts of dependencies with them, you can exhaust any system pretty quick. That’s one reason I love EOS—“all-in” but as close to “naked” Arch as possible. And you can keep it that way by not being tempted to install everything plus a lot of pomp and glitz, but instead install only the stuff you really want or need. Maybe do some housekeeping once in a while, too, maclean comes to mind.
2 Likes
And yet, Btrfs has changed its default behavior regarding discard. Asynchronous discard (discard=async) is now enabled by default on SSDs, according to Phoronix ( https://www.phoronix.com/news/Btrfs-Async-Discard-Default ). This means that when a Btrfs filesystem is mounted on an SSD, it will automatically use asynchronous discard unless explicitly disabled with the nodiscard mount option.
I believe my project is the only Arch Linux based system that sets the nodiscard option by default for btrfs filesystems.
That’s interesting. Maybe because btrfs is COW? Or just because it’s a possible compromise between continuous TRIM and timed TRIM, plus consumer-class controllers and NAND are getting better? I wonder.
I think the companies that pushed for the change, SUSE and RedHat, know that their customers are running huge server farms with redundant storage arrays, and have plenty of capital to throw at degraded SSDs. 
The slight savings that asynchronous discard “may” provide only applies to commercial server grade SSDs. Consumer grade SSDs and their controllers may not respect the continuous requests for the TRIM command that the filesystem driver issues.
Quite right, we have digressed enough! 
May well be. I think the Fedora guys & gals came up first with that “we’ve had good experiences with consumer-grade hardware…” (push, push!)
Anyway the idea of having a third option ain’t bad, if we have a feasible means of controlling exactly when it happens. Dunno if the drives report enough data for that. Yet.
But we’re digressing
Distros don’t affect how “lightweight” your OS will be after configuring them, because the programs you’re running are going to be the same. The main difference between distros is the package manager.
What’s really going to matter for you is your choice of DE. If you want to be lightweight, some choices are (in order from least to most lightweight):
- Sway if you like tiling,
- LxQT if you don’t,
- Xfce if you don’t like Qt,
- Turning the settings all the way down on KDE.
1 Like
so you are saying: OS does not matter. DE is what matters. And the apps never change which I agree with.
So if I installed uber-light Alpine with Plasma, not only would that be opposite of what you are recommending, I would be undermining my original intentions?
This is interesting. I’m new to old laptop life.
Well OS does matter, but not that much. And is it worth doing a minimal arch or void install to get a minimal install? DEs are heavier than WM for sure and have a lot of ancillary services running.
1 Like
I disagree with this. Some OS’s are heavier than others before you even start to add you own programs. Different init systems are going to handle system resources differently. I think if its based on the same Parent system then this statement becomes more true. However A base OpenSuse install was much bigger than my base EOS install with XFCE and Cinnamon.
1 Like
I gotcha. Plus my WM days are over. I feel good with 8GB and an SSD but not CPU with 1.8. that seems to be the part I can’t wrap my head around. how do I accomodate 1.8ghz?
traditionally off a Ventoy I’ve not even got OpenSuse to launch it is that big. Different inits is an interesting POV and I know people love the speed without systemd (I forgot what the tradeoff is) even though you weren’t going there. My EOS with Cinnamon has a small footprint too. I think the laptop could handle it.
base or EOS with xfce4 or LXQT will do the job. can i have your full specs sir?
also if you are specifying minimal-use do you mean light server ?
I’d like to add if you want to have a working system quickly, use an OS+WM+DE you already know and are comfortable with.
Learning the intrinsics and quirks of an OS, WM or DE you’ve never used can be quite some effort. That’s perfectly okay if you want to learn and experiment, but might not be wise if you just want something that works.
For me, a long-year Mint user, that was the reason I switched some machines to EOS+Cinnamon. I only have to (re-)learn Arch things now, but feel at home in the DE I’ve used for many years.
For low-end, I have used Mint+XFCE in the past, and would now probably use EOS+XFCE.