Watching this, as I've been daily-driving GNU/Linux phones for two years now (first PP then PPP).
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 am curious what fundamentally makes power management so difficult these days.
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?
There's no pathology, it's just really really hard. Any single component not sleeping properly and keeping the CPU, buses or radios active immediately ruins the battery life for everyone.
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.
> 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!
I always wondered what exactly it is that Electron apps are doing to use that much CPU when they're sitting in the background doing nothing, often not even being on screen. For something like chat I guess it could be polling (surely sockets are more popular now?), but it's not uncommon to see this behavior even in completely offline Electron apps. It seems like they're never truly idle.
I don't know, but I hope the efforts to drive application-level power management somehow lead to power management improvements when using gnome on a laptop as well.
For reference, macOS introduced some APIs intended to improve power management around 2016 when the fanless usb-c MacBook Air came out.
On the software side of things, for something like decade now macOS has also surfaced which programs are egregiously power hungry to the user. The most visible way is in the battery menubar item, and in the most extreme cases it'll even show a notification. Similarly Safari tells users when sites are being too voracious.
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.
The power management model in phones is just radically different than desktops. Android can get a lot of battery life by suspending applications and tightly controlling application resource usage.
There should be videos demoing the p-boot-demo image on YouTube, I included some in my Weekly Updates [0] on the topic. At this point, it makes no sense to try the image - it's simply to old, and projects have progressed too much.
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.
Imho the android vs "true linux" debate must resolve soon or act as a millstone against our hopes for a free mobile device.
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.
Android is Linux in a lot of ways that don't really matter (it uses part of the same software stack!) and it's definitely not Linux in all the ways that do matter: it's a tool by surveillance capitalism and state surveillance (more often than not illegal).
It's a device made for consumers and not hackers, and extract as much value as possible from them, correlating purchases with location data etc.
The PinePhone is a Linux phone. It's a really lovable device, even if it still has a lot of big flaws.
> it's a tool by surveillance capitalism and state surveillance
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.
>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.
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.
I think an issue is the presumption that it has to "compete"...
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.
>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.
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'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.
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.
>e.g. anti-circumvention laws that prohibit a competitor from achieving compatibility by bypassing remote attestation
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.
> 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.
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.
>In other words, it affects the compatibility of software running on the system
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.
>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.
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.
> 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.
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?
>so a technically superior device might fail on the market just because of current players artificially blocking it.
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.
> It's not anticompetitive that apps don't automatically trust every new phone that comes into existence.
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.
> The Play integrity API is not part of AOSP. Remote attestation does restrict your device from doing anything.
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.
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.
We should have laws that ban mandatory (i.e. something gets disabled if not present) remote attestation and secure boot for consumer and most business devices and software, period.
The only place where RA should be allowed is purely business oriented embedded devices like bank ATMs that actually need the security guarantees.
In general it should just be smashed into smithereens by a thousand hammers, because it can't be trusted with anything important anyway. Can you imagine what would happen if a bank actually trusted a client device and then somebody broke the attestation? That's not how ATMs work. You make a deposit and the funds are not available the same day, and it's not because their computers are too slow.
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.
> Can you imagine what would happen if a bank actually trusted a client device and then somebody broke the attestation? That's not how ATMs work.
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.
So the thieves have physical access to the ATM, and power tools. Why do they need the computer to do anything? Drill into the thing and supply power to the actuators that spit out the money.
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.
> So the thieves have physical access to the ATM, and power tools. Why do they need the computer to do anything?
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.
>Can you imagine what would happen if a bank actually trusted a client device and then somebody broke the attestation?
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.
Attestation has a minimal effect on risk because the probability of a device being compromised is high and scales with the value of compromising the device. It isn't necessary when the value is low and it isn't sufficient when the value is high. There is no place for it.
Then you might as well give up on all security then if you are going to assume any security will be bypassed. Breaking attestation is not easy to do and increases the cost of a successful attack.
Remote attestation has a track record of being bypassed, unlike e.g. AES. To the point that Intel abandoned SGX in Core processors because it just kept getting broken.
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.
If something has to be regulated as public utility it might as well be a public utility. That this cornered "market" will never produce competition is clear enough. But there has never been a device so intimately coupled with the lives of so many people. Past approaches dont apply to new challenges.
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
>The question is how can the foss community use its limited resources to facilitate a "third way".
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.
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.
You shifted goals. The share is low, but FOSS enthusiasts do use those phones as daily drivers and constantly improve them. This is exactly how many innovations start.
>but FOSS enthusiasts do use those phones as daily drivers and constantly improve them
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.
I don't understand what is not suitable in Linux for you. I am very happy with my Librem 5 running desktop Linux apps, including Firefox with all plugins. It can even work as desktop if you connect a keyboard and screen.
It's a cool project indeed but just don't get your hopes up. It remains a tinkerer's toy, like Linux on the desktop perpetually always being behind, then Linux on the mobile might be worse by an order of magnitude.
It already was the year of the Linux on mobile because of Android. Android already supports the mainline kernel.
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).
This kind of pedantry always appears when people are trying to have a discussion about non-android linux distributions on mobile devices. You know full well what they're talking about when they say "linux" here and it's not "android."
Okay, but Android literally is a Linux distro, or family of distros perhaps. I'm happy to agree that we really need better terminology, but the answer is better terminology, not less precise terminology.
- "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.
The Android ecosystem has had billions and billions of dollars invested into it along with industry buy in. Ignoring it because of some small petty reasons is just a classic case of Linux users wanting to avoid success at all costs.
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").
The description of the talk is "How the quest for mainline Linux on mobile phones is faring"
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.
The point about people wanting to use Linux on pc/phone is ownership of their machines. Do you own 99% of smartphones (Android and Apple) that currently exist? They are much more blackbox and user hostile than even laptops and desktops today.
I own less than 1% of the available phone models that exist, but I don't see how that is relevant.
>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.
Because thats the very point of wanting to use a linux pc or phone, to escape the swamps of user hostile evil garbage.
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).
You forget that some people like general purpose computing. Android and other mobile operating systems (as well as Chrome OS) do have great security, but that comes at the expense of functionality (arbitrary code execution is discouraged, putting things inside apps and strict APIs make scripting and tinkering infeasible) and user control. One of the mentioned in the talk was being able to use the traditional Linux stack and being able to use your smartphone as a general purpose computer (2:22, 4:12). I hope one day there's a solution, but it seems trade offs have to be made to have one or the other.
“User friendly” is not the opposite of “user hostile”. You’re engaging in bad faith.
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.
And its mostly not Android the os itself per se but the phone makers. Ask yourself, why is it that you can't install any os you want on almost all phones? Even something as basic as a root shell is hard/impossible to have on so many models. Why phone model and os are so tightly tied together? Ever heard of say random desktop pc only being able to run specific Windows version or specific Linux version? That, basically, is the root of all problems.
>why is it that you can't install any os you want on almost all phones?
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.
>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.
An OS is just a piece of software there is nothing magic about it. If phones were like laptops or desktops, you'd just install the Android 13 on your phone when Android 12 was outdated etc.
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.
>I never heard a thing like Debian 12 being tied to one specific model of laptop etc
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.
> The bootloader being locked down isn't malicious considering it lets the system prove that malware hasn't compromised the boot process.
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.
The very point is that you can also do what the malicious actor did, just reflash it with a clean image. And if even then the manufacturer has hidden malware code somewhere else, then at that point its moot, you need to find another manufacturer.
>>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 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.
The very point of the bootloader being not locked down means its irrelevant who did what to it in the past, you can wipe and install a clean install of Android (or any other OS) on it. It won't prevent manufacturer from having hidden code and overrides elsewhere of course, but then its the manufacturer at this stage whos hostile, not resellers.
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.
>>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.
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.
If Purism had to do some modifications to get Debian to work on their phone thats not a problem, the problem would be if they make it impossible for others to do the same with another Linux etc ie making it impossible or placing roadblocks to install other oses on their devices.
AOSP generally isn't the problem, as I said, but the question of "is it the year of the Linux phone" the answer is still no, because practically almost all real smartphones available are user hostile and locked down. The very point why people want Linux on the phone is so they can install any os or software they want to install without the manufacturer or google etc placing roadblocks. So my tldr is AOSP could be considered merely an unconventional Linux os but its moot unless you have the "master keys" to your device ie a root shell, unlocked bootloaders etc.
Again not requiring a root shell for daily use is a different topic from taking active steps from letting the "owner" of the hardware from having root.
Not running as root is common sense security, we already don't use root users for daily applications on desktop and server linux, and if you want to harden it further, good. You can harden your own pc as much as you want, you can run each app in its own user, apply SE Linux etc...but you have root access to it and can wipe it whole and install anything else if you want on it. Thats whats missing on phones, and we all know why.
> 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).
Are those not exactly correct, then? What's unfair about it?
It's correct, but it's not unique to AOSP. You are to just replacing Google with a few BDFLs and cliques who will define the direction the OS will go in. Google has done a good job steering Android and has made it very successful, so I personally trust Google's direction over for example the GNOME developers.
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.
[0]: https://xnux.eu/p-boot-demo/
[1]: https://www.kaiostech.com/