Android/Linux Dual Boot

Legacy Devices & Alternative OSes

  • Commenters note active work on dual-booting older devices like the N900, suggesting Maemo Leste as a strong option despite incomplete hardware support.
  • 3G network shutdowns make such devices less usable as phones; someone wonders about a 4G/5G “bridge” that presents a local 2G/3G cell, with a joking reference to Stingray devices.

Linux Phone Experiments (postmarketOS, Sailfish, Waydroid)

  • Several people are testing postmarketOS and Sailfish on modern hardware (Fairphone, Xperia, Redmi).
  • Consensus: usable for tinkering and some daily tasks, but not yet full daily drivers. Common issues: audio, sensors, and especially banking/“app-only” services.
  • Waydroid (Android-in-a-container) works “pretty good” and helps fill app gaps; questions remain about background GPS, sensors, and navigation reliability.
  • Some users value having a standard Linux userland (Nix, Python, git, containers) more than perfect phone features.

AOSP Forks, GrapheneOS, and Security Models

  • Debate over “why not just hard-fork AOSP”:
    • One side: Android’s permission model and sandboxing are far ahead of classic Unix security and should be preserved.
    • Others: if you can’t or don’t rebase on AOSP, Android apps break; truly hard forks are unrealistic.
    • Concern that if Google stopped updating AOSP, OEM/chip-vendor private channels or Chinese forks would dominate; unclear how non‑open SDK/NDK would affect viability.
  • GrapheneOS is cited as an example of a privacy/security-focused AOSP fork:
    • Critics report poor battery life (especially with 5G and GPS tracking apps), an intrusive GPS indicator, and UX too complex for “normal users.”
    • Defenders say it feels like stock Android with better privacy controls and no noticeable battery issues.

postmarketOS vs Android Security

  • One camp calls postmarketOS “antiquated” for phones: classic Unix permissions allow mic snooping, ransomware, and credential theft if apps are compromised.
  • Others counter that:
    • Linux increasingly uses sandboxing (Flatpak, etc.) and distro trust; dangerous permissions can be constrained.
    • Not all use cases require Android’s tight model; many users value root/admin control and reject “Android‑bis.”
  • Follow‑ups stress that all software should be treated as untrusted (citing the XZ backdoor) and that defaults, not optional hardening, matter for most users.

Terminology & Control: “Sideloading” vs Installing

  • Long subthread on language:
    • Some argue “sideloading” is a PR term to stigmatize installing apps outside Play Store; they prefer just “installing,” or phrases like “installing from outside the store.”
    • Others say the distinction is useful: installing via the main, monitored channel vs arbitrary APKs from the web is a real risk difference for typical users.
  • Comparisons to macOS, Linux package repos, and game consoles:
    • On desktop Linux, nobody calls manual .deb/AppImage installs “sideloading,” but the same conceptual distinction (official repo vs third-party) exists.
    • Some see Android and iOS converging on console-like walled gardens; others argue it’s “industry standard” and still more open than consoles/iOS.
  • There’s disagreement over whether Play Store monitoring meaningfully reduces risk, with counterexamples pointing to Play malware and F-Droid’s better record.

Hardware Openness, Bootloaders & Firmware Layers

  • Concern that unlockable bootloaders are getting rarer; advice is to buy devices officially supporting unlock (LineageOS device list, recent Pixels, some Motorolas).
  • Xperia devices are praised for upstream kernel contributions, bootloader unlocks, headphone jacks, and microSD—even as some report physical quality issues.
  • Technical discussion on why phones lack a PC-like “BIOS experience”:
    • Many modern phones (especially Qualcomm-based) do use UEFI under the hood, but there is no ACPI-like standard layer.
    • On x86, decades of legacy BIOS/UEFI interfaces (INT 10h, 13h, 16h) make minimal OS bring-up trivial and portable.
    • On ARM, each board relies on a specific devicetree and custom drivers; that fragmentation makes generic OS support and projects like postmarketOS much harder.

Alternative Uses & Networking Freedom

  • Some run postmarketOS phones as pocket Linux PCs with external keyboards and power banks; ARM and small screens limit but don’t prevent real development work.
  • A few envision phones as nodes in mesh networks and resilient P2P systems (Freifunk-style), independent of big tech clouds.
    • SDR + protocols like Reticulum/Yggdrasil could provide the fabric, but stock Android struggles as a general-purpose server/container host.
    • Commenters lament that phones, despite powerful open-source cores, are “tivoized” and locked down like consoles, undercutting the benefits of open source.

Big Tech, Competition, and Lock-In

  • One commenter delivers a broad critique of big tech as building “alien” ecosystems, with heavy AI/PR layers detached from human needs.
  • Others respond that in competitive markets, firms “fight for their lives” by erecting barriers to competition; app-store lock‑in and restricted installation are seen as examples.

Device Support & Resources

  • The postmarketOS device compatibility matrix is highlighted, plus a scraped table of “testing” devices (considered relatively stable).
  • LineageOS’s device list with a bootloader-unlock filter is suggested as a guide for future‑proof, hackable purchases.

Risk & Bricking Concerns

  • Someone asks how hard it is to unbrick a phone when attempting dual-boot/flash experiments; the thread does not provide a clear or general answer.