Invest in the Future You Want to See.
A First Public Offering of Purism Stock on StartEngine. Minimum $500.
Since I’ve seen plenty of misconceptions flying around, let’s go through a quick sum up of what is included in PureOS, the default GNU/Linux distribution installed on the Librem 5.
tl;dr: it’s pretty much Debian Stable with GNOME with Purism’s phosh, phoc, libhandy, Calls, and Chats, with some amount of adaptive apps, backports, and cosmetic patches
In the past, mobile GNU/Linux distributions were diverging from their desktop equivalents quite a lot. Frameworks like freesmartphone.org offered a comprehensive set of features expected from a mobile phone; however, they didn’t even try to integrate with existing infrastructure present on desktop platforms like GNOME or KDE – and it was perfectly understandable, since the requirements of those platforms were drastically different and main focus was supporting one thing well. Some later efforts, such as oFono, also failed to gain traction on the desktop – some popular distributions still don’t have it packaged in their repositories.
Even the Linux kernel wasn’t really ready for mobile’s prime time yet – at least on the mainline. Some mobile-specific features lacked common APIs, so userspace had to be able to support lots of various approaches found across various Linux forks made for different devices. While FSO tried to abstract that out, this presented an additional hurdle in getting those things upstreamed into major desktop frameworks that understandably weren’t really interested in maintaining code that aims at a moving target.
Fortunately, the situation has changed over time. Now, in 2020, it turns out that plenty of features that used to be exclusive to mobile phones 10 years ago had already found their way into the desktop stack. In the age of 2-in-1 convertibles, your laptop is likely to have orientation and ambient light sensors supported by iio-sensor-proxy; you can plug a 4G dongle into its USB port and have ModemManager use it for internet connection; it may even support connected suspend, which becomes very similar to how mobile phones use to do their power management. Touchscreens with high pixel density are common and well-supported. Where you had to invent your own solutions in the past, there are common and mature cross-desktop APIs now.
Since one major reason behind the choice of technology in PureOS is convergence, we try to use the same stack on the phone as we already do on desktops. Packages are installed and updated via apt and dpkg; telephony is handled by ModemManager; gnome-session and gnome-settings-daemon take care of your graphical environment etc. We diverge only where absolutely necessary (mostly the shell and bootloader) but actively try to avoid having to reinvent the wheel. Thanks to this approach improvements made for phones can be also used on desktops and vice versa. Just plug a 4G dongle to your laptop, run Chatty and send SMS to your friends – it’s as simple as that!
Unlike some other mobile environments, PureOS hasn’t created a new UI framework to use on mobile. This allows us to reuse all the applications you already know from the desktop. But wait! Of course, this doesn’t mean that there’s no work needed on them – unfortunately, desktop apps aren’t typically written with small touchscreens in mind; and because GTK3 is already in maintenance mode with no new features being developed, it’s hard to address some toolkit shortcomings there as well. That’s where Purism’s libhandy comes in – a library with a set of GTK widgets that help GTK applications adapt to various form factors. libhandy is not a platform, it’s just a library that augments GTK with additional widgets that help with common problems that pop up when trying to adjust to available screen space. You can – and often should – use libhandy for applications that aren’t even supposed to run on a phone, since that may make your app still work well when its window gets small, for instance on a crowded tiling window manager on 11” laptop screen.
Eventually libhandy is supposed to go away (or at least change its purpose), since the goal is to get all these goodies upstreamed into upcoming GTK4.
Despite of mobile PureOS being pretty much a desktop distribution running on a computer that just happens to be a bit smaller than usual, there are still some differences from the typical desktop GNOME stack that you may be using on your PC. There’s haegtesse (on the devkit) and wys (on the phone) that configure audio routing through PulseAudio – however, they’re pretty much a simple pieces of cyber-plumbing; just go check the number of LOC there, or even read the complete source code.
There is one notable part that actually differs from the typical desktop stack quite a lot – and it’s the shell. Why is that?
GNOME Shell is not designed for 5” touchscreens and its monolithic structure as a Mutter module doesn’t make it easy to experiment with new UI paradigms. It doesn’t even use GTK, which makes all the things provided by libhandy not applicable there. As per upstream GNOME developers’ suggestion, we have created a new shell that serves as a playground for mobile UI implementation and as a step towards possible future GNOME Shell replacement that would be able to work on both desktops and mobiles (Guido, one of our core developers, is successfully using it as his main desktop shell for some time now).
However, it doesn’t mean that we’re re-implementing everything from scratch. GNOME Shell became split into three different parts: phosh is the shell; phoc is the Wayland compositor; and squeekboard is the on screen keyboard. They are all based on common interoperable protocols and components: phosh uses GTK and plenty of GNOME infrastructure (it also implements Mutter’s dbus interfaces); phoc uses wlroots, which is a common library behind various Wayland compositors (most notably sway); and all three of them use the layer-shell Wayland protocol, which makes it possible to run, say, phosh on sway or MATE on phoc. We have also worked on improving some parts of the ecosystem, like virtual keyboard and text entry Wayland protocols that start to gain adoption in other implementations as well.
In the end, phoc and phosh are just small parts of the whole machine ready to be replaced when the time is right, most likely with whatever succeeds GNOME Shell, perhaps it could be phosh 😉
PureOS is a Debian GNU/Linux derivative; amber is its current stable version. It’s pretty much equivalent to Debian Buster with some packages patched in order to provide customized out-of-box experience on Purism laptops and to comply with Free Software Foundation guidelines. Packaging for PureOS is generally avoided in favor of packaging straight to Debian, and PureOS archives are automatically synchronized with Debian wherever possible (so you quickly get updates from buster-security into amber-security, for instance).
As mentioned above, amber derives from buster – so, it’s essentially a stable distribution that doesn’t change a lot (if at all).
Note: There’s also PureOS Byzantium, which automatically tracks Debian Testing.
While a stable base is a good and desired thing to have on a phone, we’re still in an early development phase where things move very quickly. Debian Buster (and therefore PureOS Amber) contains GNOME 3.30, which is too old to sensibly adapt to a small screen of a phone – so we need something newer. Tight development timeline also calls for using some temporary mobile-specific hacks that may not be perfectly suited for desktops. To give us a possibility to do those things, amber-phone suite was created, which is a thin repository overlay that augments amber (and its amber-updates and amber-security) with some backported or patched stuff that shouldn’t go into every PureOS Amber-based PC out there.
The default repository list on the phone looks like this:
deb https://repo.pureos.net/pureos amber main
deb https://repo.pureos.net/pureos amber-updates main
deb https://repo.pureos.net/pureos amber-security main
deb https://repo.pureos.net/pureos amber-phone main
There is also amber-phone-staging, which is simply a place where updated packages are incubated in for (currently) three days before being migrated to amber-phone to make QA easier. If you prefer to live on a bleeding edge, you can enable it by adding:
deb https://repo.pureos.net/pureos amber-proposed-updates main
deb https://repo.pureos.net/pureos amber-phone-staging main
On the Librem 5, PureOS is by default installed into two partitions: small ext2 /boot partition and larger ext4 / one. It looks like, sounds like, and feels like a regular PureOS (or Debian) installation, so there’s no need to go into detail there.
Let’s have a quick overview of which packages (and why) are there in amber-phone:
Backported newer upstream versions or Debian revisions:
Packages above may contain some patches that are still waiting to be upstreamed or have been already upstreamed but in later versions than what we’re using there. This is the category that is the most likely to grow in the future.
Backported packages with temporarily non-upstreamable patches:
Those patches need more work to be upstreamed, as they may be unsuitable for desktops right now (for instance automaximization of dialogs and back buttons instead of close buttons in GTK or disabled panels in gnome-control-center that are unnecessary on a phone but perfectly useful on a desktop). The plan is to eventually get all these changes upstreamed, it will just take a bit longer – so this list should eventually shrink to zero.
Packages that don’t exist in Debian Buster:
There are also phoc and phosh, but since these don’t exist in Debian Buster and are also useful on desktops, they are made available in amber-updates instead of amber-phone to make installing them on regular desktop PureOS easy (similar thing may happen with other apps in the future, like King’s Cross or Chatty). These packages should eventually find their way into Debian as well (and some already landed into Bullseye).
A notable omission right now is the bootloader – u-boot – which isn’t distributed as part of the distribution yet, but externally added to the image by image-builder. This is going to change in the future.
There are other things as well that weren’t mentioned above – some parts of the stack are yet to be created (or just has been, like feedbackd – a daemon for handling audible, visual and haptic feedback), but just like those mentioned earlier, these things will be created with upstream GNOME in mind, making sure that they will be easily able to grow and be useful way outside of the Librem 5 context (or even GNOME where applicable). After all, GNU/Linux is likely to still be there and it will still benefit from improvements made for mobile phones even if all GNU/Linux phones suddenly disappear, especially in the age of 2-in-1 laptops with mobile broadband connections.