I think many of you read the recent announcements and blog posts about “GNOME-Apps”, like this one. Initially I wanted to be at FOSDEM and attend the GNOME hackfest were this was discussed too, but university binds me here so I was unable to come (which is really unfortunate).
Some people asked me what the GNOME-App-Bundles mean for Listaller. The GNOME bundle proposal will make cross-distro application deployment for GNOME apps possible, and this essentially the same goal as the one of Listaller. So it is reasonable to question the future of Listaller when GNOME enforces their App Bundles (because most distros ship GNOME, most distros will have the app bundle support, which means people will use it because they can rely on it being present). Instead of answering the same questions again and again via private mail (remember, there is a new public Listaller mailinglist available, replacing the old Google Group) I’ll write this post.
In my opinion, there is no reason to worry about Listaller. I think the Listaller approach of app-directories and shared resources is much better than having app bundles mounted via FUSE. When Listaller was started, the Klik project already existed (Klik is dead now, Glick2 was developed by Alexander Larsson as replacement. Glick and Listaller nearly have the same age (I think Listaller might be older, when counting the first experiemnts…), so this is no case of “re-inventing” the wheel on both sides.). I initially wanted to contribute to Klik. However, FUSE-mounted app bundles have certain problems:
- No system integration: It is incredibly complicated to integrate the bundled apps with the system, e.g. if an application wants to register mimetypes.
- The way of “installing” app bundles is odd for most users, and having apps lying around in random directories is not really nice.
- App bundles can’t easily share resources. This means every app bundle has to provide all it’s dependencies again, while maybe another bundle already provides them (wastes lots of space).
- Auto-updating bundles is not possible (you simply have to re-download the new app version and replace the old bundle)
- Because every app provides it’s own dependencies, security updates provided by the distribution for a certain library won’t automatically be applied to bundled applications, which makes them a potential security risk.
- (The GNOME-Apps stuff is planned GNOME-only at time (nobody can blame anyone for that). A cross-desktop solution would be much better)
Listaller, on the contrary, integrates nicely with the system. Applications installed with Listaller will show up in every Software Center which uses PackageKit. The regular system updater is able to update Listaller applications as well as distribution components, and the Listaller dependency solver will always prefer distribution packages to satisfy dependencies, before falling back to other solutions. This tight platform integration is also one of the main reasons why Listaller is different from ZeroInstall (Listaller is also Linux-only, while ZeroInstall is not – both projects cover slightly different user-cases).
In order to have these advantages, Listaller requires all applications to be relocatable, while Glick2 does not require that (which is an advantage). But of course, Listaller provides a complete toolchain to make your application cross-distro-ready.
Apart from that, there are also some points the GNOME approach and Listaller have in common:
- Securing the system from potentially malicious 3rd-party apps: Listaller can be configured to run apps in a sandbox by default. For GNOME, a new sandbox with fine-grained permissions is being developed.
- Listaller gives apps only minimal rights to modify a setup process. Same applies to Glick2.
- Listaller and GNOME both want to define “frameworks” as dependency sets which applications should preferably use.
So, what do I plan for Listaller now? First of all, I will speak to the GNOME developers (already asked some questions, but no mailinglist post yet) and see their plans. Nothing is set in stone, and there are some things on the whiteboard which will be very useful for Listaller too. For example the new sandbox Greg-Kroah-Hartman and others plan to develop. I plan to use it as the one-and-only sandbox for Listaller apps, enabled be default.
Also, the plan is that GNOME apps should only depend on a certain “Framework” version, which the application bundles specify. The plans for a GNOME SDK & Framework are not exactly new, and I was expecting that. Same goes for KDE. Having apps only depend on a “Framework-Version” will simplify Listaller’s dependency solver and speed up installations. Work to support stuff like this has already been done some time ago (you could use “Framework: KDE-Platforms (==4)” as dependency, but the code for processing this is disabled, as certain stuff is still missing).
There are also some concrete plans for the next Listaller releases, which did not change at all: For the upcoming 0.5.7 release, we will provide automatic application and dependency updating. With the following 0.5.8 version, the API will be stabilized and the dependency solver will be updated (I will implement basic support for Python and advanced support for KDE libraries), so it becomes much more useful. The cross-distro software repositories will become reality. Also, I will write even more documentation. Then, the Listaller 0.6.x series will be started with increased API stability. The IPK specs are stable already and backwards-compatible, so it is safe to build packages. (post-0.5.7 is a great time to port your old Autopackage packages to Listaller!)
With regards to AppStream, the project will continue without any impact from whatever GNOME decides, since we need application-centric distribution software managing anyway. Solutions like Glick2 and Listaller only contribute 3rd-party-app installations as a new method for app deployment.
All projects around AppStream and Listaller are developing slowly, unfortunately, due to a great lack of manpower (in fact, I am the only one who pushes these projects and works on AppStream integration components, Listaller and PackageKit modules at time). However, all the hard bits are done. In March, when I have more time again, I will do some intense hacking on all components and make them work together nicely. There is also a blog series planned on how you can use Listaller as distributor/developer/user and how you can implement AppStream as software-center-developer/distributor (these will be smaller and easy-to-digest blogposts).
Also, I will continue work on Apper to support more AppStream features (Apper already provides extra Listaller and AppStream support already: Compile it with -DAPPSTREAM=ON -DLISTALLER=ON and see the magic happen. For AppStream, you need a distribution which supports AppStream, and have the AppStream-Core libraries installed. For Listaller, you need a working PackageKit>=0.8.x and – of course – Listaller). I will also work on GNOME-Software, which is planned to become a cross-distro software center for GNOME.
So, stay tuned – there will be some exciting news soon, when all the pieces are falling into place! And if you want to help, just contact me!
Hm… just tried your application links on the website. Unfortunately, the packagekit-plugin does not handle them, probably because the lack the correct Content-Type header.
That said, this project has some very interesting goals…
Thanks! Your description sounds like PackageKit did not load the plugin… You might see a line in packagekitd’s verbose output which tells you that it was skipped. The problem is that PK and Listaller are coupled tightly and that you need the right PK and the right Listaller version to make them work together. However, this problem will be solved soon, when Listaller releases are done frequently and the PK APIs are stable (already did work on that, since PK 0.8.6 + LI 0.5.7 the problems should be gone)
There are several other areas in Listaller which need work, but that will all be worked out soon 🙂
Thank you for your interest! And if you spot any bugs, feel free to report them!
How are you guys funded? You had mentioned you were under-staffed, so that’s why I’m curious.
I am currently taking CompSci (two years left) and really want to involve myself heavily in an open source project when I’m finished. I’m interested in this project and a few others… but of course I need to feed myself before I can take on an free jobs.
Is it lack of funding or lack of interest?
We (I) am not funded at all… All costs for servers etc. are paid by myself and code is written in my spare time. The PackageKit project has a few contributors who are backend by companies though.
In Listaller & AppStream there is a pretty high interest, but so far there haven’t been continous contributors. It is always hard for projects to get contributors.
Funding always speeds up things a lot if there are motivated people around. But for Listaller finding more developers is more important, and I hope this will happen when it gets more in focus. (Listaller has been a fringe project for a long time, where basically nothing awesome user-visible happened, because the software was rewritten in Vala and completely redesigned)
You can always work on any FLOSS project you want as long as you have spare time. Just start with submitting a patch and don’t give up too early if changes are rejected or wanted to be implemented differently. That is natural and happens all the time. (Best way to avoid this is to work in the public and if you would contribute bigger features talk to the project maintainer first)
Have fun!