GNOME OS Enables Zswap by Default, and Geary Finally Gets a Maintained Fork

GNOME OS Enables Zswap by Default, and Geary Finally Gets a Maintained Fork

Two things landed in GNOME’s orbit this week alongside the GNOME 51 release, and both solve problems that had been irritating people for a while.

Zswap on by default

GNOME OS now enables zswap by default to address out-of-memory problems on machines without much RAM.

Zswap is the middle option between having swap and not having it. Rather than writing a page straight to disk when memory runs short, the kernel compresses it and keeps it in a RAM pool. Compressed pages take less space than the originals, so you effectively get more usable memory, and reading one back is a decompress rather than a disk read.

The tradeoff is CPU time against I/O time, and on modern hardware that trade is lopsided. Decompressing a page costs microseconds. Faulting it in from even a fast SSD costs considerably more, and on spinning storage it is not close.

For GNOME OS specifically this matters because the failure it replaces is ugly. Running out of memory does not produce a slow system, it produces the OOM killer terminating whichever process it judges most expendable, which from the user’s side looks like an application vanishing without explanation.

The implementation detail is a nice one: GNOME OS uses a Rust-based zswap-generator to produce the appropriate systemd configuration, and it respects zswap.enabled=0 on the kernel command line. Automatic configuration that still honours an explicit override is the right way round. Our kernel command line guide covers setting that, and systemd generators are the mechanism producing the units.

# is zswap active on your system
cat /sys/module/zswap/parameters/enabled
grep -r . /sys/kernel/debug/zswap/ 2>/dev/null | head

# compressor and pool limit
cat /sys/module/zswap/parameters/compressor
cat /sys/module/zswap/parameters/max_pool_percent

GNOME OS also now has a documentation site with setup guides, which for a project most people try in a VM is overdue and welcome.

Convey picks up where Geary stalled

Convey has appeared on Flathub as a fork of the Geary mail client, and it arrives with the three things Geary needed:

  • Microsoft 365 support
  • A GTK4 port
  • Assorted fixes and interface work

Geary was for years the answer to “I want a GNOME mail client that is not Evolution,” and it drifted. A GTK3 application in a GTK4 desktop looks wrong and behaves slightly differently, and an email client without modern Microsoft authentication is unusable for a large share of people whose mail is at work.

Forking is often a failure signal in open source. Here it reads more like maintenance transfer: someone wanted the application to keep existing, and the practical route was a fork rather than waiting.

Email clients are also unusually hard to maintain for reasons that have nothing to do with GTK. IMAP is old, widely implemented, and inconsistently implemented. OAuth flows differ per provider and change without much notice. Our self-hosted email guide covers why the server side is worse still.

If you have been keeping Geary alive out of habit, Convey is the version that works with a current desktop.

Background reading

Explainers for the concepts behind this story.