Bcachefs "pitches itself as a filesystem that 'doesn't eat your data'," writes the open source/Linux blog It's FOSS. Although it was last October that Bcachefs developer Kent Overstreet was restricted from participating in the Linux 6.13 kernel development cycle (after ending a mailing list post with "Get your head examined. And get the fuck out of here with this shit.") And now with the upcoming Linux kernel 6.17 release, Linus Torvalds has decided to drop Bcachefs support, they report, "owing to growing tensions" with Overstreet: The decision follows a series of disagreements over how fixes and changes for it were submitted during the 6.16 release cycle... Kent filed a pull request to add a new feature called "journal-rewind". It was meant to improve bcachefs repair functionality, but it landed during the release candidate (RC) phase, a time usually reserved for bug fixes, not new features, as Linus pointed out. [Adding "I remain steadfastly convinced that anybody who uses bcachefs is expecting it to be experimental. They had better."] Theodore Ts'o, a long-time kernel developer and maintainer of ext4, also chimed in, saying that Kent's approach risks introducing regressions, especially when changes affect sensitive parts of a filesystem like journaling. He reminded Kent that the rules around the merge window have been a long-standing consensus in the kernel community, and it's Linus's job to enforce them. After some more back and forth, Kent pushed back, arguing that the rules around the merge window aren't absolute and should allow for flexibility, even more so when user data is at stake. He then went ahead and resubmitted the patch, citing instances from XFS and Btrfs where similar fixes made it into the kernel during RCs. Linus merged it into his tree, but ultimately decided to drop Bcachefs entirely in the 6.17 merge window. To which Kent responded by clarifying that he wasn't trying to shut Linus out of Bcachefs' decisions, stressing that he values Linus's input... This of course follows the great Torvalds-Overstreet "filesystem people never learn" throwdown back in April.

Read more of this story at Slashdot.

If Fedora drops 32-bit support, the gaming-focused Bazzite project would be forced to shut down, according to its founder Kyle Gospodnetich. "As much as I'd like this change to happen, it's too soon," said Gospodneitch in a post. "This change would kill off projects like Bazzite entirely right as Fedora is starting to make major headway in the gaming space. Neal Gompa already pointed out basic use cases that would be broken even if someone built the packages Steam itself needs to function." He continued: "It's also causing irreparable damage to Fedora from a PR standpoint. I have been inundated all day with people sharing news articles and being genuinely concerned Steam is gong to stop working on their Fedora/Bazzite machines. I would argue not only should this change be rejected, the proposal should be rescinded to limit further damage to Fedora as a project. Perhaps open a separate one to talk about changing build architecture to build fewer 32-bit packages?" When pushed further, Gospodnetich said: "I'm speaking as it's founder, if this change is actually made as it is written the best option for us is to just go ahead and disband the project."

Read more of this story at Slashdot.

Slashdot reader Mirnotoriety shared this report from the Register: A proof-of-concept program has been released to demonstrate a so-called monitoring "blind spot" in how some Linux antivirus and other endpoint protection tools use the kernel's io_uring interface. That interface allows applications to make IO requests without using traditional system calls [to enhance performance by enabling asynchronous I/O operations between user space and the Linux kernel through shared ring buffers]. That's a problem for security tools that rely on syscall monitoring to detect threats... [which] may miss changes that are instead going through the io_uring queues. To demonstrate this, security shop ARMO built a proof-of-concept named Curing that lives entirely through io_uring. Because it avoids system calls, the program apparently went undetected by tools including Falco, Tetragon, and Microsoft Defender in their default configurations. ARMO claimed this is a "major blind spot" in the Linux security stack... "Not many companies are using it but you don't need to be using it for an attacker to use it as enabled by default in most Linux systems, potentially tens of thousands of servers," ARMO's CEO Shauli Rozen told The Register. "If you're not using io_uring then disable it, but that's not always easy with cloud vendors."

Read more of this story at Slashdot.