6 ms·

I'm not knowledgeable enough -- what would it take to escape the Apple/Google duopoly? I'm imagining a future where you buy a smartphone and when you do the fi

I'm not knowledgeable enough -- what would it take to escape the Apple/Google duopoly? I'm imagining a future where you buy a smartphone and when you do the first configuration, it asks you which services provider you want to use. Google and Apple are probably at the top of the list, but at the bottom there is "custom..." where you can specify the IP or host.domain of your own self-hosted setup. Then, when you download an app, the app informs the app provider of this configuration and so your notifications (messenger, social media, games, banking, whatever) get delivered to that services provider and your phone gets them from there accordingly. Is there anything like that in the world today?

immibis 10mo ago
Any one of us here could learn the skills to design a smartphone. It won't necessarily be good, but I remember that years ago, someone made one with a touchscreen hat and GSM hat atop a Raspberry Pi, rubber-banded to a power bank. I'm sure any one of us HN users could do this. And it worked. Quality only goes up from there. The problem is it won't run any apps, so you'll need to carry this open-source secure phone in addition to your normal phone.
- zdc1 10mo ago
  Or use everything via the web browser; but yes, I think apps are the main reason we can't just have a generic Linux phone OS on an open hardware platform
  - bossyTeacher 10mo ago
    Apps make or break operating systems and app stores. Just ask Microsoft (Windows Phone) or Huawei (HarmonyOs). IIRC amazon was paying devs to publish to their app store or something like that. Thankfully, some apps have both web and native mobile versions but for a modern digital life, the critical apps are sadly not on both versions.
  - immibis 10mo ago
    We can have it. It won't become as popular, but we can have it.
  - fsflover 10mo ago
    We have generic Linux phone OSes: Mobian, PureOS, postmarketOS and more. They can even work as daily drivers on some phones.
  - amelius 10mo ago
    Isn't there an emulator that can run Android apps inside any Linux distro?
    - immibis 10mo ago
      No. There are a few that claim to, but none of them are actually any good. Waydroid, for instance, requires that your kernel is compiled in basically "Android mode" (e.g. binder enabled).
      - amelius 10mo ago
        How do the Android developer tools run Android apps on Linux then?
        immibis 10mo ago
        Inside a virtual machine which is easy to detect.
      - yjftsjthsd-h 10mo ago
        > Waydroid, for instance, requires that your kernel is compiled in basically "Android mode" (e.g. binder enabled). Waydroid needs you to have a single kernel module, which is in mainline Linux and just happens to be disabled in many desktop builds. That hardly makes it an "Android mode" kernel, and I certainly see no reason why it should make the system no good.
- fsflover 10mo ago
  This is not as simple as you're saying. Making a new phone not relying on proprietary drivers tied to Android is impossible without a huge effort: https://news.ycombinator.com/item?id=21656355 https://news.ycombinator.com/item?id=21656355
  - immibis 10mo ago
    Obviously you'd only choose hardware that works the way you want it to.
    - fsflover 10mo ago
      Hardware relying on free drivers is almost non-existent in the mobile world. There is nothing to choose from, obviously.
      - immibis 10mo ago
        Then aim for freely distributable drivers. You can share copies of Raspbian, so it seems possible.
        fsflover 10mo ago
        Then your hardware will turn into e-waste as soon as the vendor decides so and stops updating the drivers.
        butvacuum 10mo ago
        You mean the Linux distro that exists because it needs to contain broadcom drivers/blobs/etc that are under NDA?
- mschuster91 10mo ago
  > Any one of us here could learn the skills to design a smartphone. Unless you're Fabrice Bellard who literally created a 4G softmodem - no. It takes a whole lot of people (or, again, one genius Fabrice Bellard clone) to design a smartphone. You'll need AT THE VERY LEAST: 1) a SoC that has reasonably open device drivers and specifications - without that, all attempts are moot 2) a hardware engineer to deal with the PCB 3) a low-level system engineer to deal with the initial bringup (aka, porting u-boot and maintaining it) 4) an RF engineer to deal with the black magic that is designing ultra high performance PCBs that deal with the RF stuff (2G-5G phone networks, BT, WiFi, NFC, GPS) and high-frequency buses (storage, RAM, baseband, USB, PCIe, CSI/DSI) 5) a GPU driver engineer of the class of Alyssa Rosenzweig to get the GPU drivers to behave (she literally provided better-compliant drivers than Apple) 6) a battery engineer to ensure you don't end up with something like the ill-fated last Galaxy Note (that had to be fully recalled due to battery issues) 7) a ton of software engineers to get the basic things running that people expect from a smartphone (e.g. phone calls, 911, SMS, MMS, a browser and enough userland libraries so that third-party developers can begin to port games) 8) hosting engineers that deal with reliably delivering OS updates, application updates and A-GPS data 9) a skilled purchase and finance department to acquire all components as well as skilled QA people to make sure you don't get screwed in your supply chain by someone cutting corners or trying to engage in outright fraud 10) plastics and metal design engineers for the housing and other related engineering, and you'll probably also need engineers specializing in mass production and assembly as injection molding is a skillset on its own 11) engineers specializing in low power domains to get something that doesn't eat through the entire battery in a matter of hours 12) UX, UI designers to get something people can actually use (partially, that's also compliance stuff - think of accessibility laws) 13) testers to test your device against an insane load of other things - headsets, headphones, consumer and enterprise wifi, car head units, mice/keyboards, game controllers, USB hubs, monitors, projectors, adapters, dongles, IPv6 in its various abominations, phone network-side vendors, how devices behave in trains, cars, airplanes, cruise ships, in temperature and humidity extremes, under water, in back pockets (bending!), in dirt, dust, rain, being drenched in all kinds of beverages, muck, snow, fog, right next to extremely powerful broadcast radio transmitters, high magnetic/electric fields, teeth both human (toddlers) and animal (cats and dogs)... 14) logistics experts to deal with shipping, returns, refunds, recalls 15) customer support 16) psychoacoustics and acoustics engineers to make sure your device doesn't sound like shit (both what you hear, and that includes safeguarding the speakers from burning out, and what others hear from you, aka the beamforming stuff that the Asahi people reverse engineered) 17) video/colorspace engineers to make sure the whole darn thing isn't off color 18) camera/optics engineers, even if you acquire camera units these need to be integrated properly 19) lawyers and domain experts to deal with the compliance crap: RoHS, CE, FCC, India's regulatory authority, licensing, binary blobs, video codecs, audio codecs, carrier compliance testing, HDMI, HDCP, the RF compliance crap that's needed for US compliance [1], tariffs, sanctions laws... the list is endless 20) advertising (although admittedly, word-of-mouth could be sufficient), and PR in general (including websites, print media, AtL/BtL marketing) 21) deals with app developers, lest you end up like Windows Mobile 22) security testers/experts to make sure your devices don't get 0wned by cellebrite, mossad, nsa, cia, ... 23) human resources experts ("people engineers") to herd all the cats 24) packaging engineers to make sure the product arrives at the customer's hands both looking appealing and undamaged (tbh, that's at least four distinct skillsets as well) You're looking at a minimum of 2-4 million $ for the engineers alone, another 4-5 million $ for the compliance crap, many millions for the app deals and way more in upfront cash for components and logistics chains. That's why every attempt at a reasonably open source phone design has either failed or is many years behind the mass market. And the list of organisations attempting to do so include household names of the likes of Mozilla. And that is also why/how ODMs exist... they all have figured out some "minimum viable design" that gets tweaked a bit for the customer brand, and that's it. Everyone else went bust. Including, as mentioned, Microsoft. Including former powerhouses such as HTC. It's simply too complex to keep up. On HN, we could probably drum together people of all these skillsets, no doubt (it took me half an hour to think of all these people and I'm pretty certain I've missed important aspects still!), and even ones with enough money to burn. But even then: the competition are the richest companies on the planet: Apple, Google, Samsung. Good luck... (And yes: a minimum viable phone - probably a lot of people here including myself could whip that up using a COTS 5G modem, a Raspberry Pi and a power bank. But that's a MVP, not something you can sell to anyone less nerdy than Richard Stallman, and it's based off of the work of a lot of the people I just spent 58 minutes to think of and write down) [1] https://github.com/lenovo/lenovo-wwan-unlock https://github.com/lenovo/lenovo-wwan-unlock
JoshTriplett 10mo ago
> I'm not knowledgeable enough -- what would it take to escape the Apple/Google duopoly? At this point? Reliable emulation that can run 99% of Android apps, to provide a bridge until the platform is interesting enough for people to develop for it "natively". I think the easiest way to do that would be to run Android in a VM.
- gunalx 10mo ago
  You can go the waydroid style with namespacing, or native containers if using the linux kernel. No need to do a full vm
  - deleted 10mo ago
    [deleted]
  - JoshTriplett 10mo ago
    You could, but using containers requires that your kernel directly provide and secure Android-compatible functionality, such as binder. A VM gives you more options for abstracting that functionality. If you expect to be "essentially android, but a little different", containers make sense. If you want to build an entirely different mobile OS, but provide Android compatibility, I think a VM is much more likely to give you the flexibility to not defer to Android design decisions.
- lawn 10mo ago
  Similar to how Valve is managing the transition from Windows to Linux.
  - stOneskull 10mo ago
    it'd be cool if they made Steam Phone.. it could be to Steam Deck as iPhone was to iPod Touch.
- charcircuit 10mo ago
  Why not run Android directly, such as using Graphene OS. It's decades ahead in both OS architecture, developer tools, and developers compared to non Android based Linux operating systems.
fsflover 10mo ago
You can escape the duopoly by using a GNI/Linux phone, Librem 5 or Pinephone, but don't expect any support from Google or Apple for them. I'm using the former as a daily driver.
- kahnclusions 10mo ago
  I would not trust any of these. They are a security disaster, lacking even basic features for securing your device against tampering and hacking. There is a reason GrapheneOS is number one and a reason why they only run on Pixels (for now).
  - DANmode 10mo ago
    Depends on your threat model, but yes.
    - udev4096 10mo ago
      [flagged]
      - DANmode 10mo ago
        This is true. Many more care about neither, or intermittently care about neither, than most take into account.
      - fsflover 10mo ago
        No, it doesn't. It obeys Google's long-term development strategy for the OS. Google and privacy are absolutely incompatible. See: https://news.ycombinator.com/item?id=29502439 https://news.ycombinator.com/item?id=29502439
        tranq_cassowary 10mo ago
        Google has implemented lots of privacy and security features in AOSP over time. The app sandbox and permission model has evolved a lot, in a good direction. The codebase is also modernized with the increasing adoption of memory safe code. At least Google seemes to have a thought out development strategy to enhance security and privacy, contrary to the projects you mentioned elsewhere in this Hacker News thread. Also, what you link doesnt prove what you think it does. Manifest V3 is a very good thing for privacy and security. It restricts and controls the access of extensions much more. With MV2 you have much less control over your data.
tcmart14 10mo ago
There are some good stuff on the software side that people mention, but a big one is the driver support. We would need device makers to upstream support so there is less worrying about reverse engineering or needing to run modified ROMs based on old builds. Or just publish specs on the hardware that is enough for implementation. Sure, you can buy a specific phone and run a de-googled android or linux, but that only really works for the hobbyist who wants to spend time doing this. Which makes it difficult to create a market that encourages developers of software to port their software or write new software. With out being able to broadly support devices, most people are gonna be better off running Google's android.
- Klonoar 10mo ago
  Halium [1] technically handles that right now. It's not the right solution long term, but you can't expect the entire ecosystem to appear overnight. Using it allows deferring the driver issue a bit while building out the rest of the ecosystem. [1] https://halium.org https://halium.org

immibis 10mo ago

Any one of us here could learn the skills to design a smartphone. It won't necessarily be good, but I remember that years ago, someone made one with a touchscreen hat and GSM hat atop a Raspberry Pi, rubber-banded to a power bank. I'm sure any one of us HN users could do this. And it worked. Quality only goes up from there. The problem is it won't run any apps, so you'll need to carry this open-source secure phone in addition to your normal phone.

zdc1 10mo ago
Or use everything via the web browser; but yes, I think apps are the main reason we can't just have a generic Linux phone OS on an open hardware platform
- bossyTeacher 10mo ago
  Apps make or break operating systems and app stores. Just ask Microsoft (Windows Phone) or Huawei (HarmonyOs). IIRC amazon was paying devs to publish to their app store or something like that. Thankfully, some apps have both web and native mobile versions but for a modern digital life, the critical apps are sadly not on both versions.
- immibis 10mo ago
  We can have it. It won't become as popular, but we can have it.
- fsflover 10mo ago
  We have generic Linux phone OSes: Mobian, PureOS, postmarketOS and more. They can even work as daily drivers on some phones.
- amelius 10mo ago
  Isn't there an emulator that can run Android apps inside any Linux distro?
  - immibis 10mo ago
    No. There are a few that claim to, but none of them are actually any good. Waydroid, for instance, requires that your kernel is compiled in basically "Android mode" (e.g. binder enabled).
    - amelius 10mo ago
      How do the Android developer tools run Android apps on Linux then?
      - immibis 10mo ago
        Inside a virtual machine which is easy to detect.
    - yjftsjthsd-h 10mo ago
      > Waydroid, for instance, requires that your kernel is compiled in basically "Android mode" (e.g. binder enabled). Waydroid needs you to have a single kernel module, which is in mainline Linux and just happens to be disabled in many desktop builds. That hardly makes it an "Android mode" kernel, and I certainly see no reason why it should make the system no good.
fsflover 10mo ago
This is not as simple as you're saying. Making a new phone not relying on proprietary drivers tied to Android is impossible without a huge effort: https://news.ycombinator.com/item?id=21656355 https://news.ycombinator.com/item?id=21656355
- immibis 10mo ago
  Obviously you'd only choose hardware that works the way you want it to.
  - fsflover 10mo ago
    Hardware relying on free drivers is almost non-existent in the mobile world. There is nothing to choose from, obviously.
    - immibis 10mo ago
      Then aim for freely distributable drivers. You can share copies of Raspbian, so it seems possible.
      - fsflover 10mo ago
        Then your hardware will turn into e-waste as soon as the vendor decides so and stops updating the drivers.
      - butvacuum 10mo ago
        You mean the Linux distro that exists because it needs to contain broadcom drivers/blobs/etc that are under NDA?
mschuster91 10mo ago
> Any one of us here could learn the skills to design a smartphone. Unless you're Fabrice Bellard who literally created a 4G softmodem - no. It takes a whole lot of people (or, again, one genius Fabrice Bellard clone) to design a smartphone. You'll need AT THE VERY LEAST: 1) a SoC that has reasonably open device drivers and specifications - without that, all attempts are moot 2) a hardware engineer to deal with the PCB 3) a low-level system engineer to deal with the initial bringup (aka, porting u-boot and maintaining it) 4) an RF engineer to deal with the black magic that is designing ultra high performance PCBs that deal with the RF stuff (2G-5G phone networks, BT, WiFi, NFC, GPS) and high-frequency buses (storage, RAM, baseband, USB, PCIe, CSI/DSI) 5) a GPU driver engineer of the class of Alyssa Rosenzweig to get the GPU drivers to behave (she literally provided better-compliant drivers than Apple) 6) a battery engineer to ensure you don't end up with something like the ill-fated last Galaxy Note (that had to be fully recalled due to battery issues) 7) a ton of software engineers to get the basic things running that people expect from a smartphone (e.g. phone calls, 911, SMS, MMS, a browser and enough userland libraries so that third-party developers can begin to port games) 8) hosting engineers that deal with reliably delivering OS updates, application updates and A-GPS data 9) a skilled purchase and finance department to acquire all components as well as skilled QA people to make sure you don't get screwed in your supply chain by someone cutting corners or trying to engage in outright fraud 10) plastics and metal design engineers for the housing and other related engineering, and you'll probably also need engineers specializing in mass production and assembly as injection molding is a skillset on its own 11) engineers specializing in low power domains to get something that doesn't eat through the entire battery in a matter of hours 12) UX, UI designers to get something people can actually use (partially, that's also compliance stuff - think of accessibility laws) 13) testers to test your device against an insane load of other things - headsets, headphones, consumer and enterprise wifi, car head units, mice/keyboards, game controllers, USB hubs, monitors, projectors, adapters, dongles, IPv6 in its various abominations, phone network-side vendors, how devices behave in trains, cars, airplanes, cruise ships, in temperature and humidity extremes, under water, in back pockets (bending!), in dirt, dust, rain, being drenched in all kinds of beverages, muck, snow, fog, right next to extremely powerful broadcast radio transmitters, high magnetic/electric fields, teeth both human (toddlers) and animal (cats and dogs)... 14) logistics experts to deal with shipping, returns, refunds, recalls 15) customer support 16) psychoacoustics and acoustics engineers to make sure your device doesn't sound like shit (both what you hear, and that includes safeguarding the speakers from burning out, and what others hear from you, aka the beamforming stuff that the Asahi people reverse engineered) 17) video/colorspace engineers to make sure the whole darn thing isn't off color 18) camera/optics engineers, even if you acquire camera units these need to be integrated properly 19) lawyers and domain experts to deal with the compliance crap: RoHS, CE, FCC, India's regulatory authority, licensing, binary blobs, video codecs, audio codecs, carrier compliance testing, HDMI, HDCP, the RF compliance crap that's needed for US compliance [1], tariffs, sanctions laws... the list is endless 20) advertising (although admittedly, word-of-mouth could be sufficient), and PR in general (including websites, print media, AtL/BtL marketing) 21) deals with app developers, lest you end up like Windows Mobile 22) security testers/experts to make sure your devices don't get 0wned by cellebrite, mossad, nsa, cia, ... 23) human resources experts ("people engineers") to herd all the cats 24) packaging engineers to make sure the product arrives at the customer's hands both looking appealing and undamaged (tbh, that's at least four distinct skillsets as well) You're looking at a minimum of 2-4 million $ for the engineers alone, another 4-5 million $ for the compliance crap, many millions for the app deals and way more in upfront cash for components and logistics chains. That's why every attempt at a reasonably open source phone design has either failed or is many years behind the mass market. And the list of organisations attempting to do so include household names of the likes of Mozilla. And that is also why/how ODMs exist... they all have figured out some "minimum viable design" that gets tweaked a bit for the customer brand, and that's it. Everyone else went bust. Including, as mentioned, Microsoft. Including former powerhouses such as HTC. It's simply too complex to keep up. On HN, we could probably drum together people of all these skillsets, no doubt (it took me half an hour to think of all these people and I'm pretty certain I've missed important aspects still!), and even ones with enough money to burn. But even then: the competition are the richest companies on the planet: Apple, Google, Samsung. Good luck... (And yes: a minimum viable phone - probably a lot of people here including myself could whip that up using a COTS 5G modem, a Raspberry Pi and a power bank. But that's a MVP, not something you can sell to anyone less nerdy than Richard Stallman, and it's based off of the work of a lot of the people I just spent 58 minutes to think of and write down) [1] https://github.com/lenovo/lenovo-wwan-unlock https://github.com/lenovo/lenovo-wwan-unlock

JoshTriplett 10mo ago

> I'm not knowledgeable enough -- what would it take to escape the Apple/Google duopoly? At this point? Reliable emulation that can run 99% of Android apps, to provide a bridge until the platform is interesting enough for people to develop for it "natively". I think the easiest way to do that would be to run Android in a VM.

gunalx 10mo ago
You can go the waydroid style with namespacing, or native containers if using the linux kernel. No need to do a full vm
- deleted 10mo ago
  [deleted]
- JoshTriplett 10mo ago
  You could, but using containers requires that your kernel directly provide and secure Android-compatible functionality, such as binder. A VM gives you more options for abstracting that functionality. If you expect to be "essentially android, but a little different", containers make sense. If you want to build an entirely different mobile OS, but provide Android compatibility, I think a VM is much more likely to give you the flexibility to not defer to Android design decisions.
lawn 10mo ago
Similar to how Valve is managing the transition from Windows to Linux.
- stOneskull 10mo ago
  it'd be cool if they made Steam Phone.. it could be to Steam Deck as iPhone was to iPod Touch.
charcircuit 10mo ago
Why not run Android directly, such as using Graphene OS. It's decades ahead in both OS architecture, developer tools, and developers compared to non Android based Linux operating systems.

fsflover 10mo ago

You can escape the duopoly by using a GNI/Linux phone, Librem 5 or Pinephone, but don't expect any support from Google or Apple for them. I'm using the former as a daily driver.

kahnclusions 10mo ago
I would not trust any of these. They are a security disaster, lacking even basic features for securing your device against tampering and hacking. There is a reason GrapheneOS is number one and a reason why they only run on Pixels (for now).
- DANmode 10mo ago
  Depends on your threat model, but yes.
  - udev4096 10mo ago
    [flagged]
    - DANmode 10mo ago
      This is true. Many more care about neither, or intermittently care about neither, than most take into account.
    - fsflover 10mo ago
      No, it doesn't. It obeys Google's long-term development strategy for the OS. Google and privacy are absolutely incompatible. See: https://news.ycombinator.com/item?id=29502439 https://news.ycombinator.com/item?id=29502439
      - tranq_cassowary 10mo ago
        Google has implemented lots of privacy and security features in AOSP over time. The app sandbox and permission model has evolved a lot, in a good direction. The codebase is also modernized with the increasing adoption of memory safe code. At least Google seemes to have a thought out development strategy to enhance security and privacy, contrary to the projects you mentioned elsewhere in this Hacker News thread. Also, what you link doesnt prove what you think it does. Manifest V3 is a very good thing for privacy and security. It restricts and controls the access of extensions much more. With MV2 you have much less control over your data.

tcmart14 10mo ago

There are some good stuff on the software side that people mention, but a big one is the driver support. We would need device makers to upstream support so there is less worrying about reverse engineering or needing to run modified ROMs based on old builds. Or just publish specs on the hardware that is enough for implementation. Sure, you can buy a specific phone and run a de-googled android or linux, but that only really works for the hobbyist who wants to spend time doing this. Which makes it difficult to create a market that encourages developers of software to port their software or write new software. With out being able to broadly support devices, most people are gonna be better off running Google's android.

Klonoar 10mo ago
Halium [1] technically handles that right now. It's not the right solution long term, but you can't expect the entire ecosystem to appear overnight. Using it allows deferring the driver issue a bit while building out the rest of the ecosystem. [1] https://halium.org https://halium.org