flypig.co.uk

Sailfish OS

Sailfish OS is the operating system that powers the Jolla smartphone. It's an evolution of the Maemo/MeeGo Linux distribution that started life on the Nokia tablets back in 2005.

During its rather tumultuous life it's evolved from a trailblazing tablet OS to possibly one of the most open and interesting smartphone OSes. Applications are built using the venerable QT framework with gestures and dialogue stacks at the core of its approach to interaction. At the same time it's a true Linux distribution allowing existing applications to be rebuilt and redeployed easily (you can even fire up GCC on the phone to build them in situ or hack away at Python if that's your bag).

Personally I've been using Maemo/SailfishOS since buying an N810 around 2008, followed by an N900 and then a Jolla phone. On this page you can find out about some of the software I've developed for the OS, as well checking out my 3D printed The Other Half covers produced in agreement with Jolla.

Sailfishos

16 Sep 2020 : Contrac 0.6.2 released #
I've just pushed the latest changes to github and made Contrac 0.6.2 available from OpenRepos. This update adds new Chinese translations and fixes a bug that prevented the update button from being used daily (a borked calculation meant you could only update every two days, or thereabouts).
14 Sep 2020 : Contrac 0.6.1 released #
After a busy weekend of work, Contrac 0.6.1 is now available from OpenRepos and with code on github. The latest improvements include Chinese translations (thanks to the sterling work of dashinfantry) a homescreen cover, attenuation value configuration, and risk configuration downloaded from the Corona-Warn-App servers to ensure the risk evaluations mirror the official app.
6 Sep 2020 : Contrac 0.5.1 released #
The latest version of Contrac now analyses the keys downloaded from the server against thoe collected using Bluetooth and provides an up-to-date risk assessment for the user. This is a pretty big step, because it means the app now has all the pieces needed to perform the full exposure notification cycle (diagnosis upload, key download, exposure analysis). There are still plenty of potential improvements of course, the main one being that it needs to be plugged in to the official severs rather than my test server, but hopefully that'll come soon. In the meantime, get it from OpenRepos and github.
1 Sep 2020 : Contrac 0.4.1 released #
Version 0.4.1 of Contac, an exposure notification app compatible with Germany's Covid-Warn-App is now available from OpenRepos and github. This latest version adds a bunch of improvements behind-the-scenes, including the encrypted metadata component of the BLE beacons and an improved data aggregation algorithm.
24 Aug 2020 : Contrac 0.3.1 alpha now available #
The new version of Contrac is now available from OpenRepos and github. This is a small, but hopefully useful, update. The daemon now has persistent state, so if it's set to scan/advertise for beacons it will remain in that state even after a restart.
22 Aug 2020 : Contrac 0.2.1 alpha now available #
Another Contrac update. It now has a page to allow users to enter an officially-provided TeleTAN so that they can upload their diagnosis keys from the app to the Corona-Warn-App servers. This latest version is available from OpenRepos and as always the source is also available from github.
9 Aug 2020 : Contrac 0.1.1 alpha now available #
The second release of Contrac is now available from OpenRepos. This version allows uploads to and downloads from the official Corona-Warn-App servers, although currently it's only set up to interact with the test servers.
7 Jul 2020 : Contrac 0.0.1 alpha now available #
The first release of Contrac, my Corona-Warn-App-compatible Exposure Notification app for Sailfish OS, is now available from OpenRepos. This is very much an alpha version, intended just for testing. It'll send and receive the GApple BLE beacons and store the results, but there's no capability to interact with the servers just yet.
11 Apr 2020 : Google/Apple's “privacy-safe contact tracing“, a summary #
As I discussed yesterday, Google and Apple recently announced a joint privacy-preserving contact tracing API aimed at helping people find out whether they'd been in contact with someone who subsequently tested positive for COVID-19.

We've already relinquished so many rights in the fight against COVID-19, it's important that privacy isn't another one, not least because the benefit of contact tracing increases with the number of people who use it, and if it violates privacy it'll rightly put people off.

So I'm generally positive about the specification. It seems to be a fair attempt to provide privacy and functionality. Not only that, it's providing a benchmark for privacy that it would be easy for governments to fall short of if the spec weren't already available. Essentially, any government who now provides less privacy than this, is either incompetent, or has alterior motives.

But what does the spec actually say? Apple and Google have provided a decent high-level summary in the form of a slide deck, from which the image below is taken. They've also published a (non-final) technical specification. However, for me the summary is too high-level (it explains what the system does, but not how it works) and the technical specs are too low-level (there's too much detail to get a quick understanding). So this is my attempt at a middle-ground.
 
A high-level overview of the approach

There are three parts to the system. There's the OS part, which is what the specification covers; there's an app provided by your regional health authority; and there's a server run by your regional health authority (or more likely, a company the health authority subcontracted to). They all act together to provide the contact tracing service.
 
  1. Each day the user's device generates a random secret $k$, which stays on the user's device for the time being.
  2. The device then broadcasts BLE beacons containing $h = H(k, c)$ where $H$ is a one-way hash function and $c$ is a counter. Since $k$ can't be derived from $h$, and since no pair of beacons $h_1, h_2$ can be associated with one another, the beacons can't in theory be used for tracking. This assumes that the BLE subsystem provides a level of tracking-protection, for example through MAC randomisation. Such protections don't always work, but at least in theory the contact-tracing feature doesn't make it any worse.
  3. The device also listens for any beacons sent out by other users and stores any it captures locally in a list $b_1, b_2, \ldots$.
  4. If a user tests positive for COVID-19 they are asked to notify the regional health authority through the app. This involves the app uploading their secret $k$ for the day to a central database run by the regional health authority (or their subcontractor). From what I can tell, neither Apple nor Google need to be involved in the running of this part of the system, or to have direct access to the database. Note that only $k$ is uploaded. Neither the individual beacons $h_1, h_2, \ldots$ sent, nor the beacons $b_1, b_2, \ldots$ received, need to be uploaded. This keeps data quantities down.
  5. Each day the user's phone also downloads a list $k_1, k_2, \ldots, k_m$ of secrets associated with people who tested positive. This is the list collated each day in the central database. These keys were randomly generated on the user's phone and so are pseudonymous.
  6. The user's phone then goes through the list and checks whether one of the $k_i$ is associated with someone they interacted with. It does this by re-calculating the beacons that were derived from this secret: $H(k_i, 1), H(k_i, 2), \ldots, H(k_i, m)$, and compares each against every beacon it collected the same day.
  7. If there's a match $H(k_i, j) = b_l$, then the user is alerted that they likely interacted with someone who has subsequently tested positive. Because the phone also now knows the counter $j$ used to generate the match, it can also provided a time for when the interaction occurred.

This is a significant simplification of the protocol, but hopefully gives an idea of how it works. This is also my interpretation based on reading the specs, so liable to error. By all means criticise my summary, but please don't use this summary to criticise the original specification. If you want to do that, you should read the full specs.

Because of the way the specification is split between the OS and the app, the BLE beacons can be transmitted and received without the user having to install any app. It's only when the user tests positive and wants to notify their regional health authority, or when a user wants to be notified that they may have interacted with someone who tested positive, that they need to install the app. This is a nice feature as it means there's still a benefit even if users don't immediately install the app.

One of the big areas for privacy concern will be the behaviour of the apps provided by the regional health authorities. These have the ability to undermine the anonymity of the system, for example by uploading personal details alongside $k$, or by tracking the IP addresses as the upload takes place. I think these are valid concerns, especially given that governments are notorious data-hoarders, and that the system itself is unlikely to be built or run by a health authority. It would be a tragic missed opportunity if apps do undermine the privacy of the system in this way, but unfortunately it may also be difficult to know unless the sourcecode of the apps themselves is made available.
 
Comment
10 Apr 2020 : Initial observations on the joint Google/Apple “privacy-safe contact tracing” specification #

Apple and Google today announced a joint protocol to support contact tracing using BLE. You can read their respective posts about it on the Apple Newsroom and Google blog.

The posts offer some context, but the real meat can be found in a series of specification documents. The specs provide enough information about how the system will work to allow a decent understanding, albeit with some caveats.

With so much potential for misuse, and given that mistrust could lead to some people choosing not to use the system, it's great that Google and Apple are apparently taking privacy and interoperability so seriously. But I'm a natural sceptic, so whenever a company claims to be taking privacy seriously, I like to apply a few tests.
 
  1. Are the specs and implementation details (ideally sourcecode) freely and openly available?
  2. Is interoperability with other software and devices supported.
  3. Based on the information available, is there a more privacy-preserving approach that the company could have gone with, but chose not to?
The answers to these appear to be "yes" (but not the sourcecode), "mostly" and "no". It's quite unusual, even for companies like Apple that make bold claims about privacy, to satisfy any one of these, let alone more than one, so this is genuinely very encouraging. Based on the specs released so-far, it seems that this has been a good-faith attempt to achieve both protection and privacy.

The catch is that the API defined by the specs provides only half of a full implementation. Apple and Google are providing an API for generating and capturing BLE beacons. They don't say what should happen to those beacons once they've been captured. Presumably this is because they expect this part of the system to be implemented by a third-party, most likely a regional public health authority (or, even more likely, a company that a health authority has subcontracted to).

Again, this makes sense, since different regions may want to implement their own client and server software to do this. In fact, by delegating this part of the system, Google and Apple strengthen their claim that they're acting in good faith. They're essentially encouraging public health authorities and their subcontractors to live up to the same privacy standards.

Apart from the privacy issues, my other main interest is in having the same system work on operating systems other than iOS and Android. My specific interest is for Sailfish OS, but there are other smartphone operating systems that people use, and locking users of alternative operating systems out of something like this would be a terrible result both for the operating system and for all users.

Delegation of the server and app portions to health authorities unfortunately makes it highly unlikely that alternative operating systems will be able to hook into the system. For this to happen, the health authority servers would also need to provide a public API. Google and Apple leave this part completely open, and the likelihood that health authorities will provide an API is unfortunately very slim.

I'd urge any organisation planning to develop the client software and servers for a fully working system to prove me wrong. Otherwise alternative operating system users like me could be left unable to access the benefits of the system. This reduces its utility for those users to nill, but it also reduces the effectiveness of the system for all users, independent of which operating system they use, because it increases the false negative rate.

There's one other aspect of the specification that intrigues me. In the overview slide deck it states that "Alice’s phone periodically downloads the broadcast beacon keys of everyone who has tested positive for COVID-19 in her region." (my emphasis). This implies some form of region-locking that's not covered by the spec. Presumably this is because the servers will be run by regional health authorities and so the user will install an app that applies to their particular region. There are many reasons why this is a good idea, not least because otherwise the amount of data a user would have to download to their device each day would be prohibitive. But there is a downside too. It essentially means that users travelling across regions won't be protected. If they interact with someone from a different region who tests positive, this interaction won't be flagged up by the system.

The spec is still very new and no doubt more details will emerge over the coming days and weeks. I'll be interested to see how it pans out, and also interested to see whether this can be implemented on devices like my Sailfish OS phone.
 
Reference to region-locking, taken from the overview slide deck
Comment
15 Sep 2019 : Sailfish app updates - Scintillon and GetiPlay #
Not just one but two new versions of my Sailfish apps are now available for download. GetiPlay has been updated to version 0.9 and now uses the latest ffmpeg and AtomicParsley utilities under the hood, which will hopefully lead to better audio and video rendering. There's also now an i486 version available for the first time. Scintillon has also seen an update to version 0.3. This latest version has Italian translations provided by the brilliant Francesco Vaccaro of Jolla-IT fame. Thanks Francesco!

 

10 Sep 2019 : GetiPlay 0.8-1 released #

Version 0.8-1 of GetiPlay is now available, refreshed with the latest version 3.22 of the amazing get_iplayer and updated perl modules. After some recent glitches, this will now work again with the iPlayer catch-up service for downloading BBC TV and radio programmes to your Sailfish OS device (probably UK-only I'm afraid). Install the binary to your phone from OpenRepos, or get the source from GitHub.

 

25 Aug 2019 : Scintillon gets 中文简体 (Chinese) translations #
I'm thrilled to announce that Scintillon, my Philips Hue app for Sailfish OS, now has Simplified Chinese translations included, thanks to the amazing efforts of Rui Kon! The app is up on OpenRepos and the Jolla Store, but it may take a couple of days for the changes to make their way through the Jolla Store validation process. 
 
Comment
19 Aug 2019 : Scintillon - Philips Hue app for Sailfish - release #
Oooh. Is that a new app release? Yes it is! Scintillon is a smart home app for Sailfish OS that allows you to control your Philips Hue lights. It's early days, with free bugs and missing features, so still very much a beta release. But I'm using it every day to control the lights in my flat, so it might be useful for some other Sailfish OS user out there too. Get all the details are on the Scintillon page, binary from OpenRepos and source from GitHub.  
 
2 Jun 2019 : Pedalo... delayed Sailfish OS addition #
Back last year when I released Pedalo, a privacy-preserving app for measuring your relative cycling performance for Sailfish OS, I somehow forgot to add the download info. I've now added it to the Pedalo page.
24 Mar 2019 : GetiPlay 0.7-1 released #
Here's the changelog for the just-released version 0.7-1 of GetiPlay. More details below, from OpenRepos or github.

Sun Mar 24 2019 David Llewellyn-Jones <david@flypig.co.uk> 0.7-1
  1. Correct iterator errors when deleting media files and items from queue.
  2. Correctly trim logfile and prevent UI performance degradation over time.
  3. Correct an incorrect RPM configuration.
  4. Remove cyclic dependences in QML.
  5. Fix various other QML errors.
  6. Add scroll animation when clicking on tab to jump to the top of the page.
  7. Allow control using the lockscreen media (MPRIS) controls.
  8. Improve the button layout on the queue item info screen.
Comment
24 Mar 2019 : GetiPlay 0.7-1 released #
I've just rleleased the latest version of GetiPlay (v0.7-1), an unofficial iPlayer app for Sailfish OS that lets you download and watch BBC TV and radio programmes. More details on the GetiPlay page, install the binary from OpenRepos, or get the MIT-licensed source code from github.
Comment
31 Jul 2018 : Pedalo 0.2-1 sails into harbour #
The latest version of Pedalo, version 0.2-1, has passed through the harbour validation and checks, and is now available for download from the Jolla store. If you're on Sailfish OS, and like to pedalo (or cycle), then grab yourself a free copy and get cycling.
19 Jul 2018 : Pedalo #
If you're a ardent pedalo user, and your mobile phone OS of choice is Sailfish, you should definitely check this new page on the site.
18 Jul 2018 : Pedalo approved! #
My Pedalo app was just approved for release in the Jolla App Store. Exciting times!
Pedalo is now approved!
 
29 Jun 2018 : Going QML-Live #

In my spare time I've been developing a QT app called GetiPlay. It's a simple app that allows you to download audio and video from BBC iPlayer, for use on Sailfish OS phones. The traditional approach on Linux devices would be to use get_iplayer in a console, but for all of the progress that's been made on mobile devices in the last decade, console use still sucks. Given I spend so much time listening to or watching BBC content, slapping a simple UI over the command line get_iplayer was an obvious thing to do.

The app has been developing nicely, using the QT Creator for C++ and the UI written in QML. Historically I've not been a fan of QML, but as I grow more familiar with it, it's been growing on me. For all of the things that I find weird about it, it really does give great performance and helps build a consistent UI, as well as promoting loose coupling between the UI and underlying functional logic.

A big downside to QML is that there's no preview, so the development process follows a consistent cycle: adjust code, build code, deploy code, test, repeat. The build and deploy steps are loooong. This impacts things in three serious ways: it makes development slow, it makes me sleepy, and it incentivises against making minor tweaks or experimentation.

Is It Worth the Time?
 

Nevertheless, there's always a trade-off between configuring and learning new technologies, and just getting things done using those you're already using. The ever-relevant XKCD has more than one pertinent comics covering this topic.

 
Automation

The UI for GetiPlay is straightforward, so I was quite content to use this lengthy, but (crucially) working approach until yesterday. What prompted me to change was a feature request that needed some more subtle UI work, with animated transitions between elements that I knew would take a couple of hundred cycles round that development loop to get right. Doing the maths using Randall Munroe's automation matrix, I needed to find a more efficient approach.

So this morning I started out using QML Live. This is a pretty simple tool with an unnecessarily bulky UI that nevertheless does a great job of making the QML design approach more efficient. You build and run the app as usual, then any QML changes are directly copied over to the device (or emulator) and appear in the app immediately. Previously a build cycle took between 40 and 100 seconds. Now it's too quick to notice: less than a second.

QT Creator IDE and QML-Live

Using a quick back of the envelope calculation, I'll perform a UI tweak that would previously have required a rebuilt around 20 times a day, but probably only every-other day, so let's say 10 times a day for the next six months. So (10 * 365 * 0.5) / (60 * 24) = 1.27 days I can save. I spent about half a day configuring everything properly, so that leaves a saving of 0.77 days, or 18 hours. Not bad!

QML-Live certainly isn't perfect, but it's simple, neat and has made me far more likely to try out interesting and experimental UI designs. Time configuring it is time well spent, even if that extra 18 hours is just about the same amount of time I wasted dithering over the last two days!

Comment
29 Jun 2018 : GetiPlay v0.6-1 released #
Another exciting GetiPlay update. This new version has improved aesthetics, the ability to directly download a programme using the PID or URL from the BBC website, configurable skip/replay buttons in the media player. It also fixes the issues experienced on Jolla One and Jolla C devices refreshing with multiple connections by allowing the number to be limited to one or two (in which case, there don't seem to be any more failures generated). Get it from the - usual - places.
20 Jun 2018 : GetiPlay v0.5-2 released #
A few more updates to GetiPlay, including a bundle of bugfixes; getting it working across multiple devices (Jolla One, Jolla C, Xperia X); using different graphics resolutions for different devices; persistent tab selection across executions. Plus, did I mention bugfixes? As always, get it from the - usual - places.
13 Jun 2018 : Another GetiPlay release: 0.4-2 #
This is a bug-fix release, to add in dependencies that should have been there from the outset. This ensures the app will install and run on more devices. Get it from the - usual - places.
12 Jun 2018 : GetiPlay 0.4-1 released #
The latest version of GetiPlay is now available. This version has built-in media players for video and audio, including the exciting and innovative '10 seconds back' button. Get it from GitHub, OpenRepos, or this site.
12 Jun 2018 : GetiPlay now actually plays, too #
For some time now I've been meaning to add a proper media player to GetiPlay. Why, you may well ask, bother to do this when Sailfish already has a perfectly good media player built in? Well, there are two reasons. First, for TV and radio programmes, one of the most important controls you can have is 'jump back a few seconds'. I need this when I'm watching something and get interrupted, or miss an important bit of the narrative, or whatever. It's such a useful button, it's worth writing a completely new media player for. Second, it's just far more seamless to have it all in one application.

So I finally got to adding it in. Here's the video player screen.
 

The QT framework really does make it easy to add media like this. It still took a good few days to code up of course, but it'd be a lot quicker for someone who knew what they were doing.

I'm also quite proud of the audio player, with the same, super-useful '10 seconds back' button. It also stays playing no matter where you move to in the app. Here it is, showing the controls at the bottom of the screen.
 


If you'd like to get these new features in your copy of GetiPlay, just download the latest version from OpenRepos, grab yourself the source from GitHub, or check out the GetiPlay page.
Comment
10 Jun 2018 : GetiPlay 0.3-3 released #
This is basically a bug-fix release. Earlier versions had dependency problems, preventing them working on a clean Sailfish OS phone. This version, hopefully, gets all that stuff right, so it should install working out-of-the-box. Thanks to Robin Weston for working with me to get it sorted.
Get it from GitHub, OpenRepos, or this site.
Comment
6 Jun 2018 : Huge GetiPlay release 0.3-1 #
I'm really pleased to release version 0.3-1 of GetiPlay, the unofficial interface for accessing BBC iPlayer stuff on Sailfish OS. This latest version is a huge update compared to previous releases, with a completely new tab-based UI and a lovely download queue so you can download multiple programmes without interruption.

Immediate info about every one of the thousands and thousands of TV and radio programmes is also now just a tap away.

Install yourself a copy from OpenRepos, grab the MIT-licensed source from GitHub or visit the GetiPlay page on this site.
 
Comment
16 May 2018 : GetiPlay update v0.2-6 #
The latest GetiPlay for Sailfish OS phones is now up on OpenRepos. This update has the latest get-iplayer (v3.14, which is always one of the most exciting version numbers to hit!) and I'm hoping will get the perl dependencies right (after literally years of trying). The code is on github.
Comment
10 Mar 2017 : Minor Pico victories #
Late last night (or more correctly this morning) my SailfishOS phone completed its first ever successful authentication with my laptop using Pico over Bluetooth. A minor, but very fulfilling, victory. One step close to making Pico a completely seamless part of my everyday life.

Authentication-wrangling results
Comment
22 Sep 2016 : ownNotes 1.8.6 for Sailfish OS #
A new version of ownNotes is now available. The main difference is a fix to allow it to work with more ownCloud installations (specifically, it now also works on installations where the domain root requires different credentials than the ownCloud subfolder). As before the source is on GitHub and the RPM on OpenRepos.
Comment
18 Sep 2016 : New ownNotes release 1.8.4 #
Now the new version of ownNotes is available on OpenRepos, and the source is up on GitHub, there's also a page around here somewhere to pull everything together. Thanks go to Benoît Hervier (Khertan) for kindly allowing me to make the new release now he's no longer supporting the Sailfish version.
Comment
10 Feb 2016 : GetiPlay added #
Added GetiPlay to the Sailfish OS downloads page. Probably a bit premature, since it won't work without manual installation of some Perl packages on your phone. I've not been able to figure out how to add them to the RPM.
Comment
7 Apr 2015 : Sailfish Really Is Linux #
One of the great things about smartphone operating systems is that, despite being really quite mature, they're nonetheless still fairly well differentiated. This means there are good reasons to choose one over another. For example iOS has a very mature app ecosystem, but with restrictions that prevent some types of software being made available (crucially restrictions on software that downloads other code). In contrast, Android and Google Play have much more liberal policies. This results in a broader ecosystem, but where the overall average quality is often said to be lower.

Android also has the claim of being Linux, which in theory means it has access to the existing - incredibly mature - Linux software ecosystem. In practice for most people this is moot, since their focus is on the very different type of software available from the Play Store. For developers though, this can be important. For me the distinction is important partly because I'm already familiar with Linux, and partly as a matter of principal. In my world computing is very much about control. I love the idea of having a computer in my pocket not because it gives me access to software, or as a means of communication, but because it's a blank slate just waiting to perform the precise tasks I ask of it. That sounds authoritarian, but better to apply it to a computer than a person. I'm pretty strict about it too. Ever since being exposed to the wonder of OPL on a Psion 3a (way back in 1998), direct programmability has always been one of the main critiera when choosing a phone.

This weekend was the Easter Bank Holiday, meaning a lengthy train ride across the country to visit my family. I wanted to download some radio programmes and possibly some videos to watch en-route, but didn't get time before we set off. I'd managed to install the Android version of BBC iPlayer on my Jolla, but for some reason this doesn't cover BBC Radio, which has been split off into a separate application. Hence I embarked on a second journey while sitting on the train: installing get_iplayer entirely using my phone. This meant no use of a laptop with the Sailfish IDE, and building things completely from source as required.

The experience was enlightening: during the course of the weekend I was able to install everything from source straight on my phone. This included the rtmp streaming library and ffmpeg audio/video converter all obtained direct from their git repositories, all just using my phone.

Banished downloaded using get_iplayer

Why would anyone want to do this when you can download the BBC radio app from the store? You wouldn't, but I still think it's very cool that you can.

Here's how it happened.

get_iplayer is kind-of underground software. It shouldn't really exist, and the BBC barely tolerates it.

It's written in Perl and is currently available from http://www.infradead.org/get_iplayer. Getting it is just a matter of running the following command in the shell:

git clone git://git.infradead.org/get_iplayer.git

Perl is already installed on Sailfish OS by default (or at least was on my phone and is in the repositories otherwise). There were some other Perl libraries that needed installing, but which were also in the repositories. I was able to add them like this:

pkcon install perl-libwww-perl
pkcon install perl-URI

Because it's Perl, there's no need to build anything, and at this point get_iplayer will happily query the BBC listing index and search for programmes. However, trying to download a programme generates an error about rtmpdump being missing.

The rtmpdump library isn't in the Sailfish repositories, but can be built from source really easily. You can get it from http://rtmpdump.mplayerhq.hu, and I was able to clone the source from the git repository:

git clone git://git.ffmpeg.org/rtmpdump

Building from source requires the open-ssl development libraries, which are in the repositories:

pkcon install openssl-devel

After this it can be built (although note developer mode is needed to complete the install):

cd rtmpdump
make
devel-su
make install
cd ..

As part of this build the librtmp library will be created, which needs to be added to the library path.

echo /usr/local/lib > /etc/ld.so.conf.d/librtmp.conf
ldconfig

This should be enough to allow programmes to be downloaded in flv format. However, Sailfish won't be comfortable playing these unless you happen to have installed something to play them with. get_iplayer will convert them automatically as long as you have ffmpeg installed, so getting this up and running was the next step. Once again, the ffmpeg source can be cloned directly from its git repository:

git clone git://source.ffmpeg.org/ffmpeg.git

ffmpeg installation

The ffmpeg developers have done an astonishing job of managing ffmpeg's dependencies. It allows many extras to be baked into it, but even without any of the other dependencies it'll use the autoconfig tools to allow a minimal build to be created:

pkcon install autotools
cd ffmpeg
./configure
make
make install
cd ..

ffmpeg is no small application, and compiling it on my phone took over an hour and a half. I know this because we watched an entire episode of Inspector Montalbano in the meantime, which get_iplayer helpfully tells me is 6000 seconds long!

Inspector Montalbano info from get_iplayer

Nonetheless, once completed the puzzle is complete, and get_iplayer will download and convert audio and video to formats that can be listened to or viewed on the Sailfish media player.

For me there's something beautiful about the ability to build, install and run these applications directly on the phone. get_iplayer is command-line, so lacks the polished GUIs of the official applications, but it's still very efficient and usable. I get that this makes me sound like Maddox, but that only makes me more right.

Three, my mobile carrier, insists I'm using tethering and cuts my connection whenever I try to download files using get_iplayer. It's annoying to say the least, but highlights the narrow gap between GNU/Linux on a laptop and GNU/Linux on a Sailfish OS phone.

Comment
26 Jul 2014 : New Special Jolla Covers #
There are now three new 3D printed cover designs available from the The Other Side pages for Jolla phones. There are two Celtic knot designs and one with studs that can be built on with LEGO ® bricks. Hopefully this will be just the start and there are more new designs in the pipeline!
Comment
12 Jul 2014 : New colours for 3D printed Jolla covers #
After some new deliveries from Shapeways, I'm pleased to now be making available three new colours in the The Other Side 3D printed Jolla cover range. There's yellow, orange and green to go alongside the other five colours that were already available.
Comment
18 Jun 2014 : Jolla The Other Halves #
After lots of preparation (and procrastination) I've finally managed to get things together so you can buy 3D prints of The Other Half back covers for Jolla phones from Shapeways. Check out the details on this page. Given the design is from Jolla and the printing is by Shapeways it really shouldn't have taken so long to get this sorted, but it's astonishing how much preparation was involved. That, and I had to wait for a sunny day before I could take the photos (doesn't happen often here in Liverpool!).
Comment
15 Jun 2014 : Seaworthy #
There's a growing quantity of material about Sailfish OS on the site, so after a bit of restructuring there's now a new Sailfish OS page to pull it all together into one place.
Comment
30 Mar 2014 : OpenVPN-Rig submitted #
OpenVPN-Rig is a small application for configuration and controlling an OpenVPN client connection from a Sailfish OS phone. I've just submitted it for QA to the Jolla Store. It's the first time I've submitted an app so this is all very new, but to be honest I'm not expecting it to get through. The app violates one of the store's requirements that it not need setuid permissions. Still you never know, and I thought I'd give it a try anyway. There's also now an OpenVPN-Rig page with some more info and screenshots.
Comment
23 Feb 2014 : Adventures with The Other Half #
It's fair to say this is a misleading title. As you'll discover if you take the trouble to read through (and now you've started, you'd be missing out if you didn't), this has nothing to do with either feats of derring-do or my wife Joanna.

No, this is to do with my Jolla phone. Back in the day, before smartphones were ubiquitous, many phone manufacturers tried to lure in the punters by offering interchangeable fascias or backplates. Not very subtle, or high-tech, but presumably effective.

Well, Jolla have decided to return to this, while taking the opportunity to update it for the 21st Century. Each Jolla smartphone appears to be built in two halves, split parallel to the screen and with the back half ("The Other Half") replaceable to provide not just different styles, but also additional functionality. The extra functionality is provided by cleverly using NFC-detection of different covers, along with the ability for covers to draw power from and communicate with the main phone via a selection of pins on the back.

At the moment there are only four official Other Halves that I'm aware of: Snow White (the one that comes as standard), Keira Black, Aloe and Poppy Red (the preorder-only cover). They use the NFC capability to change the styling of the phone theme as the cover is changed, but in the future there's a hope that new covers might provide things light wireless charging, solar charging, pull-out keyboard, etc.

For me, the interesting thing about the phone has always been the Sailfish OS that powers it. As anyone who's ever set eyes on me will attest, I've never been particularly fashion conscious, so the prospect of switching my phone cover to match my outfit has never offered much appeal. However, since the good sailors at Jolla have released a development kit for The Other Half, and since it seemed like an ideal challenge to test out the true potential of future manufacturing - by which I mean 3D printing - this was not an opportunity I could not miss.

Rather brilliantly, the development kit includes a 3D model which loads directly into Blender.

 

From there it's possible to export it in a suitable format for upload directly to the Shapeways site. The model is quite intricate, since it has various hooks and tabs to ensure it'll fit cleanly on to the back of the phone. Sadly this means that most of the usual materials offered by Shapeways are unavailable without making more edits to the model (sadly, it will take a bit more work before it can be printed in sterling silver or ceramic!). My attempt to print in polished Strong & Flexible failed, and eventually I had to go with Frosted Ultra Detail. Not a problem from a design perspective, but a bit more expensive.

The result was immaculate. All of the detail retained, a perfect fit on the phone and a curious transparent effect that allows the battery, sim and SD card to be seen through the plastic.

 

Although a perfect print, it wasn't a good look. Being able to see the innards of the phone is interesting in an industrial kind of way, but the contouring on the inside results in a fussy appearance.

The good news is that all of the undulations causing this really are on the inside. The outer face is slightly curved but otherwise smooth. The printing process results in a very slight wood-grain effect, which I wasn't anticipating, but in hindsight makes sense. The solution to all of this was therefore to sand the outside down and then add some colour.

 

The colour I chose was a pastel blue, or to give its full title according to the aerosol it came in, Tranquil Blue. Irrespective of the paint company's choice of name, the result was very pleasing, as you can see from the photos below. The 3D-printed surface isn't quite as nicely textured as the original Other Half cover that came with the phone, but I believe most people would be hard-pressed to identify it as a 3D-printed cover. It looks as good as you might expect from mass-produced commercial plasticware.

With the design coming straight from the developer kit, I can't claim to have made any real input to the process. And that's an amazing thing. Anyone can now generate their own 3D printed Other Half direct from Shapeways with just a few clicks (and some liberal unburdening of cash, of course!). A brand-new or updated design can be uploaded and tested out just as easily.

It's genuinely exciting to see how 3D printing can produce both practical and unique results. The next step will be to add in the NFC chip (it turns out they're very cheap and easy to source), so that the phone can identify when the cover is attached.

 

 

Comment
9 Feb 2014 : Jolla: Easy Wins #
This weekend I tried my hand at a bit of SailfishOS programming, and once again have been pleasantly surprised.

There's no shortage of places to get Apps from for a Jolla phone: the Jolla Store, the Yandex Store and the OpenRepos Warehouse being just a few. But even with this smörgåsbord of stores there are still obvious gaps. For example, I wanted to connect my phone through my home VPN, so that I can access things like SMB shares and ssh into my machines.

The iPhone has an OpenVPN client, but the frustrating file management on the iPhone meant I never got it up and running. Unsurprisingly Android has good OpenVPN support which combines well with the broad range of other good network tools for the platform.

In contrast the various SailfishOS stores are sadly bereft of OpenVPN solutions. However, a quick search using pkcon showed the command line openvpn client available in the Jolla repositories. I was astonished when, after a few commands to transfer the relevant client certificates and install the tool, it was able to connect to my VPN first time.

 

This is what I'm loving about SailfishOS. It speaks the same language as my other machines and runs the same software. Getting it to talk to my VPN server was really easy, even though you won't find this advertised in the headline features list.

Still, having a command line tool isn't the same as having a nicely integrated GUI App, so this seemed like a great opportunity to try out Jolla's Qt development tools. I've not done any Qt development in the past so started by working through the examples on the Sailfish site.

Qt seems to be a nice toolkit and it's set up well for the phone, but Qt Quick and QML in particular require a shift in approach compared to what I'm used to. Qt Quick obfuscates the boundary between the QML and C++ code. It's effective, but I find it a bit confusing.

 

Still, after a weekend of learning and coding, I've been able to knock together a simple but effective front-end for controlling OpenVPN connections from my phone.

As well as providing a simple fullscreen interface, you can also control the connection directly from the home screen using the clever SailfishOS multi-tasking cover gestures: pull the application thumbnail left or right to connect to or disconnect from the server.

 

What I think this demonstrates is how quick and easy it is to get a useful application up and running. The strength is the combination of the existing powerful Linux command line tools, and the ability to develop well-integrated SailfishOS user interfaces using Qt. I'm really pleased with the result given the relatively small amount of effort required.

If I get time, there's plenty more to be done. Currently the configuration runs directly from the openvpn script, but allowing this to be configured from the front-end would be an obvious and simple improvement. After this, mounting SMB shares will be next.

Comment

Download

  • Contrac Contrac
    Version 0.6.2 (16 Sep 2020) for SailfishOS.
    A (nearly) full reimplementation of Germany's Corona-Warn-App for Sailfish OS. It supports BLE beacon send/receive, diagnosis key upload/downlaod and exposure checking. More info...
    Download: binary, source, screenshot.
  • Scintillon Scintillon
    Version 0.30 (15 Sep 2019) for SailfishOS.
    Scintillon is a Philips Hue compatible smart home app that lets you control your Hue lighting using your Sailfish OS phone. Install the binary from the Jolla Store or OpenRepos. More info...
    Download: binary, source, screenshot.
  • GetiPlay GetiPlay
    Version 0.90 (14 Sep 2019) for SailfishOS.
    GetiPlay is a simple user interface for the get_iplayer command line utility for Sailfish OS devices. It allows TV and radio programmes to be downloaded from the BBC iPlayer listings.
    Download: binary, source, screenshot.
  • Pedalo Pedalo
    Version 0.21 (18 Jul 2018) for SailfishOS.
    Measures your relative pedalo performance with others in a privacy-preserving way. Although originally designed for waterways, it could be used just as well to measure your performance in other cycling situations, such as when riding a bike. Install the binary from the Jolla Store. More info...
    Download: source, screenshot.
  • ownNotes ownNotes
    Version 1.86 (22 Sep 2016) for SailfishOS.
    ownNotes is a note-taking application for Sailfish OS. It supports some basic markdown feature and notes can be syncronized with ownCloud or any other WebDav server. More info...
    Download: binary, source, screenshot.
  • OpenVPN-Rig OpenVPN-Rig
    Version 0.00 (30 Mar 2014) for SailfishOS.
    OpenVPN-Rig is an OpenVPN client configuration interface. It provides a simple interface for configuring your Sailfish OS phone and connecting as a client securely to an OpenVPN server. More info...
    Download: binary, source, screenshot.

Comments

Uncover Disqus comments