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.

An anonymous reader quotes a report from TorrentFreak: Cloudflare doesn't block pirate sports streaming sites through its 1.1.1.1 DNS resolver in France, only through its CDN. The Paris Judicial Court has now accepted that stance, rejecting [French pay-TV provider] Canal+'s request for penalties of 50,000 euros per site, per day. Interestingly, the court's conclusion relies on statistics provided by Canal+ itself. [...] As a result, Cloudflare will not be penalized under these orders, even though its public DNS resolver is not blocking the sites in question. That is in line with the company's long-standing claim that it doesn't interfere with its DNS. In its recent transparency reports, Cloudflare repeatedly stated that it hasn't blocked any content through 1.1.1.1, despite orders from French and Italian courts. "To date, Cloudflare has not blocked content through the 1.1.1.1 Public DNS Resolver," the company's latest report reads. [...] Blocking through the CDN is another matter. According to the same report, Cloudflare geoblocked 1,238 domains in France in the second half of 2025, all under a single court order. In the first half of the year, it geoblocked 662 domains under seven orders. Cloudflare recently explained its position to the European Commission, in a submission (PDF) to its Counterfeit and Piracy Watch List consultation, stressing that global public DNS resolvers should not be used to block or restrict access. Instead, it highlights its real-time pirate stream blocking program, which allows vetted rightsholders to flag pirate streams that run through its network. These streams are disrupted "within seconds," Cloudflare says, without any DNS or IP address blocking. "For live content, where speed is crucial, Cloudflare has built real-time mitigation mechanisms that allow vetted rightsholder partners to flag infringing streams. When those streams are running through our network, we act on them in seconds," Cloudflare informed the Commission. For now, Cloudflare can continue to block pirate sites through its CDN only, while its 1.1.1.1 DNS resolver remains untouched. Canal+ can still appeal the rulings, so it may not be the last we hear of it.

Read more of this story at Slashdot.