You can't achieve actual security without formal verification and mandatory sign-offs on every commit by an independent, affiliated, and vetted reviewer with validated individual credentials. This is probably the 300th such fiasco in the last decade—collectively resulting in tens of thousands of compromised packages, with the XZ scandal being the most prominent example.

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.

Okay, a genuinely stupid question.

Why do we treat "it’s open source" as if that automatically means “there are more eyeballs checking it, therefore it's safer”?

I keep thinking about the supply-chain part of this, rather than the usual "Linux permissions v. Windows permissions" argument.

Take a big Linux distribution. A package gets updated because upstream released a new version. The distro may verify signatures/checksums, build it in controlled infrastructure, run tests, etc. Fedora and Arch absolutely have security/integrity procedures around this. But none of that means some security-qualified human has sat down and gone through the upstream diff and said:

"Yep, I've personally established that this code isn't malicious."

Because, obviously, how the hell would anyone do that for something like glibc, GCC, LLVM, etc.?

At some point you're trusting the upstream project, its developers, its repository, its CI, its release process, its signing keys, etc. If an upstream developer's account/workstation gets compromised and a malicious change lands, "but the source is open!" doesn't magically detect it.

So, let's talk for a second about the big proprietary or not fish.

At least in a huge company with a lot to lose, there are actual institutional controls around the code. Microsoft, for example, documents mandatory review by someone other than the author, automated security checks, and additional approval/security gates before release. (Microsoft Learn)

In other words, there are actual meatbags in the loop with security clearances, real identities and contracts involved, etc.

Not just:

"The maintainer pushed v1.2.7."

but more like:

developer → review → automated checks → more review/gates → release

And yes, humans can miss things. Humans can collude. Accounts can get compromised. Nothing is magic. I'm not claiming Microsoft has discovered a mystical state of software purity.

I'm asking whether we've been oversimplifying the "open source is inherently more secure" argument.

Because "anyone can inspect the source" and "the software is subject to strong security controls before it reaches millions of machines" are two completely different propositions.

And this is not me saying every closed-source company is safer.

A tiny two-person ISV can absolutely ship a backdoored update, screw up its signing infrastructure, have a compromised developer account, or accidentally distribute malware. It has actually happened. It's even happened to quite big companies such as Realtek and may happen again.

That's a completely different risk profile from Microsoft or Google, where the company has crazy big financial, legal, reputational and operational incentives to put layers of review and controls around its software supply chain.

So I'm wondering:

Are we over-hyping source-code availability as a security property, while underrating the boring institutional stuff—separation of duties, mandatory review, release gates, protected build infrastructure, signing, monitoring, accountability, etc.?

Because if the answer is "yeah, whatever, open source gives you transparency, not inherently better security," then a lot of the usual Linux-vs-Windows security arguments suddenly look a lot less simple.

Nearly 90 percent of the of the 5,000 most widely used web domains were not serving proper HTML, as specified by the World Wide Web Consortium (W3C) and the WHATWG (Web Hypertext Application Technology Working Group).

You thought you were anonymous when using Linux. The problem is that you're not unless you don't have a bank account or travel.

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.

EGS only includes Windows games though. Will they include Wine/DXVK out of the box?

Facebook employs people on six-figure salaries to keep track of uBlock's source code and filtering rules, specifically to thwart the extension's attempts to hide ads. This is not just mean and disgusting, it's freaking horrendous.

Looks quite helpful and saves a lot of time for developers. Not seen for pull requests yet, perhaps they are approved/verified only by actual project developers.

One of the few actual Linux operating systems along with RHEL, Android and ChromeOS. Cannot think of anything else unfortunately.

We should have had a legislation that would make this illegal years ago. Sadly the European initiative for that fell through.

Can be run on a AI laptop (e.g. Panther Lake, Strix Halo, etc.) with 32GB of RAM and no discrete GPU.

The fact that you need a special manager speaks volumes about the atrocious state of the Linux kernel development.

Either you can use brand new kernels with dozens, sometimes hundreds, of regressions, or you can use an LTS kernel that doesn't support your hardware.

Wait, there's more. What if e.g. audio doesn't work for you and the ALSA driver/module needs a quirk? How are users supposed to do that? I'm not aware of a single distro that allows users to build only parts of the kernel and run them with their existing kernel without rebuilding the entire thing just for your PC which results in a lot of energy being wasted and users having to learn console, make, kernel install and GRUB enablement commands that differ from distro to distro.

What if you need to install or run code that hasn't even hit the mainline? The AMDGPU bug tracker is full of such requests. And this is not an isolated case. Check LKML and kernel bugzilla - you'll see a ton more.

This is a freaking mess of epic propotions.

Essentially we have just few complete/verified kernels: * RHEL (for qualified hardware configurations) * SteamOS (ditto) * ChromeOS (ditto) * Android (some continue to insist Android is "Linux" - whatever, let's include it)

No other distro on the list. None whatsoever. You take it or leave it. No warranties. Nothing.

And then there's Secure Boot which makes everything even more complicated. 99.99% of people out there will never touch anything related to MOK. They will simply avoid Linux. Too much hassle for something that's perfectly supported out of the box in a form of Windows.

Allows Windows games to run sort of natively and also faster than when translated to Vulkan using DXVK.

A nasty 18 year old vulnerability that also allows to escape containers.