6 min

We are fed up with Android's endless forks! Fifty days ago I have announced postmarketOS, a touch-optimized, pre-configured Alpine Linux, which can be installed on smartphones. It avoids Android's bad habit of forking software for every single device (!) entirely by going the other way around and unifying as much as possible: We use regular Linux programs, and try to have only one unique package per device, with ideally one kernel for all devices.

While we already have a solid pmbootstrap program for installation and development, pmOS itself is in an early development stage. Making calls and other basic phone features do not work yet. Nevertheless, a small development community has emerged and we can show off quite a few improvements.

From 2 to 8 "working" devices We have an unusual definition of working as of now (USB networking and graphics output is enough), but even with that in mind I find this progress impressive for a bunch of random people on the Internet, that never worked together on anything. Sorted by the first commit date, we have the following new devices.

non-Android device! It comes with a hardware keyboard, so one can type in the full disk encryption password directly. It uses pali's 4.6 Martijn Braam Nokia N900 ( nokia-rx51 ) The firstdevice! It comes with a hardware keyboard, so one can type in the full disk encryption password directly. It uses pali's 4.6 kernel , which is relatively close to mainline already.

Another 8 WIP devices Check out the devices list for eight more work in progress ports. Usually we managed to compile the kernel source (this always requires patches, because we use a modern GCC ), and most of the time we have even more working.

37 wiki articles All the porting experience was immediately written down as porting guide, troubleshooting, boot process and finding device specific information articles, just to name a few. Dive right in with the new start page and sidebar!

264 git commits / 74 closed issues You would need to read every single commit to learn about all the little improvements we have made (including really easy ones, such as displaying a link to the troubleshooting page on errors). But here are the most interesting ones (no one likes to read about boring bug fixes, right?). Two more complex features are explained further below.

aarch64 target support (#84)

target support (#84) Add ConfigFS based usb network configuration (#148)

Easily include custom packages in the installation with pmbootstrap install --add=vim,gcc (#67)

(#67) Full disk encryption became optional (still enabled by default!) (#104)

Python 3.4 support (for Debian Jessie) (#6)

Sane default IP and subnet (#70)

Simplify heimdall flashing, make it work with i9070 (#144)

Upstreamed to Alpine: Telnet daemon enabled in busybox (aports#1092, 1e64a3b)

Workaround for the red screen bug in Weston packaged #93 (WIP upstream fix: #141)

abuild is the package building program from Alpine Linux, that pmbootstrap wraps around. Just like in most Linux distributions it considers packages up to date, when the package version is equal with the version of the package recipe. This has the side-effect, that package developers must pass --force to rebuild a package if they changed anything, but do not want to increase the version yet.

I have accepted this and didn't even think about it anymore, but then I was confronted with a different view (especially by mmaret): He expected it to work like the classic make build automation program, which means that after modifying one file anywhere in the source tree, it automatically detects which packages are out of date and rebuilds them (and updates them in the relevant chroots) as soon as you execute an action, that depends on that file. Regardless of a version number change.

As I still believe in making pmbootstrap as user friendly as possible (to get more developers, to get more postmarketOS development done in the same time!), I have implemented this principle for all actions now. It is on by default, but can be turned off at the end of pmbootstrap init .

New actions: initfs , flasher export , challenge initfs makes development of the initramfs easier. It allows to build it without running the "lengthy" install action, which would build a full installation image instead. Besides that, this new action can list, add and remove initramfs hooks (e.g. usb shell) and extract/list the initramfs contents (just like lsinitramfs in Debian).

flasher export generates symbolic links to all files, which are generated in the install step (because they aren't that easy to find inside the chroots): The system image file, kernel, initramfs, boot.img file (if the device is fastboot compatible) and others.

challenge is used to verify reproducible builds for #64, more about that in the next post.

More numbers

That's it for today's post. I would like to thank everyone in the alternative open source phone operating system scene, especially everyone working on postmarketOS. It is incredibly motivating to be part of such a community, and to see how everyone is helping everyone, how we all bring this further one tiny step at a time! If I had done all the ports, pull requests, wiki edits from the pmOS community by myself, that would probably have taken a year or so, I'm impressed every time I think about it.

Collaboration across projects is also working, the best example of that would be Bhushan Shah who works on (KDE) Plasma Mobile, Halium and hangs out in the postmarketOS chat talking about the newest Nexus 5 kernel mainlining work he just did every now and then (and this is just the OSS work I know of).

Off-topic shout out to Andrew Mc Swain, who talked to me about a completely unexpected topic regarding pmOS: Marketing. Honestly I thought that this was a euphemism for ripping people off and has no place in the open/free software world. But I stand corrected — as he puts it: "Marketing isn't tricking people into buying sugar water". The following has always made sense to me: Listening to what people need and reaching out to few people who might very likely benefit from knowing this project (without anyone shoving advertisements in their faces, making false promises, or doing something else immoral). Apparently this could be seen as marketing.

I have already learned so much from everyone involved and I'm incredibly excited to see where this project is heading :>