After I listen to a podcast host for quite some time, and then read a text message from them, my brain starts reading it in their voice. That definitively happened here. Thanks a lot for making this great show, listened to quite a few episodes by now and had a great time!
When looking back like that, it's mind boggling to realize how far we've come. I sincerely thank everybody who is mainlining their devices, reporting bugs, sending patches, reviewing and testing patches, maintaining packages, updating the wiki, helping out others. Without such a huge and skilled community, we wouldn't have made it this far.
And yes we have a challenging road ahead, as the blog post mentions. But at the same time, I believe the wider Linux Mobile community has reached critical mass of developers and projects. There are so many great projects in this space now (which collaborate quite a lot, Mobian developer kop316's MMS efforts is just one great example). Multiple phones where mainline support has a bright future. Even if a few of these projects or even phones should fail, Mobile Linux can still carry on. Let's find out where we all can carry this effort in 2022 and the years to come!
I'm involved in postmarketOS, one of the Linux phone distributions the article talks about. Also a heavy Qubes OS user and previously user of a certain hardened android project on the nexus 5x while strcat was still involved in it.
I think it's quite simple,
* if you are a more casual user with strong security and privacy needs, then the Linux phone distros are not there yet. Use something else.
* if you are a Linux enthusiast/developer/hacker who is interested in getting away from Google and Apple eco systems, consider getting involved in one of these Linux phone projects and helping out there.
This should not be seen as competition, it's all free and open source software. Android hardening projects focus on delivering a reasonable solution today while Linux phone projects focus on getting something truly independent in the long run.
Is there any indication that Linux is going to catch up to Android/iOS in terms of security?
From my perspective, not only has Linux userspace security barely improved at all over the past few decades (almost all programs run as the user with all of their privileges, no sandboxing, barely any permission/access control to speak of (and yes, I know that there are some projects that aim to fix this, but they're all woefully immature and barely adopted)), but the Unix philosophy itself seems opposed to these security measures. Am I just being overly pessimistic?
I like to think there are some groups thinking about these problems.
Could using something like Fedora Silverblue or OpenSUSE MicroOS (immutable OSes) plus Flatpak (containerized apps) plus SELinux (access controls) get you almost there?
These already exist, but I've seen the push back to the concepts in real life among admins around me, so I wouldn't expect the mass adoption it'd need to stabilize anytime soon. I'm not even including the Internet rage and arguments about these technologies.
I have no idea how Linux phones are different, but if you compare Android to traditional Linux, app sandboxing is huge difference alone. Is anyone implementing it? How are app specific permissions handled? How full e2ee or secure boot is implemented? By default, you have to add alot in top of Linux kernel.
For one, apps in a Linux distro are generally built from source on distro infrastructure, often maintained by a separate person - the distro maintainer - from the original authors of the software. With the source code fully in the open like this, its much harder to slip in user hostile behavior, without anyone noticing and doing something about it.
In comparison on Android or iOS Autors directly upload unauditable binary blobs to an app store that then pushes app updates without almost any user control, often fully automatically. Sandboxing makes more sense in this context as a result.
Unauditable binary blobs will come to Linux phones as well, if they hit the mainstream. It should exists on phones already if the want to say that they are privacy friendly.
There area already many closed source apps such as Spotify client or Slack. Nothing is stopping those apps to read your browser cookies if they want, in case they are installed as regular apps and not sandboxed.
If it makes you feel better: this will always be optional, and we strongly advise against using Android apps on postmarketOS unless there is no alternative for one's use case.
With that being said, I find this an incredible technical achievement by Antoine Fontaine. I've tried to run it on postmarketOS myself, and ran into all kinds of problems with LXC and what not (since Ubuntu used another version than Alpine, at least at that point in time). All I got was this loading screen: https://postmarketos.org/static/img/2018-06/anbox-starting.j...
I think the title of this article could be better, because it's not "yet another" comparison. It's the first one I've seen that goes into all the technical detail of the hardware:
> Comparing the hardware is way more interesting. While a lot of articles just seem to copy the released spec sheet for the devices I'll be comparing the specs as checked by the schematics. The nice thing is that both phones have their schematics downloadable online so things can be fact-checked.
Also there's great photos of the devkits, as always when Martijn Braam publishes something. Well done!
> Added: I've noticed that Alpine seems to have dispensed with ARMv6 architecture support altogether in the upstream. Unfortunately, this cuts off a lot of the oldest AOSP devices from support - devices that used to run quite well with CyanogenMod, and that ought to still be usable in some way, if perhaps not in a truly general-purpose sense given how limited some of them are (512MB RAM/512MB "internal" storage, etc.). Is there any hope of pmOS picking up this support?
In theory it would be possible to keep armv6/armhf around in postmarketOS even if Alpine dropped it. But right now we don't have the resources to do that (and if we had, it would make more sense to help out in Alpine to keep the architecture alive there, if they are interested).
Is there any specific list of things that still has to be done before voice calls are more or less functional for the N900? I looked around the Gitlab but couldn't seem to locate anything. The wiki[0] mentions a requirement of "libcmtspeechdata" but there doesn't seem to be any other information beyond that.
Yes, I had intended on spending this month on the audio codec for nexus 5 but was deterred by the modem not working. I want to split my time between reverse engineering mediatek baseband and getting a pmos daily driver going with the shelli UI. So hope to come back to the audio codec in about a month. Hopefully somebody comes along and does it before me! :p ;)
