- 1 Is there a list that explains all the technical abbreviations?
- 2 What Linux distribution is postmarketOS based on?
- 3 How often is postmarketOS Stable released?
- 4 Why is postmarketOS based on Alpine Linux?
- 5 Will Android apps be supported?
- 6 Can project Treble help postmarketOS?
- 7 Is dual boot supported?
- 8 Which GUI toolkits are supported?
- 9 Do Flatpak packages, snaps, and AppImages work?
- 10 Any GUI front-end for package management?
- 11 Does postmarketOS have its own binary package repository?
- 12 Which file system is used?
- 13 What are the TODOs and where is the OS heading?
- 14 Are all postmarketOS packages and the kernel built locally when creating an installation image?
- 15 Which USB/Wireless peripherals work?
- 16 Why don't we use firmware files from Android's firmware partition?
Is there a list that explains all the technical abbreviations?
Sure, take a look at the glossary.
What Linux distribution is postmarketOS based on?
It is based on Alpine Linux. Alpine Linux has multiple release channels. Alpine Edge is a rolling release with the latest updates, while Alpine Stable is released every six months from Edge. PostmarketOS has edge and stable channels that track the edge and stable branches of Alpine.
How often is postmarketOS Stable released?
A stable release of Alpine is made approximately every six months. postmarketOS stable tracks the current release of Alpine Stable so it will receive feature updates approximately every six months as well. So far Alpine tends to release at the end of the month in May, June, or July, as well as at the end of November, December or Janurary. As the releases are on no set schedule, we cannot predict when the next stable release will be made. Rather it will be released when it is ready.
Why is postmarketOS based on Alpine Linux?
The biggest upside is that Alpine is small. The base installation is about 5 MB! Only because of that, our development/installation tool
pmbootstrap is able to abstract everything in chroots and therefore keep the development environment the same, no matter which Linux distribution your host runs on.
And if you messed up (or we have a bug), you can simply run
pmbootstrap zap and the chroot will be set up again in seconds. Imagine how long it would take to do the same with Debian (which is a fine distribution for plenty of other use cases).
Another angle on the tininess of Alpine - many older devices don't have much space to spare, so hilariously tiny system images can be quite useful or even required.
Will Android apps be supported?
Currently, our best bet seems to be getting Anbox or Waydroid running on postmarketOS. It's highly recommended to use native Linux applications though, as there are some downsides to Android apps:
- Freedom issues (most are proprietary, or only work together with a proprietary network, some even track you), see F-Droid for FLOSS programs, that respect your freedom.
- Heavy resource usage: With all resources, you will most likely need to run a Android environment next to your regular Linux. So it will use more RAM and CPU compared to native Linux applications.
So at least try to find a native-Linux alternative for your favorite application or ask yourself if you really need it. For app developers, consider using Kirigami UI or similar to develop apps for both mainstream mobile OSes (Android/iOS) as well as natively for Linux distributions.
Can project Treble help postmarketOS?
Google proposed Treble to improve the update situation for Android by having a "vendor implementation" with a stable API, that Android builds upon. The idea is, that you can swap out the Android version easily, because of that API. As postmarketOS developers see it, that is a step in the right direction, but it does not resolve the updates problem completely.
You will still have the "vendor implementation", which is different for every device. It will contain at least the kernel and drivers (kernel/userspace), for which you, as a user, depend on the manufacturer to keep it updated, and which will probably not be mainlined. This means, that after two years or so, when the support runs out, you will still have a device, that does not get updates anymore. Only for a smaller component of the operating system.
Also keep in mind, that this will work for newer Android O phones only. We already have an alarmingly high number of phones, which will never get that improvement. They can be saved from being electronic waste with projects like postmarketOS.
TL;DR: No. Treble is only helpful for Android ports and does not solve pmOS issues.
Is dual boot supported?
It is possible to boot postmarketOS from an sd card without overwriting the existing OS, if you can load a kernel and initramfs with your USB cable (or load it from the sd card as well, like it's possible with the N900). Typically this will work with fastboot devices that have an sd card slot. See Dual Booting for more details and supported options.
Other dual boot solutions are not supported, but it should not be that hard to add them, if you know how these work. See #421 for ideas.
With Google creating A/B partition scheme on Android devices, it is possible to flash pmOS to the other/unused slot. The initramfs will find the installation, even if you're currently on the slot with Android.
Which GUI toolkits are supported?
The ones that Alpine provides, use its package search to find the toolkits and versions. For the typically used ones, QT5 and GTK+3 are among them.
Do Flatpak packages, snaps, and AppImages work?
Flatpak packages — yes! That said, Flathub — the most prominent Flatpak repository — hosts a good deal of nonfree software, and as such Flatpak has similar issues as Anbox. In addition to this, many free software Flathub packages are only repackaged pre-compiled .deb files, and consequently it is more difficult to verify what code you're running.
Snaps don't work as snapd depends on systemd (which Alpine Linux and in turn postmarketOS does not use). Snaps also have various other issues, including but not limited to the ones mentioned in regards to Flatpak/Flathub.
AppImages do not work as they are linked against the glibc libc implementation, while Alpine Linux and postmarketOS use the musl libc implementation. That said, AppImageKit does have plans for some sort of musl support, so this may change in the future. See https://github.com/AppImage/AppImageKit/issues/1015
Any GUI front-end for package management?
Yes, GNOME Software supports apk (postmarketOS and Alpine's package manager, not the Android package format), however it currently has several issues (pmaports#699, pmaports#799, pmaports#785). Support for Plasma Mobile's Discover is being worked on: pmaports#506.
Does postmarketOS have its own binary package repository?
Yes, the primary mirror is located here. The package build recipes (APKBUILDs) are in the pmaports repository.
Which file system is used?
We're using ext4 right now. People can add other file-systems in pmbootstrap if they need them. There are discussions regarding potentially using Btrfs to allow for rolling back updates: pmaports#492
What are the TODOs and where is the OS heading?
Detailed TODOs can be found in the gitlab issues. Some of them have a "help wanted" label:here. The big picture is discussed in this thread currently: postmarketos.org#83.
Are all postmarketOS packages and the kernel built locally when creating an installation image?
You build the rootfs image on your PC with binary packages from the postmarketOS binary repository. Missing packages get built locally. But usually the repo is up-to-date. Building packages locally is useful for development.
Which USB/Wireless peripherals work?
Quite a few devices have working wifi, and USB network is available for most devices. See the devices feature matrix for details.
USB mouse, keyboard, game pads etc. should work just as well as on other Linux distributions. Typically, you would need a OTG cable to use them on a phone.
Connecting phones to external monitors usually depends on proprietary Android userspace drivers, so it will not work on postmarketOS (or only with hybris and not with mainline kernels, unless somebody reverse engineers them and makes them work with mainline).
Why don't we use firmware files from Android's firmware partition?
When we package it directly, we have the following advantages (see the discussion in #637):
- We know which version we have
- We can update it easily (either with official new versions, or with hacks like nexmon)
- We don't run into conflict with other OSes that may be installed on the device (e.g. when uninstalling pmOS and installing another ROM, or when doing NFS boot)
- This also works for non-Android devices, which may not have such a firmware partition.