ostree & Flatpak at CERN

A week and a half ago I spent a few days in Geneva and gave a presentation about ostree and Flatpak at the CERN Computing Seminar. I started by briefly introducing Endless to give some context of the problems we’re trying to solve and how we’re using ostree and Flatpak for that, then proceeded to talk more in detail about these technologies. In the end, there were several questions, and I was happy to learn afterwards that among the audience there were some of the people working at the CVMFS project: a software distribution service to help deploy data-processing infrastructure and tools. I don’t know the full details about the project’s implementation, but from the problems they’re trying to solve it seems like ostree (or more specifically libostree) could perhaps be used to replace part of the core, which would leverage all the niceties of using a complex Open Source project (more eyeballs looking into bugs, more testing, etc.). I also think more use-cases could be found in the organization, so I hope my talk was a small seed to help introduce these projects at CERN in the medium/long term. The presentation has been recorded if you’re interested.

Getting authorization to access CERN this time was also different, as for the first time I got an entrance pass as a member of the CERN Alumni. So I would like to thank Antonella Del Rosso for the Alumni initiative and also for allowing me to kindly borrow her EU-CH power adapter when I forgot mine at my friends’ home. In the end Antonella also interviewed me about my experience at CERN and after I left, and produced this summary if you want to check it out.
I would also like to thank Miguel Ángel Marquina of the CERN Computing Seminar for organizing the presentation and all the details around it.

Photo showing the author and his daughter sitting close to the lake in Geneva.

Sitting by the lake with my daughter

Having spent more than 2 years in the region, it is the friends we have there that we miss the most. So it was great to meet them and old colleagues again.
My family traveled there with me and we stayed with friends from Spain, so it was funny to see our daughter (who used to play with those friends’ kids all the time when we lived there) excusing her shyness for not speaking Spanish. But after a day or two they were all successfully playing together; it’s amazing how children can get along no matter what differences or barriers they find, while adults often resort to stupid feelings and dangerous actions.
The mountains landscape is another thing we miss in Berlin and the Spring’s clear weather allowed us to fully gaze at the Jura or the Mont Blanc which should last us for another few more months. After that, I guess I’ll try to find some graffiti of mountains around Berlin 🙂

Updates on the Endless App Center / GNOME Software

The great majority of my work at Endless is to (try to) tame GNOME Software and apply the changes that make it what we simply call “the App Center” (repo here) in the Endless OS.
This is a lot of work and usually I’d love to share more often what I am doing but end up neglecting the blog due to the lack of time. So here’s a summary of what I have done the past few months.

New App Tiles

From the times where it was called the App Store (and not based on GNOME Software like know), the Endless OS’s App Center used to have what we called internally as “app thumbnails”. These were images carefully produced for each app that Endless distributed, that worked as a way to provide some visual hint and attractiveness that is many times not achieved by the apps’ own icons. Here’s a screenshot of that version:

Old version of App Center in the Endless OS: displays colorful images in squares representing the apps available

Old version of the App Center


There was a couple of problems with “app thumbnails” like that: 1) we started shipping Flathub as a remote by default, and it’s simply not scalable to go and create an image for every app that is available in the repository; and 2) even if visually appealing, the app tiles make it a bit difficult to correctly display text on them, and depending on how apps appear next to each other, it can become visually quite bloated.

Thus the solution we came up with for the 2nd problem was to give dim a little bit the effect that the thumbnails have by placing a translucid layer on top of them, and to have a dedicated area for textual information. This means we still use app thumbnails for the apps that have it, but they will all seem a bit less intense and more alike.
That still leaves us with the first problem of not having thumbnails for most apps. For fixing that we create a background from the main colors presented in the app’s logo. The background is composed of 4 gradients, each with one of the icon’s main colors. Using the logos’ colors ensures there’s some harmony between the logos and their backgrounds, and I am very happy with the result:

Generated backgrounds for apps: shows squares where the background is a mix of gradients with colors picked from the app's icon

Automatically generated backgrounds for apps

Combination of app tiles that have a thumbnail image, and some that have automatically generated backgournds

Updates from USB and LAN

As you know, Endless’ mission is to give access to computers (and all that comes with them: knowledge, entertainment, productivity) to those who are often in remote areas, with very weak or innexistent connectivity. Maybe you’ve already heard that at Endless we’re developing an “asynchronous internet” and optimize the use of the little data connectivity some of our users have. So it’s only logical that we can give the possibility for users to share the data among themselves without an internet connection. To do that, we (more specifically Philip Withnall, kudos to him!) have implemented a way in ostree for local repositories to be found, particularly, repositories in removable drives (e.g. USB keys) and LAN. This means that e.g. a teacher’s computer in a class room can download app updates from the interwebs and the sudents’ computers will just get the updates through LAN (without the need for an external connection). In the case of the USB, as you probably guessed, a user can just set up a repository in a USB, and share the drive with friends.
For the USB case, in which the number of apps available may differ a lot from the user machine’s catalog, we need to show which of those apps are available, so when inserting the USB drive in the machine, the App Center should just pop up and show a new category “USB” with the apps that are contained in it. See the following screenshot:

App Center showing the one app in an inserted USB  key, as a category

App Center showing the one app in an inserted USB key

Performance Constraints

One of our constant concerns is that our OS and apps run smoothly even on less powerful machines, since it’s what many of our users have. GNOME Software spawns a thread for every main operation that the user does, like installing or updating an app, and we’ve noticed that when a few of these operations are running in parallel, some machines will just freeze. Moreover, downloading a bunch of data in parallel may easily occupy the whole bandwidth without actually completing any of the downloads.
One can think of a lot of smart approaches for dealing with this, but for now we just implemented a restriction on the number of operations that can be run in parallel. This was implemented together with upstream and the number of possible operations in parallel is one per GB of RAM. You may argue this is good a heuristic as any other, but it gives a low number of operations for slower machines, while still allowing powerful machines to have multiple parallel operations.
For the Endless OS we just opted to limit this number to 1, but may revisit it later. Google Play also performs just one update/install at a time, so this is not such a crazy thing.

We need also to inform the user that an app is waiting for it’s turn to install/update, so in such cases an empty progress bar with a message is shown:

An app waiting for its turn to be updated: has an empty progress bar with the message "Pending update..." on top.

An app waiting for its turn to be updated

For consistency, we’ve changed also how we showed the “queued-for-install” state (a state that happens when the user clicks install and there’s no internet connection), to be consistent with the UI shown above.

Auto Updates

Another push we’re taking together with upstream is auto-updates. GNOME Software has had something similar to auto-updates for a while, though it was more like auto-downloads. This was heavily based on the fact that it’s not very safe to just go and install new versions of packages right away (apps may be running… ). So it’s up to the user to choose when to (reboot and) install those.
Flatpak though, has no such problems. Apps can be updated even while running, as the way the new update replaces an existing version happens atomically, without touching the running app’s files.

So the ideal thing to do for Flatpak is to have real auto-updates (that is, download and deploy them right away). But since GNOME Software still has to support other sorts of app distribution, it required a bit of creativity when designing the new UI for this, which Allan Day kindly did, and very patiently with me and all my opinionated views of it 🙂

I have implemented auto-updates downstream first, without some of the niceties of the new mockups, since we needed them for our very-soo-to-come new version. But the idea is to do the real implementation upstream soon.
Surely enough, even when turned on, auto-updates only happen when on unmetered connections currently; and Philip Withnall is working on a creative solution for metered connections (soon to be announced).

Misc Fixes

This post is long enough so it’s not really sensible to enumerate all the fixes done in the last months. So I will just mention that recently we have fixed important issues (upstream as well) like installing new runtimes’ extensions when an app update needs them; cancelling auto updates/downloads when their running and the connection is switched to a metered one; setting an app as updatable if one of its runtime extensions has an update (otherwise it was not possible to install those extensions), etc.

If you’re still reading this, thank you! But especially thanks to Richard and Allan for their patience and leadership upstream!
Hope you liked this. I will try to keep the updates more frequent!

Attending FOSDEM 2018

On Friday I will attend FOSDEM 2018 after having missing last year’s (but I had a good excuse).

It’s pretty sad that there’s no longer a Desktop devroom, but there is still plenty of other interesting topics to follow.

Thanks to my company Endless for making my attendance easier, and if you’re willing to know more about the problems we’re solving just reach out, as FOSDEM is the perfect place for that!

FOSDEM

Have a great 2018!

I have spent most of December with my family in Portugal and, as it’s becoming tradition, Helena and I (and the kids) are spending the New Year’s eve alone at our place. It gets more and more difficult to say good bye to our family every time we need to come back, especially now that Olivia really enjoys being there and spending time with the grandparents. But I come back with my batteries charged, ready for the coming year.

This year, similar to 2014, will be one that we will never forget because of the birth of our second child, Gil. Gil is a force of Nature! So different from the quiet baby that Olivia was; he always has energy and is (almost) always smiling. But even though we are usually very tired, it’s also much more interesting that they are different like that.
Life is certainly more challenging with two babies than with one, it’s not a linear relation of “2 × kid = 2 × work”, but having a flexible schedule, an understanding manager, and an awesome wife, allows me to manage.

To add more challenges to our personal life, we have also moved to a new place (still in Berlin) this year. The move was already going to be tricky since we did it ourselves instead of hiring a company, but it became boss-like when I got injured in my leg (tore muscle) while playing squash 4 days before we rented a truck and were supposed to carry all big items in it. But that’s gone, and we love our new place!

Even if it was a good year for me personally, in terms of global events, 2017 seemed pretty much the continuation of the shitty ending of 2016. That feeling of “end of the world” was still present all over the news and general day to day talk. In Portugal, the 3rd safest country in the world, more than 100 people were killed by wildfires, and the year has had a dangerous drought, to the point of having to distribute water by train/trucks to some cities… But sure, it’s chilly in some places so global warming must be just a hoax
Luckily the 2017’s big elections in Europe (France, the Netherlands, and Germany), which could set the Union on fire, proved that people can still choose the better route for their lives, despite all the attempts of scaring them off. The current situation in the EU is still alarming but at least it held better than I thought it would.

Workwise, it’s been another very busy year at Endless. I am still in charge of the App Center (our GNOME Software fork) and doing what I can to tame this beast. Endless’ mission has always been a noble one, but with the current direction of the world it’s even more significant and needed; so I will continue to give my best and hope we can keep making a difference in less fortunate regions. If you want to help, check out our job openings.

I really hope 2018 is a great year, with more hope than the past few years. So everybody reading this, have a great 2018!

Paying for FOSS apps

tl;dr: TrinkGeld is a proposal for a GNOME project (but should be usable in most free desktops out there) that uses monthly donations and distributes them to app developers based on how much their apps are used, together with a Humble Bundle style customization options.

There’s been an ongoing topic in the GNOME community about how developers can get some money for their apps. From a fixed price to pay-what-you-want or donations, getting people to pay for software as end users is not easy. This is true even if you’re selling software through a mainstream platform like Google Play or the Apple Appstore, let alone if you’re a Free Software developer and you are relying on donations from your users.

Even if you’re willing to donate a couple of euros for supporting an app you’re about to install, you’ll have to go through the trouble of finding out how to make the donation. This may involve: 1) going to the app developer’s website; 2) finding out whether they accept donations; 3) hope they receive donations through a service you already use (PayPal, bank transfer, Bitcoin, etc.) and perform the donation.
During GUADEC, Richard Hughes organized a discussion around the problems of getting donations through GNOME Software. And now the GNOME app center has a “donate” button for apps that declare a donation link.
So that donation button solves most of the steps I enumerated above, however it still requires that users pursue that option, which will simply take them to the app’s donations page. If a user eagerly installs an app and uses it for a while, they will have to remember to make a donation later on if they want to support the app monetarily.

Spot the donation button at the bottom of an app's details page in GNOME Software.

Spot the donation button at the bottom of an app’s details page in GNOME Software.

There are of course other approaches for getting people to pay for apps, like the one that Elementary uses: showing a price for an app but allowing the user to modify that price including offering 0 (meaning you get it for free). While this seems like a good way to allow people to pay what they will, the downside is that many users find it deceptive when all indications are that you have to pay for an app; it’ll scare off users who think they have to pay for those apps; and it’s still a step to be done before getting the app (before you know whether you’ll even use it for more than 5 minutes…).

A (not so) new model

So, if having to pay before installing an app is not ideal (and not really a donation!), and post-installation donations are tend to be forgotten and thus minimal, what else can we do?

Subscription based services like Spotify and Netflix are extremely successful these days. Some people may think that’s simply because of their large catalog (access to “all” songs for only 9.99 EUR a month? a bargain!), but I dare argue that a lot of their success is due to people’s lazyness. Why are those platforms successful when there was/is so much “piracy” out there? Either a good percentage of the people who downloaded content illegally suddenly started caring about increasing Hollywood’s profits, or they just feel like they’re now being offered a very convenient service for a reasonable monthly price (besides being completely legal of course)! Set up the monthly payment and off you go!

I think that a subscription based donation model for apps in the Linux desktop is something that could work. I think that a good number of people are willing to give some money for the apps they use, but they’re too busy to remember to do it regularly. In this subscription model, users wouldn’t pay for installing apps, they would donate money for the apps they use instead.

TrinkGeld

I am very bad at naming stuff but it’s good to have a way to refer to this project easily, and I think I got a good one for it: TrinkGeld! “Trinkgeld” is a German word that means “tip money” but as you may have guessed it comes from the words that translate as drink+money. I think it sounds great! It’s easy to write and pronounce, and associates with the concept of paying a developer a drink, which I like.

Here is the base concept of Trinkgeld: it is a desktop application where you sign up and choose a monthly amount you think the software you use is worth (and that you can afford, of course). Trinkgeld then tracks the applications you use on your system (which ones were installed and, more importantly, how much they were used), and at the end of the month your donation amount is divided according to how much each app has been used, and finally the divided amount is sent to its respective app’s developer. Think of it as Flattr + Spotify (+ Humble Indie Bundle… just keep reading).

I think this concept has many advantages: users won’t have to pay upfront for an app they don’t know they’ll use or not. Nor will they have to remember to go to an app’s page in the app center in order to donate some money. It’s affordable for users because they set up how much they can give out. It’s fair for app developers because they will keep getting paid as long as users keep using their apps.

An oversimplified diagram of how TrinkGeld operates is something like the following:

TrinkGeld diagram

Money flow

There are two approaches towards distributing the money: 1) send it directly to the app developers using some service’s API; or 2) use a “middle-actor”.
While #1 is tempting, it has some downsides: it’s technically much more challenging to schedule a bunch of payments to different accounts and systems; we’d have to offer ways for users to correct the donations if there’s a mistake/bug when sending out the money; usually smaller individual payments end up paying a higher percentage as a service fee; and maybe users can get in trouble with the law if they end up giving out money to some person or organization that they shouldn’t (I can think of sanctioned countries, dubious organizations, etc.).

I actually prefer approach #2 where the money would be donated as the pre-selected monthly sum to some entity that would be in charge of distributing it according to the report sent from TrinkGeld.
I can imagine this middle-actor being e.g. the GNOME Foundation, or distros. Let’s take the GNOME Foundation for this example. We’d select say 20 EUR monthly for TrinkGeld, the money would be sent out to the GNOME Foundation (say using PayPal for example), and the Foundation would also get the monthly reports from TrinkGeld. Then, it would distribute the money among the apps’ authors (that had registered as part of the GNOME Foundation’s TrinkGeld partners). The money could be sent out from the Foundation only when it reached a certain amount (common in other app distribution platforms) in order to minimize fees.
The GNOME Foundation would rightfully take a percentage of the monthly amount for covering the work Trinkgeld involves but also because of its role (in the example of using GNOME as your desktop, then surely supporting the GNOME Foundation is a good thing).
This means we could have more options of payment services between the middle-actor and the app developers since we’d not have to tie it to the users directly anymore. And users would also be safe as they only have to make sure they are eligible to donate to the middle-actor (GNOME Foundation/Fedora/Ubuntu/etc.).

As for the exact way the money is to be divided, it’s something that needs to be discussed as there are many ways we can do that: should we just simply divide the money according to how much an app is used? Should we always have a minimum for an newly installed app, even if it’s been used just for 10 minutes in the whole month? etc.
How the money is divided is not the main discussion to be held at this point.

Having a middle-actor also means that TrinkGeld should have a server part where it gets the information from users and organizes it for the distributor. This increases the complexity of the project but as I think it’s still less complex than what the approach #1 above implies.

Tracking Apps

I know some of you will have already frowned when you read about “tracking” apps. Yes, the apps you use and how much you use them is your own private information, but we can make Trinkgeld do its job and still respect everyone’s privacy. The obvious solution for that is to anonymize the data by doing the tracking and calculation in the client, and only send out the amount per app. It’s one thing to send out info like “Tor usage avg: 80 hours”, it’s another thing to send out, “Donation for Tor: 5 EUR”. How much information one could actually deduct from the amount given will depend on the way it’s divided + the customization options we give to users (see next section), but it shouldn’t be that easy.
It will also be important to understand who gets to see this information (do you trust Fedora to see this information?), and of course users should be able to tell Trinkgeld not to consider a certain app…

Besides, users should trust the money distribution partner, or middle-actor mentioned in the section above: i.e. if you are using a distro and you don’t trust the organization behind it, then maybe find another Trinkgeld provider (and/or switch to a new distro!), or maybe this service is not for you.

As for the technical solution for tracking the apps, I don’t know of any cross-desktop library capable of offering this functionality out of the box, but at least in GNOME Shell there’s already code in place that we can extend to implement whatever functionality TrinkGeld needs. I am sure other desktops could do something like this too.

Humble Indie Bundle style tweaks

The Humble (Indie) Bundle is a genius idea! I usually buy bundles that have games for Linux, and it’s awesome to be able to choose how much money each game gets (so I can make sure I pay more for the games I will play then for others), as well as giving something for charity.
A good complement to the TrinkGeld system would be to offer some choices of how the money is distributed. I imagine that the TrinGeld desktop app could pop up once per month showing the calculated division of the donation and options to tweak it. Say you realize that you’re always giving most of your money to one single app (I expect this to happen for web browsers for example), then you could tweak how much that app gets, and choose other apps to donate to because you find it to be more fair that way. Or you could choose organizations related to the software you use, much in the way that Humble allows you to donate to charity: e.g. if TrinkGeld is being run by Fedora, it could still offer the GNOME Foundation as one of these organizations, considering its role in the technology that powers the user’s desktop + apps. Here’s a mockup of what I imagine it would look like (we’ll need real designer work if TrinkGeld goes from idea to code, but for now you’re stuck with this):

TrinkGeld mockup

As you see, there are lots of possibilities here, but this post is getting large so let’s leave it for a later discussion.

Opinions?

Usually I blog more about stuff I’ve done than ideas that may never happen but TrinkGeld has been in my mind for a while, so I really wanted to share it and ask what Linux desktop users out there think of it. I know it’s a challenging project to set up, and that a lawyer may have to look into it, but it could may be worth the try.
I’m really curious to know what Linux desktop users think about this. Do you think it could help getting more people to donate? Would you use it? (comments in this blog are moderated so you may want to use the social network where you found this post mentioned in order to comment on it if you don’t want to wait until I approve the comments, thank you for understanding)