Oh that's one of the best news in the smartphone world in a long time.
It's impossible to escape the Apple/Google duopoly but at least GrapheneOS makes the most out of Android regarding privacy.
I still wish we could get some kind of low resource, stable and mature Android clone instead of Google needlessly increasing complexity but this will over time break app compatibility (Google will make sure of it)
Edit: I do think Pixel devices used to be one of the best but still I'd like to choose my hardware and software separately interoperating via standards
I have been trying to come off of google and cloud by building — quite slowly — my own nas server which has 2 nodes in two geographic regions where I am building certain services like cloud storage and backup, webhosting etc. But I think there are a few key things that need to be community driven to really get rid of this duoply.
0. A privacy first approach would be something like this:
`You+App --Read/Write-> f_private(your_data) <--Write only- 3p` and App cannot communicate your data to 3p or google/apple.
Think of Yelp/Google Maps but with no _read_ permissions on location, functions can be run in a private middleware e.g. what's near an anonymous location or ads based on anonymous data. You can wipe your data from one button click and start again for EVERYTHING, no data is ever stored on a 3p server. Bonus: No more stupid horrible permission fiascos for app development that are just plain creepy.
1. An opensource data effort that can support (0) with critical infra e.g. precise positioning, anonymous or privacy preserving functions that don't reveal their data or processes to 3p.
Here is my favourite open source effort: Precise Location Positioning. A high recall, opensource, 3D building and sattelite-shadow Data-Infra effort[3]. This world class dataset on shadows and sattelites are a must. Most geo-location positioning tied to Radio signals is just a bandaid and fraught with privacy issues — thought there are heroic privacy first efforts in this direction[1][2] which though amazing will be playing catch-up with google already deploying [3].
Totally agree. Pixel devices are probably still the best Android offering, but I originally got into the ecosystem because it was less confined and that appears to be changing. While I'm likely not representative of most consumers, I would love it if I could choose both the right device and right software for my particular needs .
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.
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.
> 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.
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.
Graphene uses the Google codebase, so Google is choosing its long-term development strategy and standards it will support. It's like choosing Chromium to escape Chrome.
The same can be said about the Linux codebase. Tomorrow Linus could private his branch and stop supporting public releases. If AOSP goes closed source then people can fork it and continue to maintain it.
If someone is making a new browser, considering you want to support the same web standards as everyone else, being independent is pretty low on the priority lists. In fact it is more of a liability since it could make for compatibility issues.
Well if you rely on running Android apps, you still rely on Android.
Actually, if you rely on the app, you really on the Android SDK which is not open source.
Now if you could run AOSP but your own apps built with an open source SDK, that would be a different story. Some people seem to really want to do that with PWAs. I personnally tend to hate webapps, but I have to admit that they can be open source.
How do you run WhatsApp or Signal without a smartphone? Pretty hard.
If your answer is "don't use them", then you're not living in a country where the vast majority of communications are done on WhatsApp or Signal, good for you I guess.
Access to Signal and Bitwarden are the only two apps I really need daily that keep me on a smartphone. I have tried using a feature phone in the last couple years, but honestly I might as well just not have a phone at that point as almost all my communication is via Signal.
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.
> I think the easiest way to do that would be to run Android in a VM.
Sony's cameras used to have an Android userland that they used for their PlayMemories apps. No idea how exactly that one was implemented though, but it should be possible to get Android apps without going into being an Android fork.
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.
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.
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
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.
> 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
17) video 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
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.
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...
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
If you're stateside and want a shipping Linux phone today, [FuriLabs](http://furilabs.com) is another option.
Graphene is in a class of its own compared to both of these though and there's frankly no reason to bother unless you're trying to improve those ecosystems.
I admit to being shocked that such a common phrase isn’t widely understood, but this site has plenty of international traffic so I can only say thanks for the context comment. :)
Cloudflare does both but some providers do one or the other. You can use any CDN no matter if you use Cloudflare or not (shout-out to Bunny CDN btw, very happy with them - they do one thing and do it well)
While Rails indeed tries to support old versions for a while I found that many devs are eager to stay on top of upgrades (which also has been less painful the last few years and definitely when done incrementally)
Fair there will be some old never updated backend only services, but that seems like a stretch that those will need a FE library all of a sudden
Solar and battery for refrigeration seems a waste.
If you own a house I'd look into very old school options like digging a deep hole to store your food in a dark&cool place - forgot the name for it but it'll work for weeks or months without a single milliwatt
That sounds really inconvenient (am I going to keep my food down there all the time, or is the plan to carry the entire contents of my refrigerator down there in an outage?) not terribly effective (RIP all the frozen stuff) and probably not any cheaper. Plus the hole can’t be used for other things like charging my phone.
That's very smart and might end my quest for a truly quiet bedroom fridge, if it really only runs two minutes in an hour. (Light fridges marketed as "quiet" just produce near-constant annoying fan noise, quietly.)
By more efficient you mean taking hours to settle? And no inflation as in Bitcoin level volatility and up?
I'd love an efficient and cheap option to move funds online - especially for micro payments too. But so far I haven't heard of any crypto option that actually stayed around long enough to prove these things.
Stablecoins on any number of low cost networks are fine for small payments (I haven’t lost anything, not even $0.01 in 10+years, vs tens of thousands in chargebacks, mostly fraudulent, for credit card processors).
I factor in 2.5% total costs for transaction frictions, historically that is a bit over 3x our actual average cost from payer to bank account, but it would easily cover the occasional loss of a day or two of sales in a catastrophe.
Pick a top 5 stablecoin that has a good reputation and at least 3 years, on a network with at least that, and settle your accounts daily, or whenever the accumulation represents a significant dent if lost.
The approximate aggregate risk-cost of major (top 10) stablecoins is somewhere south of .001% per day, and is better than the aggregate risk-cost of national fiat currencies, which unremarkably collapse or suffer catastrophic inflation and rebasing on a regular basis. There are frequently several undergoing this process at any given time.
> The approximate aggregate risk-cost of major (top 10) stablecoins is somewhere south of .001% per day, and is better than the aggregate risk-cost of national fiat currencies
This "stablecoin" garbage needs to die yesterday: a lot of people are going to lose their shirt when the first one blows up. Fixing exchange rates is folly, yet here we go again...
Why would I care if a stablecoin blows up? My payment cost allocation more than compensates for that possibility and my losses in a worst case scenario would be eclipsed to oblivion by the cost savings I have already realized.
My theoretical potential losses compared to the costs of the payment processsors I ditched, and the chargebacks we used to deal with.
International payment processing is quite expensive, both on a teansaction and on an administrative basis.
My worst case total risk exposure is approximately the same as the cost of 3 months of payment processing overhead, without counting fraudulent chargebacks and “we are going to freeze your account because we can” risks.
FWIW in the last 60 years I have lost way more money to fraud and theft dealing with banks and cash then I ever will using cryptocurrency. On a total, or a percentage basis. I see the risk profile, when properly managed, to be much, much lower using blockchain solutions.
> My worst case total risk exposure is approximately the same as the cost of 3 months of payment processing
Okay, yes: what you're describing is the actual utility of these things.
I think you underestimate how many people dealing in them are using them much less intelligently than you are.
They are being marketed in an extremely dishonest way, as a safe long term store of value. I regularly overhear normal people at my local bars talking about how they're "investing big in stablecoins" and it terrifies me.
>>This "government issued fiat currency" garbage needs to die yesterday: a lot of people are going to lose their shirt when the first one blows up.
What you are saying is a risk endemic to all fiat currencies, including stablecoins.
All symbolically represented forms of value quantization are subject to a failure of confidence. Cryptocurrencies are nothing new in this regard. All money is memetic in nature.
That’s one of the reason the stablecoins won’t be taking my assets? Idk what your point is but it doesn’t seem like you are debating from a point of rational examination.
Weird, people on the internet spewing BS? Who’d have thought?
Well, losing three months of revenue is going to really hurt when the stablecoin inevitably eats shit: hope you're prepared for that.
The risk is obviously lower because you aren't parking money there. I could certainly see how you might come out ahead in fees for certain international transactions.
But your original claim was that the aggregate risk-cost of dealing in stablecoins is lower than real currencies, and that is absolutely preposterous: you aren't accounting for all the risks.
It's ridiculous that we live in 2025 and most people in North America have apartment buzzer systems that don't work with "long distance" calls or forward to multiple phone numbers.
[freshbuzzer.com](freshbuzzer.com) does that and much more!
It's impossible to escape the Apple/Google duopoly but at least GrapheneOS makes the most out of Android regarding privacy.
I still wish we could get some kind of low resource, stable and mature Android clone instead of Google needlessly increasing complexity but this will over time break app compatibility (Google will make sure of it)
Edit: I do think Pixel devices used to be one of the best but still I'd like to choose my hardware and software separately interoperating via standards
reply