The Tech Blog

Last week, I happened to go through a slide deck by Gregory Price of Meta about CRAM, presented at the Linux Plumbers Conference. It’s good stuff. With RAM prices rising, I think the idea is worth understanding.

From fundamentals first. Linux already uses kernel modules zram & zswap that compress less-used blocks of memory called pages. A 4 KiB page might shrink to 1 KiB. That’s 3 KiB saved, letting you store more in the same RAM. But when an application needs it again, it triggers a page fault. Linux pauses the app, decompresses the page and restores access. Repeating this costs time.

Now CRAM asks a simple question. What if the CPU could read that page without Linux first unpacking it? The idea is to put compression and decompression inside the memory hardware. Data stays compressed in RAM, but when the CPU requests it, the hardware returns the original bytes automatically. Applications still use normal memory addresses. Linux doesn’t need to swap the page back in just for a read. This could be especially useful for data you read often but rarely change.

Writes are harder. Our 1 KiB compressed page might expand to nearly 4 KiB if you replace its contents with data that won’t compress. CRAM handles this by keeping compressed pages read-only. A write triggers a move back to ordinary RAM before the change is made. So the benefit depends on the workload. His work reported a 452x throughput gain over zram. But the test used DRAM-backed memory to isolate page-fault overhead. It doesn’t prove 452x faster applications on real compressed hardware.

I think the question is whether this can scale. With RAM prices rising, saving physical memory could matter for servers. But it’s no magic bullet. CRAM needs compression-capable hardware, making widespread use a next-generation change rather than a software update. The approach isn’t limited to Linux either. Will hardware makers and OS developers, including Microsoft, see value in adopting it? I really hope they do.

This is one piece of tech that has been around for about 10 years with so much unused potential. Glad to see that changing, with the Apple ecosystem finally putting its weight behind it. Let’s discuss that today.

WiFi Aware allows nearby devices to discover each other, pair securely and create a direct WiFi link without joining an access point. There is no router, DHCP server or internet connection in the middle. Your phone can also stay on its normal WiFi while talking to the device.

Things get interesting on the device setup side. Today, many connected products use Bluetooth only to find the device and pass WiFi credentials. Others create a temporary SoftAP, forcing your phone to switch networks just to configure the product.

With WiFi Aware, the app can discover the device, establish a secure connection and communicate over normal IP networking directly. That same link can be used for configuration, firmware updates, file transfer, camera feeds or higher-rate sensor data. If the product later needs cloud access, you can still pass the home WiFi credentials over this link. It also fits portable instruments, cameras and diagnostic devices that only need a fast local link to your phone, with no router involved.

Android has actually supported WiFi Aware since Android 8.0. The catch is that support depends on the phone’s WiFi chipset, firmware and manufacturer, so you cannot assume every Android phone has it. Apple joining with iOS 26 changes the ecosystem significantly because iPhone 12 and newer now support it.

Last month, Espressif also added WiFi Aware support for selected ESP32 families. It is still early, and support is not universal across ESP32 variants.

I think it will be a great shift. A product that currently carries Bluetooth mainly for commissioning could eventually use one WiFi radio for discovery, secure setup and high-bandwidth local communication. I really hope more chip vendors implement it. I want my phone to stay connected to WiFi and the internet while maintaining a separate direct link to a device.