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.

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.

[ Removed by Reddit on account of violating the content policy. ]

Derived 5G Band Support

The filing explicitly covers the standard frequency allocations managed by China's MIIT. The device, codenamed PYB110, should support the following core 5G Sub-6GHz bands (NR):

• n28 (703–733 MHz UL / 758–788 MHz DL) — Low-band coverage
• n1 (1710–1785 MHz UL / 2110–2170 MHz DL) — Mid-band FDD
• n3 (1710–1785 MHz UL / 1805–1880 MHz DL) — Mid-band FDD
• n5 / n8 (824–835 MHz / 889–915 MHz) — Low-band FDD
• n41 (2575–2675 MHz) — Mid-band TDD (China Mobile / global 2.5 GHz)
• n78 (3300–3600 MHz) — Primary global C-band TDD
• n79 (4800–4960 MHz) — High mid-band TDD (China Mobile / Japan / specific regional allocations)

Global 5G Coverage Analysis

China & East/Southeast Asia: Near-Native Support

• Covers all primary sub-6GHz bands for China Mobile, China Telecom, China Unicom, and China Broadnet (n1, n3, n28, n41, n78, n79).
• Broad compatibility across South Korea, Japan, and Southeast Asian carriers relying heavily on n1, n28, and n78.

Europe, Middle East & Africa (EMEA): Very Strong (Sub-6GHz)

• Core European 5G deployment relies on n78 (3.5 GHz) for high capacity and n28 (700 MHz) / n1 / n3 for blanket coverage. The filing covers all of these.
• It lacks specific regional band certifications like n77 (3.7–3.9 GHz extended C-band used in some EU nations) or mmWave (n257/n258), though n78 carries the bulk of modern European sub-6 networks.

North America: Partial / Sub-Optimal

• T-Mobile: Good mid-band coverage via n41 (Ultra Capacity) and low-band via n28/n5 overlap, but lacks n71 (600 MHz), which is T-Mobile’s primary rural 5G backbone in the US.
• Verizon & AT&T: Works adequately on shared n78 frequencies, but missing n77 (3.7 GHz C-band and 3.45 GHz DoD), which forms the core of both carriers' mid-band 5G footprint.
• mmWave (n260/n261): Not supported (typical for Chinese domestic market SKUs).

Latin America & Oceania: Strong

• Covers key regional deployments anchored on n28 (low-band) and n78 (main sub-6 capacity).

Key Technical Caveats

These regulatory filings don't guarantee full software provision in baseband firmware for international cellular operators:

1. Carrier Aggregation (CA) & VoNR Profiles: Domestic Chinese firmware builds often omit software IMS profiles, VoNR configs, and carrier-specific ENDC (E-UTRAN New Radio Dual Connectivity) combination tables required by overseas carriers (e.g., US or European tier-1 telcos), even if the underlying RF front-end supports the frequency physically.
2. Missing Extended C-Band (n77): The upper bound listed is 3600 MHz (n78 target). It explicitly stops short of 3700–3980 MHz. Without n77, mid-band 5G performance in North America and select parts of Japan will be significantly compromised.
3. C-Band Filtering Limitations: CMIIT filings only register bands actively used inside China. If the physical RF front-end filtering is physically tuned strictly to 3300–3600 MHz for n78, it will not lock onto n77 networks even if reflashed with global OxygenOS/EU firmware.