You heard it here first folks: systemd is coming to postmarketOS! As a mobile oriented OS, our main goal has always been to work for everyone. From technical folks to casual users. postmarketOS should have all the benefits you expect from a Linux based distribution, such as being free software, respecting your privacy, getting updates until your device physically breaks, respecting your attention and not shoving advertisements in your face. Your phone should be a tool you use, not the other way around. This is of course not an easy task, one of the main blockers we found as we collaborate more closely with KDE and GNOME developers is that they have a hard time with our OpenRC-based stack. In order to get KDE and GNOME working at all, we use a lot of systemd polyfills on top of OpenRC. So while we are technically “not using systemd”, in practice we already do use a large chunk of its components to get KDE and GNOME running, just different versions of those components. While we are very grateful for everybody who works on these polyfills, we must point out that most aren’t a full replacement, and take additional effort to support and maintain. As much as we might want to romanticise the idea of spending 6, 12, 24 months attempting to come up with an even vaguely competitive alternative to systemd, we would quite simply rather be working on making postmarketOS better. ↫ postmarketOS blog This is the sensible choice to make, and I’m glad they made it. It makes no sense for a relatively small project that already has to deal with the difficulties of supporting smartphones to also have to deal with shoehorning the smartphone variants of GNOME and KDE into an init system they’re not at all made for.
I’ve recently been working on putting together a CI system for postmarketOS that will allow us to do proper automated integration testing. That is to say – when someone opens a merge request that modifies our initramfs (for example), we should be able to click a button and some minutes later know that this change doesn’t break any of our important usecases. QEMU absolutely can (and will) get us most of the way there, but at some point we need to just run the same software that we’re running on end user devices. Furthermore, QEMU can’t tell us anything about changes in the kernel that might affect our devices, and manually testing during kernel upgrades, frankly, sucks. So we need a fancy board farm, this is one of those things where folks with the right technical background could build something over the course of a week. But for someone like me it’s full of trial and error and hidden complexity… It’s easy enough to do this with one device – just hack something together, but to be successful we need something reliable and adaptable, that we can adjust to fit our needs in the future, and the wide range of devices we support. Now this is an article you won’t come across very often, as the number of people setting up something like this who can actually talk openly about it – someone doing this for a closed company probably can’t – is probably quite small. A great read.
We talked about postmarketOS back in late May, and this weekend the project published a summary of all the work they've done over the past 100 days.
What you see here is only the tip of the iceberg. So much work has gone into fixing bugs, and little improvements, that it would be ridiculous to go through the effort and list them all. The community has grown so fast in such a short time and we have people with all kinds of skills on board, ranging from Linux experts to kernel hackers to people who reverse engineer bootloaders (hi @McBitter!). We collaborate with people from other projects as well, such as @pavelmachek, who is close to using his N900 as a daily driver with his own distribution, recently just reached out to us.
So if you read through the whole post, you are probably interested in what we do. Consider contributing to the project, the entry barrier is really low. pmbootstrap automates everything for you and we are more than happy to help you through any issues you encounter in the chat. There are also a lot of opportunities to help with development, so there's plenty to do. And plenty of fun to have.
That's a lot of work for just 100 days.
It is 2017. Pick an average PC from 2007 and install a minimal GNU/Linux based operating system. You will be able to do basic computing tasks (eg. surfing the web, reading E-Mails, listening to music, chatting) just like on an expensive modern PC. You will even get security updates, so your old computer is protected, just like as a new one.
postmarketOS (I love the name) aims to do the same for smartphones. A small Linux distribution with a phone interface, designed to be easy to update and maintain to solve the problems Android poses in this area. The project is in its infancy, so it needs a lot of help to further realise its vision.
This is a great idea, and it could breathe life into devices not even LineageOS can keep alive.
Linux hardware projects are made or broken by their community support. PINE64 has made some brilliant moves to build up a mobile Linux community, and has also made some major mistakes. This is my view on how PINE64 made the PinePhone a success, and then broke that again through their treatment of the community. I want to start by pointing out that this is me leaving PINE64 and not the projects I’m involved in like postmarketOS. This is just a sad story. I hope some of the problems can be mended in time.
On the right you can see photos of a Coolpad Modena 2, which was built around MediaTek's MT6735P SoC (System on a chip). In case you are wondering why we're not showing a picture with postmarketOS running on it: we can't! This is because the vendor decided to ship it with a closed down bootloader, which prevents users from running custom kernels.
The postmarketOS team details how they are cracking open the bootloader and the cellular modem firmware on MediaTek-based devices.
