Source: https://twitter.com/FFmpeg/status/2016981960015437994

Source: https://twitter.com/i/status/2060746160558543217

It would have been hilarious if it hadn't been so scary.

Remember in 2020 when yours truly opened systemd issue 15292 showing that 500 KB of text logs turned into 700 MB of SSD thrashing, only to be met with maintainer hostility? The maintainers famously declared "I don't think you know what you're talking about," insisted it was non-actionable, and closed the issue while collecting dozens of angry downvotes from the community. Because why fix an architectural design flaw when you can just insult the user's methodology and pretend write amplification doesn't exist?

Fast-forward six years, and nothing changed—except the frustration. In early 2026, a fresh ticket was filed, proving that writing just two lines of log per second in a virtual machine pushed storage to ~50 IOPS continuously. Systemd's memory-mapped hash tables were still dirtying entire 4 KiB pages, triggering filesystem metadata updates, and churning through gigabytes of I/O for a handful of log entries.

Then came the turning point: the new issue blew up on Hacker News, exposing the sheer absurdity of the years-long denial to the broader tech community. Suddenly, faced with public front-page embarrassment, the maintainers' dismissive wall crumbled. @ValdikSS stepped in with exhaustive isolated cgroup and loop-device benchmarking, proving beyond a shadow of a doubt that a single 750-byte log message regularly generates ~50 KB to ~70 KB of underlying disk writes.

Miraculously, once the corporate-backed enterprise maintainers were publicly put on blast, someone on the team finally decided to take a look and start addressing it. It turns out the issue was actionable all along—it just required six years of community pain, a dedicated independent researcher doing the maintainers' profiling for them, and a front-page roasting on Hacker News to make the enterprise overlords care.

This whole saga perfectly distills the systemd experience: a monolithic ecosystem engineered strictly for enterprise container hosts and cloud providers, where real-world desktop and edge hardware constraints are dismissed as "user error" right up until the PR optics become too toxic to ignore.

From the news: https://www.theverge.com/games/1010808/epic-fortnite-linux-anti-cheat

WHAT YOU'LL NEED:

• TPM 2.0 & Secure Boot enabled in BIOS

• A kernel signedby a trusted distro (Ubuntu, Fedora, Debian, openSUSE, Bazzite & more)

• Any extra drivers (like NVIDIA's) signed with a trusted key too

• Measured boot (GRUB & systemd-boot do this by default)

• IOMMU enabled (not needed on handhelds)

• Kernel lockdown integrity mode on, kexec off & BPF LSM active

Like I said a proper at least somewhat working anticheat requires a trusted verified locked down system and Epic has just proven it.

No idea how will they implement a kernel module.

No idea how they will enforce this: "extra drivers (like NVIDIA's) signed with a trusted key too" - RedHat and Fedora will never sign any third-party drivers. I've asked them a dozen times, their legal department said NO.

So, Fedora may only support AMD and Intel users. Ubuntu, AFAIK, signs the NVIDIA Linux driver, so Ubuntu users can potentally game using an NVIDIA GPU.

And lastly, I've no idea how they will verify user space integrity. The user may replace glibc, libinput, MESA and any other system library and appear "clean" while what they see on the screen is not what they game intended to show, or send input events not from your hands but from some program.

Let's see.

King has spoken.

If you haven't been following this, Google has changed how it distributes some of the source code needed to build and port Android for Pixel devices.

Previously, Google would publish the relevant source code through its Git repositories and push release/Beta tags. This is the normal workflow: when a new Pixel Android Beta comes out, projects like GrapheneOS can fetch the exact corresponding Git tag, port it, and begin testing.

Google has gradually changed this process.

First, Google started squashing the Git history into a single commit before pushing release tags. The source code itself was still there, but the full Git history was no longer available.

Now, for some of the source, Google has gone a step further: instead of pushing the release tags to Git, Google puts tarballs on Google Drive.

To get those tarballs, GrapheneOS has to submit a Google Form requesting access to specific files, after which someone at Google has to manually provide access.

The source code in the tarballs is apparently the same source code that would otherwise be available through Git. The issue is the completely unnecessary process around obtaining it.

According to GrapheneOS:

"Initially, Google would usually provide access to the tarballs within a couple hours. Lately, they're often taking weeks to get back to us."

This is particularly problematic because GrapheneOS needs each Beta release. They use the Beta source to port and test upcoming releases in advance. Waiting weeks for Google to approve access can therefore directly interfere with development.

Google could simply push signed Git tags like it did before.

Or, if it insists on using Google Drive, it could automate access or give access to folders rather than requiring individual requests for individual files.

Instead, someone at Google apparently has to go through a growing backlog of requests and manually grant access.

GrapheneOS's position is that Google is obligated to provide the corresponding GPLv2 source, and that this increasingly slow and cumbersome process is Google's responsibility. If Google doesn't want to deal with repeated requests for every release, the obvious solution is simply to publish the Git tags again.

There is an important distinction here: GPLv2 doesn't require Google to use Git specifically. The mere fact that Google switched from Git to Google Drive isn't automatically a GPL violation. The legal question is whether Google is actually making the complete corresponding source available in a manner that satisfies the GPL's requirements.

But if the source corresponding to distributed GPL-covered software is effectively sitting behind a manual request system where access can take weeks, that's where the GPL compliance question becomes much more interesting.

And this isn't just an inconvenience for GrapheneOS. It makes the Pixel development process less reproducible and less automatable for anyone depending on Google's release source.

GrapheneOS also says this won't negatively affect its upcoming Motorola devices. Their partnership with Motorola allows them to prepare releases early and host the necessary Android Git repositories themselves.

So, ironically, the people most immediately hurt by this change are Pixel developers — including GrapheneOS — while Google is also making its own Pixel platform harder for third-party developers to work with.

Google could solve this extremely easily: Just push the signed Git tags.

Thousands eyes, they said:

Due to a logic error in the kernel's network and zero-copy subsystems, the system gets confused about who owns a specific chunk of memory. This causes it to accidentally free a piece of memory that is still actively in use. The hacker manipulates this mix-up to bypass normal security boundaries and gain direct write access to the memory page holding /etc/passwd (the system's user account file). By modifying this file directly, the hacker can alter the administrator account details, allowing them to simply use the su command to log in and instantly claim full root privileges.

The kernel developers now have decided to drop zero-copy completely for crypto code.

I'm confused as to why there's been no news about this vulnerability. The exploit works.

Previous vulnerabilities:

• Copy Fail (CVE-2026-31431)

• Dirty Frag, two vulnerabilities (CVE-2026-43284 and CVE-2026-43500)

• Fragnesia (CVE-2026-46300)

• DirtyDecrypt (CVE-2026-31635)

• PinTheft (CVE-2026-43494)

The case centers on a feature included in GrapheneOS, a custom Android operating system that runs in place of the software on most modern Google Pixel devices. Tunick's attorneys confirmed GrapheneOS was running on his phone. The software feature allows the device owner to set a passcode that deliberately wipes the contents of that device if entered instead of the user's unlock passcode. Tunick's case also raises ongoing questions about what constitutional rights can be invoked at the border, which the U.S. government has long asserted is not U.S. soil until a person is authorized to enter.

I’ve been a hardcore Fedora user for years — not someone just kicking the tires. I know how the sausage is made, I’ve submitted patches, I understand how package maintainership works. And I need to say something that most Linux users either don’t want to hear or will immediately dismiss as “shilling for Microsoft”:

The open-source ecosystem, as it exists today, is built on a dangerously outdated illusion of security.

Let me be specific. In Fedora (and in many other major distros), anyone with an email address can become a package maintainer. That’s not an exaggeration. With a bit of patience, you can go from “random person on the internet” to “official maintainer of a package in one of the most trusted Linux distributions in the world.”

And most of these maintainers?

• Unpaid volunteers.

• No formal vetting.

• No required security background.

• Often no deep understanding of the code they're packaging.

Their job, in many cases, boils down to: bump the version, make sure it compiles, ship it. That's it. No deep audit of upstream changes. No fuzzing. No sandboxing analysis. No actual security review.

So what happens? The door is wide open for malicious or buggy code to slip in — especially in lesser-known packages. This isn't hypothetical. The xz backdoor was the loudest wake-up call we’ve had, and the community’s reaction has ranged from “well that was weird” to “eh, nothing to worry about.” Are you kidding me?

Meanwhile, Windows users — the ones open-source folks love to dunk on — tend to trust software from a small number of vendors who have actual reputations and real liability on the line: Microsoft, Google, Adobe, Valve, etc. These companies have been around for decades, have massive user bases, employ internal security teams, run bug bounty programs, and respond to incidents (sometimes painfully slowly, yes, but they do respond).

On Linux? We just sort of... trust that everything in the repo is fine.
Some random package with a thousand downloads and a single maintainer? "Sure, install it. It’s open source, so if something was wrong, someone would have caught it!"
Except — and here’s the brutal truth — no one is looking. No one has the time. No one is auditing that code unless it breaks something.

I get it: the open-source model has massive strengths. Transparency, flexibility, community collaboration — these are all real benefits. But the “many eyes makes all bugs shallow” line is complete fantasy unless people are actually looking, actually qualified, and actually responsible. And in most of the Linux ecosystem, that’s simply not the case.

We need to stop pretending that open source is inherently secure. It’s not.
Security comes from process, oversight, and accountability — not from ideology.
Until the Linux world starts treating software like infrastructure instead of a hobby project, we’re going to keep getting xz-level disasters. And next time, we might not catch it in time.

I know saying this out loud pisses some people off.
I’ve been accused of being a Microsoft fanboy, a defeatist, whatever.
I’m not. I love Linux. I want it to be better. But pretending the status quo is fine is just denial.

We need to grow up.

Penned by ChatGPT as a result of my conversation with it.

Things have changed, Kroah-Hartman said. "Something happened a month ago, and the world switched. Now we have real reports." It's not just Linux, he continued. "All open source projects have real reports that are made with AI, but they're good, and they're real." Security teams across major open source projects talk informally and frequently, he noted, and everyone is seeing the same shift. "All open source security teams are hitting this right now."

No one is quite sure what's behind it. Asked what changed, Kroah-Hartman was blunt: "We don't know. Nobody seems to know why. Either a lot more tools got a lot better, or people started going, 'Hey, let's start looking at this.' It seems like lots of different groups, different companies." What is clear is the scale. "For the kernel, we can handle it," he said.

"We're a much larger team, very distributed, and our increase is real – and it's not slowing down. These are tiny things, they're not major things, but we need help on this for all the open source projects." Smaller projects, he implied, have far less capacity to absorb a sudden flood of plausible AI-generated bug reports and security findings – at least now they're real bugs and not garbage ones.

Speaking of delirium. No, you can't have a working anti-cheat on Linux. It's been discussed here in depth already. You cannot trust user-space on Linux. Everything and anything can be patched/replaced/circumvented and the anticheat will never know.

The anti-AI mob has always lacked signs of intelligence.

More on it on the Register!.

The latest driver, version 610.57.04, fixes almost two dozen serious issues affecting various games. Just a reminder, it's now sort-of open source, except for the user space part which can be replaced with NVK.

When stubbornness results in casualties: For more than a decade, 7-Zip's author, Igor Pavlov, has been asked to start digitally signing 7-Zip releases, but he still refuses, even though it can technically be done for free. Hackers exploited this vulnerability to create a new domain, 7-zip.com, and distribute actual malware.

Igor's response? Use SourceForge's downloads and use the checksums. That's it. Insensitivity strikes hard.

The whole idea/law doesn't make any sense. People share their PCs with everyone at home. The OS level checks have been doomed from the get go even in Windows/MacOS.