Phoronix reports on a presentation this week by Meta engineer Gregory Price at the Linux Plumbers Conference in Prague: With today's memory shortages, high prices, and ever increasing memory capacity needs, Meta engineers have been working on Compressed RAM ("CRAM") for Linux. This hardware-offloaded compression still allows cacheline/byte access to compressed memory and in turn a better implementation than the likes of ZRAM and Zswap. Very promising is that there is near-native performance to raw DRAM speeds with CRAM... For end-users that may already be relying on the likes of Zswap or ZRAM, CRAM is offering near-native DRAM speeds. Read-only data is shown to be as fast as the raw DRAM performance. And for memory writes, CRAM is much faster than ZRAM or Zswap or plain swap. "Most of the individual pieces needed to support CRAM are already mainline," the article points out. Tom's Hardware writes that "It uses a private NUMA node (essentially, a ghost CPU) instead of pretending to be a block device, and this lets Linux continue using all of its memory semantics, including migration and ballooning, to manage CRAM." Because CRAM is stored in RAM and treated as RAM, with full cacheline/byte access, it can be accessed in a read-only fashion with little delay; just the cost of hardware-offloaded compression... Even when you enable writes, CRAM is still much faster than ZRAM; 5.4x in the worst tested case of 20% writes. That's a huge drop from the 452x read-only case, but keep your context; a 5.4x speedup is still titanic. The massive performance cliff when writes are involved comes down to the need to page fault and migrate folios back to the original NUMA domain, as you can't write directly to compressed data; you'd corrupt everything... While the obvious target of the work here (given its origin at Meta Platforms) is big Linux servers, ZRAM and Zswap are used all over the Linux ecosystem, even on machines as constrained as the Steam Deck. Many distributions enable one or the other by default. CRAM seems like it could offer a considerable speed-up for some of these machines, so hopefully it finds its way into the kernel once the remaining implementation questions are answered.

Read more of this story at Slashdot.

Reuters reports: Flock plans to let go of about 18% of its employees, people with direct knowledge of the plans said on Thursday, as the maker of AI-powered surveillance cameras and license-plate readers faces mounting opposition to its products from communities and lawmakers.... The company has about 1,500 employees [with job cuts hitting 270 employees]. Flock faces growing scrutiny from regulators, lawmakers, and privacy advocates, despite drawing strong investor interest among venture capitalists. A recent Reuters/Ipsos poll showed Americans are divided on whether Flock cameras are a good idea. Some 38% of the country supports the use of Flock cameras in their community, compared to 47% who oppose their use. A related story... In Texas this week a county commissioner decommissioned all 61 of their Flock surveillance cameras and license plate readers, according to a local news report. County residents "have raised serious questions about who can access this data, what vendors can disclose, improper searches, and records being kept after data expires," the precinct's Chief Public Affairs Officer said.

Read more of this story at Slashdot.