I think this stuff is super important, simply because there is a ton of stuff we can't do using our phones today.
Think mesh networking, resilient ad-hoc application clustering, non-Internet P2P, like Freifunk but everywhere. We shouldn't have to depend on Google or any of the big tech companies for anything except the hardware.
That would offer much more freedom. There are also contexts where this kind of thing could also enable life-saving applications. And unlike todays Internet where a database query in Cloudflare or a DNS bug in es-east-1 can disrupt half the services we use, this kind of technology really could withstand major attacks on infrastructure hubs, like the Internet was originally designed to do.
Twenty years ago, if you told me that by today we'd have smart phones with eight or more cores, each outperforming an average desktop computer of the time, with capacitive OLED touch screens, on a cellular network with hundreds of megabits of bandwidth, I'd find it believable, because that's where technology was headed at the time.
If you said that they'd effectively all be running either a port of OS X or a Linux distribution with a non-GNU but open source userspace, I'd consider that a somewhat unexpected success of open-source software. I would not at all expect that it would be as locked down as video game console.
The more time passes, the less I use my phone for, and the more likely I am to whip out my laptop to accomplish something, like it's 2005.
The open source components in your android phone are suffering from what FSF called "tivoization" a few decades ago. They can't reasonably be replaced without breaking security measures, a pretty high barrier for most users, even sometimes for advanced users. It removes the biggest benefits of being open source.
Open source userspace? Google Play Sevices?
>Think mesh networking, resilient ad-hoc application clustering, non-Internet P2P, like Freifunk but everywhere.
(if dumbed down) What's are the gaps in features and functionality between what you're describing and what might be achievable today (given enough software glue) with an SDR transceiver and something like Reticulum [1] on an Android?
Very good question!
SDR + something like Reticulum or Yggdrasil would definitely provide the infra or network fabric for the kind of thing I'm thinking of.
However, a normal Android, e.g. a Pixel 7, can't to my knowledge be turned into a web server or a podman host for containers. (I know of people hosting websites on old Androids that are flashed or hacked).
Given phones already have a WiFi/WLAN radio chip, it's a shame to need extra kit for connectivity.
It's something that's been on my mind a lot recently and so you provoked me into writing down a series of scenarios in story format that illustrates what SHOULD be possible using current hardware, were it not, as dlcarrier says, locked down like a games console.
Here you go:
This will become increasingly important as Google has boiled the frog too fast while trying to force its new store policies + banning sideloading; however, all of the pieces are now in place for them to try again in a year or 2, which history shows us they will. It’s certainly time to start toying with Linux phones if you haven’t already. This year I picked up an Xperia 10 to flash Sailfish OS on—which has rough edges (many of the hardware issues should be fixed in the next release), but Android App support bridges some of the gaps in application support.
> sideloading
It's called installing. Language matters and I see no reason to concede this point in Google's favour.
I agree with the ethos but "banning installing" wouldn't have been correct here.
There should be terminology for installing from the source of your choice which doesn't carry the marginal or sinister connotations of "sideloading" though.
"Freeloading" would have been a good one but... yeah
Wouldn't it be accurate to say that you can no longer install apps on your phone, only Google can?
If we're being pedantic, the user still has to perform the final action before the install begins. I think it' more "Google has to allow you to install apps on your phone"
And they've never allowed the users to uninstall certain apps.
(interestingly the keyboard app is not among these, so my sister has uninstalled it by mistake once)
I'm not suggesting a drop-in replacement within that context, just that widening the definition of sideloading does us no favours
'installing from beyond the walled garden' would be a nice fit here imo
Installing is still the right word, you just need to use more of them:
"Installing arbitrary packages"
vs
"Installing google-approved packages"
> but "banning installing" wouldn't have been correct here.
it would
and it would show exactly why it is absurd
But currently, the masses know it only as a button in the play store and app store.
"Freely installing"?
"banning installing from anywhere but play store"
Language matters, so don't let google turn sideloading into a dirty word. It was called sideloading before Google was even founded.
My first encounter with "sideloading" I think was loading up a MP3 player with music, for some reason that was called "sideloading" by some people. In that case, "sideloading" was just transferring basically, nothing about installing.
But once Android appeared, and there was one Google-approved way of installing applications (Google Store) and one way of installing directly from .apk after enabling "Unknown Sources", then the word started to be used for the second approach.
I don't remember if it was Google who started using "sideloading" or the community itself, but regardless, "installing" would be a more understandable word for anyone to use for the processing of installing an application on your phone, as (what I recall to be) the original meaning was just transferring.
> My first encounter with "sideloading" I think was loading up a MP3 player with music, for some reason that was called "sideloading" by some people. In that case, "sideloading" was just transferring basically, nothing about installing.
Probably influenced by the original iPod, which really wanted you to sync your iPod with your iTunes library (conveniently directing you to purchase all of your music from Apple's platform). "Sideloading" referred to the few extra steps to get your computer to simply expose the iPod as a removable storage device and drag-and-drop your mp3s over that way.
It wouldn't have made sense in the context of other mp3 players, because for many of the ones I remember (like my Creative Zen Touch), that was the only way to add the mp3s. I don't think Creative even supplied a front-end media manager...or if they did, I never bothered installing it.
Well actually..
Steve Jobs himself said in his famous “Thoughts on Music” letter that was posted on the Apple home page that less than 10% of users music on iPods were bought from iTunes.
> Probably influenced by the original iPod, which really wanted you to sync your iPod with your iTunes library (conveniently directing you to purchase all of your music from Apple's platform).
iTunes (the software) came out before the iTunes (the music store) and iPods and Apple actually marketed the iMacs as “rip mix burn”.
Even before the iTunes store appeared, I always hated the over-complicated import/sync pattern.
1. "Import" your files into iTunes "library"
2. "Sync" that library with a device
My computer already has a filesystem. Why do I need to involve some application's "library"? I hate applications that insist on grafting its own "library" container on top of my already-working filesystem. My OS already allows me to copy files. Why do I need to rely on that application to copy files? Just expose the thing as a mass storage device and let me use my OS!
Because with iTunes, I could and did have regular playlists and smart playlists using conditions like ratings, last played, play count, number of times skipped (so that it would automatically be removed from a playlist if I continued to skip a song on my iPod or computer), genre, year released, etc.
You couldn’t have that metadata with just file syncing. Later when iTunes was introduced, it had to support DRM.
Later it also had podcast syncing.
I used iTunes to burn CDs before I had an iPod.
And don’t forget that Jobs being able to negotiate users being able to buy music on iTunes with DRM [1] and letting users burn them to a DRM free CD was so revolutionary that even Bill Gates was impressed.
https://9to5mac.com/2021/07/09/unearthed-email-shows-bill-ga...
[1] later Jobs argued in the same “Thoughts on Music” letter that instead of Apple licensing its DRM the record label should license DRM free music to everyone since most music was already sold as DRM free CDs and then everyone’s music could work anywhere. Only one record label took them up on the offer from day one. It wasn’t until 2009 that all of the record labels agreed.
Yeah, people in my circles and also people on the internet would refer to it as "sideloading" even though none of us were using iPods (I think this was all before the iPod actually, but my memory is a bit hazy), just copy-paste the files with explorer.exe over to the built-in MP3 player storage, people calling it "sideloading".
You can also install through the Play store. Sideloading is more specific.
Like hacking, sideloading is now a loaded & misunderstood term. It is considered as something only nerds or bad actors do.
Let's just call it alternate install.
Or "open install", correctly implying the alternative is closed.
It's bypassing the usual channel for app installations, so the term is technically fitting and the loaded meaning is also appropriate since it's mostly used by nerds (maybe too strong a word) and bad actors.
There are legitimate uses of sideloading for regular users, for example if you have solar panels that work with a Huawei app, they can't put it on the Play store because of US sanctions. But that's not Google's fault, and that does mean the app is more risky since it's not monitored by Google.
(I'm not saying sideloading is otherwise illegitimate, it's an important feature but it's not something I'd normally recommend to a non-technical user that already chose to use a phone with Google's system.)
> that does mean the app is more risky since it's not monitored by Google.
Why is Google the arbitrator of risk here ?
As a user I'm capable of assessing the risk directly or indirectly by delegating that responsibility to another store or another program a.k.a anti-virus programs, its my choice in the end.
I want Google to build software like Windows Defender and allow others to build similar software. I want the ability to chose my security provider or not have one. I don't want Google to play nanny.
> Why is Google the arbitrator of risk here ?
Because they do the monitoring and take some responsibility? I'm just comparing "install from the Play store" with "install some apk from wherever". If you bring additional context/knowledge of course it makes a difference.
Risk and responsibility are different. Monitoring, responsibility, those are just silly words with semantic games since Google's store is full of malware while F-Droid is not. Google's store is the risky one, and the words on their compliance statements are irrelevant to that fact.
Yes because that has worked really well in the history of PCs with malware, bundleware, ransomware, etc
Just because its the channel that google would prefer you use doesn't mean its "the usual channel". What counts as "usual" is user specific. I don't even have google play installed on my Android phone.
True, I'm speaking of the situation for the crushing majority of users (outside China I guess), not for literally every user.
Sure, but if we want to chip away at that majority, we need to encourage them to think of using the play store as a choice they have. Implicitly assuming that "install" means "install from the play store" is counterproductive.
>and that does mean the app is more risky since it's not monitored by Google.
This implies the play store isn't hosting tonnes of malware right now
Yeah maybe it gives the wrong idea. It's still better than no monitoring at all.
It gets tricky with alternative stores like F-Droid. I guess if you use F-Droid as a trusted source then it shouldn't be called sideloading.
There is currently zero evidence that the "monitored" Play Store is better or safer than the open internet.
it's not "alternate" install - it is install
it's google's monopolized install that needs to be called by a long name
Or manual install.
How about calling the other one "installing from the play store"? installing was there first.
Exactly. Let's invent a word for "installing from play store". Playstoring?
So we can rewrite the story to something like: Google wants to prohibit app installation on Android phones. The only way to get an app would be through playstoring.
Restricted installing
how about "dogmatize" - I dogmatized this app from the play store.
Corpoloading
Nannyloading
I can install on my Fedora laptop through dnf. I've never felt like I needed a new word to describe downloading and running an AppImage. Why would phones be different?
`adb sideload` existed as a command for installing an apk from your PC on to your phone. Sideloading was not meant to refer to installing an apk on the phone from the phone.
I knew if I read enough comments I'd finally arrive at my favorite take.
Installing an APK directly through your phone is in fact NOT sideloading.
That actually sounds like a good idea, the situation is similar with an official channel of "trusted" software for which the distributor takes some responsibility, versus whatever file you downloaded yourself. It's certainly more risky on a Debian system to install a .deb from some random website, or an AppImage, compared to a .deb from the official repositories. I guess it's the same for Fedora.
well because its not allowed to "install" from third party sources (atleast not yet)
google has control on their android ecosystem behave, same reason why its not allowed in playstation or xbox or ios
The whole selling point of Android up until now was that it allowed you to install any app you want.
The point of the above comment is that Google intentionally introduced the word "sideload" to make "installing an app on your own device which Google did not curate" sound more risky and sinister than it is, and I'm inclined to agree.
I "make" coffee on my keurig. If Keurig decides that making any single-serve coffe pods that aren't owned by the Keurig brand is now called "off-brewing," I'd dismiss it as ridiculous and continue calling it "making coffee."
We should use the language that makes sense, not the language that happens be good PR for google.
>The whole selling point of Android up until now was that it allowed you to install any app you want.
Could've fooled me. Maybe it was a thing a decade ago when android just launched, but none of the marketing pages for vaguely recent phones has that as a selling point. At best it's a meme that android proponents repeat on hn or reddit.
We're not talking about phones, we're talking about an operating system. If those companies could port IOS to their phone, they probably would. Since the OS will be mostly the same across devices, it makes sense to market a phone based on hardware differences -- like having a higher quality camera.
I've never met or talked to an android user that truly believes android is better technology or a better user experience. They all use it because of flexibility.
"The whole selling point of Android up until now was that it allowed you to install any app you want."
we can debate whether this is bad thing or good thing, it would have no ends
what matters is reality, the reality is google have the right to change it.
You've changed the subject. We were discussing whether one ought to use Google's term for it, or the term that's been used to describe this action since (I assume) the beginning of personal computing. Not whether Google is legally allowed to make the change.
My reason for bringing up the "selling point" was to bring attention to the language -- "You can install any app you want" has always been the common refrain when I see friends get into a debate about IOS vs Android. People are already using the term because it makes the most sense.
"You can install any app you want"
the asnwer is not anymore
What does that have to do with whether we should say "install" or "sideload?"
same reason like you cant sideload in ios,playstation,xbox,switch etc
sideload is illegal
Calling something a right is an assertion about morality; it implies that a law to the contrary would be a violation of that right.
I do not believe an an OS vendor with an app store has a right to limit alternate distribution channels or that a government does something wrong by restricting such practices as unfair competition.
"I do not believe an an OS vendor with an app store has a right to limit alternate distribution channels or that a government does something wrong by restricting such practices as unfair competition."
but its not illegal and wrong tho???? if this is probihited then xbox,playstation,nintendo,ios etc would be fined already
unironically android is still more "open" than all of its competitor even after all of this
It might be illegal in the EU under the DMA. As I understand it, litigation involving Apple's equivalent is in progress, and the outcome may not be known for years.
Wrong in this context is an assertion about morality. I do think it's wrong in the context of consumer products for a vendor to attempt to override the wishes of the owner of the product outside of a few narrow exceptions. I would absolutely apply that to iOS, and I think the DMA didn't go far enough; Apple should have no ability to enforce notarization or charge fees to app developers if the device owner chooses otherwise.
I feel less strongly about game consoles because they're not as important as smartphones; they don't touch most aspects of life in modern society, and there are viable alternatives for their primary function, such as gaming on PCs. I don't like their business model and I don't own one.
that's what I call hypocrite
all of big tech doing it for 20+ years and suddenly google isnt allowed to do "industry standard", like what we talking about here????
I know its bad for pro-sumer which is minority but consumer would get more protection which is majority so I dismiss HN audience because they are biases vs normal people
They all should be? I've never understood why gamers just accept constant blatant anti-competitive practices, going so far as to act as if "exclusives" via DRM are a good thing rather than monopolistic product tying. e.g. it's been demonstrated that a Steam Deck is technically capable of running Switch games better than a Switch, and yet you are forced to buy a Switch in order to buy the games.
It's no longer 30 years ago when hardware was unique and quirky and programs were written in assembly specifically for the hardware. It's all the same commodity parts along with what is supposed to be illegal business practices. In a reasonable world, something like Ryujinx would be just as front-and-center as Proton as part of Valve's product features, and courts would fine companies for trying to stop their software from working on other platforms.
because steam deck is more like "PC" than a console
I know, I know everything can be a "PC" if you look close enough but hear me
people can create their own ecosystem of walled garden whenever they want
Antitrust law exists exactly to prevent companies from making their own ecosystem/walled garden that competitors cannot sell into. Product tying (forcing you to buy product B in order to buy product A) falls under that umbrella. Game console are not magical in this regard.
Yeah, thats my point
game console has been doing it for 20+ years and they are fine, apple has doing it for 10+ years and they are fine
Google wants doing it???? they are fine to do that. if you have problem then you are hypocrite
Lots of us have a problem with all of those things, and would like the government to enforce the law. I've never bought an Apple product, and the last game console I owned was a PS2 when I was a child.
I do not get this use of the word "reality"? The reality is Ted Bundy's currently-at-large successor has the ability to shoot me with a gun. And that fact is about as relevant as what you said.
What you're doing here is resigning from a game just because of the fact there is a game, and then being condescending to other people for trying to win the game instead, as if what you're doing is something superior. This would already be very odd behaviour if this were only Monopoly or Risk, but is downright dangerous propaganda when the game is capitalism and the future of free computing is at stake.
"future of free computing is at stake."
that is what AOSP are, android remain "free"
the ecosystem around android??? remain google rights and rightfully so since google fund and develop most of it
same like apple does, microsoft does, nintendo does. nothing wrong againts that
Would you make the same distinction on a mac when installing Photoshop from the Adobe installer vs installing KeyNote from the MacStore ?
I'm not too familiar with macOS... How normal/expected is it now to install through the App Store? As mentioned in another comment, for a Linux distribution like Debian there are highly trusted official repositories, and I think using "sideloading" for other sources would make some sense.
Doesn't feel like any conspiracy.. Isn't sideloading installing through adb instead of from the system itself? (by clicking on an APK or using an app Store like Xiaomi/Googled/Huawei/Fdroid)
"Side" being.. from your computer
No, on android, it always meant installing an APK directly, without a store-app. You can use ADB, but you also can just download the APK on your device and install it locally with your browser or filemanager.
Yes but fdroid is facing restrictions while adb is not
sure, google is trying to cash in. not saying theyre nice people. but the handwringing over semantics and suggesting Google has a master plan to abuse vocabular just sounds ridiculous
So you do know, they want to make profit.
You also know, what is commonly used for making profit? PR.
And they are all about changing the meaning of words, to achieve a certain effect in people.
https://en.wikipedia.org/wiki/Torches_of_Freedom
What exactly is ridiculous to the idea, that maybe there was a google meeting where the name was debated and the pro and cons of different names evaluated from their buisness perspective?
I just bought a second Fairphone 4 just to play a bit with pmOS. I'm really surprised by the state it is. It's not fully usable as a daily driver yet, but with some work it can get there. Waydroid works also pretty good. Of course, the major problem are banking apps and similar. I hope that some progress can be done in this direction. And, who needs working audio, if you can have python and git in your phone!? :P
I made a partition for Nix on mine so I have all the tools I need while not relying on Jolla to package things (the installable package list is quite barren). My audio works from the speakers, but the patches to make the headphone jack (something you Fairphone users no longer know of :P) work won’t come til the next release. For banks, I just use cash or log into the website on my laptop if required—while I will refuse goods/services that require an apps to the fullest extent possible (couldn’t get around TicketMaster which was a real blood-boiler beyond just the “phone required” aspect).
Yes, I think that just trying to use services that don't require special mobile apps can get you a long way. It is sometimes difficult, but now I'm beginning to move more in this direction :)
It’s the same as unGoogling your life where you can slowly start moving off one service at a time & make sure new ones you use are open or at least otherwise ethical.
> Waydroid works also pretty good.
Did you test apps that need sensors and notifications? If I want to run an OpenStreetmaps apk (there's no good way to run OMS on Linux natively), do I get GPS and compass heading? Do I get turn-by-turn navigation? Even if the app is in the background?
Organic Maps has a flatpak, though oddly they don't refer to a desktop app on their website anywhere so idk how trustworthy this is.
Unfortunately CoMaps doesn't seem to have desktop client builds at all yet.
They do mention it at the bottom: https://organicmaps.app/#community
But it's less full-featured than the mobile-only versions.
What I never get is: why not prepare to fork AOSP? I like the security model of AOSP :-).
Some people (like myself) prefer the desktop userland which is more familiar and works like you would expect as opposed to the android quirks.
eOS is basically what you are looking for for most phones or GrapheneOS (pixel only)
That's already happening today.
But for the reason an antiquated os like postmarketos are suggested is that the project is being opportunistic thinking this is a chance they can be relevant. Additionally, the population of HN has more sentimental view on these legacy operating systems and view it as a chance to go back to the past and use software they are familiar with.
I really wanted to like Graphene OS but I ended up bouncing off it due to a few major pain points that badly effected battery life.
- Using the default 5g setting resulted in far worse battery life than stock, telling people to choose 4g isn't a solution. They desperately need something like the adaptive connectivity service.
- Using Homeassistant's GPS tracking feature just destroyed the battery life, even switching to 4g didn't solve this issue. Changing all the GPS settings didn't help either.
- The obnoxious green GPS active icon makes the notification bar useless if using a GPS tracking app (or even gps navigation). The request for a whitelist was either ignored or rejected, the teams communication can come off a bit rough.
No normal user is going to be happy with Grapheneos. From what I've seen postmarketos is much more user friendly.
I don't know what to say about your battery life issue, other than that I don't have any such problems.
What's obnoxious about the green GPS icon? How does it make the notification bar useless? It is on all the time while I'm using Google Maps, it's small and not in the way and is a good reminder if I have accidentally left Google Maps open in the background. What's the problem?
I don't recognise the 5g battery life issues personally. I do 100% agree the GPS thing is such a bad decision. It just becomes noise that no one pays attention to anymore.
I ended up using my public ip address in combination with a list of known ips for home and work and such, and building my HA automations around that. I wanted to do it with wifi SSID's, but that also requires the location permission and triggers the indicator (which is understandable, just wish I could still read SSID's with location services disabled entirely) (or, just let me disable the gps antenna and leave everything else).
> I do 100% agree the GPS thing is such a bad decision. It just becomes noise that no one pays attention to anymore.
It's not noise for me, I only ever have GPS on for Google Maps, and I like the indicator because its absence reassures me that nothing is using GPS in the background.
I also want to have audible notification or, even better, a loud siren when GPS, or WiFi are activated without my direct action. Sadly, SafeDot doesn't work properly on Graphene.
It certainly could be something else other than 5g but it's one of the first things that gets thrown around when battery drain is mentioned and the mobile internet was the main user of power on the phone.
> No normal user is going to be happy with Grapheneos.
I am a normal user, extremely happy with GrapheneOS. I just don't use HomeAssistant, which seems to have been your dealbreaker in this case.
I genuinely don't see a difference between Stock Android and GrapheneOS, except that I get more updates and I have more privacy controls (like scopes, but honestly I haven't had a need to use them yet).
I'd wager nobody on HN is a normal user. If you know what AOSP is, you are already way too nerdy to qualify.
You are very fortunate for not hitting any edge cases, but sorry anyone commenting here typically isn't anywhere near to what you could call a "normal user". I ran into quite few minor issues with the enhanced security settings, my partner would never been able to figure out the solution to that issue and I consider them a normal user.
Not to mention the 5g battery drain is a hard show stopper, not just Homeassistant issues. I even experimented with different apps like owntracks but same problem with GPS.
I found a solution to the GPS icon but it requires an ADB command so not a great fix.
> That's already happening today.
That's not a hard fork. They always rebase on top of AOSP when there's a new AOSP source release
There is no reason to hard fork, as long as Google contributes to AOSP without breaking it.
Regulators in the US decided that Android did not have to be split from Google, but they could theoretically decide that Google is not allowed to break AOSP to gain a competitive advantage. Not that it would matter: TooBigTech is too powerful to care about regulations anyway.
It doesn't have to be. Most of Android is fine.
Outside of China, to a first approximation no one once to use an Android device without Google Play Services.
I would love to, for the record.
Nobody really want a hard fork, if you can't run Android apps, you might as well use a Linux distribution.
Well the idea would be to run Android apps on the hard fork :-).
If you can run Android apps then you need the same behavior as AOSP or I'm missing something?
If you don't rebase from AOSP, the apps won't run pretty quickly.
I actually wonder: if Google stopped pushing to AOSP and "the community" had to fork... the whole Android SDK/NDK is not open source, so I wonder if AOSP could survive at all without Google, even though it is open source.
I think if Google would stop pushing AOSP, there's a very high risk for Google that a consortium of manufacturers would continue themselves as they need it and they would lose control.
I think that is unlikely reality because from manufacturers perspective they don't get AOSP from the public. They get it from their chip provider like Qualcomm who gets private releases from Google. Everything is already set up such that people aren't using the public version, so the more likely reality is that the public version goes away, and google partners keep doing what they are doing. Maybe things are different on the Chinese side of things. So if it were to be created, it would be over there.
Would they, though? Like Huawei forked for a while, and then they made their proprietary HarmonyOS.
For a while I thought it was a missed opportunity to compete on a hard fork, but then I realised that Huawei probably cannot fork the Android SDK/NDK because it's not open source.
How is Postmarket OS antiquated ? Its just a standard Linux distro (unlike anything Android based).
At least in regards to the security model, it is decades out of date. For example any app can listen to your microphone and spy on you at anytime. Programs can act as ransomeware or destroy all of your files. Stealers can steal your login credentials and access tokens for all your sites including banking ones.
I think people don't realize how inadequate the Unix security model is.
Linux doesn't solely rely on the Unix security model. Linux security is mostly based on trust, the trust of the distribution and its maintainers. But if you want to run random, untrusted apps you'll want a different model. Linux is slowly addressing that need w/ a variety of different approaches which could be picked up and used for a mobile OS.
Well, isn't the idea that you use apps compiled from source by distro maintainers, which are separate from the upstream maintainers ?
Frankly, I still trust this model much more than black box Android apps automatically updating in the background, sending tons of telemetry and demanding random permissions so they can spy on you.
Not to mention the security model preventing many useful things from working properly (try to get a SFTP working on an Android system so that you can copy out photos taken by the phones camera.
> Frankly, I still trust this model much more than black box Android apps automatically updating in the background, sending tons of telemetry and demanding random permissions so they can spy on you.
You're comparing a security model to... apps? I don't see how that makes sense.
Apps you install on Linux can do more than apps you install on Android, period. That's part of the security model.
Of course I like that I am an admin on my computer, but I don't need that on my phone. And one can enable root on Android and still keep the apps sandboxed...
>isn't the idea that you use apps compiled from source by distro maintainers
That might work if the main danger was upstream maintainers with bad intentions. But the main danger is security holes that no upstream or distro maintainer knows about, which allow attacks by parties that are not open-source maintainers.
Big picture is that GrapheneOS is much, much more secure than PostmarketOS.
...except in virtually any case where you'd run something untrusted there you'd use Flatpak or something similar where what you wrote doesn't apply.
> untrusted
I think the important distinction is _everything_ should be considered untrusted because even trustworthy software can become malicious. For example, the XZ Utils backdoor[0].
On Android, everything I run is subject to the permission model and sandboxed. That is not the case on Linux.
It's not the case on Android either and it could be subjected to a XZ-like backdoor just as anything else.
Could you be more specific on how to circumvent the android permission model + sandbox? So far I have only thought of two ways an XZ-like backdoor could circumvent that:
1. By being baked into the OS itself, which is unavoidable since the OS is the thing providing the sandboxing + security model. It still massively reduces the attack surface.
2. By being run through the android debug bridge, which is far from normal and something users have to explicitly enable. Leaving you the option to shoot yourself in the foot in an opt-in manner 99.9% of users will never touch isn't the same as Linux where foot-shooting is the default.
The defining aspect of the XZ backdoor was that it was baked into the OS itself, being linked into memory space by about half of the system and activated by being packaged in a specific way in a specific distribution. If you wanted to ignore 1), you would have to choose a different example.
If you want to confine yourself in a sandbox, feel free to do it. The past decades have demonstrated that it's only necessary for some specific threat models.
> If you want to confine yourself in a sandbox, feel free to do it.
I want to confine apps in a sandbox. Android has that, Linux... well not really. I mean "it's possible", but it's not integrated like in Android.
>where what you wrote doesn't apply
You can configure your flatpak app so that it will have permission to read microphone in the background or have full access to the disk. Many flatpaks of real apps request dangerous permissions that users have been conditioned to ignore. For example Blender is such an app which has full disk access and background microphone access, and I'm sure many people have installed that. This is unlike Android where these are locked down for every app.
...and if you want an Android app to actually be able to do something useful, you give it root permissions and completely bypass the permission model.
The world isn't black and white. Most reasons why Android apps are being so heavily locked down don't apply to Blender. As a user, I'm not interested in Android-bis - if I were, I would just use Android after all. Nevertheless, things like Flatpak give me, the user, the power over application's permissions and I can take them away (or give more) in a few taps at will. The defaults being tuned for different use cases and threat models are not "being decades out of date", especially when you could already use the existing tooling to replicate other models - regardless of whether you happen to like these defaults or whether they fit your specific use case.
>you give it root permissions
This is not possible on a device following the Android security model. Permissioned features should always be implemented using proper security mechanisms like permissions.
>don't apply to Blender
You say that until the SuperRetopologyTools5000.py addon you try out infects your system.
>Flatpak give me, the user, the power over application's permission
Most people are not going to bother with this. It's important for the defaults to be secure. People shouldn't have to opt in to a secure experience, and doing so shouldn't break the program.
Meaning, it's a way to keep old hardware running linux instead of being a phone.
or they already have hardware which postmarketOS supports and grapheneOS does not (or they would just prefer that hardware)
> I picked up an Xperia
I had an Xperia for awhile. I liked it while it was new, but after a year the back started peeling off.
Pretty lousy for a phone that was supposed to be waterproof. At that point I realized that the Japanese change out their phones every 6-12 months, thus Sony didn't realize that the market demands much longer reliability in a smartphone.
They do a good job contributing upstream to the kernel & are one of the few phones out there that still allow users to unlock the bootloader & they support headphone jacks + microSD cards.
Honestly, if mine didn't fall apart after reasonable use, I'd probably still be an Xperia user today.
My biggest worry is that it's harder and harder to find a phone with an unlockable bootloader.
Lineageos maintains a list and you can filter for devices with official bootloader unlock https://wiki.lineageos.org/devices/. Buy only these devices to signal to these companies that this matters.
Noteably OnePlus 13 and Pixel 9a, both 2025 phones, can be unlocked.
If someone want something also quite recent and cheaper in this supported list there is also motorola edge+ (2023) with good specs. I got myself refurbished with perfect condition for just 240usd.
The wiki has instructions for the N900! Not everything works, but it appears to be a work in progress.
For the N900, Maemo Leste <https://maemo-leste.github.io/> would be a good choice, if not even better.
Nice, I still have my N900 but my provider here (Swisscom Switzerland) is killing 3G by the end of the year...
I wonder if there's some sort of GSM hotspot device where it connects to 4G/5G networks, but creates a small localised 2G/3G cell for older phones. Kind of like how we have mobile hotspot devices, but instead of (or addition to) creating a WiF hotspot, they provide 2G/3G...
I installed PmOS on my old Xiaomi redmi note 9 with KDE Plasma Desktop. It works remarkably well, with the exception of sound. I am using it as a full Linux PC when I am on the go with my large power bank and a full sized folding keyboard/track pad.
For my use case it's beyond great, albeit the small screen and the aarch architecture I can develop small projects as if I was on my PC.
My current phone OP13r doesn't is supported yet by PmOS, when someone does it Im gonna try to install it on one of the slots.
pmOS device compatibility matrix: https://wiki.postmarketos.org/wiki/Devices
If anyone wants a table for the testing devices (which are arguably still quite stable!), here's a table I put together by scraping the site a few months ago:
If anyone wants the code for scraping and reformatting, let me know.
It's a shame phones didn't get anything similar to BIOS back in a day.
Imagine if every laptop manufacturer had not a couple of incompatible sensors, but a whole unique boot system only allowing you to boot a crippled version of Windows ME.
There's a lot of UEFI in the phone ecosystem, it's not the BIOS later that's missing - it's the ACPI layer.
Yeah, the requirement to build and provide device trees for most mobile devices is the huge issue. For all of the garbage we have gotten from buggy ass ACPI tables on assorted PC’s, it’s absolutely true that it solved a lot of headaches with hardware discovery/enumeration.
It’s really too bad that ARM had adopted ACPI as part of their SystemReady certification. It does work, and not reinventing the wheel is always a wise where feasible, but I think we could absolutely push something better.
I've never seen UEFI in any mainstream Android device.
The problem is... in the x86 world, even the most modern systems around still ship with decades of garbage. INT 10h and VBE, every x86 system still speaks it - either directly in the card, or emulated in BIOS/UEFI compatibility layers, so even a basic "hello world" can get video output, 09h/16h gives you keyboard input, 13h gives you disk I/O, 14h a serial port.
That means that at least the initial bringup for a second-stage bootloader is incredibly easy, less than 40 lines of assembler code [1]. And when you write a tiny operating system, as long as you're content with that basic foundation of 640x480 and text output, it will run on any x86 compatible PC or server.
On anything ARM, that's outright impossible to do and that is a large part of the problem. ARM is power efficient, but it comes at a serious cost. The low level bringup will be handled by the board's ROM, similar to PC BIOS/EFI, but after control is passed to the OS it gets different - all the OS gets is the devicetree stating "here's the memory addresses and interfaces of the hardware in the system", but you still need to write drivers for each and every individual thing from the bottom up, there is no framework for even most basic hardware interactions.
[1] https://gist.github.com/MyCatShoegazer/38dc3ee7db9627ff3a20e...
I have many x86 devices that don't provide a CSM, so no, it's untrue that it will run on any arbitrary x86 device. You can do something similar running entirely inside the UEFI boot services environment - and that'll work just as well on any of the large number of UEFI-based ARM phones.
isn't uefi used for all the modern qcom devices..?
Yes it is. It can be hard to spot if you don’t know it’s there though.
What's 09h/16h ?
09h is keyboard interrupt, the utter basic interface [1] that only gives you scancodes and that's it, 16h is the extended interface [2] that you need to deal with if you want to read/set shift and other special keys [3].
[1] http://www.techhelpmanual.com/106-int_09h__keyboard_interrup...
[2] http://www.techhelpmanual.com/228-int_16h__keyboard_services...
[3] http://www.techhelpmanual.com/58-keyboard_shift_status_flags...
google/android/apple/microsft are fighting for there lives, as there is no reason for there continued existance all the important types of comunications can be hard coded into chips and operate free of any external OS, everything else is two way media, 95% of which can be handled on local networks what big tech is trying to build is something alien to human needs, false promises and enticements, faked up ideals bases on faked up images and outright lies served by monsterous AI data farms that look more and more like the set of "the matrix" the issue with that, is that it is essentialy empty and boring, demanding that the viewer suspends ANY judgement or discernment and further defend this completly impossible and artificial media creation as real. litteral zombies.
In a competitive market, companies are fighting for their lives. The companies you listed are fighting to put up barriers to competition and are succeeding to a great measure.
But have you thought about shareholder value?