Posted by tapanjk 2 days ago
I find 2006 an interesting horizon. It was then that the average home computer massively jumped in processing power compared to the software running on it. For the vast majority of users the computer spent more idle time waiting for input than users waited for output. Of course for some users there's never enough power but for most all of their tasks were effectively instant. Even heavyweight (for the time) stacks like Java ran incredibly well. He'll even Emacs could run well!
Then the curve seemed to invert. Hardware kept getting more capable with even faster CPUs, more cores (on common consumer machines, and more RAM. As the article points out a "lightweight" Linux DE with native apps really flies on such hardware.
But more development seemed to move to the web. More JavaScript required more powerful JS engines and those are up more and more memory. More shit loaded into the DOM means more and more objects on the heap with more pointer chasing.
Modern stacks are really only fast because modern computers brute force their way through them. A simple CRUD type task that fly as a VB or Delphi (neither stack performance kings) app on Windows 2000 now requires a 2GHz dual core CPU with 4GB of RAM as a baseline thanks to it now being a web app.
Using a twenty old machine with native applications and the CLI feels to me like a super computer compared to the computers I first used (Apple IIs). A Core 2 Duo is a stupidly powerful CPU for most tasks. If you can get by with a command line workflow even a Core 2 Duo is crazy fast.
/soapbox
The big difference is zswap is dynamically managed by the kernel and zswap sends out compressed pages to swap.
The article says they want to avoid swap hitting disk, so that seems counterproductive.
Zswap will still compress pages in ram. It only evicts to the disk when the in memory swap pool is filled. The difference being that the pages swapped to disk remain compressed on their way there.
When using zram, there is no "evicted to swap"; zram is the swap. Even if you activated zram and disk-backed swap, I'm pretty sure they just get used in parallel, not through some sort of fallback.
It was my understanding that zswap does decompress pages before writing them to disk. Annoyingly, this doesn't seem to be spelled out either way in https://www.kernel.org/doc/html/latest/admin-guide/mm/zswap.... ; https://wiki.archlinux.org/title/Zswap does say "Once the pool is full or the RAM is exhausted, the least recently used (LRU) page is decompressed and written to disk, as if it had not been intercepted." but doesn't cite that claim.
EDIT: I think my belief is backed by https://elixir.bootlin.com/linux/v7.1.2/source/mm/zswap.c#L9... -
> We are basically resuming the same swap writeback path that was intercepted with the zswap_store() in the first place. After the folio has been decompressed into the swap cache, the compressed version stored by zswap can be freed.
> Even if you activated zram and disk-backed swap, I'm pretty sure they just get used in parallel, not through some sort of fallback.
You can tweak priorities such that zram ends up being the preferred location for swaps.
However, since it looks like just another block device, what happens is it simply gets filled up with the first swap entries and those in turn aren't written out to the disk device.
zswap works better in that way because it'll keep hotter pages in memory and sends LRU pages to the swap device. That's really the biggest reason to use zswap over zram if you are getting into a situation where you overfill your ram.
zram works best if it's the only device with the expectation that you'll OOME when it fills up.
This paragraph especially feels LLM generated. It's nonsense (a fast disk makes disk cache more effective), with a "not even wrong" explanation (speed of RAM is unrelated to speed of disk). It's the kind of error you often see from LLMs, where you have the right words but no solid world model behind them. Of course, I can't actually prove it's LLM writing, and if it is then it appears to be edited by a human, but I don't recall ever seeing this kind of error from a known human writer.
or better yet, install NetBSD. That system will run on anything that old :)
That is not true. They are slow, because ALL software got better and more advanced and that is not only the operating system. It always makes me mad when people say that macOS is so optimized you can do more than on windows.
No. Old hardware not having a hardware decoder for modern youtube videos won't play them.
Modern webpages full of interactive realtime features won't fit in the RAM or will be bottlecked by a cpu. Yes, the modern linux will run, but are you going to do anything more than opening a notepad or old software? No. You are not going to use modern web apps or software on it.
Is it okay? Yes. Optimizing for old hardware is EXPENSIVE. Just move on.