Hacker News new | ask | show | jobs
by Abishek_Muthian 2413 days ago
Incase you're ordering the PinePhone & looking forward to jump on Linux development; check out Ubuntu Touch by UBPorts[1].

UBPorts community have done a commendable job in continuing Ubuntu Touch development after canonical left it. Even Nexus 4 receives regular updates, albeit old kernel due to libHybris

Ubuntu Touch is the most accessible Linux phone now because of their support to older available devices. Unfortunately, they don't get enough attention as Purism or PostmarketOS gets.

Hopefully, PinePhone should change it.

[1]:https://forums.ubports.com/topic/2403/pinephone

4 comments

"Commendable job" is about the only praise I can give, sadly.

I just spent the last two weeks attempting to get an Ubuntu Touch phone to work as a mobile transceiver / network hub for a BLE peripheral that my company is developing. Our device works very well with the standard Linux bluez stack and tools (bluetoothctl, hcitool, etc.), so we thought that this would be the easier route for a one-off project than developing an Android app from scratch, given Android's BLE quirks (e.g. minimum notification interval of 11.25 ms instead of the 7.5 ms that the BLE spec requires -- we have a high bandwidth device that needs the shorter interval).

It was a nightmare, and we eventually gave up and wrote an Android app.

Can you go into actual development issue? Was it the QT or were you trying to run a Linux binary.
We were trying to interface with bluez (the Linux kernel Bluetooth stack, which exposes a D-Bus API) in order to communicate with our device, and no method we tried was able to get past opening the initial connection (no MTU negotiation, no connection interval selection, no service discovery, etc.). It was an old kernel, so it could have been bugs in the bluez implementation from that era, or bugs in the firmware blob of the BLE chipset (it worked on the same hardware running Android, but we didn't verify whether the BLE firmware blob was the same).

The argument in favor of this approach was that it was supposed to look and feel "just like normal Linux" which is where we do most of our development work. Unfortunately, this just isn't the case. I think the two biggest issues are:

1. ubports uses an Android kernel, and although it's 99% pure Linux, Android kernels usually disable a lot of things that your typical Linux machine expects and that some libraries rely on (e.g. most IPC mechanisms). This is really frustrating to work around.

2. This one could just be my lack of experience with these things, but the AppArmor security policies and the weird container setup slowed me down a lot and made the system unpleasant to work on. This didn't really cause an issue, but it made working with the system unpleasant.

> Unfortunately, they don't get enough attention as Purism or PostmarketOS gets.

I didn't know of this project, however my first thought at putting the ideas "ubuntu" and "phone" together would be: another phone that doesn't respect you.

This comes from the way ubuntu forces stuff you might not want, like the amazon app, telemetry and stuff like snap.

I might be thinking unfairly.

(meanwhile purism takes great pain to think of the user compassionately via GPL)

Amazon searches were a huge mistake of theirs, but they don't force anything, you don't have to use snap or submit telemetry. Much bigger problem with Canonical is they think it's okay to have some tightly integrated bits and pieces that are proprietary and not to contribute some fixes upstream.
> you don't have to use snap

I have to disagree. My experience trying to disable or remove snap led me to believe they designed it to be hard.

UBPorts Ubuntu Touch apps are GPL, they have their Appstore called OpenStore.
That UBPorts forum is the worst implementation of a discussion thread I've ever seen. Infinite scroll vs. pagination makes it impossible to ever go back and find something quickly, for instance.
I used ubports for a bit. Liked it a lot, very stable. If it had anki and authy I would have stuck with it, and they had plans at the time to support android apps via emulation