Today I published a rather sombre Always Developing session to YouTube. In it I go over how far I've managed to get with my attempt to package Snippet Pixie as a Flatpak.

Creating a Snippet Pixie Flatpack for elementary OS 6 AppCenter: Part 6 | Always Developing #50

As you can tell from this post's title, and first sentence, it's not looking good for getting Snippet Pixie packaged up using Flatpak, and therefore it's unlikely to make it into elementary OS 6.0's AppCenter.

elementary OS 6 Odin Available Now

This is a shame as I really like elementary OS, and I especially like what the elementary project is trying to do to encourage Linux application development via a number of initiatives, including the AppCenter. And elementary OS 6 is fantastic, the amount of work that has gone into it is mind boggling, it is a truly beautiful release that all involved should be extremely proud of.

However, the new AppCenter requires curated applications to be provided as Flatpak packages, and unfortunately Snippet Pixie uses a couple of technologies that the Flatpak sandbox will not allow as they have the potential to be abused.

I've made no bones about the fact that I prefer Canonical's more flexible Snap package format over Flatpak, and very much wish elementary could have used Snap instead, but given their criteria I totally agree that Flatpak is the correct choice for the AppCenter.

elementary AppCenter + Flatpak

It's just unfortunate that Flatpak does not have the equivalent of Snap's "classic" confinement which allows for an application to be distributed as a Snap but does not impose a sandbox on it. Snap has this "classic" confinement (i.e. not confined) mode to enable certain classes of application to be distributed which Snap's current sandbox features can't yet support, or may never support. I guess that's one of the main strengths of Snap, because there is a single Snap Store managed by a trustworthy company (Canonical, makers of Ubuntu), they have the ability to vet an application that needs to break out of the sandbox to ensure it is safe. This is different to Flatpak which does not have a single source of packages (even though flathub is effectively the de-facto single source), and so the Flatpak project can't vet each package for trustworthiness. You could argue that each repository of Flatpaks should verify each new package and determine whether its permissions are appropriate, but the Flatpak project can't stop a nefarious repository from springing up that distributes compromised versions of apps. So I understand why the Flatpak project is reticent to allow various potentially dangerous sandbox permissions, or enable a non-sandboxed mode.

Therefore Snippet Pixie is very unlikely to make it into the elementary OS 6.0 AppCenter. It is however available via the Snap Store, and nixpkgs.

Snippet Pixie on the Snap Store

Snippet Pixie on Nix Packages

In the future I may explore other means of distributing Snippet Pixie. I haven't as yet tried packaging it as an AppImage, and given that up until elementary OS 6.0 the AppCenter has been using Debian packages, maybe I should investigate whether packaging for Debian is a goer too. 🤷️

I may also explore using different technologies for building Snippet Pixie seeing as I no longer have a strong incentive for using the technology stack that elementary promotes. There are some definite shortcomings in the way I built Snippet Pixie that I'd like to address now that I know better, maybe a Snippet Pixie 2.0 rewrite in a different language could be on the horizon? Having said that, the whole Vala + GTK + Granite thing is pretty sweet, there definitely could be a case made for just improving what's already there?

Subscribe to my Always Developing YouTube channel to find out what I do next with Snippet Pixie!

Always Developing on YouTube

The Always Developing podcast is dead, long live AlwaysDeveloping.show!

AlwaysDeveloping.show

As heavily hinted in my 4th goal for 2021, I've decided that the Always Developing podcast was not working out. So instead I am "live coding" on YouTube.

2021 Goals

I'll let the blurb from the about page explain what it's all about…

about page

Hello, my name is Ian M. Jones, and I'm always developing.

Before starting every work day, I do half an hour or so of noodling on side projects, making sure to keep them moving forward, albeit slowly.

Working on these side projects is how I learn new programming languages, frameworks and technologies.

Chances are I'll fail miserably each and every day, so at the very least you can take comfort in seeing a so-called senior developer fumbling through some development with little success.

Because live streaming sounds like an absolute nightmare for concentration, and the goal is to lean and keep progressing my side projects, it's recorded coding sessions. However, I am recording them "live" with OBS, and not editing them except for editing out any sensitive data (once so far), or should there be some sort of interruption (none yet 🎉️).

OBS

And true to the description on YouTube, there has already been plenty of opportunities to learn from my mistakes in the 10 episodes I've recorded so far (11 if you include the short follow-up episode 9.1).

10 episodes

episode 9.1

The idea of doing half an hour of development every day was inspired by one of Andreas Kling's Car talk episodes. In Car talk: My technique for discipline he was answering a question on how he is able to be so disciplined. His answer was basically that he's not disciplined, he just has a routine that works well for him. He also mentioned that even if you could do half an hour of something every day, it would add up nicely over a year.

Andreas Kling on YouTube

Car talk

Car talk: My technique for discipline

Given that I work approx 46 weeks in a year, that's 115 hours worth of half hours before work. That amounts to about 15 professional days for me (I do 7.5 hours per day). 3 weeks of pure coding days (which never ever happens in a real job) should produce something of worth, and at the very least I will learn a lot.

I'm doing the coding before work for a couple of reasons:

1. The first and most important is that it's easy for me to slot in half an hour as part of my pre-work routine, just after having breakfast while catching up on that there internet thing. If I tried to schedule something in the evening I would forever be skipping the session for some reason or another as evenings are much less structured for me. There's always the problem of motivation in the evenings too, YouTube isn't going to watch itself you know, someone's got to do it. 😜️

2. The second is that I have a daily 10am stand-up meeting with my team mate Erik which forces a hard stop, giving me a sense of time scarcity to concentrate my mind and reason to step away and come back with fresh eyes.

Erik Torsner

And so far it's worked out well. My very first attempt on April 1st 2021 didn't go so well though, and has been trashed. In that joke of a recording session I was trying to also code at my standing desk, which I never do, and it just didn't work at all. I struggled to use the keyboard properly, and what with trying to code and talk at the same time too, it was a fool's errand. I should have known given the date.

Since then I've been sitting at my desk, so am way more comfortable, and haven't been trying so hard to explain absolutely everything that's gong on. I haven't really properly introduced what I'm working on either, as each session needs to stand on it's own feet.

It's still very very early days and I've a lot to learn about live coding and recording etc, let alone learn all the development technologies I'm working with, but I'm enjoying it and making progress.

So head on over to YouTube and start watching me fumble my way through learning some stuff!

Always Developing on YouTube