A common point in the Linux community is that escaping the walled garden of ecosystems like Android or iOS is already a means to higher security. Having no contact with Google or Apple servers ever again, nor cloud providers ever snooping on your private files or contacts again is a good selling point for the privacy-conscious.

The ability to freely sideload applications, switch and update kernels, plus a deeper knowledge of what data each apps send to remote servers means that total control of our personal device feels finally achievable. And, of course, the mainline Linux kernel is generally safer than the half-baked, often outdated manufacturer kernels ("downstream") that most mobile devices rely on, at least when stable patches are no longer provided.

There is no catch here: the above are perfectly sound points. But while Linux phones can be potentially more secure devices in the entire control of their owners, it is important to realize that most Linux systems are not secure by default, as most distributions prioritize freedom over strict internal isolation. Don't panic, though: we'll go through this.

I would also like to deeply thank Luca Di Maio, infosec professional, author of DistroBox and contributor of VanillaOS, for helping me write and proofread this post.️ ❤️

Modems trust their home

Both Librems and PinePhones adopt a radical solution to prevent the unwanted flow of sensitive data: hardware kill switches. These are an effective, intuitive way to make sure you are sharing only the data you wish to at any point, and make wireless attacks or e.g. sneaky GNSS logging physically impossible. Though of course, with proper privilege separation, a software switch can be just as effective. But what happens once these switches are turned on?

The modem is hooked up via USB on both the Librem 5 (which lets you replace it directly) and on both PinePhones. Consumer phones take different approaches. Up until around 2019, Qualcomm mobile SoCs featured the modem as a built in component, sharing the same memory address space and utilising standard MMU security features as well as custom XPU hardware to provide protection in both directions. With the advent of 5G, the x55 and x65 modems are instead hooked up over PCIe, with the modem running it's own Linux kernel, presumably in order to hit the required speeds, and so that the same modem can be shipped on X86 laptops and other devices.

Whilst Qualcomm's approach of having the modem and CPU share the same address space does enable the potential for devastating exploits, the amount of protection (see that XPU hyperlink above) makes these integrated modems arguably more secure than what you get on a PinePhone or Librem 5 - depending on how much you trust Qualcomm.

When there isn't a "chain of trust" involving the modem, and when the modem includes its own storage (i.e. on the PinePhone and Librem 5), it is usually possible for this to be externally tampered with. This may involve e.g. reflashing by malicious agents with root permissions on the device, or through physical access.

Open Firmware For PinePhone LTE Modem – What’s Up With That?

In their monthly announcement, among all the cool things Pine64, they talked about the open firmware for PinePhone’s LTE modem. The firmware isn’t fully open – a few parts remain …

HackadayArya Voronova

There are some benefits to this. For example, the PinePhone lets you flash a custom, open-source firmware on its modem (which, being illegal in some countries, we report just for educational purposes). This allows for better trust in one of your phone's most critical mobile components, but at the same time, it means any bad guy with physical device access will be able to reflash it.

Some pedants might insist that the PinePhone modem "open firmware" isn't actually open source: the actual baseband component which implements the lowest level of communication runs on a Qualcomm DSP and is proprietary. Whilst this is an important distinction, it fundamentally misses the point of articles like the above, and only serves to diminish the fantastic work done by FOSS developers to continue pushing for user ownership and control of their devices. We hope that other reports will nonetheless continue to be clear about this fact, as Hackaday is thankfully in the above article.

Sandboxes and granular permissions

By default, user-space software loaded inside a Linux device follows the standard UNIX paradigm, and is trusted to access all parts of the system of the user who runs it. Granted, if you installed and executed something, that implies that you probably trust it in the first place. But one binary executed outside the sandbox is enough to compromise the entire userspace, and per-app sandboxing solutions such as Snap and Flatpak are only now starting to become popular.

The exceptions in this case are projects such as Fedora Silverblue, which use a Flatpak runtime to confine even core components and prevent unwanted access. Using Silverblue, however, still carries some compromises on actual usability - as does deep sandboxing in general.

Immutability, and read-only system partitions

On the same track, immutability in Linux systems has been under the spotlight in recent years. When I spoke to Luca (see above) at LAS 2022, he explained me on the fundamental benefits of immutability and why it should be implemented more widely in Linux systems.  As Red Hat explains, immutability is quite intuitive to understand.

What does "immutable" mean? It means that it can’t be changed. To be more accurate, in a software context, it generally means that something can’t be changed during run time. [...] In Silverblue’s case, it’s the operating system that’s immutable. You install applications in containers (more on this later) using Flatpak, rather than onto the root filesystem. This means not only that the installation of applications is isolated from the core filesystem, but also that the ability for malicious applications to compromise your system is significantly reduced.
                       — RedHat, 2019

This works essentially by "freezing" all non-sandboxed parts of the system. A better explanation can be found here:

Immutable Linux with Silverblue: My favorite superpower

As a security guy, I approve of defense-in-depth, which is why I like Silverblue.

Enable SysadminMike Bursell

The main two reasons for immutability in mobile systems are guaranteeing atomic updates, in order to maintain a stable system and allow "snapshots" and rollbacks, and the ability to sign the boot and system images, as dm-verity does on Android.

Basically, by signing the critical areas of the filesystem and verifying at boot, Android and iOS phones ensure that the system has not been modded, er, compromised, and if a serious root exploit disables the read-only mode on system components and overwrites them, the device will not be able to boot until it is reflashed. On the other hand, a "simple" read-only system partition is slightly less solid, because a root exploit could acquire write access and compromise the system permanently.

Overview | Android Open Source Project

Android Open Source Project

Aside from Android, read-only system partitions are also the default e.g. in Ubuntu Touch.

Immutability brings some undeniable limitations, as with e.g. ostree, installing system-wide binaries requires "snapshots" of the partition, rebooting the system often, and can become painful if these images need to be signed. So take the above example of immutability-plus-read-only-plus-signatures as the valhalla of immutability, and not something that the normal Linux mobile user should necessarily pursue. At least in it's current state.

Busy sandboxes: Thousands of users

As we mentioned, non-sandboxed apps in a standard Linux user space can do everything at some user permission level. That is, access the entire filesystem for that user, data from other processes, install and autoload executables, and so on.

This has been the common practice also in most desktop systems up to shortly ago, and theoretically the user had to trust every binary independently to be good, and not snoop on them.

Following the practice of many modern containers, every Android app has an unique UNIX user. This sort of system-level isolation has always been popular in containers like Docker, Flatpak or podman, which are based on the same principle.

In a UNIX-style environment, filesystem permissions ensure that one user cannot alter or read another user's files. In the case of Android, each application runs as its own user. Unless the developer explicitly shares files with other applications, files created by one application cannot be read or altered by another application.
                    —  Android Open Source Project

More on this topic can be found in Android's official documentation:

System and kernel security | Android Open Source Project

Android Open Source Project

Tracking snoopy peripherals

This is not exclusively a Linux phone issue, because not even most commercial mobile OSs do permission tracking in a proper, "fair" manner.

For instance, Android asks user-installed apps for granular permissions, yet lifts an exception for the proprietary Google Play Services suite, treated as almost system-level, but at the same time fully proprietary. In fact, the Google Play Services runtime is allowed to do essentially any operation silently, such as installing or overwriting new software, accessing software and hardware permissions, and so on.¹

Google Play services automatically obtains all permissions it needs to support its APIs. However, your app should still check and request runtime permissions as necessary and appropriately handle errors in cases where a user has denied Google Play services a permission required for an API your app uses.
                     —  Google Developers docs

On the Linux side, much progress has been made on filesystem and peripheral permission tracking in the last 2-3 years. For instance, webcam and microphones can now be funnelled through PipeWire, and every application accessing this hardware will need to go through it for permissions. Furthermore, thanks to Wayland, your display's pixels are not in "public domain" any more, and each application is allowed only to see its own rendered screen unless explicitly authorized.

Regarding Flatpak, the new-ish XDG Desktop Portals allow interfacing Flatpak applications with system-level hardware smoothly, allowing for fine-grained authorization, and possibly showing Android-like dialogs for specific authorizations. This is not yet a foolproof sandboxing system, as e.g. full user-space filesystem level is often granted to applications, but it comes very close.

Open ≠ Unsigned Bootloaders

As some will know, we do advocate for free bootloaders – in fact, it's one of the main points that should be legally regulated in order to let users use their hardware as they wish. However, bootloader signatures should be a possibility also on free hardware, not as an imposed thing by the maker or device carrier, but rather as a feature to enable if needed.

Qualcomm’s Chain of Trust

Covering Qualcomm bootloader’s up to the point of Android being loaded

LineageOS

By uploading their custom keys, users in security-critical situation could flash only an image they personally compiled and authorized to their Linux mobile device, and prevent overwriting from malicious agents.²

This is at the end of our list, however, as it is often easier said than done. While most mainstream phones could (and sometimes do) offer something like this without much effort, on custom-built Linux mobiles this requires a custom secure bootloader reimplementation with boot key sideloading, a chip-level trusted boot framework, and more critical stuff than it would make sense to have.

Most Linux phones currently encrypt the user space data partition to make it useless to attackers, but being – thankfully – fully unlocked, they do not prevent e.g. unsigned reflashing of the system partition while the device is turned off.

Google's lineup of Pixel phones are often touted for their support of custom AVB bootloader keys which, among other good practises, puts them in the elusive category of devices supported by the privacy-oriented GrapheneOS, who include many extra software features to offer a much greater level of privacy and security. GrapheneOS were unhappy with a previous version of this paragraph describing them as an Android ROM, a common term used by the community to describe any modified Android/Linux (or, as I've taken to calling it Android + Linux) system. We'll let this tweet speak for itself.

Basically, you upload your own keys to the Pixel device, and then have a custom trust chain, allowing you to use your own (or a third party's) signed images. Every element in the chain can verify the next one before loading it and yielding control, allowing every component in the system to be "proven" to be unmodified. (More on boot trust chains can be found here)

Coming to the end, Linux phones might be indeed the most respectful option for their users when it comes to privacy, and user space sandboxing is making the Linux platform more trustworthy than it has ever been. But when "hard" security becomes a requirement, a Linux phone in its default configuration is far from foolproof, and taking additional precautions is the only way to harden one's device and guarantee a truly safe (and more mature) usage experience.

On the other hand, the default configuration of most distributions is tailored to provide users with freedom to play around with their mobile device without too much overhead or scary warnings, and adjust their features to their needs to a degree that has never been seen to this point. So keep your device safe from all the darkness out there, and happy hacking.

[1] See also Google Play Services - Package Index
[2] An example of how to sign LineageOS builds with AVB keys can be found here

As we tend to mention often, cameras are one of the areas where Linux phones are often seen as lacking behind their Android alternatives. This is partly due to extreme fragmentation of sensor drivers, with most mainlined devices not having any kind of Linux camera support, and just partly due to the lack of a software infrastructure for acquisition and post-processing.

The first camera app for Linux phones was Megapixels, developed by Martijn Braam as a Python GTK3 app for the PinePhone, and now the standard choice for Linux mobiles. Megapixels can be easily extended to new phones with a working kernel camera driver through configuration files, which specify sensor drivers to use, colour processing matrices, how previews are to be displayed, and much more.

postmarketOS / megapixels · GitLab

The GTK camera application

GitLab

Forking Megapixels, Purism developed Millipixels last year, a device-specific fork of Megapixels to be shipped with the Librem 5. So far, Millipixels has been progressing side by side with Megapixels, with some optimizations and minor differences to support all Librem hardware revisions.

Librem5 / millipixels · GitLab

Legacy API support / Librem 5 fork For packaging see https://source.puri.sm/Librem5/debs/millipixels

GitLab

However, contributor Pavel Machek has developed an "automatic" photo mode for the Librem 5 in Millipixels, which optimizes the three parameters of the usual "exposure triangle" as in simple digital cameras to get closer to a point-and-shoot experience. A first autofocus algorithm has also been added, as well as support for video recording, which seems to be working smoothly.

This work on autofocus and automatic exposure is now in the bleeding-edge master branch, and should land to the Librem 5 within the next release.

Although this has not been tested with third-party devices, this should be generalizable with relative ease to other camera-supported Linux phones, opening a way to taking pictures from Linux phones without having to manually set gain (ISO), shutter speed and focus manually every time.

The user who first tested this commit, adamd, published a set of test images and videos taken in automatic mode, and they look quite good – maybe also thanks to his careful eye.

Librem5 Automatic Camera Controls

Previous posts that may be of interest that talk more generally about my experience with the Librem 5. 2022-10-14 2022-12-13 Librem 5 Automatic camera controls If you are willing to install / use bleeding edge software you can have automatic controls on the Librem 5. If you want to give it a shot I…

adamd’s placeadamd’s place

Another recent effort to standardize the complex Linux camera stack is libcamera, which attempts to centralize most core components of the photography stack into a single starting point. Quoting from their FAQ,

libcamera is an open source camera stack for many platforms with a core userspace library, and support from the Linux kernel APIs and drivers already in place. It aims to control the complexity of embedded camera hardware by providing an intuitive API and method of separating untrusted vendor code from the open source core.

libcamera aims to encourage the development of new embedded camera applications by limiting the complexity that developers have to deal with. The interface is designed around the way that modern embedded camera hardware works.

Welcome — libcamera

_+-/ \-+| (o) |+-----+ libcamera

According to its authors, the libcamera project is to be seen "as the continuation of V4L2", with its API allowing applications to configure the camera and access image frames to be passed directly to image encoders (e.g. JPG) or video encoders (e.g. h.264) for finalization (more here).

Furthermore, libcamera is designed to support also proprietary camera stacks by loading all untrusted binary "blobs" required for image processing in a sandboxed, controlled space.

That is all, for now. With the Linux image stack being slowly demystified, efforts to add support for cameras on more mainlined devices are finally starting to bear fruit.

Via @adamd@social.sdf.org (Mastodon)

In their December update, Pine64 announced the PineTab2, which is the successor to their PineTab from 2018. As a major change, the PineTab2 upgrades the slow A53-based A64 SoC with an A55-based Rockchip RK3566, the same chip that was used for the Quartz64, and that helped to mainline this chip and base board.

This new SoC should provide more speed and better power management, and according to some Android benchmarks, its performance should be comparable to that of a Snapdragon 450 chipset. Although this is a far cry from the RK3399 chipset in some of PINE64's "pro" line (PinePhone/PineBook Pro), it is still faster than the PineTab's A64, and comes with a far better GPU (Mali G52) thanks to being much more recent (2020 vs. 2015).

A summary of the known PineTab2 specifications is the following:

• SoC: Rockchip RK3566 (released in 2020)
• CPU: 4x ARM Cortex-A55 @ 1.8GHz with 1TOPS NPU
• GPU: Mali-G52 (OpenGL ES 1.1/2.0/3.2, OpenCL 2.0, Vulkan 1.1, 4K/1080p video decoding)
• Memory: 4/64GB and 8/128GB variants, microSD card slot
• Display: 10.1" IPS LCD (resolution unknown) +  micro-HDMI output
• USB: 3.0 Type-C, 2.0 Type-C
• Audio: 3.5mm jack
• Camera: 5MP (?) + 2MP
• PCIe connector on internal mainboard (no SSD space tho)
• Battery: 6000mAh (unconfirmed)
• Included detachable keyboard cover with touchpad
• Easy-opening metal case for repairability and hackability

All in all, the PineTab2 looks very promising if the (currently unknown) price remains reasonable. Specifications are preliminary, and might change in the final product, but the first developer prototypes should be released in early 2023. More information can be found in Pine64's December Update below.

December Update: Merry Christmas and Happy New PineTab | PINE64

Merry Christmas, happy holidays and a Happy New Year to you all. This month’s update has a different formula from the usual – aside from the announcement of the PineTab2, most of this month’s content…

PINE64Bruno Verachten

Although the most well-known, the PineTab2 is not the only new Linux tablet released in these months. Another portable device that was released in November is the Intel-based Juno Tablet by Juno Computers, a London-based Linux hardware company which assembles their hardware in the UK.

The Juno Tablet comes with a relatively conventional Celeron N5100 processor, which lets it run mainline Linux effortlessly.

• SoC: Intel Celeron N5100
• CPU: 4x Jasper Lake x64 cores @ 1.1-2.8GHz, 6W TDP
• GPU: Intel UHD Graphics (Jasper Lake 24 EU, 350 MHz – 800 MHz)
• Memory: 8GB LPDDR4 + 256GB / 512GB / 1TB (replaceable?) SSD
• Display: 10.1" FHD IPS 1920×1200@60Hz (MIPI-DSI) + DP 4K@60 via USB-C + mini-HDMI 4K@60
• Wireless: Dual-band Wi-Fi + Bluetooth 4.2 (Intel AC 9460/9560 Jefferson Peak 2.4 and 5GHz)
• Dimensions: 249 x 167 x 11 mm, 670 grams weight
• USB: 1x Type-C 3.1 with charging + DisplayPort video out, 1x USB3.0
• 1x Micro SD (TF)
• Audio: 3.5mm headphone jack, built-in mic, speakers (stereo output 2x1W),  Intel ES8336 sound card
• Power: USB-C (min. 36W) or through DC barrel charger (36W – 12V 3A)
• Cameras: 5MP + 2MP
• Battery: 3200 mAh 7.6V (so double cells)
• Software: Manjaro Plasma Mobile, Mobian Phosh (mainline with hybernation suppoer), optionally also Windows 11
• Plastic chassis with included legstand
• Assembled in the UK (according to site footer)

Juno Tablet - Juno Computers UK

Ubuntu | Mobian | Manjaro | Plasma Mobile | Phosh | Intel N5100 | London | England | Scotland | Wales | Ireland | Europe | Linux Tablet

Juno Computers UK

The JunoTablet is priced at $407, plus import and shipping taxes. It will be a bit more powerful than the PineTab2, and come with a stabler (if not quite boring) kernel, but is also more expensive.

One last, honorable mention goes to the Fydetab Duo by (also London-based) Fyde Innovations, a Linux tablet which bas been in crowdfunding since July and which uses a degoogled, ChromiumOS-based fydeOS ("openFyde") distribution and aims at productivity and smooth integration of Android and Linux apps.

Fydetab Duo

Open-source and hackable Linux tablet, powered by FydeOS | Check out ‘Fydetab Duo’ on Indiegogo.

Indiegogo

With modern specs, premium build and pricing (starting at €620), the FydeTab Duo reminds a bit of the JingPad, although using a more conventional and easily maintainable software stack.

The FydeTab is one of the most elegant Linux tablets ever released, and the mix of ChromeOS and Linux features could also be - with a bit of luck - a game-changer.

But all things considered, these three new Linux tablets follow different approaches and targets, none of these are wrong. The PineTab2 is an affordable device for ARM Linux hackers, the JunoTab offers an effortless Linux mobile experience for an average price, and the FydeTab is meant as a premium-ish Linux device that still manages to remain within a reasonable price range.

Via Brad Linder (Mastodon) + Liliputing

Our first post ever on this website was about the GNOME Project "getting ready" to adapt their environment to the growing demand of responsive, mobile-friendly Linux devices. That was back in 2019, before libhandy (Gtk mobile library) was considered stable, and when Librem 5s and PinePhones were less than a clear mockup on their engineers' desk. One year later, the first concepts of a tablet-friendly GNOME Shell were released, which would then see its first realization in the major GNOME 40 update from 2021.

Six months ago, I was at the Linux App Summit (LAS) 2022 when I had the opportunity to see one of the very first experiments of a responsive, mobile-friendly GNOME Shell experience, from its developer Jonas "verdre" Dreßler.

Tobias Bernard 🦣 (@tobias_bernard)

Productive hacking at LAS today: Jonas managed to get an initial implementation of two-dimensional navigation gestures working 🎉

Nitter

Although its new gesture-based system would remain somewhat buggy for the weeks to come, it felt surprisingly consistent and smooth to see, and its usability was one of its strengths. In fact, it was a matter of weeks until some distributions started packaging it (sometimes too early), and videos started appearing and comparing the overall experience to other shells like Phosh - often with excellent results.

Tobias Bernard 🦣 (@tobias_bernard)

Playing with Jonas’ latest WIP mobile shell branch. It’s honestly more fluid than my Android phone with Lineage, super impressive given the much weaker hardware✨

Nitter

Fast-forwarding to September 2022, Jonas made his work on a mobile GNOME Shell finally official by releasing an in-depth blog post showcasing the new Shell, including some demo videos of it running on a PinePhone Pro. As you can see, at a first glance the experience does not differ much from that of iOS and Android devices, and all happens in a smooth flow.

GNOME Shell on mobile: An update – GNOME Shell & Mutter

GNOME Shell & Mutter Development blog for GNOME Shell and MutterJonas Dreßler

With progress on the mobile shell happening so quickly, one YouTube channel has recently posted an in-depth overview of the usability of Shell on mobile devices, specifically on a "mainlined" Android (Qualcomm Snapdragon845) device in this case.

Although the OnePlus 6 is still one of the most powerful Linux-supported phones around, there has been considerable work spanning from Gtk, St, and Mutter to the high-level JS code in bringing Shell to such an optimized stage. As you can see from the video, performance never appears to be an issue, and multitasking is extremely smooth with the interface looking generally complete. Furthermore, the new Shell animations do their job in enhancing the "cool" appearance of this project.

At around 3:00 in the video, Niko mentions the battery life of the OnePlus 6 on Linux to be loosely comparable to that on Android, which would also be an impressive achievement for a mobile platform that has so far been killed by terrible battery life and lack of efficient standby consumption. Although no official ETA exists, considering the current stage of things, it would not be surprising to see this work land in the final Shell in the relatively near future.

Around one year ago, Sipeed announced initial support for Android on their RISC-V development boards, hinting that a first functional prototype of RISC-V phone could be coming within one or two years. Although Android is now supported by several development kits based on this architecture, as can be seen in the relatively new RISC-V Android Source repositories, we have yet to see a major mobile device implementing this architecture. Although still in the depths of the Linux kernel's architectural porting, things are moving fast.

But if the very first PDA to support a quasi-RISC-V architecture was the Precursor, released in late 2020, the NLnet Foundation is now funding a new, homegrown RISC-V phone project. As for many other mobile Linux projects, such as postmarketOS, MNT Research's Reform and PocketReform, and others, the rvPhone also appears to be sponsored by the European Union's Next Generation Internet project.

To put things clear, the rvPhone is quite different from the devices above, as in spite of what its name may suggest, it is still far from doing the tasks of even a basic smartphone, and is rather focused on enabling mobile communication on a low-power RISC-V platform than about providing a modern smartphone user experience.

And if the rvPhone developments are more about its open-source hardware than the software, some specifications can be derived from the current prototype:

• todotodo proc
• CPU: SiFive Freedom E310 RISC-V microcontroller (320MHz, RV32IMAC)
• CPU (on daughterboard / SoM): NXP i.MX 8M (the same family as the Librem 5's), e.g. CL-SOM-iMX8 (4x ARM Cortex-A53@1.5GHz + ARM Cortex-M4 coprocessor)
• Display: 480x854 IPS LCD capacitive touchscreen, ILI9806E  (FocusLCDs E50RG84885LWAM520-CA)
• Graphics: BT817 controller
• Wireless: Espressif ESP32 Wi-Fi + Bluetooth
• Cellular: SIMCom SIM7600X or Quectel EC-25 broadband modem via mini-PCIe
• Audio: I2S audio subsystem, Class D amp (MAX98357A) + microphone (ICS-43434)
• Others: gyro, accelerator, magnetometer (LSM9DS1), haptic driver (DRV2605L)
• Camera: ArduCAM / OV2640 sensor (5MP)
• Power: Lithium battery + charger (BQ25895)
• Storage: SD card (FAT filesystem, AES/Blowfish encryption support), possibly eMMC on i.MX8 daughterboard

As can be seen, this prototype seems to be an interesting combination of an inexpensive, low-power RISC-V SoC sharing the board with a relatively high-performance i.MX8 ARM module. Although the electrical schematics are available, it is not entirely clear how the two subsystems interface with each other, or how the switching logic occurs between the ultra-low-power RISC-V system and the fully-featured i.MX8 board.

For instance, although electrical specifications are open and downloadable (also in KiCad format from the hw directory of its repository), the general documentation looks to be still limited. Similarly, no videos or pictures of the prototype apart from that above seem to be released at the time of writing.

The project looks developed by one developer, Uroš Majstorović ("majstor"), and its official Git repository looks to be relatively active. This probably falls into the spectrum of homebrew projects, and it represents the first experimentally working RISC-V mobile device. Having some kind of Linux integration through the i.MX8 subsystem, it could also be a good source of inspiration for privacy-oriented RISC-V hardware stacks - although for ypu will need to wait at least until next year to see more fully-featured RISC-V phones.

RISC-V Phone

Ubuntu has been traditionally considered the most popular and user-friendly distro, and its core principles inspired a stream of derivate distributions in the past years. Although many users are happy with the general architecture, Ubuntu owner Canonical has sometimes been criticized for some technical choices, such as pushing most parts of the runtime into snap runtimes, moving even essential apps to the container format, or shipping "patched" version of software and desktops, or more including (harmless) ads in their desktop or even inside the terminal.

With some known flaws, but excellent community and adoption, some projects are trying to provide a compromise to make Ubuntu suitable also for the most die-hard Linux fans, while falling back in the pure Debian paradigm. And, truth be told, most of these projects work, but tend to be quite boring from a technical perspective - for instance, shipping different repositories of "purified" software, or removing every proprietary bit as in Purism's (Debian based) PureOS.

The reason why Vanilla OS in particular deserves a mentioned is that it looks like a considerably better developed idea than most, and represents in some ways a modernized experience compared to Debian and Ubuntu.

Vanilla OS was born some weeks ago as a side project by developer Mirko Brombin, who is mostly known in the community for being the lead developer of Bottles, the app which made installing Windows applications through WINE easier, by providing custom-tailored "runners", complex dependency and library management, and - of course - a damn sexy UI.

The general approach of Vanilla OS seems to integrate some innovative Linux concepts in the otherwise very conservative Debian base while still opting for mainstream, mature technologies. In other words, Vanilla OS aims for a sweet spot between the usability of Ubuntu and the different concepts of Ubuntu derivatives such as elementaryOS, Pop OS and others. In fact, Vanilla OS tries to provide "vanilla" (as in upstream) experience of developer software such as GNOME, thus also becoming a mature "test bench" for software, and giving the end users the choice to adapt to their needs. We could say that Vanilla OS is not too unlike projects like Pop OS, but achieves that while remaining technically, er, more vanilla.

Diving into the project, we can find several core concepts:

Freedom of (packaging) choice – plus a new package manager

Vanilla OS includes a custom graphical (Gtk4) installer, which provides a "build-a-bear" setup to tailor many settings to the users' needs, without ever touching the terminal. For instance, the Snap runtime is now no more mandatory, but an option offered in a convenient switch to the end user. Similarly, users may choose to set up Flatpak, or AppImage packaging, at their choice during the installation process.

In general, most of the set-up process feels like Ubuntu, but gives users some more choices without scaring newcomers away in the process.

Last but not least, Vanilla OS comes with a new package manager, apx, that provides lightweight containerization and format-agnostic installation of software from different sources. In particular, apx is based on the work of DistroBox.

On-demand immutability

The core idea of traditional immutability is to isolate all critical areas of the filesystem from user modifications,

Usually, immutability comes together with the possibility to snapshot, and "commit" new changes to the system partition while allowing for easy rollbacks if something goes wrong, not too unlike the "restore points" in Windows-based systems.

However, Vanilla OS goes for a simpler, "on-demand" immutability, which on the one hand does not require filesystem modifications, but on the other provides no support for snapshots or restore points. The docs justify this choice, versus using OSTree or similar projects, as one that is simpler to use and compatible with all setups.

In general, the idea should be that a read-only system partition also allows for temporary modifications to the system partition, which can be restored to their original state when needed. This allows for "virtual" modifications to critical parts of the system upon need, but does not affect the final filesystem state. However, traditional, permanent modifications of the system are also possible, if needed, by toggling the immutability of certain areas of the filesystem.

Vanilla OS is an on-demand immutable distribution, the system is read only to prevent unwanted changes and corruption from third party applications or a faulty update. Some paths are still writable, such as the home directory, this allows the user to keep their files and ensure the normal functioning of applications.

You can find more about on-demand immutability, achieved via almost, in the Vanilla OS docs.

Purity – "upstream first"

A common debate that appears is between distro maintainers, who tend to customize desktops and app themes for branding reasons, and more "puritan" software projects like GNOME, which emphasize how such customizations affect the styling quality and overall stability of the system, and discourage distributions from delivering variants of their apps that have been modified or reskinned through patchwork.

The truth may be in the middle, but Vanilla OS tries to deliver software as the initial developers intended it, also for the sake of better stability. In doing so, it represents one of the very rare downstream distros that try to deliver fewer bugs than its parent, and at least ideally an exception to the idea that software becomes always less stable in derivative distros, which I wrote something about in the past.

Similarly, the Vanilla OS website presents the project as one also aimed at gamers, and being upstream-first in this case should reduce the risks of glitchy games or broken graphics.

GUI-centric user experience

Because most actions and post-install configurations can be achieved through a set of GUI apps. An example is the driver manager, which can be seen in the video below

Mobile friendliness?

In doing all these things, Vanilla OS tries to be "sort of" lightweight, and would likely present, in its default configuration, a similar footprint to projects like Mobian. At the same time, immutability gets closer to the system partition isolation that Android and iOS devices offer, and may reduce the risk of an unreliable or corrupted Linux system, provided that an easy restore mechanism exists for the end users.

In other words, the core concepts of Vanilla OS could be as useful for mobile Linux devices as they are for desktops, aiming for stability while being as inoffensive and upstream-first as possible. But Vanilla OS is still at an early development stage, no plans for ARM (mobile) devices have been done yet, and only time will tell how far it can go.

You can find more information about Vanilla OS on its official website, or in their Discord channel.

Vanilla OS

Vanilla OS is an On-Demand immutable Linux based distribution which aims to provide a vanilla GNOME experience.

Ubuntu

Via Mirko's Twitter

The dream of an HTML-based operating system is nothing new, and in fact, something we have seen since the early 2000s. With the Internet exploding in popularity and complexity, it has always been tempting to think of browsers as convenient graphical renderers, and CSS as the ultimate markup language for designing complex UI elements.

However, reality has often clashed with this view. Many projects proposing an HTML5 or JavaScript desktop UI have historically shown bottlenecks even on high-spec machines, and although a subset of CSS is finally being used in the majority of "traditional" toolkits such as Qt, Cocoa, and GTK, the adoption of JavaScript logic to control desktop frontends is still lagging behind. Aside from Google's Chrome OS, Electron, and many other projects, the whole GNOME Shell frontend runs on top of a JavaScript interpreter... and sometimes it shows.

Mozilla’s $25 Smartphone Is a Brilliant Gamechanger

If you don’t have any customers, create them.

TimeAlex Fitzpatrick

One of the most important open source attempts in this direction was Firefox OS, the alternative to Android created and promoted by Mozilla in the early 2010s. Firefox OS, also known as Boot2Gecko from the "Gecko" rendering engine of Firefox, was a surprisingly clean and smooth experience, and its official deprecation in 2016 was probably more of an adoption issue than a technical problem. In fact, the idea of booting to a browser and interfacing apps with the kernel directly is rather intuitive, and would not be that much heavier than booting most other modern UIs in the first place.

Even Firefox OS's user interface was very nicely designed, with visible inspiration from HP WebOS and Palm OS. Clean lines, a lively flat design, and an easy-to-use app development toolkit made it a compelling alternative to Android and iOS. Except nobody adopted it seriously, and it died in 2016.

However, in the last months Firefox OS has experienced a similar revival to other projects, such as HP webOS (which became LuneOS) and Nokia's Maemo (now Leste). The first major commercial adoption of B2G/Firefox OS was seen around 2018 with KaiOS, a  widely popular commercial fork of Firefox OS that promised to be a modern OS for inexpensive feature phones. Although KaiOS turned out to be disappointingly closed and oriented to tracking users and shipping advertising, it was quickly forked in GerdaOS, a custom ROM that promised to bring back some of the openness of Firefox OS to KaiOS devices such as newer Nokias, and kill the intrusive user trackers in the process.

GerdaOS: a custom ROM to liberate the heart of Kai

GerdaOS project page

Most importantly, however, the Capyloon project is not just a heavily modded (still somewhat closed) KaiOS as was Gerda, but a functional, fully open-source Firefox OS build for modern Linux phones, such as the PinePhone Pro, Purism Librem 5, and Pixel 3A.

In spite of its clear goal, Capyloon's project page has some admittedly confusing marketing: defining it an "experimental user agent" for better Internet privacy and a GUI at the same time, the website does not clarify that the main purpose is a full user-facing OS. Furthermore, the Capyloon page proposes WebAssembly and IPFS integration as the main priorities of the project, but it is not made immediately clear how this integration works in practice.

Capyloon's frontend, Nutria, is shipped with an SDK for development of new apps, and will likely run older Firefox OS apps with little or no adaption. Furthermore, it is possible to test Nutria also on most new Android devices by live-booting a Google GSI (Generic System Image) and test the Firefox OS UI on top of the Android kernel. For those without a supported phone, a Capyloon virtual machine can also be built in one command using a Rust-based build script, or downloaded as a Debian package.

Capyloon - Reclaim Your Web!

An Experimental Web Based User Agent

Reclaim Your Web!

Via @linmobblog / Twitter

In some sense, 2022 has been resembling the long-memed Year of the Linux Desktop. Although this sounds like some cult's prophetic rubbish, by looking at the success of the Linux desktop in very empirical terms an improvement of the last couple of years becomes clearly noticeable.

The Steam Deck alone has had the most merit for this. Although its reviews were mixed, its power and overall technical brilliance has been acknowledged by essentially all (mainstream) reviewers that could get their hands on it. And alongside it, a new generation of Android/Linux hybrid devices is slowly growing, alongside many ex-Android phones (with Qualcomm Snapdragon chipsets) that are starting to "just work" on mainline Linux kernels.

On the desktop side, products such as the Librem 14 laptop which we reviewed back in April show a surprisingly stable and practical Linux experience. Other reviewers - finally also on mainstream tech sites - acknowledged the Librem 14 perks and faults, mainly agreeing on the general practicality.  Furthermore, newly developed machines such as the HP Dev One and Dell XPS 13 Plus are both heavily Linux-centric professional machines, the former being developed in collaboration with Pop OS, the latter officially certified by Ubuntu for full hardware support.

The secret for such stability may boil down to some simple rules for anyone building Linux-based hardware, which may turn to a generation of Linux mobile devices that happens to work surprisingly well out of the box. These rules allow not only to sell well-rounded Linux devices, but also to build customized ones at home (relatively) easily starting from off-shelf ARM boards.

• Simplifying drivers. Get peripherals that work out-of-the-box on Linux kernels, which are nowadays a good part of the existing hardware landscape. Ironically, such peripherals would usually feel more stable than most heavily proprietary counterparts on Windows as well: having "upstream" Linux drivers means that the devices will be maintained for decades, whereas a Windows-only peripheral requiring proprietary (non-Microsoft) drivers will often last just a couple of OS releases before being abandoned by its supplier.
• Simplifying SoCs. That is, choosing those for which new carrier boards can be developed with good documentation, but also taking mainline kernel support and stability as a first priority. If this sounds obvious, most early Linux mobile experiments such as Firefox OS phones, early Ubuntu Touch devices, and even the recent Cosmo Communicator and JingPad did not consider mainline kernel to be a priority, and thus had to rely on self-made "bridges" between unmaintained, old Android trees and Linux user space features.
• Pick GPUs wisely. After all, why not do it before? As a hardware manufacturer, they can probably just benefit from higher stability and security thanks to crowdsourced contributions, at no extra cost. Even Nvidia, to adapt to the trend, made their GPU better integrated in the kernel in the last months, shipping the "wrapper" around the proprietary firmware inside the upstream Linux tree. As another "success story", Imagination Technologies is finally starting to ship open-source drivers for their recent graphics chips after over ten years.
• Ship with a stable software stack. Currently, there is a huge gap between the level of stability and usability of Linux distributions, and most of the bugs tend to be gathered in the downstream distributions rather than on top ones. Eliminate layers, get closer to "pure" Linux and upstream packages, and a fraction of bugs will appear. As a rather limited "rule of thumb", considering how many "steps" a distribution has from its root ancestor might be a decent measure of how stable the end user experience will be. [1] The reason would be that packaging on a "forked" distribution while keeping one-to-to compatibility with upstream packages is not trivial, and most distribution tend to add many layers of customization (reads "patches") and additional software over their parents, while being used by a fraction of their user base. This implies that bug reporting will be less specific and effective, and new bugs will be introduced only on downstream machines.
• Aim for the mainstream. The SteamDeck, or HP Dev One are not marketed as "Linux machines". Very few people buy a product for the tech alone, but rather as a modern gaming or developer workstation if the experience is good.
• Finally, Aim for a no-frills user experience. Don't overcomplicate the software or hardware features, but provide a product that simply does its job easier and faster than the competition. It can be OK not to have super-high-end performance or gimmicks, as most people in the end tend to prefer simplicity and usability on work machines.

Alongside the many commercial Linux devices, a similar peak has been that of homebrew Linux computers. In the last months, several makers have developed their own mainline-ready Linux phones and laptops, often turned into easily (3D-) reproducible, somewhat stable devices.  In fact, increasing interest for modular, self-repairable devices, alongside with a growing technical knowledge in ARM board design and availability of "plug-and-play" computing boards ("SoM"s), made it possible for several to wire up peripherals to the core boards, 3D-print a case, and in some sense prototype brand new devices at home.

This can be, indeed, the best year in the last decade to buy a native Linux device. Journalists from the New York Times, Wired, TechRadar, and The Guardian are getting their hands on the "vanilla" penguin OS again after decades. Gamers are realizing that with GPU driver fragmentation and heavy operating system services, Windows is also not an ideal platform for gaming, and the simplicity of Linux may represent a way out once a proper software base exists. In fact, I bumped several times into people using SteamDecks on subways or planes, and not being much of a gamer myself, at first I thought they were a bulkier variant of the Nintendo Switch. Recently, I even spotted a couple of Linux phones in the wild – although, in this case, strictly hooked up to laptops as developer devices.

But making predictions is easy, and the future has often been less rosey than the Linux community liked to admit in the last decades. In fact, whether this trend will last is also up to the existing community. Being inclusive towards newcomers, helping test and debug software issues as users rather than complaining about some possible instability, and making the software space stabler rather than even more fragmented will surely ease the transition of new users to the penguin desktop.

[1] As an example, Arch, Debian, and Fedora would be the "level 0", Ubuntu and postmarketOS would be on level 1, distros such as Zorin OS and elementary on level 2, and so on. For more examples, have a look at the DistroWatch "Family Tree"

Cover picture: SteamDeck

I should start by notifying readers that is a slightly old post, initially written in reaction to first Fairphone, then Pine64 announcing their "true wireless headphones" in April. In spite of this draft staying on my laptop since then, the situation has not particularly changed.

Some days ago, I was sitting in a dark, neon-tinted, pleasingly nerdy computing club in Berlin, with several Linux hackers around me. Most of them either had a PinePhone or a PinePhone Pro, someone else had Librem 5s plugged into their laptop as they tested out new software. Most of them were developers of mobile Linux UIs, and what we all agreed on about the ecosystem was its general immaturity, none of us feeling it was complete enough to be advertised to the general world.

In this peculiar context, it was a long discussion on how the PinePhone appeared to many as just tangently open, but not per se "ethical", that encouraged me to polish the long draft, and finally publish this post. Because, in the end, it does not say anything too new.

I joined postmarketOS chat rooms in early 2018, after strange photos of Android phones running (barely working) mainline Linux distributions grew my desire to replicate that. In all honesty, if it wasn't for the Librem 5 and PinePhone coronating my dream of seeing commercial Linux phones, I would not have started writing on this topic. But that also makes us –  or shall I say me, since I would like this post to represent my opinion exclusively – responsible for being honest. As we've been with Jingling about mainline kernels, or with FSF about a flawed certification, and with Purism about an arguably useless, "anonymous" mobile network carrier.

This article aims to represent solely my personal opinion, and reflect on an issue rather than cause further "flame wars" in the already fragmented open-source community, so take it peacefully. Discussion is always welcome, but let us keep it civil.

To start, the PinePhone became so popular because it was an amazing mobile Linux playground for its price. Similarly, the PineTab and PineBooks brought Linux laptops to pleasingly entry-level pricing, rather than pricey Intel ultrabooks. But recently, something has changed. Just in the last months, the following new Pine64 products were proposed:

• A pair of true-wireless, in-ear headphones based on an entirely proprietary SoC, an almost off-shelf design (although apparently not a clone), proprietary hardware and audio codecs from unheard silicon companies. Consumer-grade true-wireless earphones on the same chip can be found on Alibaba starting from $7.40 shipped (the BES2300 chip alone costing ~$1), the audio codec should provide acceptable sound quality. But in this way, is Pine64 trying to tackle a field as hard and closed as wireless audio through a nearly off-shelf design? (More on this later)
• Secondly, a portable audio player was annnounced, the PinePod, that would run on the same chip as the in-ear headphones.
• A third product, the PineSound, is a general development board that would expose all audio interfaces from this chip to the mercy and creativity of hobbyists and developers, possibly to experiment with wireless audio codecs and digital signal processing

But you read that right. The same chip, a closed-source, off-shelf Chinese microcontroller with 900KB RAM, will run the wireless earbuds and a portable audio player. This implies some things,

• This product family will never run Linux, as developers will need to develop a new firmware from scratch. This is obviously not a problem for the earbuds, but a big limitation for the player
• Processing wise, this chip is well sufficient for TWS headphones, but very inadequate for an audio player. It will not drive a good screen, it nor run high-resolution flacs or (probably?) support a high-quality, high-bandwidth codec. In fact, a first generation iPod Nano (retailing for $149 in 2006) had 16MB RAM, so over 16 times what the PinePod would offer. In fact, even the features of any custom firmware are limited from so little memory

In their announcement, Pine64 specified that we "will be pleased to know that the SDK has already been compiled and proven to work, and that a development board is incoming.". The base support SDK for an obscure closed chip is "compiling", and that is enough to ship a product to developers? For anyone who worked close enough to audio, this field is an absolute nightmare of codecs, licensing, closed-source libraries, and getting just the digital signal processing part of it right requires talented engineers.

I’m told that with the right tweaks, the PineBuds may actually work as over-the-counter hearing aids too. Seriously. The chipset inside the PineBuds is so versatile that it will also serve as the basis for the PinePod digital audio player. [...] Regardless, I just feel an open stand-alone music player belongs in 2022 [source]

Apart from the hearing aid claim, which  I am dubious about given the quality of microphones required for a whistle-free experience, this is no more "open" than the majority of commercial digital audio players. Both my FIIO and my XDuoo audio players are not bootloader-locked, they are flashable with custom firmware, and most of them support the "libre" Rockbox firmware that was popular in the late '00s.

In fact, considering how long the work on opening up existing players was, and how they are supported by decently well-known chip makers (Ingenic, ...), at their current stage they might be more open, while also more powerful, than a PinePod will ever be. Buy a RockBox-supported device, which often means an already open-hardware one, donate a reasonable tip to to its porting author, and you will be arguably more "ethical" than in buying a PinePod.

To be clear, I would love, and probably buy, an open-source, acceptably-high-fidelity audio player. That is something I dreamt of for years, and irrealistic sketches of some Pi Zero-based audio players are slowly decomposing somewhere in my desk drawers. But with a stack being more closed, and more underpowered, than off-shelf solutions, the PinePod does not solve any problems, but rather bets on the hope that some volunteer developer, somewhere, will reverse-engineer its chip to an usable point.

Why not just start from a decently documented SoC used in one of those off-shelf players, rather than going for a considerably more obscure one that will require an entire porting? Or why not ask users what they really want in it before, since CD-quality audio is generally easy to provide? The reason is probably cutting costs, a step too far.

This comes to the marketing pattern, the "trademark formula", that is often noticeable in Pine64's secondary products:

1. Find a successful existing product (PineTime from generic nRF52832 smartwatches, Pinecil from the open-source TS100 iron, PineNote from Remarkable). Produce a clone of it, or buy the base board design from the OEM. Then, rewrite the reference mainboard design provided by the OEM – or more often, modify it just slightly. (Again, this is nothing bad in itself - re-inventing the wheel would not make sense here)
2. Develop a product based on an anonymous, inexpensive SoC from some obscure company. All closed-source, with just minimal base-support packages (BSPs) and documentation provided.
3. Release a ton of manufacturer-supplied schematics and PDFs for closed source, obscurely inexpensive hardware present on the board as "documentation"
4. Send free early-stage samples and prototypes to a range of developers, and expect volunteers with great knowledge to work (for free, given the gifted sample devices) on it
5. Wait for them to develop a working proof-of-concept (usually alpha-level) firmware, not a beta or feature-complete one, then sell the device as an open-source community product

For some readers, this is nothing new: part of the PineNote's hardware (e.g. the e-ink panel) is not natively Linux-friendly, and the PineTime was initially criticized for looking close to a rebranded, generic Eastern smartwatch – a claim which was later debunked, although the PineTime baked a modified baseboard into the same exact closed-source chipset, plastic chassis (and possibly display?) as those.

In the past, even Rockchip, which produces chips for Pine64's "pro" line, was not famous to be open. AllWinner, which makes the A64, was very far from loved in the open-source community when the Pine64 SBC was launched. In fact, Allwinner was often vastly criticized for its GPL license violations, which were known in the linux-sunxi community (which authored most of the initial Allwinner mainline work) since the A10-based CubieBoard times. That means 2012.

Retailing from $4 to $6, the A10 and A64 ARM chips were just incredibly cheap to buy for their performance, so single-board computers competing with Raspberry Pi could be released in the $15 to $25 range, and as many developers in linux-sunxi worked hard enough on the new boards, many AllWinner chips became part of the mainline tree independently from their will.

With respect from the open source community, increasing popularity, and possibly growing sales, Pine64 has now a seal of openness on their existing devices thanks to their amazing community. But with growing prestige and respect in the Linux niche, should this not return in the form of sustainable hardware to their loyal developers and users? Why not just go for SoCs and hardware that truly respects this community, rather than exploiting them?

Most of the competition, at this point, is doing it: SHIFT, Purism, Framework, MNT Research, and Raspberry Pi are moving towards more openness, not less, as time passes. In fact, even Fairphone seems to nod at the possibility of Linux and long-term software support on their new models, although nothing official exists at the moment to confirm it.

It would be irresponsible to point out a problem without providing a solution, but thankfully, the steps here are rather intuitive. To achieve a proper "formula", which closely resembles what you will find in most other Linux device makers, Pine needs to fix up some bits:

1. Find silicon and hardware makers that care about openness

That is, without requiring a free, crowdsourced reversing of often bad and unmaintained OEM code. This should not be a problem, as there are many of them: as just one of many examples, NXP i.MX6 and i.MX8 seem a popular choice. Most open-source ARM makers including Purism, MNT Research, and most industrial embedded Linux manufacturer seem settled on this family, which is a good compromise of decent performance and acceptable pricing.

Alternatives for lower-powered SoCs – e.g. those usable in the PineBuds – that provide documentation are companies like AVR, Microchip, STM32, and the newly released RP2040. In the middle stays all the "gray area", of somewhat developer-friendly companies, which can keep prices for secondary components lower. These companies provide either a full mainline stack, or otherwise proper documentation and open code to developers, not closed-source codec "blobs".

2. Release actual software to prove the openness of boards

Rather than shipping "lazy" boards, develop a proof-of-concept, fully open-source software stack for developers to start from. That includes a panel driver, if the device has a screen, or a basic software endpoint required to use all the onboard hardware. Get the prototype of this device to work well enough the labs, to release a tiny "proof of concept"

3. Then release a developer board,

And/or an actual product based on this proof-of-concept open stack.

Otherwise, you will keep feeding the "bad apples" in the industry, that barely provide reference code for their products, and not support those who invest in making their products friendly to the end users and developers in the long run. If not even open-source hardware companies support somewhat open silicon manufacturers anymore, who will?

4. Finally, send stuff to developers

Once a basic software and hardware proof-of-concept exists, and tidy documentation has been provided to developers, it sounds fair to send devices to developers. On the PineTime and PineBuds, none of this happened, and even some early prototypes from other products were close to bricks.

As a consequence, a happier volunteer community will be thankful for the hardware and the mission behind it, and will set down develop ethical software for an ethical hardware stack in reasonable times, rather than wasting their first months of work on reversing its original, proprietary garbage stack.

In fact, being "ethical" can be a risky loophole from a financial perspective: no matter your investments, at the current stage of the tech industry, you will never be enough to define yourself so. To start, half of the production chain is messed up by a disturbing lack of human rights, and even ignoring this factor – as does essentially every manufacturer – even the greatest investments in "libre" components for a mobile device will not let you escape from hidden proprietary blobs. In fact, one of our old posts pointed out that Purism eliminated proprietary components from their software stack by hiding them exclusively in the Librem 5 modem, and updating them externally, because it is e.g. currently impossible, for legal reasons, to provide a modem with modifiable, radically open-source firmware.

As a consequence, "fairness" in technology is a spectrum, if not a multidimensional scale, with a particularly harsh curve of diminishing returns. At the current stage, there is a point at which especially smaller corporations such as Pine64 do need to take compromises. But still, the approach taken to designing a product should be detached from this market logic. If we were to see the approach to openness as a spectrum, this would have at one extreme "fully commercial off shelf hardware"  – to which the PineBuds are worryingly close – and at the other "full self made, open-hardware", which is represented e.g. by Penk's home-replicable, open-hardware projects, the Precursor, and the MNT Reform family.

The second formula will clearly cost a bit more more: "pure" hardware manufacturers need to charge a lot for hardware that, to be honest, is sometimes nowhere near "daily driver", consumer-grade quality. A Librem 5 is open, has a partly self-developed libre stack, and it is technically working, but as nothing more than a hacker concept device at its current stage. As another example, a considerably less libre Fairphone is well built for its price, but it's no iPhone.

So if being entirely "ethical", both in development and in hardware choices, is too much of a compromise for Pine to keep its prices low (or, as in recent releases, "in the lower average"), is there at least a reasonable compromise between the two? That is a question that we will leave open to Pine64 for their future decisions.

Pine64 has always been about bold product releases. Initially booming by announcing a Raspberry Pi-like single board computer for less than half the price in their early days, launching the second "modern" Linux phone when the user base did not exist, and a series of very niche mobile devices for competitive pricing in recent months, they did indeed build a loyal community over years.  But now the market is growing fast, and so is their competition.

With most alternative devices being designed to be "fair", (even more) modular, and often running mainline kernels from their nursery days (thinking of the now-hyped SHIFT6mq, which is by design a "true Linux" phone hidden in an Android hardware stack), and others being based on entirely self-designed boards for the sake of trust, Pine64 are not the only player anymore.

Now that Pine64 is growing out of the early startup phase, a direction has to be taken, and I hope that comes at an advantage of long-term technical sustainability. That is, not only in respect of their end users (which is mostly granted through open components and their FOSS software stack), but equally respectful of the time and quality of work provided by their volunteers and developers. Just my two (euro) cents.

As a second side note, after writing this I shared my draft with a mobile Linux developer, to make sure the argument was sound enough. Interestingly, their own opinion was not too far:

The Linux mobile space has changed a lot since the PinePhone released, as with most companies Pine64 are feeling the pressure of always having their new devices be better than their old ones. [...] The problem is that Pine64 have no in-house developers, and thus no way to strive towards that goal. It seems to me that they're feeling the pressure of higher expectations from their users and attempting to push it onto community developers, demanding features get fixed. Making demands like this of developers who work in their free time not for you, but for the community, is completely unacceptable. I think it's high time Pine64 consider how they reinvest into the community.

I was also recommended a post which appears to express a similar point about PINE64's "weird priorities": that is, expanding in large (e.g., gathering more distros, releasing more devices) rather than in depth and quality. I will leave a link to it below.

Pine64 should re-evaluate their community priorities

The Pixel 3A was released in 2019 by Google as a cheaper alternative to the Pixel 4, and is powered by a Snapdragon 670 processor coupled with 4GB RAM, an OLED display, and a 3000mAh battery.  Being somewhat popular among the developer community, it was two years ago that this device obtained the first beta porting of Ubuntu Touch. The main reason for the popularity of the Pixel 3 is its compact form factor and excellent camera capabilities, and it was adopted very quickly after its release as a feasible candidate for Ubuntu thanks to its versatility and relatively powerful SoC.

What is new is that the Pixel 3A has finally reached a 100% "feature compatibility" score on the Ubuntu Touch page, making it fully able to run the OS stably and integrate it with all major existing peripherals, thus essentially enabling worry-free usage as a daily driver. In fact, not even the historically supported BQ Aquaris M10, Volla Phone and OnePlus One can currently boast the same 100% feature support score, although this is sometimes determined by subtleties in the onboard peripherals e.g. unsupported FM radio, not existing on newer models, or NFC, who arguably uses on a Linux phone nowadays.

Although this impressive achievement was only possible thanks to the growing UBPorts developer community and their long work, it is to be noted that this Ubuntu Touch porting runs on top of the original Android kernel provided by Google, coupled with the Halium 9.0 abstraction layer over the Android userspace. In fact, a "full mainline" porting with the same degree of features and stability is still to be seen of any Android phone.

But if features on mainline phones are yet too limited for your needs, this is a good chance to break out of the Google/Android ecosystem and transition to a Linux phone without losing too much in real-world stability over its original OS. For the moment, more details can be found on the official Ubuntu Touch device page.

Google Pixel 3a/3a XL • Ubuntu Touch • Linux Phone

Flash your Google Pixel 3a/3a XL with the latest version of the Ubuntu Touch operating system, a privacy focused OS developed by hundreds of people.

ubuntu-touch-logo

Via r/tuxphones (Reddit)

In the last year, we have seen an unexpected revival of handheld computers (or PDAs) with hardware keyboard, all of which based on Linux: the PinePhone with its keyboard case, the GPD series of mini-laptops and several others which we covered here last month. For those wondering, the main difference between these trendy miniaturized computers and "standard" Linux phones can often be just the lack of a cellular modem. In general, the board designs appear to be quite similar between PDAs and phones, and for most applications, a Linux PDA can be cheaper and just as useful as a fully fledged smartphone.

Back in 2019, the MNT Reform project promised a new laptop concept: being entirely self-made, radical (and rather punk-sexy) in style and functions, this Linux laptop focused on repairability, modularity (even for input devices!) and total openness of the platform firmware. The device was designed by Lukas Hartmann in Berlin, all of which based on the ARMv8, i.MX8MQ processor. Furthermore, the Reform sported a tiny OLED display above the keyboard for status monitoring, an open-source trackball, and replaceable stylus-shaped 18650 LiFePo4 batteries, all with entirely replicable PCB and hardware design.

MNT Reform: The Much More Personal Computer—MNT Research

Yet the PocketReform, a recently announced Linux PDA by MNT Research, appears at least as innovative as its predecessor: firstly because it is designed and assembled in Germany, although with some boards sourced from China, and secondly for being a partially EU-funded project rooted in the Berlin University of the Arts.

The first difference from other PDAs is the everyday customer oriented, yet radically open-source nature of this product. While not many technical details are known yet, the PocketReform will focus on a flexible, easily repairable hardware and structure, probably taken at least in part from the full-size Reform laptop. In the current prototype, the two wooden and plexiglass panels for the keyboard and display modules are connected by a hinge, with one circuit board, and likely one replaceable LiFePO4 battery.

Moreover,  according to its makers, crucial for the PocketReform is its modularity and durability, in the perspective of a circular economy model. Early renderings showed a miniature mechanical keyboard not unlike that of the Penkesu, alongside a tiny trackball and OLED display, which are not yet seen on the current prototype. In fact, the trackball could make for a satisfying BlackBerry-like feel and easy navigation even in traditional, not mobile-optimized Linux environments.

The PocketReform will likely accommodate the same SoM (System-on-Module) of its larger sibling, with on-board slots to connect wireless cards and other modules.

On the technical side, specifications are aligned with the Reform laptop: The PocketReform uses the same high-end NXP i.MX8 SoC as the MNT Reform, which is also that used by Purism's famous Librem 5 smartphone.

Its modular design supports a variety of base modules:

• NXP i.MX8M Plus (4× ARM Cortex-A53 @ 1.8GHz, 4 or 8 GB DDR4, Vivante GC7000UL GPU, NPU)
• NXP Layerscape LS1028A (2× ARM Cortex-A72, 8 or 16GB DDR4, Vivante GC7000UL GPU)
• Raspberry Pi CM4 (via Adapter, 4× ARM Cortex-A72, 8GB DDR4, VideoCore GPU)
• Pine SOQuartz RK3566 (via Adapter, 4× ARM Cortex-A55, 8GB DDR4, Mali G52 GPU)
• FPGA AMD/Xilinx Kintex-7 (for industrial use, RISC-V SoC possible)

Furthermore, this modularity allows to recycle modules from the standard Reform laptop.

The PocketReform uses a 7" Full HD IPS panel, plus an additional 4K micro-HDMI output. It uses an RGB-backlit ortholinear keyboard with mechanical switches, plus an optional customizable trackball.

RAM is determined by the base module, and eMMC storage alongside an NVME m.2 SSD slot can be found on the board. Moreover, the PocketReform offers several wireless capabilities, with Wi-Fi 802.11ac and Bluetooth 5.0 in the base model, plus an optional WWAN slot for 5G and 4G modems.

At 20 × 12.6 × 4.5cm, the PocketReform is somewhere in between a handheld and a netbook, and its thickness is wholly justified by the replaceable 18650 Lithium batteries (8000mAh) and overall modularity of the board. These can be charged by one of the two USB-C ports, which supports Power Delivery (PD). A micro-HDMI 4K output and an industrial Ethernet port are also present in the casing.

Many colours and finishes were showcased in renderings, from a slightly 2000-ish light blue tint, to solid gray, to the amazing wood-and-glass blend of the current prototype, which we would like to see replicated in production. In the end, the case will be either in (cyber-punkish) purple or black anodized aluminium, or in recycled PLA.

The PocketReform supports a range of OS that goes, interestingly, beyond Linux to include OpenBSD and even Plan9 ports.s

In conclusion, this new project looks intriguing to say the least. With funding at least partly ensured, and inheriting expectations from the MNT Reform as a quality product, hopes for the PocketReform are high. You can find more information in the official introduction post below.

Introducing MNT Pocket Reform—MNT Research

Photos from the official project page.

So far, cameras on Linux phones have been known for their extremely basic results. Lacking good sensors, premium optics, and most importantly good post-processing capabilities, the PinePhone's, extremely basic sensor cannot often offer the shots one would expect. Even on the Librem 5, which uses a somewhat better Samsung sensor, users often need heavy manual configurations to get basic shots.

However, the PinePhone Pro will include a respectable Sony IMX258 sensor, not unlike that used on many older Android devices, including the LG G6. This model in particular is one of the few Sonys with a working driver in the mainline kernel.

There is not, however, much we know about its implementation yet. Assuming a basic plastic lens mount, the sensor will definitely need some processing on the software side to achieve good results.

The first results we know about the PinePhone Pro camera come from Megi's log, maintained by one of the most productive mobile Linux contributors in the scene - if not one of the earliest PinePhone Pro users. More test pictures should be coming in the next weeks, hopefully.

The contrast and dynamic range look okay considering the low light of the shots, which brings hope for using a PinePhone Pro camera as something which will bring satisfying results in most condition.

In comparison, there are many samples of pictures taken with the non-pro PinePhone. Martijn maintains a folder of those, which are somewhat reminiscent of vintage film photography – and, of course, had to go through post-processing in Darktable to look they way they do.

Megapixels (31 pictures)

Photoflow

As another term of comparison, most known Librem 5 camera samples were taken by Sebastian "dos" Krzyszkowiak, a developer and enthusiast whose shots are probably the most successful results achieved from its camera.

Sebastian Krzyszkowiak (@dos@librem.one)

Attached: 1 image #shotonlibrem5 #librem5

Librem SocialSebastian Krzyszkowiak dos@librem.one

Librem 5 Photo Processing Tutorial – Purism

Purism makes premium phones, laptops, mini PCs and servers running free software on PureOS. Purism products respect people’s privacy and freedom while protecting their security.

PurismSebastian Krzyszkowiak

With upgraded sensors for native Linux mobiles, and moving closer to working cameras also on existing Linux phones, we may finally (and literally) see some light in the complex process of getting cameras to work on Linux phones. But explaining this alone might be worth a future article.

Via Twitter

As a software developer on the go, one of the very first use cases that I started investigating after installing Linux on my first tablet was that of using a portable device as a secondary display for another Linux machine. Ideally, this would happen wirelessly (or wired, if that involved lower power consumption), with unnoticeable delay, and - why not - even including real-time touchscreen input.

The journey, however, took longer than planned. Existing solutions, like VNC, tend to be strangely laggy, and others, like Miracast, are so deeply enclosed in proprietary protocols that they do not scale well to a bug-free experience on all devices. The first solution to this problem, at an even less stable stage than currently, was my most shared post ever on Twitter, so I decided to write a post on how this was done.

why is everyone liking my hacks
~ me, 2022

To start, let us split this problem in even smaller bits. Namely, components are:

• Virtual display handling: creating a fake video output. On Xorg, some GPU-specific hacks exist (probably Intel-only) vs Wayland (mutter)
• Video capturing: we assume that the windowing system grants enough permissions to capture the screen
• Video streaming: This, of course, needs to be fast. So real-time stream compressing and decoding is necessary.
• Network: This one is easy, at least on our side. By replacing most known network overhead (e.g. not relying on central Wi-Fi APs, getting rid of TCP packets, ...) and transmitting bare-bones UDP packets from point to point, we achieve significant gains in performance. In fact, even dropping wireless entirely and using Ethernet over USB (which e.g. postmarketOS supports) could further reduce latency.
• Display / decoding on host machine: as we said, needing fast video decoding is not obvious in the hellish landscape of fragmented ARM SoCs, and their many video decoders, some running over proprietary wrappers (e.g. Adreno), some over hacky adaptions of Android userspace (e.g. hybris), some supporting a ridiculously small subset of features in mainline (e.g. old Nvidia Tegras), and some not supported at all. Furthermore, with most ports using Android drivers, this needs to be reproducible on myriad of kernels also without mainline kernel!
• (Optional) input device handling: to get and transmit touchscreen events smoothly on the receiving screen, and map them as a real touch input on the host device. A little spoiler: I did not get here yet, and will not any time soon.

Decent reliability, easy reproducibility (even on downstream kernels) and acceptable latency are required.

The off-shelf solutions for streaming existing desktops (but not a virtual desktop) with are endless, and they include Deskreen (which communicates over WebRTC), or more simply an almost hidden feature in VLC that enables streaming and transcoding of the desktop, simple VNC,  and a myriad of open-source (X11, often semi-abandoned) and proprietary streaming apps. However, not all devices have a hardware HDMI port, and bringing a fake hardware adapter to trick the GPU into enabling a second video sink is chaotic to say the least. The alternative, at this point, is to use a Mutter-based desktop, or any other window manager with some sort of built-in interface for creating virtual screens in software.

After a few failed attempts, with latency in the range of seconds, I am starting to see some light. By getting rid of as many layers as possible, minimizing the overhead, and just trying the simplest hacks for raw streaming, performance is getting surprisingly acceptable: at 5Mbps bandwidth, this means over 10 FPS, and latency is probably around 200ms over good connections.

Prerequisites

• In particular, this solution requires the Mutter window manager (40+), so GNOME, Elementary, Budgie or other Mutter-based desktops. This clean D-Bus API is also an unified solution for virtual monitors between Wayland and Xorg. Theoretically, virtual monitors have also been supported by other window managers like KDE and Sway for a while, so adapting this solution should be relatively easy.
• You will also need a PipeWire enabled stack, so a very modern distribution such as Fedora 35+ or Arch Linux. In theory, you can use PipeWire for video also on a system using the now-legacy PulseAudio for handling sound
• Wi-Fi, working USB Ethernet, or any other network with acceptable latency
• Finally, hardware video acceleration on the receiver side is a must. Plain CPU video decoding will either lag behind the stream, or consume a lot of power in the process, or both.

Current st(h)ack

I created a Python script based on an older Mutter API demo script. This was modified to have bare-bones streaming, and requires the following D-Bus and command line interfaces:

• Mutter: to create a virtual display
• PipeWire: to manage the stream
• GStreamer: to compress/send/receive video between the two devices.

In particular, two commands are used. On the sender:

• pipewiresrc path=%u ! This starts the stream from PipeWire
• %s videoconvert ! ...and transcodes to x264 video stream
• x264enc tune=zerolatency bitrate=5000 speed-preset=superfast !
• rtph264pay ! ...encapsulates the stream
• udpsink host=... port=... ...and transmits it to the host via "raw" UDP

On the receiver:

• DISPLAY=:0 is optional, but allows invoking the script e.g. from headless sessions such as SSH. The display identifier may clearly differ (:1, :2, etc.)
• gst-launch-1.0 udpsrc port=... caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264" ! This receives the UDP stream
• rtph264depay ! avdec_h264 ! videoconvert ! ...decodes it,
• autovideosink sync=false ...and starts an auto-detected compatible video sink

Remember to install gstreamer1.0-tools or the equivalent package on the receiver.

How to test (pre-alpha)

Again, this is just the earliest working experiment. However, if you are not worried about this script probably not working in your case, here is the testing procedure:

• Download the script linked at the end of this post,
• Establish a network connection, point to point (aka: "computer to phone") if possible to minimize the switching and routing delay of far away access points.
  This can be done either via USB Ethernet, or more simply via Wi-Fi (e.g. with one device in AP/hotspot mode, and the other connected to it). Using "standard" Wi-Fi with an external router is also possible, but results in unreliable latency of around 0.5-1.5s.
• Get the (local) destination IP address of the receiver via ifconfig, or an equivalent, and run the command on the sender:
  python3 gnome-virtual-cast-and-stream.py -v {width} {height} {destination IP}
• Copy the "receiving command" from the console, and execute it on the receiving device, e.g. through SSH. You may need to adapt or remove the DISPLAY=:0 variable.

Results

This solution, which should minimize overhead to reasonable levels, depends highly on the decoding capabilities of the receiving devices:

• On CutiePi Tablet (Raspberry Pi CM4), using open-source drivers, this tool worked perfectly
• On a mainline Linux phone (Purism Librem 5), the virtual monitor experience was equally solid
• On an Intel i5 tablet, this solution also worked flawlessly
• However, on some older Qualcomm devices (tested on Snapdragon 820) this was seemingly much slower and glitchy. This is possibly due to the mainline Linux drivers for the Qualcomm Venus (V4L2) video decoder being immature, although replacing avdec_h264 with v4l2h264dec in the command above should enable Venus-based decoding.  (– thanks Yassine for the suggestion)
• On a Linux device with no video decoding or hardware acceleration, this will be inevitably slow

Generalizing

Needless to say, the priority would be to find ways to generalize this procedure to a wider share of Linux devices:

• KDE: This should already be possible at the moment. PipeWire and screencasting APIs are indeed present, and Kwin should support creation of virtual outputs to some extent
• Sway: there is an issue for this, and it may become possible in the future
• To X11-based desktops:  This is much simpler, although messier, than on Wayland. Creating virtual screens is supported, for example, by Intel GPU drivers, and screen capturing on this virtual sink is possible also without Mutter.
  However, in my experience, Xorg streaming is considerably glitchier, maybe due to the different buffering mechanism;
• To (possibly?) even lower overhead: Using network via USB, rather than Wi-Fi as in the demo seen above. Removing or replace the x264 codec for a faster alternative, reducing the latency of encoding and decoding the stream at the price of possibly higher bandwidth and power consumption;
• To Linux devices without GPU drivers and/or video acceleration (e.g. many Android phones with basic Linux support): replacing x264 with a raw stream might work better for CPU rendering, but it will remain a relatively painful and power-consuming experience;
• To many virtual screens: This works already as simply as launching several instances of the script on the transmitter, each pointing to a different target IPs and port. Provided that the wireless bandwidth is enough, and the higher power consumption is not a concern.

Conclusion

The road to a universal, usable solution is still long, but this is the first footprint of a working solution for the majority of devices and distributions. For the moment, a 100-line Python proof of concept is linked below.

TuxPhones / Side Displays · GitLab

Secondary wireless screen experiments

GitLab

After SXMO, the DWM-on-phone mod that became popular for its practical minimalism with the PinePhone, and the lesser known ExpidusOS XFCE-based shell, many of the traditional lightweight Linux desktops are receiving touch-friendly adaptions. A relatively new project, AVMultiPhone, is loosely based on the popular MATE desktop, which continues the GNOME 2 legacy experience with modern libraries such as Gtk3.

However, there is more to this than standard MATE. First and foremost, the touchscreen experience appears to be nearly complete, and generally usable. Secondly, a series of applets and configurations was added to ease the integration of details such as touchscreen keyboards.

The desktop can be tested as part of the "AVMultimedia" distribution, which is available for download on SourceForge in a PinePhone image, and was developed by the Swiss firm Archivista GmbH.

But apart from the above, not much is known about this desktop yet.  The blog post announcing a version 2, linked below, explains the project in depth, but the source code for this pre-alpha does not appear to be immediately available online, and the author suggests buying a book, or donating to their bank account to motivate any possible future development. Which, admittedly, is a peculiar approach to open-source.

AVMultiPhone V2

AVMultiPhone AVMultimedia Open Source PinePhone PostmarketOS Linux Android LineageOS e.foundation Havoc Pocket Computer Nokia N900 Smartphone

ArchivistaBox: Zero Maintenance DMS, ERP & VirtualizationArchivistaBox: Zero Maintenance DMS, ERP & Virtualization

Via LINMob (YouTube)

Following the first part of our review of the Purism Librem 14 laptop, this review focuses on software, multimedia usability, repairability, and long-term maintainability.

Disassembly and Repairability

When I asked Purism whether I was allowed to disassemble their sample, I received a very encouraging response – as if, in fact, this was given for granted to their experienced customers. Not only users are allowed to disassemble it, but official guides exist on replacing fundamental parts, and getting your hands dirty with component upgrades.

In fact, after removing the back metal plate through M2 star screws, held together by diagonally placed, very solid aluminium guides, this is nostalgically one of the few remaining laptops where components are supposed to be upgraded.

Justified by the promise of thinness, one often debunked by the abundant empty space in casing, most manufacturers solder RAM, SSDs and processors on circuit boards, pursuing a "buy and regret" philosophy: regret not spending an extra $200 on $50 worth of RAM upgrades, and for this reason seeing your laptop slow down in few years, or $300 for a slightly larger solid-state drive, at the time of purchase. After Apple, essentially all consumer laptops (including some ThinkPads) are taking the same route.

Purism pursues the opposite: total transparency of upgrades, with a variant of the standardized modular layout found in most older machines. In fact, not only can the m.2 NVMe SSD and DDR4 SO-DIMM RAM be upgraded from the base 8GB to up to 64GB (!) through standard slots, but the 4-cell Lithium battery can be downgraded to a smaller, 3-cell one if place for a second (SATA over m.2?) disk drive becomes a priority.

The network card can also be replaced by hand, popping it out of its m.2 slot, as is the case on the Librem 5.

The circuit board shows excellent soldering, with very solid connections, apart from some stray wires for replaceable circuitry (fans, etc.) held together by tape. There are some microswitches on the board, perhaps easing the re-flashing of onboard chips such as the EC (more below), and a physical RTC battery floating around, which in my test sample happened to attach to the magnet of one speaker cone, compressing it.

Display

As usual, I will skim on in-depth display judgement due to my inexperience in this department. At a first glance, the Full HD, 60Hz, IPS screen appears good, if anything enough to align with good IPS panels, with balanced colors and decent viewing angles. Brightness is just "okay" (probably around 300 nits?), making it hard to read in direct sunlight. On this side, most expensive consumer laptops go further, with 2K panels, 400- or 500-nits brightness, HDR, and such.

The matte finish is somewhat limiting compared to most glass assemblies used nowadays, which would provide enhanced contrast and brightness. But the majority of premium laptops, including new ThinkPads, still choose matte over glass, perhaps for its better durability, weight, and higher flex resistance. Similarly, Full HD panels tend to provide considerably better battery life than 2K+ counterparts, so given its "high enough" resolution on a 14" panel, it does its job respectfully.

Multimedia usability

Coming to the audio and video side of things, edges get rougher: the webcam is just okay for video calls, with narrow area and entry-level resolution. It does its job, but is just basic for videoconferencing.

The microphone appears to work without distortion, while speakers sound noticeably worse than on most high-end laptops: tinny and muddy in the default configuration, with an extreme emphasis of frequencies around the 1kHz mark, with any mid-bass presence covering the midrange, and somewhat artificial-sounding treble. This gives problems with clarity also in conversations.

I am also doubtful about the placement of the speakers: the stereo speaker cones look to be of good quality and generously sized, but perhaps due to the lack of a large enough acoustic "chamber" on their back, or due to the bottom-firing orientation, which is overly reliant on the resonance made by the bottom of the laptop rather than firing them to the outer world. In general, resonance is hard to handle correctly, and exploiting the "chamber" on the bottom of the laptop will significantly decrease quality if not tuned carefully.

Since audio is, in general, something I tend to pay particular attention to, I wanted to understand what made the speakers sound so disappointing. The answer is partly simple: lack of system-level software equalizer (which would need to be maintained as a custom PulseAudio daemon), or a hardware DSP, for the sake of a "vanilla" Linux experience. Thankfully, post-processing will fix part of this, but I believe that a slightly modified assembly of the same speakers (ideally facing in another direction) would solve most of their remaining issues.

Downloading PulseEffects and tuning the equalizer considerably optimized the speakers, bringing perceived sound quality from a 2/10 to a 5.5/10 or so, with vocals becoming clearly audible, and acquiring control over mid-bass. The base profile I used can be found on this page, although there is room for improvement from the suggested configuration: for example, the "maximizer" enabled by the maker of this profile can make sound levels inconsistent (if not be dangerous for the voice coils?), and recessing the artificial peak at 16kHz given by this profile makes the sound smoother and easier to appreciate in the long run.

Software: PureOS and beyond

What makes the experience so transparent is the upstream integration of the Librem hardware with vanilla Linux. For instance, no matter what distribution the user will run, firmware for all hardware components is upgradable through the fwupd interface, a project to unify all firmware upgrades in a single Linux userspace standard.

On the other hand, Purism's own PureOS is a strange choice for daily usage. This spin of Debian Stable appears mostly maintained as a sacrifice to the gods of the Free Software Foundation, from which PureOS gets the rare RYF (Respects Your Freedom) certification, and complies with its guidelines e.g. by removing all traces of non-free software, and not letting users enable non-free repos without manual work.

This means that out of the box, PureOS will not support Bluetooth, since the Atheros card is currently only open-source on the Wi-Fi side. Installing Bluetooth blobs should be possible, anyway.

Being based on Debian Stable means that packages might look relatively dated: for example, PureOS is based on GNOME 3.38 (September 2020), and the only Firefox to be found is ESR, the LTS variant designed for maximum stability. Although this leads to essentially zero bugs, PureOS will give one of the most conventional (if not lightest) Linux experiences around.

If GNOME is not your thing, PureOS also comes in a KDE spin. I did not test it, but random reviews of it found on the Internet appeared favourable at a first glance.

What needs emphasis here, for the sake of the free software spirit, is that the Purism will be as happy running any other distribution as it is on PureOS.

The Librem 14 has also been my test ground for the new Ubuntu 22.04. What I found in comparison with PureOS was a faster GNOME and similar boot time of applications (less than 2 seconds for LibreOffice Writer). For some reason, Ubuntu would still not recognize the Bluetooth card, with kernel logs asking to copy its required firmware blob to the system firmware folder.  So due to this bug, unless you copy the proprietary component by hand, there will be little risk of introducing proprietary drivers in your runtime.

Thanks to the lack of buggy, proprietary video drivers or such, the very new Ubuntu 22.04 is a joy to use on this laptop and looks just as smooth - if not more, thanks to GNOME's recent efforts to speed up the graphics through triple buffering and such. This is thanks to Purism being ethical in its development, and upstreaming every bit of their work (see fwupd) to make sure that no component collides not with PureOS, but with Linux in general.

Performance

Regarding the main components of the system, here are some considerations on the real and expected performance in the real world.

CPU

The Intel Core i7-10710U packs some real punch in its modest consumption. Being possibly the first laptop-oriented Intel with 6 physical cores (so 12 in hyperthreading), this SoC can get up to 4.7GHz during "boosts". In the PassMark benchmark, this chip achieves 10126 points.

GPU

The Librem 14 uses the built-in Intel HD Graphics 620 rather than a dedicated video card. The performance looks good under normal loads, although applications such as heavy demanding gaming will not be too suited to the Librem. As known, avoiding the ubiquitous Nvidia video cards makes the most part in an essentially bug-free Linux experience. Without Thunderbolt on the USB-C port, there is no support for plug-and-play eGPUs.

Wireless connectivity

The Wi-Fi and Bluetooth card used in the Librem 14 is the Atheros AR9462, one of the very few that can run entirely on open-source firmware.

However, this brings to two issues: firstly, wireless looks to be considerably slower than that used on my Dell (Killer / Qualcomm), also in 5GHz mode, resulting in around -25/-30% of speed. Similarly, the antenna reception on the Atheros was considerably worse than Dell's, and moving too far from the router resulted in abrupt speed drops. Tthe reported signal strength (dB-wise) was identical nearly identical between the two laptops, so the wireless card might be the bottleneck in this case. In any case, a manual wireless card is trivial to perform.

Secondly, as mentioned above, there is no Bluetooth support, unless proprietary firmware blobs from linux-firmware are installed.

SSD

The storage device used in our sample was a Samsung 970 Evo Plus, 512GB NVME m.2 drive, which is a widely popular solid-state disk, and received 4.5/5 stars for its performance in a Tom's Hardware review. As said above, you can also add a secondary SATA drive, if you are willing to sacrifice the large, 4-cell battery for a 3-cell one.

Battery

The large 4-cell, 8800mAh battery from our sample was good enough for us to forget the charger at home without issues, and the declared life of 9 hours and 48 minutes sounds reasonable under light loads.

(attach graph?)

Alternatives

Apart from the long glorified (yet outdated) old ThinkPads, one modern device that could be considered competition to the Librem 14 is Framework, from the homonymous startup aiming at a fully (port-wise) modular laptop. Yet the Framework does not come with software freedom (shall we say libreness?) in mind, being shipped with Windows in its "consumer" version, and neither providing a trustable, open circuit board, nor all the security measures of the Librem. And for those wondering, you can run Windows 11 on the Librem 14 as well, in case you really cannot do without.

Another vaguely similar device, the MNT Reform, brings Purism's values of hardware openness to the extreme: being based on a custom-made modular board, with most components redesigned from scratch and running on custom firmware, all on top of an ARM i.MX8 processor such as that used in the Librem 5 smartphone, the Reform makes a much slower, possibly less practical, but probably even more libre device for a similar price.

Additionally, more conventional business laptop lines such as HP's Elitebook series (or System76's?) will resemble the Purism for a similar price tag. But they are considerably less security-focused, tend to use many proprietary components down to the BIOS, and with no attention to Linux drivers, luck will be needed to run Linux as smoothly.

Conclusions

With the Librem 14, Purism happened to find a market niche in which, so far, not much competition is to be seen. What Purism did here was not only achieving one of the cleanest hardware boards on the market, but caring about the software to the point of rewriting big parts of firmware for the sake of security and software longevity.

The target for this laptop is actually wider than it looks: it is a sleek, minimalistic black device with good hardware. The price tag is on the higher side, but in line with other business-oriented laptop brands, and top-notch security comes in the package. I could imagine anyone from programmers to security-conscious political figures enjoying a device like the Librem 14. From the impression that I received from using it, this laptop is designed to be a trustable daily driver, in the way it "just works", cannot physically leak most of your data while you are using it, and cannot easily be compromised without a Pureboot scan warning you.

Some products are designed to produce immediate enthusiasm when you see them, giving the so-called "wow effect", and others that are machines that you will grow to love with time. At first, when I booted the Librem 14, it did not look that different from the HP EliteBook I had at work. But then, seeing the obsessively clean, no-frills boot and bug-free experience during my usage, I quickly grew to love the product after turning it on and see how its software would never let me down during weeks of use.

My experience with most newer ultrabooks throughout the last years was the opposite: shiny at a first glance, yet hiding flaws in hardware quality, nearly phone-like soldered boards for the sake of profit, and quickly deteriorating software due to abandoned proprietary drivers (not only on Linux).

The Librem 14 is the opposite: with minimal design, a fairly standard display, and no impressively tiny bezels, this is rather a mature machine that you will be happy to rely on. If you can give up rock-solid stability, you might enjoy breaking out of PureOS to experience the forbidden pleasure of Fedora or any more bleeding-edge distro, while also enabling the Bluetooth card and getting wireless audio to work properly.  Just, if you switch distro, do not forget to keep the disk encrypted.

This was the second part of our Purism Librem 14 review. For the first part, click here.