ollieparanoid

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!

Thanks for this post, Drew!

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.

Higher is better.

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...

Why does Hacker News auto-capitalize the first letter? It's "postmarketOS" with a lowercase p, just like blink-182.

Related: >180 comments in /r/linux:

https://www.reddit.com/r/linux/comments/eh3o41/state_of_linu...

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?

Alpine has support for armv6, it is called "armhf" in the arch list here: https://pkgs.alpinelinux.org/packages

There was some discussion if support for it should be removed, but no decision had been made: https://lists.alpinelinux.org/alpine-devel/6569.html

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).

From what I know, one person planned to look into it, but not much has happened since then.

Time flies by, right? Here's your Google Glass pull request from November 2017 with photos and everything: https://github.com/postmarketOS/pmbootstrap/pull/957

(I just had to dig it up to see what you mean with "nearly two years", but given that this two years post is late by a month, and you started your porting work before making that pull request, I can see why you would write that now :) )

It would be very feasible, as long as you know where the kernel sources are (and since there is a Fedora build for it, this should not be a problem). Just follow the porting guide and it will show up as new device in pmbootstrap: https://wiki.postmarketos.org/wiki/Porting_to_a_new_device

Regarding touch-friendlieness: users can also pick user interfaces that are not optimized for touch input during the installation, such as xfce4, mate, i3wm.

Thank you for the kind words.

Phone calls do not work yet, and since we get asked about this all the time, it is in the header of the homepage now - on every page.

> Is there a reference phone that I can be sure will work?

We have two featured devices on the homepage, the Google (LG) Nexus 5 and the Nokia N900. But even for those two we can't guarantee that they are always working, in fact with the Nexus 5 we have quite a lot of breakage lately with one of the reasons being a mesa update that broke the freedreno driver. For the PinePhone devkit we started publishing reference images, which you can expect to not have major issues such as not being able to boot (as mentioned in the blog post).

EDIT: and of course: contributions welcome! if you are passionate about getting phone calls working with let's say the N900 on postmarketOS and have some time to spare, and you are not afraid of learning something new and having a lot of fun in the process, then have at it. Especially with the N900, there is a lot of groundwork available to build upon.

Then we have a match: postmarketOS is the type of project that happily accepts code contributions ;)

Here is the big overview link of all sorts of things where people can contribute to: https://wiki.postmarketos.org/wiki/Contributing

I suggest to familiarize yourself with the project first. That is, play around with it in qemu, flash it to a device if you have one or start your own port (porting is quite feasible, as one can see from the steadily increasing count of booting devices). Then work on what interests you most, and if you need some inspiration, take a look at the gitlab issues that are tagged with "help wanted". (Some are also tagged with "easy", which is obviously a good start.)

> something as prone-to-broken as Alpine

How do you come to that conclusion? Sure, Alpine's edge repository has breakage, but so does Debian sid.

> I’ve got an old Sprint Samsung Epic 4G slider (WiMAX, the old 4G), that would love to be a little mobile terminal...might be a little too dated though...

Give it a try then, here's the step-by-step porting guide: https://wiki.postmarketos.org/wiki/Porting_to_a_new_device

> What is the best way to help the project?

See https://wiki.postmarketos.org/wiki/Contributing

> Anyway, this is a fantastic project and I’m eager to contribute!

Happy to read that \o/

To anyone who would like to see sr.ht grow, please note that Drew DeVault is running it on donations. He chose to go work full time on free software with these donations:

> I need to clarify that despite choosing to work full-time on these projects, my income is going to be negative for a while. I have enough savings and income now that I feel comfortable making the leap, and I plan on working my ass off before my runway ends to earn the additional subscriptions to sr.ht and donations to fosspay et al that will make this decision sustainable in the long term.

https://drewdevault.com/2019/01/15/Im-doing-FOSS-full-time.h...

> I learned 600 new things from this :)

This made me smile, thank you :D

We are addressing the mainline issue, a few devices actually run closely to the mainline kernel in postmarketOS. See our previous big update post for details:

https://postmarketos.org/blog/2018/06/09/one-year/#mainline-...

Thanks! :)

@justicz: that's one clever hack, thanks for explaining in detail how it works!

In case somebody is wondering about Alpine Linux based postmarketOS, this is what I wrote on /r/linux regarding this issue:

postmarketOS is directly using Alpine's apk-tools package from their repositories, so a simple "apk upgrade" will install the latest apk version where this is fixed.

Regarding the pmbootstrap tool we are using for development to set up Alpine Linux chroots, just update to the latest git version with git pull as usually, and it will make sure that the apk version is installed where this is fixed before you can use any of the chroots. Pulling from git may seem strange, but we do not have a stable release yet for pmbootstrap, so this is the normal way to update the code anyway. We're getting closer to a stable release of pmbootstrap though.

The way chriswwweb quotes the article is leaving out important parts. It puts emphasis on the "rate limited API" wording, as if that was the part that matters.

Let's take a look at what's missing:

> But independent of that, GitHub has always had a vendor lock-in with the user's issues and pull requests hidden behind a rate limited API instead of a proper export feature. And even if you managed to export it through that API, you can not host your own GitHub instance and modify it as you like because there is not even a partially open source version of it.

With gitlab, we have one API call to request the entire export, and another one to download it. Whereas with GitHub we need a script that queries the API for all kinds of information we would like to extract. Whenever GitHub changes their API, it needs to be adjusted. And there aren't many projects out there that do this. Besides running a full gitlab instance, the best way seems to be the "github-backup" project [1], and it can not keep up with GitHub's changes:

> Notes added to commits and lines of code don't get backed up yet. There is only recently API support for this.

But the part that really matters is that you can not run your own GitHub instance after you exported all the data with the API and your preferred script.

With the tools available today, the next best thing for us to switching from GitHub to gitlab and using gitlab's export functionality would be running a local gitlab instance that does the GitHub import once a week, and using that as fallback. But if you are willing to do that, then you might as well switch to gitlab completely, just like we did it.

[1]: https://github-backup.branchable.com/README/

In the software sense, sustainable software is software that can be maintained. That means in practice not to have thousands of forks of the same piece of software (like it is done with the Linux kernel in Android). Instead, sharing as much of the same codebase and binary packages as possible across all devices just like it's done in a typical Linux distribution.

We would not even need the mainline kernel to decouple images from particular hardware. In postmarketOS we only have a hand full of device specific packages (ideally only one per device), and one of them is the downstream kernel for non-mainlined devices. All other binary packages can be shared between all devices of the same CPU architecture (in Alpine terms usually "armhf" or "aarch64" for mobile phones and tablets). Just like Linux distributions do it.

The big benefit of the mainline kernel is, that it is the only way to get all the (security) fixes. Greg Kroah-Hartman (Linux kernel who maintains the stable releases) wrote in Februrary:

> As proof of this, I demoed at the Kernel Recipes talk referenced above how trivial it was to crash all of the latest flagship Android phones on the market with a tiny userspace program. The fix for this issue was released 6 months prior in the LTS kernel that the devices were based on, however none of the devices had upgraded or fixed their kernels for this problem. As of this writing (5 months later) only two devices have fixed their kernel and are now not vulnerable to that specific bug.

Source: http://kroah.com/log/blog/2018/02/05/linux-kernel-release-mo...

In case you should have time at some point, there is already a proof of concept with LVM made by drebrez. It is basically working after the installation, but all the use cases that are not straight forward (such as re-installing postmarketOS, what happens to the LVM partitions then?) need to be sorted out before this can be integrated into the master branch.

https://github.com/postmarketOS/pmbootstrap/issues/60

We looked into that as well, and besides missing restore functionality, the problem is that it needs to access GitHub's rate limited API to crawl through one issue after another. In gitlab there is one API call to prepare a full backup, and another one to download it. At least that's what the docs say, we have not tried it out yet.

https://docs.gitlab.com/ee/api/project_import_export.html https://docs.gitlab.com/ee/user/project/settings/import_expo...

Username checks out ;)

But seriously: I can only imagine how many hours each individual has put in writing all these messages on github. Some pull requests and issues read like full blog posts, and oftentimes we reference them in the source code. So it would really be a shame if they got lost.

People are giving so much of their data into third party hands these days without ever thinking about it. We want to be in control of our own data, and while hosting a gitlab instance by ourselves is not feasible for us at this point, having a good backup strategy would already be a big improvement in that direction.

For people curious about all the GitHub links: we are probably switching to gitlab soon. This has been in discussion since October and recent events with Microsoft tipped the scales for us. Besides the issue of trusting Microsoft or not, GitHub does not have a convenient way to backup the issues and pull request descriptions and all the comments.

Full title (HN has a limit of 80 characters):

> postmarketOS Low-Level: Tiny Steps Towards Liberating Bootloaders and Cellular Modem Firmware of MediaTek Phones

Unfortunately we couldn't reproduce it with Firefox 58. If this still happens, please reply here:

https://github.com/postmarketOS/postmarketos.org/issues/48