Welcome to glick2, a application bundle system for linux
Glick2 is a runtime and a set of tools to create application bundles
for Linux. An application bundle is a single file that contains all
the data and files needed to run an application. The bundle can be run
without installation, or be installed by just putting the file in
a known directory (/usr/lib/bundles or ~/.local/bundles).
Glick2 has been designed to be used pervasively in a desktop OS, i.e.
almost all applications installed and running on the system is expected
to be bundles, and it would be the primary way software is shipped. I
explain some reasoning for this in this (slighly out of date)
blog entry.
There are several other bundle-like systems for linux, like
0install, Chakra,
PC-BSD PBI.
However, they are not ideally suited for an OS with pervasive
use of bundling.
Here are some of the properties that make Glick2 an especially good fit for this:
- Allows integration with the desktop: The linux desktop has a set of standard for how
applications interact with the desktop. We use desktop files to get apps into panel
menus, we have icon themes for app icons in multiple resolutions, we have standards
for mimetype database extensions, dbus services, gconf schemas, etc.
Glick2 supports this by allowing installed bundles to export files to a separate
directory structure which the desktop can pick up. Without something like this
app bundles will always be a second class citizen. Glick2 also has triggers that
runs scriptlets when exported files are updated in specific places which lets
us update various lookaside caches that are typically created in post install
script in linux packages.
- Share disk and ram for common files: Bundling means shipping all depencencies
in each application. This not only means larger files on disk, but also that we might
be reading the same data from disk multiple times and caching it in memory multiple
times.
Glick2 solves this by having all files inside a bundle indexed by a sha1 checksum, and
whenever two bundles share a file with the same checksum (or even two files in the same
bundle), these are automatically exposed as hardlinks in the glick filesystem. This mean
that we'll only read the data for this file from one place on the disk, and we will only
cache that data once in the kernel page cache.
- Robust support for non-relocatable apps: Many bundle system require applications to be
relocatable, but that isn't how linux apps typically work. Linux packages are built with a
specific prefix directory, and then assume at runtime thats where its data files are.
So, its easy to build packages with a different prefix, but once they are built its hard
to change that.
Glick uses some new kernel features like
mount
namespaces and shared subtrees to create
a static per-bundle-instance directory prefix. Just build your packages with --prefix=/opt/bundle,
and all the bundle files will magically appear there when its running.
- Atomic "safe" installation: A common problem with packaging systems or directory-based
bundle systems is that application upgrade/removal in unsafe. For instance, if you upgrade
firefox in a deb or rpm system it will replace all the data files that firefox loads at runtime,
and any running instance of firefox will fail in mysterious ways as its getting the newer
versions data files rather than the files it was expecting. Chrome goes to
extreme lengths
to avoid problems like this by using app-specific hacks.
Glick2 bundles are a single file, and once a bundle is running we access all the files that the
app needs via the opened file handle. So, if the bundle is replaced, or even removed, while it
is running, the running instance will keep seeing the old version of the files, and only if
you start the new bundle will the new instance see the new files.
Glick2 also has the traditional advantages shared by all bundling systems:
- Easy to install apps
- Apps keep working if the OS packages are upgraded, no sudden breaks due to some
library change.
- In fact, you can run the same bundle on older or newer OSes, meaning you can
keep running an older OS and then cherry pick new versions of apps without
having to upgrade the while OS to get the new dependencies.
- You can install multiple versions of the same application
- Bundling leads to an increased level of cross distribution compatibility.
Although, you're not bundling your own xserver and kernel, so at some point
there is a dependency on system installed things.
At the moment Glick2 is only a lowlevel implementation of the bundle runtime. A full OS design based
on bundles would also contain an automatic application installation and updates system. This is
mostly orthogonal to the bundle implementation, but certain details like the sha1 indexing of file
content in bundles does lend itself to a smarter incremental download of bundles.
At the moment there is just the glick-mkbundle tool, but for serious use some level of tooling would
have to be created to automate the building of bundles. Various approaches are possible, including using
existing packages from current distributions.
Bundling isn't perfect, there are some well known disadvantages. Increased disk footprint is one, although
current storage space size makes this not such a big issues. Another problem is with security (or bugfix)
updates in bundled libraries. With bundled libraries its much harder to upgrade a single library, as you
need to find and upgrade each app that uses it. Better tooling and upgrader support can lessen the impact
of this, but not completely eliminate it.
The code is availible in the glick2 git module in gnome git.
Alexander Larsson, alexl@redhat.com
gipoco.com
is neither affiliated with the authors of this page or responsible
for its contents. This is a safe-cache copy of the original web site.
gipoco.com
is neither affiliated with the authors of this page nor responsible
for its contents. This is a safe-cache copy of the original web site.