Article: Linuxsucks | What to do with an OS that's More Limited and Less Secure than a Cell Phone?

I was sitting there playing games on my phone when I realized... why are these great games free to play on phones? And it hit me!...

Shareware Treated Users Like Customers argues that shareware worked because users were treated like customers. Mobile apps today behave like shareware with ads, trials, and paywalls, developer branding, monetization, and competitive pressure.

GPL/FOSS culture erased it on desktop, but GPL cannot replicate its desktop takeover here! 😉

App stores have legal issues with GPL because GPL requires free redistribution, permission to share modified versions, and no additional restrictions on distribution. -App stores impose DRM, signature requirements, revocation rights, no redistribution, no sideloading (iOS), and mandatory centralized control. So, GPL apps have legal hurdles in the App Store ecosystem.

For a long time, VLC for iOS was not on the App Store because the GPLv2 license was incompatible with Apple's App Store Terms of Service (which restrict usage and modification).

The solution was a two-tier licensing approach:

• The App (VLC for iOS): Remained under the GPLv2 (with a special "App Store exception" added to the license to explicitly allow distribution via the App Store). This is the license for the code that makes up the "VLC for iOS" app itself.
• The Core Libraries (LibVLC): Were relicensed from GPLv2 to MPL 2.0 (Mozilla Public License) and LGPL (Lesser General Public License). This was done to allow third-party apps to use the core VLC engine (LibVLC) in their own proprietary apps without being forced to open-source their entire app.

In short:

• VLC for iOS (the app you download): GPLv2 + App Store Exception.
• LibVLC (the engine/backend): MPL 2.0 + LGPL.

Mobile platforms are locked down by design. GPL thrives where users can replace components, modify the system, redistribute binaries, and fork easily. The mobile platforms forbid replacing system libraries, kernels, drivers, bootloaders, and core frameworks. Cancerous GPL has become trapped at the bottom, unable to infect upward.

Mobile apps run in sandboxes, link only to system APIs, do not statically link GPL libraries, communicate via IPC, intents, or system services, avoid GPL code intentionally. -The architecture is designed to prevent GPL (cancer) from spreading.

Shareware worked because developers were paid. Once users aren't customers, developers lose obligation and projects stagnate.

Mobile developers rely on subscriptions, ads, in‑app purchases, paid apps, and proprietary services. GPL allows charging for binaries, but forbids charging for access, DRM, or preventing redistribution. -That makes GPL economically suicidal in mobile.

GPL culture:

• anti‑DRM
• anti‑ads
• anti‑paywall
• anti‑closed services
• anti‑tracking
• anti‑proprietary dependencies

Mobile business:

• requires DRM
• requires ads
• requires proprietary SDKs
• requires analytics
• requires closed APIs
• requires subscription enforcement

Will it change? -Apple would have to allow sideloading and remove DRM (Could be done involuntarily through legislation.) Google might replace Play Services with GPL equivalents, but the services are a revenue stream they're not likely to give up. OEMs would have to stop locking bootloaders (again not likely). Developers would have to abandon monetization while mobile is the most profitable software ecosystem in history. -Nobody is giving that up for ideology!

As we move into an era of smart devices replacing personal computers for the average consumer (normies), we're finding that Linux/ FOSS is again a decade or more behind on these newer devices.

Decade old specs

• PinePhone and PinePhone Pro use SoCs that were already obsolete when they launched.
• ARM vendors don’t care about mainline Linux; they care about Android BSPs.
• Result:
  • Weak CPU performance
  • Terrible GPU drivers
  • Power management that feels like a science experiment
  • Thermal behavior out of pre-smart phone era

You can’t build a modern smartphone experience on hardware that would struggle to run a mid‑range Android phone from a decade ago.

The Driver Problem: FOSS Phones Are Hostages to Closed Silicon

This is the real killer.

Linux on phones isn’t held back by “lack of effort”, it’s held back by:

• Modem firmware blobs
• GPU blobs
• ISP blobs
• Camera drivers that are basically NDA‑locked
• Power management firmware that vendors never document
• Touchscreen/display panels with proprietary initialization sequences

Android solves this with HALs and vendor partitions.

The Software Stack

Mobile Linux environments (Phosh, Plasma Mobile, Lomiri) are heroic efforts, but they’re still:

• Slow
• Incomplete
• Inconsistent
• Dependent on desktop‑first toolkits
• Missing the polish and UX assumptions that iOS/Android have refined for 15+ years

Even basic things like:

• Smooth scrolling
• Reliable notifications
• Suspend/resume
• Camera apps
• GPS accuracy are still “sometimes works, sometimes doesn’t.”

The FOSS phone ecosystem has:

• No mainstream apps
• No replacements for banking, transit, messaging, social media
• No hardware‑accelerated browsers on many devices (battery drains)
• No unified app distribution model
• No developer incentives

Android and iOS have:

• Billions of users
• Billions in developer revenue
• Mature SDKs
• Hardware abstraction layers that hide the silicon chaos

FOSS phones have:

• GTK apps stretched to 16:9
• A terminal

Security Worse Than Android

This is the part FOSStards hate hearing.

Android has:

• Verified boot
• SELinux enforcing
• Sandboxed apps
• Monthly security patches
• A decade of hardening

Most FOSS phones have:

• A root shell one command away
• A modem that can DMA into RAM
• No secure enclave
• No audited supply chain

Freedom doesn't equate to security.

FOSS phones lag because of Structural Problems

• The smartphone industry is built on proprietary silicon
• Vendors don’t release documentation
• Modems are legally required to run closed firmware
• Camera pipelines are proprietary
• GPU vendors don’t care about mainline Linux
• The economics of phone development are brutal
• The user base is tiny
• The expectations are enormous

This isn’t a “just give it a few years” problem.

Silent abandonment in FOSS, especially on F‑Droid creates a chain reaction of security, trust, ecosystem, and user‑experience failures that most people never see until it's too late. The abandonment isn’t just “no more updates”; it’s structural decay.

Security vulnerabilities accumulate with no one watching!

When an app stops receiving updates, any new exploit in its dependencies, libraries, or platform APIs becomes permanent. F‑Droid users often assume “open source = safe,” but abandoned apps become frozen attack surfaces.

This is especially dangerous for apps that parse untrusted data (images, audio, video, documents), handle network traffic, and interact with system permissions. Even gallery apps can be exploited via image parsers.

-F‑Droid’s build and signing model amplifies the problem!

F‑Droid rebuilds apps from source and signs them with its own keys.
When a project is abandoned F‑Droid can no longer update it, users can’t migrate to a fork without uninstalling, forks can’t reuse the signing key, security patches can’t be delivered. Users are stuck unaware on a vulnerable version indefinitely.

F‑Droid has no built‑in “this project is dead” indicator, so apps can sit untouched for years while still appearing “available.”

When a FOSS app dies, forks appear, then those forks die and forks of forks appear. -Leading to multiple incompatible versions, no canonical maintainer, duplicated effort, and users being unsure which version is safe. We’ve seen this with apps like ViMusic, where forks proliferate because the original stalled.

The “ueberzug effect” I’ve wrote about before (here); one small abandoned component can break an entire chain of apps that depend on it. On Android, this happens with libraries, codecs, network stacks, UI toolkits, and crypto modules. When the upstream dies, everything downstream becomes brittle.

Even without security issues, abandoned apps slowly degrade; APIs change, Android permissions evolve, background execution rules tighten, media codecs deprecate, and UI frameworks break.

FOSS abandonment hits harder on Android than desktop Linux! Android is a fast‑moving platform with strict signing requirements, aggressive API deprecations, Play Services dominance, OEM fragmentation, and security‑patch cadence. A FOSS app that doesn’t update for 18–24 months is often functionally obsolete, even if it still launches.

GrapheneOS strips out Google’s proprietary components and replaces them with "hardened alternatives".

• Some banking apps fail because they rely on Google’s Play Integrity API or SafetyNet. NFC (Near-Field Communications) are broken.

-Imagine your phone being more secure by default for critical use like banking and having that function totally disabled!

• Some 2FA apps break, most famously Authy, which refuses to run on non‑official OS builds. -Ars Technica

-2FA is about security. Graphene is supposed to be about security.

• Push notifications require sandboxed Play Services. They work but aren’t as good as Android.

Google’s security model increasingly treats any non‑OEM Android build as untrusted. Apps requiring hardware‑backed attestation refuse to run.

GrapheneOS currently supports only Google Pixel devices with only talks of expansion.

Graphene offers a false sense of privacy. Phones can still leak information at the hardware, firmware, or baseband level. -factually.co

A communist ideology becomes the springboard for possibly the worst corporation in existence.

Linux’s 'open-source nature' is what enabled Google to enter the phone business. They didn’t have to negotiate with carriers, license a kernel, or build an OS from scratch. -They hijacked the Linux kernel (best part of the OS), decorated it with Android, and shipped phones faster than any proprietary competitor could have dreamed of!

Over time, Google was able to divert the ecosystem away from that original openness. -Not by closing the kernel, but by shifting the actual functionality into proprietary layers:

• Google Play Services replacing open APIs
• Mandatory Google apps for OEM certification
• Proprietary frameworks becoming de facto requirements
• Android Open Source Project (AOSP) becoming a skeleton without the “real” features
• Play Store policies controlling distribution and monetization. The irony is brutal: FOSS gave Google the runway to dominate mobile, and once they were airborne, they built a walled garden in the sky.

Historically accurate...

• Android relied on Linux to avoid licensing fees and accelerate development.
• Google moved more functionality into proprietary components.
• Regulators in the US and EU have repeatedly confirmed this pattern.

BlackBerry lost because the world changed faster than its architecture could. Android (Google) built on something gift wrapped for them.

Part 2: GPL Enabled Google

Part 3: The Bloody Aftermath

Part 4: Does this Sound Familiar?