Graphene is reaching that status for me every day and i'm looking forward to switching to it as my daily driver.
The short is that yes the GNOME/KDE apps do often look more impressive, but they suffer the same sort of malaise which seems to have infected Linux desktops sometime since Eternal September, and between the sporadic crashing and "this doesn't feel right", it's really hard for me to accept "It's more polished than AOSP!".
pmOS's installation page opening with a warning:
Make sure you read state of postmarketOS before installing postmarketOS.
The goal is to make postmarketOS usable for everyone, but we are not there yet. Usability and most importantly stability issues need to be worked out first. If you are looking for an OS that is as usable as iOS or Android, this project is currently not for you.
All of the default apps in GrapheneOS are being rapidly overhauled or replaced. It wasn't a priority due to the incredibly good open source app ecosystem with many existing alternatives available. There isn't a similarly large and high quality open source mobile app ecosystem available for what's being promoted.
All of the default apps in GrapheneOS are being rapidly overhauled or replaced. It wasn't a priority due to the incredibly good open source app ecosystem with many existing alternatives available. There isn't a similarly high quality open source mobile app ecosystem available there.
All of the default apps in GrapheneOS are being rapidly overhauled or replaced. It wasn't a priority due to the incredibly good open source app ecosystem with many existing alternatives available. There isn't a similarly large and high quality open source mobile app ecosystem available for what's being promoted.
Pixel 3a will lack firmware updates regardless of what you put on it. Having serious unpatched vulnerabilities for radios and other firmware is considered acceptable for desktop operating systems but definitely not by us.
All of the default apps in GrapheneOS are being rapidly overhauled or replaced. It wasn't a priority due to the incredibly good open source app ecosystem with many existing alternatives available. There isn't a similarly large and high quality open source mobile app ecosystem available for what's being promoted.
there is clearly no future for android for anyone wanting an open and spyware free platform. its time to invest out efforts elsewhere.
All of the default apps in GrapheneOS are being rapidly overhauled or replaced. It wasn't a priority due to the incredibly good open source app ecosystem with many existing alternatives available. There isn't a similarly large and high quality open source mobile app ecosystem available for what's being promoted.
Or they can get a Garmin watch with contactless payment, or do what I do - stick a credit card in their phone case.
Anyone is free to fork, add the desired hardware support and flash.
(that's aside of some Moto flagships in 2027)
You say they can. How?
This is a real threat, but the reality is that the average person is more likely to be hacked/spied on from the software side, which Graphene would protect you from as effectively as it does on Pixel.
Fully supporting and using AVB grants protection against persistence of *all* kinds. If an attacker gains privilege escalation through a remote attack, persistence become much easier if the system is not cryptographically verified every time the device boots.
Keystore and Attestation also rely on the bootloader being locked. If the hardware root of trust reports the device as untrusted, there is a broken chain of trust for biometrics, encrypted app data that uses the hardware keystore, and any form of attestation checks (like AOSP's Hardware Attestion API) will report the device as untrusted.
Going back to the first point, if it is possible to modify the system and gain persistence, there is also the possibility of modifying the kernel, which would allow an attacker to rewrite or patch the kernel, rendering AOSP's sandbox useless.
This would also make it more vulnerable to downgrade attacks because rollback protection is tied to a locked bootloader and AVB.
This could all be accomplished through remote exploitation. The "software side" you speak of is built atop AVB as a minimum requirement to assure that the software you're running is unmodified and intact.
:)
Well, go for it, fork and "provide support" to the hardware hostile to non-stock OS, be a hero :)
The rest is not (might be lazy, insecure or just silly but not hostile)
It's surprising some vendors still don't support unlocking and/or relocking.
Delayed patches (they don't keep up with AOSP), missing secure element (makes disk encryption key cracking trivial in comparison).
Fairphone 6/6+ (the latest), is based on..... It's pretty hard to find the Android version it's based on... Got it. They ship phones based on Android 16 half of the year after the release of 17 (9 since public beta).
Many security patches are NOT backported to 16, which makes Fairphone insecure by design.
They allow relocking the bootloader, which is nice, If they also support custom AVB keys, I'd say this is a fine example of the example of the vendor that is not hostile, just not good enough.
I wouldn't say they're hostile - Samsung is hostile for example.
So, what's your angle here? Do you want me to go through every vendor you bring up or what?
> Well, go for it, fork and "provide support" to the hardware hostile to non-stock OS, be a hero :)
In the comment about issues with software and hardware, that somehow is being painted as GrapheneOS fault, I mentioned (among other things) hardware hostile to non-stock OS.
I didn't say it's Fairphone, I didn't name them.
You brought them up, so I addressed that, explained why I don't consider Nothing hostile but just vulnerable by default and inadequate. I even provided an example of the vendor I actually consider hostile (Samsung).
So if you understood quite well, you're trolling now and not discussing in the good faith.
The alternative is you didn't understand and thought I consider ALL vendors as hostile, which is putting claims in my mouth, which would be fine if you asked, but you keep discussing with strawman.
So please go bother someone else; this is the second time you're doing that and I wasted enough time on that.
[0]: https://www.claimsjournal.com/news/national/2024/03/15/32248...
Not to mention to reach GOS’ requirements the cost of the phone would have to significantly increase which I imagine only hurts Android phones even more for no real gain since GOS users are minuscule overall.
And the long term support is definitely not the norm yeah. It’s pretty much just Apple and Google doing it for their own devices. Motorola will be a newcomer to this concept with GOS. But we can only wait and see if they actually stick to it, given their track record prior to the collaboration.
Google probably got away with it cause they made the chips and security chips themselves. I read something like Tensor costing $70 vs. a Qualcomm chip with MTE costing $250.
But even with of all this, it wouldn’t make sense for GOS to spend it’s limited resources developing for a less secure platform when appropriate target devices exist (they mentioned something to this effect a few days ago on reddit too): https://www.reddit.com/r/GrapheneOS/comments/1wifsiq/comment...
Back then the primary goal was checkboxes for the carrier to advertise and UI/UX was a distant second priority at most. Sometimes an advertised feature would just flat out be unusable (such as MP3 players), but good luck waiting for any kind of update because by then those developers had already been reassigned to the next handset model they promised to carriers.
Also, Samsung extensively customizes their OneUI fork of Android, with its own UI look and feel that evolves independently from Android based on their own priorities. Plus Samsung's Android maintains hundreds of features that either don't exist at all on AOSP/Pixels or later get folded into mainline Android.
(Including the little known killer app suite "Good Lock" available on Samsung's Galaxy store which gives power users an almost obscene amount of additional niche options and customizations that would give UX minimalist designers at Google or Apple a heart attack)
But despite how different Pixel vs. OneUI look and feel, I can use the exact same apps whether on a Pixel or Galaxy or $100 trash phone. Interoperability is very easy to take for granted and Android app ecosystem is (still) paradise compared to the lowest common denominator J2ME "app" era of the 2000s.
Oracle was a mighty powerhouse when it bought MySQL, StarOffice, and more. It lost defacto control of all of them, due to its stupidity. In the world of open source, the tighter you hold on, the less likely you'll retain control.
And yet, here we are, with Google playing games.
Google, a note: there are far more relying upon Android than you, and now there are forced alternative stores in the mix. If Samsung and everyone else said "sorry Google', or even a large majority, you're out. Gone. Nada.
They can now fork, and force old Android to have their new fancy pants 'Play' store too.
Google is also getting more and more pushy with Chrome. What if everyone depending upon that backend, shrugs and says "Sorry Google, we're hard-forking Chrome and we'll all maintain it".
The OEMs are incapable of writing a competent operating system, and don't particularly care to.
> Google is also getting more and more pushy with Chrome. What if everyone depending upon that backend, shrugs and says "Sorry Google, we're hard-forking Chrome and we'll all maintain it".
With what maintainers?
https://chrome-commit-tracker.arthursonzogni.com/organizatio...
It definitly still is. We run Postgres when we host our banking / financial stuff, but when we talk with banks and say that, they demand Oracle not that 'open source amateur stuff'. We have a version of our software for Oracle (and MSSQL) as well so no biggy, but still, we always try if we know it's not a complete immediate kill (which it will be if we put it in our documentation as only option). Oracle is still everywhere at the big guys.
Oracle used to be a must-have because it was one of the few products that could handle transactions on a scale of a bank, with all the requirements for backups, redundancy, etc.
A fun anecdote. Back in 2000, I was present at negotiations (as a note-taker) where database vendors were bidding for a project for a factory control system. Vendors submitted benchmark results for various DB sizes up to 40Gb, and Oracle's rep hautingly said something like: "Our minimal size for benchmarks is 80Gb, so here are our results for that size".
And this was a _lot_ for that time. Now? It's so ridiculously tiny that you can host it on a smartwatch. So why would you pay Oracle?
Our Oracle license licensing went up so dramatically that the team I work with is moving some very large databases to postgres from Oracle because it doesn’t make financial sense anymore.
now, if we could only stop eating at the trough of Broadcom…
Postgres ftw. Long may it eat their lunch.
Who will step up to maintain it? Keep in mind that it has to be somebody that every other OEM trust. In other words it would likely have to be an alliance of manufacturers. And they'd inevitably treat OEMs outside the alliance poorly and we'd be back to the current situation, but worse.
Anything Oracle doesn't have much relevance. They were not really interested in growing any marketshare of those products for anyone.
They have their private own agreements with Google to secure whatever access they need to maintain their OneUI fork and are not the one making any public complaints. Samsung did have a love/hate relationship with Google that was openly simmering with resentment during the early years of Android but those days are long past.
Samsung already includes their own Galaxy store alongside the Play Store on all their devices, and have for 10+ years. But during that time have actually moved the opposite direction from your hypothetical fork scenario and both companies clearly view their current relationship as mutually beneficial.
Even though GrapheneOS and Samsung both maintain their own Android fork their views on AOSP/Google are not aligned.