The year of Linux On Desktop^WMobile [video]
media.ccc.de
media.ccc.de
One change I've noticed: when waiting for things in public, I don't reach for the phone, as I need to preserve battery for the essential functions--as a means of contact :)
Edit: The video is an /okay/ overview of the current state of some things for a Linux-familiar audience. A more compelling thing would be to step through the distros on this multiboot image [0] and show what works and what doesn't work. I think it's really understated how much choice one gets when using a Linux phone. That said, Gnome and KDE are pretty darn functional for the basic stuff these days. Definitely more than a modern feature phone [1], which is plenty for many people.
I know some of the effort is just inadequate driver support - the various modes can't be turned on properly because they're locked behind proprietary blobs which need to be reverse engineered.
But is their something else? What's the pathology that leads to issues in software?
Power saving is all about racing towards that sweet idle state where every chip is clocked down and nothing radiates.
Which means that good power saving requires full vetting of every process on the system and making sure they all cooperate or, at least, are forced to sleep.
Android needed years to get into that state and developers/hackers are still sour about the restrictions it puts on them to keep battery life in check.
True. In my experience, many desktop applications do not care about minimizing idle cycles or network activity. So you end up with your radios always active, or some persistent CPU activity. For example, if one were to use Element Desktop, Signal Desktop and Discord simultaneously on PPP (all electron apps), we're looking at ~20% CPU utilization, idle!
Mobile Linux will get there eventually!
For reference, macOS introduced some APIs intended to improve power management around 2016 when the fanless usb-c MacBook Air came out.
I think this sort of thing is probably more effective than many believe at helping curb lackadaisical attitudes towards resource consumption among devs, with how it turns users into squeaky wheels.
I think Gnome has been taking starting steps - around Gnome 43/44 IIRC it started listing 'background apps' in the upper right pop menu.
Regarding the battery life: This is a thing on the PinePhone, even more on the PinePhone Pro and (to a lesser degree) the Librem 5. These days I carry a Librem 5 (PureOS) and a OnePlus 6 (postmarketOS), the battery angst does not really apply to the One Plus 6, it easily lasts a day unless something goes terribly wrong. The main reason to do so is that I like to listen to way more podcasts than current (and likely also future) Librem 5 battery life allows.
The desired end state of the world is one where is a well developed and mass-usable "third option" besides the duopoly. There should be a well identifiable app store where vital apps that one cannot not use (public sector, banking, medical etc) can be available, ideally as open source.
There are clearly major obstacles on the hardware side due to the cartel nature of mass mobile production and distribution but having a diffuse vision on the software side doesn't help.
The experience with linux desktop suggests that remaining niche and techie oriented is not fatal. The FOSS model has long term resilience. But the stakes are those days so high that a FOSS mobile in any shape or form that can break into the mass market would literally change the world.
The PinePhone is a Linux phone. It's a really lovable device, even if it still has a lot of big flaws.
That’s just the additional userspace bits installed by vendors. The core itself, e.g. GrapheneOS is orders of magnitude more secure than any “traditional Linux” desktop (which is a shame that security is so low priority), and has zero privacy violations, even if you do install play services it will be sandboxed properly.
PinePhone is a Linux toy (I have one), it is absolutely unusable as a daily driver and this stance is what puts back linux adoption by decades.
Let’s build on Android instead of starting from scratch.
Wake me up when any phone like this will run mainline Linux.
It's much easier to regulate the heavily entrenched duopoly at this point, like how EU is trying to do, than somehow get a third player on the market, and convince people and devs to jump on board off Android and iOS. That's just not gonna happen.
Even Microsoft was forced to throw in the towel and exit the mobile market and Windows Lumia phones were actually great, so there just is no space on the market for a third player that comes in so late in the game, to gain any sizable market share, that would convince users and devs to switch and allow for a sustainable business.
It doesn't.
A semi-niche device that is also a reliable "Don't need to upgrade hardware for a decade" option definitely has its place in the market, it just won't ever exceed 5% of the market... which would place it exactly where Linux desktop is.
Why do we keep acting like we need more than that?
A phone that won't be unusable due to vendor refusal to upgrade is a big thing for many users isn't it? Given widespread sentiments snd the fact most don't need to play high spec games, I could actually see it potentially exceeding Linux desktop share... but that presumes we don't see hardware fracture that destroys any market potential, which is what I've seen with the few projects for Linux phones - too many dogs eating each others lunches.
It won't even reach 5% of the market, when it will cost more than a mass produced cheapo Android device, be uglier, have less battery life, and take worse photos along with not being mainstream available in shops.
FOSS phones already exist, and nobody is buying them other than Linux youtube reviewers (and they aren't daily driving them either), because they cost as much as half-decent phones, while being a lot worse and not supporting the major apps that people use to communicate with normies (what people mostly use their phones for).
The amount of consumers who value a FOSS phone over everything else is a lot less than 5% of the market. It's an extremely niche market.
Ecosystem fracture and uncertainty of LTS are _The_ reasons I don't have a Foss phone. Full stop.
A coordinated drive behind a few hardware designs and an independent central org (think GNU/FSF) that effectively guarantees at least one OS option exists for the device lifetime are the keys to the goal.
Having that allows others to build thier variants.
We can't have a Foss phone built using phones which are explicitly built for a specific OS (android) and without having the drivers for components open source (to ensure anyone can patch it etc).
And look at the drive to "dumb" phones currently occurring specifically because people are tired of the "this device doesn't support the current version of android" bs... there are far more people in the potential customer pool than ever existed with PCs (where you have historically been able to upgrade for a decade+ before hardware was simply unable to support the software).
> It won't even reach 5% of the market, when it will cost more than a mass produced cheapo Android device
It costs similarly.
> along with not being mainstream available in shops.
This is a real problem delaying Linux adoption on laptops. I wonder why it's the case for those.
There is a significant possibility to do this with Android because nearly the entire platform actually is open source. What you need is for someone to provide an alternate implementation for the Google-proprietary bits. Which isn't trivial -- it's a lot of work -- but it's at least feasible given some dedication.
What you really need from laws is to get rid of the ones that prevent this from happening, e.g. anti-circumvention laws that prohibit a competitor from achieving compatibility by bypassing remote attestation. Because as long as those laws are still on the books, you can't build a compatible system, which is the first foothold you need in a market with a network effect.
I have a feeling you are misunderstanding remote attestation. Unless you are suggesting an Android competitor should harvest the keys from Play certified android phones and inject them into their own phones. Remote attestation does not affect the compatibility of software running on the system. It affects the ability of a third party server from being able to tell if your phone is running software the server trusts. If an app chooses to support only Play certified devices you will need to convince them that is worth supporting your phones too and you may need to provide your own remote attestation API. Perhaps support can be made easier if there was an intermediate API that wrapped a bunch of other remote attestation APIs and made it easier for apps to decide which they trust as opposed to needing to spend extra engineering time in adding support.
In other words, it affects the compatibility of software running on the system, because you can't get software that runs on their system to run on your system, because the third party server has been deputized as a monopoly enforcement agent.
> If an app chooses to support only Play certified devices you will need to convince them that is worth supporting your phones too and you may need to provide your own remote attestation API.
You can provide the exact same API, but if it doesn't sign the same code it won't be accepted until you have market share, which you can't get when your phone can't run people's apps. You have to be able to make it run the existing apps, as they are, without modification.
> Unless you are suggesting an Android competitor should harvest the keys from Play certified android phones and inject them into their own phones.
That is exactly what I am suggesting. Or find and publish exploits that allow users to extract the keys from their own devices and install alternate systems on them or port them to other systems.
If this anti-competitive edifice is not to be banned outright then at a minimum, maintaining it should have no support from the state.
Any app that targets AOSP will be compatible.
>because you can't get software that runs on their system to run on your system
Server side code is completely separate from an Android app. It would never run on your system.
>but if it doesn't sign the same code it won't be accepted until you have market share, which you can't get when your phone can't run people's apps.
Then bootstrap this process with as many apps as you can afford to work with. As you grow your platform you can onboard more apps and you won't have to pay as much money to get them to support your OS.
>That is exactly what I am suggesting.
Promoting breaking device security is a shady business practice and if found out the keys would be blacklisted.
You can only get keys to put in your device to do the attestation from Google, who then imposes restrictions on what your device can do.
> Server side code is completely separate from an Android app. It would never run on your system.
You obviously need the apps that run on your system to be able to access the server for that app.
> Then bootstrap this process with as many apps as you can afford to work with. As you grow your platform you can onboard more apps and you won't have to pay as much money to get them to support your OS.
There are no examples of this working. Microsoft even tried it and it did not work.
It's also clearly unavailable to Mozilla or Debian or anyone else without an existing monopoly to extract rents from in order to operate at a loss for an extended period of time.
> Promoting breaking device security is a shady business practice and if found out the keys would be blacklisted.
You don't tell them which keys they are. And if they blacklist entire device models then they'll hit lots of their own customers and make it hard for apps to rely on the attestation, which is great.
The Play integrity API is not part of AOSP. Remote attestation does restrict your device from doing anything. A new attestation API can be made if you want to offer remote attestation to apps.
>There are no examples of this working.
Amazon successfully did it.
>It's also clearly unavailable to Mozilla or Debian or anyone else without an existing monopoly to extract rents from in order to operate at a loss for an extended period of time.
It just means that it will take longer if a there is trouble in finding investors. The standard 30% cut can be used to make it sustainable to support the operating system and fund getting apps into the store.
>they'll hit lots of their own customers and make it hard for apps to rely on the attestation, which is great.
It isn't great because it sets back the security of the industry back a couple years each time an exploit allowing this is found.
I guess you wanted to write "does not" here, but it's the opposite - it obviously restricts the new device from being practically useful, but what's important is that this is done not because the device has no capability to run those apps, but because it was not "whitelisted" by the app vendor, so a technically superior device might fail on the market just because of current players artificially blocking it.
This is an anticompetitive practice, where you need to get "permission" to be able to run the app. And no matter how "fair" that sounds theoretically, practically this should (and hopefully will) be a subject of some antitrust ligitation.
> It isn't great because it sets back the security of the industry
Notice how users aren't defending that "security of the industry". Isn't it strange?
Technically superior products can fail. A users choice on what to buy isn't just what in the most superior product. Apps not trusting a phone is a major drawback of a phone. It's not anticompetitive that apps don't automatically trust every new phone that comes into existence.
>Notice how users aren't defending that "security of the industry". Isn't it strange?
Because users on average do not care about security until its too late and damage has already happened. They don't care about how to stop spam, they just get angry when they get spammed.
Creating a mechanism that enables such things to happen obviously is. Google knows well that:
> Apps not trusting a phone is a major drawback of a phone.
and Google having the dominant position created and now controls that "trust", and actively abuses it to force its unremovable spyware onto users' devices. And when the user dares to remove them, then poof - they're not " trusted" anymore.
It prevents you from using apps that require it.
> A new attestation API can be made if you want to offer remote attestation to apps.
In other words, you can't use the existing apps.
> Amazon successfully did it
The Amazon Fire phone was discontinued after only a year.
> It just means that it will take longer if a there is trouble in finding investors.
What investors? The purpose of Debian is not to make money, it's to make operating system.
And if "take longer" means after we're all dead, that's not sufficient.
> The standard 30% cut can be used to make it sustainable to support the operating system and fund getting apps into the store.
30% of nothing is nothing.
Moreover, the 30% is a monopoly rent -- they only get away with it because they're the only viable store for that platform. Who is going to pay 30% in a competitive market?
> It isn't great because it sets back the security of the industry back a couple years each time an exploit allowing this is found.
They find new ones every year. :)
Then don't use that app. The app won't work on a different phone Linux distro either.
>The Amazon Fire phone was discontinued after only a year.
The Amazon app store still exists. Windows even partenered with Amazon to bring their app store to Windows.
>What investors? The purpose of Debian is not to make money, it's to make operating system.
Making a successful operating system is much easier if you have funding.
>30% of nothing is nothing.
Even the Ubuntu software store was able to find people willing to buy software off of it.
>Moreover, the 30% is a monopoly rent -- they only get away with it because they're the only viable store for that platform. Who is going to pay 30% in a competitive market?
That is part of the business strategy that will need to be figured out.
>They find new ones every year. :)
Yes, but it is something we can get better at preventing and detecting to the point where it stops happening every year.
The only place where RA should be allowed is purely business oriented embedded devices like bank ATMs that actually need the security guarantees.
The only thing it's good for is anti-competitive prohibitions on interoperability, which only works if the law makes it illegal for competitors to extract the keys and use them.
I was more thinking about insider attacks aka maintenance people (or thieves with a good drill) inserting a malware-loaded USB stick that instructs the ATM to dump out money [1]. RA could be used as an additional safeguard here.
[1] https://www.hackread.com/security-expert-hacks-atm-by-drilli...
Not only that, what is remote attestation supposed to do against a purely local attack like that? The attacker doesn't have to prove anything to the server. The local machine they've compromised is the one that directly controls dispensing the cash.
It's easier to hack into the computer using an exposed USB port than to drill up the safe - its control electronics are usually well defended which means you have to spend way more time which may raise suspicion.
> Not only that, what is remote attestation supposed to do against a purely local attack like that? The attacker doesn't have to prove anything to the server.
RA could be used to verify what exactly is running on the computer, if done correctly.
Security isn't binary. Attestation makes the attack more expensive to carry out and less likely to happen. Businesses want to minimize risk. They understand that risk always will exist.
There are security models that actually work. Alice and Bob want to communicate over a non-private channel, Alice encrypts her data with a key she shares with Bob, Eve has to do an infeasible amount of computation to decipher it because she doesn't have the key. Alice wants to encrypt her hard drive so when she turns off her computer no one who steals it can read it because they don't have the key which exists only in her own head.
Attestation is when Eve has Alice locked in her basement under 24 hour surveillance and can go at her with battery leads and MRI scans forever until she gives up the key. It gets broken again and again, because you're trying to prevent Eve from getting a key out of something she has in her possession, and "Eve" is everyone in the world because phones are commercially available to the public. The chances of that being broken are so high that you can't rely on it not happening for anything important.
The chances of AES being broken in the next couple of years, or at all, aren't nearly as high. Conversely, if you need to trust a remote device, you do it by providing physical security. This is why banks have vaults and guards and ATMs are encased in hardened steel and bolted to the ground and contain surveillance cameras with remote recordings. This is why the bank's servers, which actually are trusted by all the ATMs to identify who should be able to withdraw cash, are kept under 24 hour guard.
The amount remote attestation adds to these things is negligible because of the high probability of it being bypassed. It's snake oil. The only thing it does is trigger bad laws that prohibit honest competitors from bypassing it for benevolent reasons. Because the technology doesn't work, and the law only works against people who aren't willing to break the law.
Which is why such laws are pure negative. In the case were someone is trying to commit fraud or some other crime, there is already a law against that and a redundant law against bypassing attestation adds nothing. So all a law against bypassing attestation can do is prohibit legitimate otherwise-lawful activity.
Those aren't comparable. One is a mechanism for protecting private keys and one is an algorithm that uses private keys.
As security of hardware matures we will be able to have implementations that successfully protect private keys without any software vulnerabilities.
The question is how can the foss community use its limited resources to facilitate a "third way". There is some precedent in this respect from the fediverse/mastodon experience. The easy availability of a near substitute removes the TINA excuse from various stakeholders and policy makers.
Its neither a concrete path nor a certainty. My comment was simply that people should not create further obstacles by pursuing self-indulgent agendas
It can't, you and I already answered that it's impossible to enter the mobile market withtout any government intervention to break up the existing duopoly.
Even the most hardcore Linux/FOSS fans don't daily drive FOSS Linux phones because they suck big time and have quirks impossible to live with, so mostly use iPhone or degoogled Androids, let alone have mainstream average users use them.
This is plain false. Sent from my Librem 5, which I daily drive. You can find more people like me in HN comments of other related submissions.
But what does this prove? The market share isn't there for these devices. Even the vast majority of hardcore Linux fans daily drive iPhones or Androids and only use those toys for tinkering. You being a Librem 5 user doesn't move the needle on how niche these devices are in the wild.
How many users other than you use FOSS phones? Is ist a sizable market or are we talking about a rounding error part of niche hobby?
Just judging by the comments here you seem to be the only user on HN with one, and HN is already a super niche community of FOSS enthusiasts, but even here most use iOS devices because people like using stuff that already works with the mainstream apps.
Are you really so inattentive that you didn't see this https://news.ycombinator.com/item?id=37042238? And you could find many more on HN if you actually wanted: https://news.ycombinator.com/item?id=35850098, https://news.ycombinator.com/item?id=29401950, https://news.ycombinator.com/item?id=24959506, https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu....
Also a lot of people are waiting when these phones become better daily drivers: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
> Is ist a sizable market
Why does it matter? Every breakthrough starts with a niche community (unless it comes from large corporations).
Genode does now run on PinePhone[0], with a much more suitable system architecture.
The author also gives unfair cons to Android, incorrectly claims the location API requires a separate API such as Play Services, and claimed that depending on Google is bad because new major versions of Android are developed in private before they are released to the public and that they may make an attestation API for Android (they already have).
- "Linux" is bad because Android is Linux.
- "GNU/Linux" doesn't quite work because 1. ChromeOS is GNU/Linux and 2. Alpine isn't.
- "mainline Linux" is a thing we want, but still separate - I'd take Droidian with a hacked-up vendor kernel over a Pixel running an official Android image on mainline Linux any day.
The best I've been able to come up with is something like "user-controlled Linux" or "community OS" or even just "not Android", but I'd really prefer a better term.
If you are being precise, Android is not Linux (and neither is Debian for that matter). It is an operating system that uses the Linux kernel.
> The best I've been able to come up with is something like "user-controlled Linux" or "community OS" or even just "not Android", but I'd really prefer a better term.
Here is my proposal, we continue to call operating systems like those "Linux" and call operating systems like Android and ChromeOS "Operating systems that use the Linux kernel".
No reason to give the common and useful definition an awkward name like "Community OS" just to allow the abberant cases to continue to reside within the "Linux" definition.
https://developer.android.com/ndk/guides/stable_apis
Applications deployed via Play Store might crash and burn by ignoring this fact, which is a reason why termux nowadays must be sideloaded.
When people use the word Linux they have a specific definition in mind which may or may not match the definition you have in mind. Some (you included I assume) think that the definition should include Android and some (like myself) think that it shouldn't include Android.
People will continue to use the definition they find to be the most useful, and the less useful definitions will eventually become niche. For me, defining Android (or ChromeOS) as Linux is not useful since it does not live up to any of the properties that make Linux useful to me. For me, calling Android "Linux" is like calling a table a stool. It may technically be appropriate (I can technically sit on it, it has no back support, etc.) but not useful (for example, it would be awkward to place a table in front of a dining table for use as a stool).
For another such example you can look at how the game genre Roguelike transformed from meaning "Similar to the game Rogue" to "Having procedural content generation" and how RPG means "You can level up" (though it feels like in recent years the term is starting to morph into "Has a story we think is worth following").
Mainline Linux has a very specific meaning. It refers to Linus Torvald's repository of the Linux kernel. Android using mainline Linux on a mobile phone is in scope for the talk.
>They are much more blackbox and user hostile than even laptops and desktops today.
They are much more user friendly than most Linux distros for desktop/pc. Most users and developers will never understand how their phone's OS works and that is okay. Abstractions are a very powerful concept in software engineering.
If you think there are user hostile features in Android, it will be much easier to make an Android fork that removes them instead of trying to recreate a whole entire mobile OS and software stack.
A computer is a computer is a computer. If there weren't artificially constructed restrictions (and boy do they work hard to create these restrictions: millions of lines of code, developing encryption algorithms, etc) anything could run on anything (if the hardware exists, and in this light phones and laptops have all the required hardware).
iOS is more “user friendly” than android but it’s absolutely hostile to anyone who wants control of their phone. Android is the same with only slight improvements.
Because the OS typically has device specific drivers that are not included in the OS for another phone.
>Even something as basic as a root shell is hard/impossible to have on so many models
What it may seem basic to you is poor design and poor security. The android way is for the OS to expose APIs that to apps to do privileged operations. There is also typically a permission required to use such an API. There shouldn't be a need for the user to use a root shell.
>Why phone model and os are so tightly tied together?
Because the OS is one of the distinguishing features of a phone. It's one of the ways Android phones compete against each other.
An os is just a piece of software. There is nothing magical about general oses running on general purpose computers where an OS specifically magically depends on one model of computer. Desktop and server linux distros also compete among each other, I never heard a thing like Debian 12 being tied to one specific model of laptop etc
Because lets be honest, if people can upgrade and install any software they want, that reduces incentive for them to buy a new phone every 3 years. And thats the real reason, the crux of the matter. Well obviously not just profit, the power and control over peoples computers also counts for much more than mere profit.
If I don't have root shell then I don't own the device. Simply. Its a useless brick and toy.
As I said, its not Android the piece of software rather the manufacturers who hate users. They don't provide drivers generically either as blobs or sources. Why is it again, when you have two computers and you can generally install and update anything on one and can't do shit on the other? Not providing drivers is one thing, that falls under passive acts, another thing is active malice where even rooting or providing you the bootloader is often cryptographically locked down.
Purism does this, though not to a specific device. For the products they sell they have their own custom fork of Debian.
>if people can upgrade and install any software they want, that reduces incentive for them to buy a new phone every 3 years
You are going to be limited by the support of the BSP even if you can install any software you want. You will end up stuck on old software which may not be properly maintained especially if the OEM has moved on to supporting newer products.
>If phones were like laptops or desktops, you'd just install the Android 13 on your phone when Android 12 was outdated etc.
Google has been making efforts to make it easier to upgrades parts of Android without involving the OEM. Later versions of Android may not me compatible with older hardware as minimum specs change and architectures are dropped. For phones with unlocked bootloaders you can flash Android 13 on your phone if someone creates a compatible version of it.
>If I don't have root shell then I don't own the device. Simply. Its a useless brick and toy.
UNIX is not the only way operating systems can be designed. Considering everything that isn't UNIX as being useless is an ignorant mindset.
>As I said, its not Android the piece of software rather the manufacturers who hate users
Then what's the point of this argument if you agree AOSP is a fine way to have an OS with Linux on a phone.
>They don't provide drivers generically either as blobs or sources.
This same issue would exist if you wanted to use Linux with a different userspace.
>Why is it again, when you have two computers and you can generally install and update anything on one and can't do shit on the other?
I don't understand what you are getting at.
>is active malice where even rooting or providing you the bootloader is often cryptographically locked down.
The bootloader being locked down isn't malicious considering it lets the system prove that malware hasn't compromised the boot process. In computing if malware is running first there isn't much the system can do the detect it's existence. It will have the upper hand in the cat and mouse game. If a normal person buys a ACME brand phone, but a malicious actor unlocked the bootloader and installed malware into the OS, that user will never realize they were pwned until they encounter software that is a step ahead in the cat and mouse game and the malware isn't able to hide its existence. A user having root is also problematic because it compromises Androids security model. If a banking app saves an access taken to your phone it is relying on the security of Android that no one is able to steal this taken. If the a user is able to get root they could bypass this and steal the token and commit fraud.
It's actually the opposite - it lets the system prove that the unwanted spyware by Google has compromised it.
> If a normal person buys a ACME brand phone, but a malicious actor unlocked the bootloader and installed malware into the OS, that user will never realize they were pwned until they encounter software that is a step ahead in the cat and mouse game and the malware isn't able to hide its existence.
Well this just shows how far has Google gone with its bundled spyware. People use unlocked devices because even being less secure is better than not being in control and having spyware installed on your phone...
> A user having root is also problematic because it compromises Androids security model. > If a banking app saves an access taken to your phone it is relying on the security of Android that no one is able to steal this taken. If the a user is able to get root they could bypass this and steal the token and commit fraud.
Oh what a beautiful example. Since my bank allows me to use the website and me being able to see all their cookies is not a problem for me, I think this example is kinda impractical.
But worry not - I have a different example:
If an adware vendor called Google bundles its spyware into your phone they rely on the security of Android that the user is not able to uninstall this crap. If the a user is able to get root they could uninstall this and then Google would be unhappy.
>You are going to be limited by the support of the BSP even if you can install any software you want. You will end up stuck on old software which may not be properly maintained especially if the OEM has moved on to supporting newer products.
If I am able to install current Debian on a laptop it does not matter if its a 20 year old laptop, I have the newest apps from the repositories and I can build/obtain via other repos newer versions if I want. Its not the OEMs responsibility its the software and distro community's responsibility under the sane system where users control their machine. And being able to install a current OS on that hardware is a matter of having the drivers available either by someone reverse engineering it in case of hostile/dead manufacturer or the manufacturer making it available in a form Linux kernel devs can mainline it or otherwise make it work with their distro for the phone.
>>As I said, its not Android the piece of software rather the manufacturers who hate users
>Then what's the point of this argument if you agree AOSP is a fine way to have an OS with Linux on a phone.
Again I repeat the reason why people want Linux on the phone is so they can own and control the phone. So it does not matter if their choice is Debian or AOSP or anything else, and the practical reality is that this need is 99% unfulfifled in current market.
People are able to use asymmetric key encryption on non-locked down devices alright, so thats total bs. The exact mechanism and os design does not matter the end question is do you control your phone? Can you wipe it and install software of your choice? And since Android is based on a linux kernel, root access is one aspect of having the "master key" to your phone. Its not enough, the full step is not only a root shell but having enough information available to reinstall anything you want on it.
>I don't understand what you are getting at.
Manufacturers at this stage haven't yet been able to strangle general laptops and desktops to the stage of mobile phones yet. So people are still thankfully able to wipe and reflash them, install and upgrade oses as they wish etc.
Are those not exactly correct, then? What's unfair about it?