I wanted to write this blogpost since April, and even announced it in two previous posts, but never got to actually write it until now. And with the recent events in Snappy and Flatpak land, I can not defer this post any longer (unless I want to answer the same questions over and over on IRC ^^).

As you know, I develop the Limba 3rd-party software installer since 2014 (see this LWN article explaining the project better then I could do ) which is a spiritual successor to the Listaller project which was in development since roughly 2008. Limba got some competition by Flatpak and Snappy, so it’s natural to ask what the projects next steps will be.

Meeting with the competition

At last FOSDEM and at the GNOME Software sprint this year in April, I met with Alexander Larsson and we discussed the rather unfortunate situation we got into, with Flatpak and Limba being in competition.

Both Alex and I have been experimenting with 3rd-party app distribution for quite some time, with me working on Listaller and him working on Glick and Glick2. All these projects never went anywhere. Around the time when I started Limba, fixing design mistakes done with Listaller, Alex started a new attempt at software distribution, this time with sandboxing added to the mix and a new OSTree-based design of the software-distribution mechanism. It wasn’t at all clear that XdgApp, later to be renamed to Flatpak, would get huge backing by GNOME and later Red Hat, becoming a very promising candidate for a truly cross-distro software distribution system.

The main difference between Limba and Flatpak is that Limba allows modular runtimes, with things like the toolkit, helper libraries and programs being separate modules, which can be updated independently. Flatpak on the other hand, allows just one static runtime and enforces everything that is not in the runtime already to be bundled with the actual application. So, while a Limba bundle might depend on multiple individual other bundles, Flatpak bundles only have one fixed dependency on a runtime. Getting a compromise between those two concepts is not possible, and since the modular vs. static approach in Limba and Flatpak where fundamental, conscious design decisions, merging the projects was also not possible.

Alex and I had very productive discussions, and except for the modularity issue, we were pretty much on the same page in every other aspect regarding the sandboxing and app-distribution matters.

Sometimes stepping out of the way is the best way to achieve progress

So, what to do now? Obviously, I can continue to push Limba forward, but given all the other projects I maintain, this seems to be a waste of resources (Limba eats a lot of my spare time). Now with Flatpak and Snappy being available, I am basically competing with Canonical and Red Hat, who can make much more progress faster then I can do as a single developer. Also, Flatpaks bigger base of contributors compared to Limba is a clear sign which project the community favors more.

Furthermore, I started the Listaller and Limba projects to scratch an itch. When being new to Linux, it was very annoying to me to see some applications only being made available in compiled form for one distribution, and sometimes one that I didn’t use. Getting software was incredibly hard for me as a newbie, and using the package-manager was also unusual back then (no software center apps existed, only package lists). If you wanted to update one app, you usually needed to update your whole distribution, sometimes even to a development version or rolling-release channel, sacrificing stability.

So, if now this issue gets solved by someone else in a good way, there is no point in pushing my solution hard. I developed a tool to solve a problem, and it looks like another tool will fix that issue now before mine does, which is fine, because this longstanding problem will finally be solved. And that’s the thing I actually care most about.

I still think Limba is the superior solution for app distribution, but it is also the one that is most complex and requires additional work by upstream projects to use it properly. Which is something most projects don’t want, and that’s completely fine.

And that being said: I think Flatpak is a great project. Alex has much experience in this matter, and the design of Flatpak is sound. It solves many issues 3rd-party app development faces in a pretty elegant way, and I like it very much for that. Also the focus on sandboxing is great, although that part will need more time to become really useful. (Aside from that, working with Alexander is a pleasure, and he really cares about making Flatpak a truly cross-distributional, vendor independent project.)

Moving forward

So, what I will do now is not to stop Limba development completely, but keep it going as a research project. Maybe one can use Limba bundles to create Flatpak packages more easily. We also discussed having Flatpak launch applications installed by Limba, which would allow both systems to coexist and benefit from each other. Since Limba (unlike Listaller) was also explicitly designed for web-applications, and therefore has a slightly wider scope than Flatpak, this could make sense.

In any case though, I will invest much less time in the Limba project. This is good news for all the people out there using the Tanglu Linux distribution, AppStream-metadata-consuming services, PackageKit on Debian, etc. – those will receive more attention

An integral part of Limba is a web service called “LimbaHub” to accept new bundles, do QA on them and publish them in a public repository. I will likely rewrite it to be a service using Flatpak bundles, maybe even supporting Flatpak bundles and Limba bundles side-by-side (and if useful, maybe also support AppImageKit and Snappy). But this project is still on the drawing board.

Let’s see

P.S: If you come to Debconf in Cape Town, make sure to not miss my talks about AppStream and bundling

Switches are one of idea, which makes libgreattao amazing. It’s allows interface to morph. For example: we have question dialog with one button(abort) and we add to it ok and cancel. Libgreattao can automatically puts ok and cancel into select list and put exit as separate button. Another example is implementing view switching in file manager. File manager will deliver list of file name, properties and icons and libgreattao takes full advantage about select view and view it in iconview control or in properties list control.

Look at video:

Readers of this blog should be already a little bit familiar with the Ailao brand, which we use for spinning off and commercialization of our academic research. Originally, Ailao was all about text and question answering, but there was always the theme of dealing with unstructured data in general.

Nowadays, Ailao is not just me (Petr BaudiÅ¡) anymore – but a partnership with Tomáš Gogár and Tomáš Tunys, fellow PhD students! And we are widening our breadth to cover documents in general, developing a machine learning computational platform Ailao Brain (just a codename!) as well as working hard on some exciting end-user products. We are also working on a prettier website (including a new look for this blog) and many other things, but more on that soon.

What I wanted to point out is our talk at Machine Learning Meetups Prague. The talk itself (video) is in Czech, but you can enjoy at least our English slides on our bleeding edge technology research (webpage information extraction and text understanding). Stay tuned for more!

Git itself provides support for running hook scripts at many events. It would be nice to run some checks automatically, for example when creating a commit.

The problem is not how to run the checks but how to integrate them, make them fast and safe, provide a nice output, etc…

Overcommit

By chance I came across Overcommit, a nice framework for running Git hooks.

It provides a wide variety of predefined checks which are easy to use. I found some of them really useful:

• Forbid commits to blacklisted branches - e.g. you can forbid direct commits to master because you want to use Pull Requests. This can also avoid mistakes, e.g. once I did a typo in git checkout -b and overlooked that. The following commit and push went by mistake directly to master…

• Run Rubocop automatically to avoid fix up commits later. I see “make Rubocop happy” commits quite often in YaST.

• Run the tests locally before pushing the changes, that makes sure the tests still pass. Sometimes you forget to run the tests or simply you are too lazy to run them.

• And last but not least it can check spelling of the commit messages to avoid typos.

For more details see the Overcommit documentation.

Speed?

A very nice Overcommit feature is that it wants to be quick, your usual git workflow should not be slowed down because of the hooks.

For example it tries running all hooks in parallel and the Rubocop hook checks only the changed files, which speeds it up for large repositories a lot. Running Rubocop over all source files in the YaST registration module takes about 7 seconds on my machine, but when a single file is checked it takes just a fraction of a second.

Installation

I have prepared RPM packages with Overcommit, simply add the YaST:Head repository and run

zypper in "rubygem(overcommit)"

Initializing the Hooks

Now go to your Git repository and set up the hooks:

• Use overcommit --install to install the hooks.
• Add the .overcommit.yml configuration file.
• Run overcommit --sign to sign the current configuration. You will need to run it again whenever the config files is changed. See the Security section in the documentation for more details.

You need to install Overcommit in each Git repository separately, but it is possible to automate the setup.

Using the Hooks

Then you use the git commands as usually, you do not need to change anything to run the hooks. You will just see the results of the Overcommit hooks in the output.

If a hook fails the whole git command fails. So if for example the Rubocop hook fails when creating a commit then the commit is not created and you can fix the problem early.

If for some reason you want to temporarily disable the Overcommit checks run the git command with OVERCOMMIT_DISABLE=1 environment setting.

Example Configuration

Here is an example .overcommit.yml file proposed for YaST:

PreCommit:
  # do not commit directly to these branches, use Pull Requests!
  ForbiddenBranches:
    enabled: true
    branch_patterns:
      - master
      - openSUSE-*
      - SLE-10-*
      - Code-11*
      - SLE-12-*

  RuboCop:
    enabled: true
    # treat all warnings as failures
    on_warn: fail

CommitMsg:
  SpellCheck:
    enabled: true
    # force using the English dictionary
    env:
      LC_ALL: en_US.UTF-8

PrePush:
  RSpec:
    enabled: true
    command: [ "rake", "test:unit" ]
    # do not fail because of translations
    env:
      LC_ALL: en_US.UTF-8

Example Session

I recorded an example session to show the mentioned Overcommit features in action in the registration repository:

It looks nice, isn’t it? (If you like the git status in the bash prompt check this older post).

Conclusion

It looks very promising and it could catch some obvious mistakes early, I will give it a try. I will try using it for some time and then we will see if it could be used in YaST more widely.