
A Quick Introduction to Flatpak - sjellis
http://apebox.org/wordpress/linux/1184
======
alex_duf
I hope flatpack becomes the de facto standard. It seems to solve problems the
right way.

Between that and wayland being ready for showtime, I think the future of linux
looks pretty good!

~~~
davexunit
Flatpak is yet another dependency bundling tool, and dependency bundling
always leads to unpatched security vulnerabilities for users.

~~~
curt15
Flatpak puts most of the common dependencies into cross-distro "runtimes". The
runtime maintainers would bear the responsibility for keeping the base system
patched.

~~~
davexunit
Trying to classify dependencies as "common" or "non-common" is a big design
mistake. It's an insufficient solution done because flatpak can't actually
capture the full dependency graph of an application. If it could, then common
dependencies would be implicit (shared nodes on the graph) and no bundling of
supposedly non-common components would be necessary. Examples of this problem
solved correctly are Nix and GNU Guix.

~~~
hexxington
The thing about dependency bundling is it's the only way to guarantee that the
app end users are running is the one your QA team tested against. Minor point
releases of seemingly innocent libraries can cripple an application with no
visible recourse. As an ISV, you want tight control over the end user
experience, and the only way you can achieve that is vigorous QA of _the exact
thing your users are running_ , top to bottom.

Banshee was badly hit by this, around the time it was under discussion as the
default music player in Ubuntu - an innocent SQLite point release completely
crippled the random button (30 second delays on next track, on a small
library). Bundling would have avoided it, the distro model is why end users
hit it. And anyone who's ever managed a Jenkins install knows minor point
release updates can completely fuck the world (since so few Jenkins addins are
subject to adequate CI)

I'm not new to the problem at hand, I've been packaging .NET apps on Linux for
a decade. But this is the reality of where we are, especially when distro
maintainers (quite reasonably) only want to ship one major version of any
given library at once, and you just can't make any assumptions about your base
system. Bundling means you can actually ship a _product_, and train your
support staff on a single configuration that everyone will experience.

~~~
davexunit
>The thing about dependency bundling is it's the only way to guarantee that
the app end users are running is the one your QA team tested against.

No, it isn't. See how Nix and GNU Guix solve this problem without resorting to
bundling. Shipping a single binary to _all_ systems is the use-case of
proprietary software. Free software just needs distros that are more capable,
that can handle multiple versions of the same dependencies, like Nix and Guix
do. Bundling may be convenient, but it's harmful to the users.

~~~
hexxington
Guix solves literally zero of the issues I have, including anything I
mentioned in my blog post. And you conveniently ignored the _real world
problems with trusting someone else 's dependencies_ I gave concrete examples
of in my parent comment.

C'mon, I _know_ bundling has issues, but it's like writing about the
comparative merits of two cars, and someone saying hippos are cool. It's a
non-sequitur. Wrapping up "configure && make && make install" in some Guile
doesn't make it a useful answer.

~~~
davexunit
>And you conveniently ignored the real world problems with trusting someone
else's dependencies I gave concrete examples of in my parent comment.

You can use whatever dependencies you'd like with Nix and Guix, that's a big
reason for them to exist in the first place. To attempt to translate into
Flatpak terms, the "common" runtime would be whatever part of the dependency
graph you share with the upstream package collection. Share as little or as
much as you'd like, you know the trade-offs.

>Wrapping up "configure && make && make install" in some Guile doesn't make it
a useful answer.

Now you're just being demeaning and dishonest. You could insult any package
manager by saying it's just a wrapper around make.

~~~
hexxington
> You can use whatever dependencies you'd like with Nix and Guix, that's a big
> reason for them to exist in the first place. To attempt to translate into
> Flatpak terms, the "common" runtime would be whatever part of the dependency
> graph you share with the upstream package collection. Share as little or as
> much as you'd like, you know the trade-offs.

If I can't rely on _specific versions_, I have gained nothing at all vs. using
.deb. API changes are a real issue. Shit really does just suddenly break.
Automake 1.11.2 arbitrarily removed something relied on mostly by GUI .NET
apps (and also GRUB) - how would I have been able to anticipate that if I have
no control over the build system being used during app installation? Changes
to default GCC flags have broken Mono's garbage collector in the past. How can
I be sure changes to the underlying libraries and toolchain _not provided by
me_ won't break my app's installation or use by my users? I can't. So now I'm
on a distro churn wheel, but where the target distro has almost no users, no
traction, no user acceptance, no institutional knowledge, and a crap first-run
UX that involves mangling bashrc.

Sorry, but it's just not up to scratch, and I would have scrubbed a project to
use Guix within a week.

~~~
davexunit
> If I can't rely on _specific versions_, I have gained nothing at all vs.
> using .deb.

You _can_ rely on specific versions of software build with specific
dependencies, each using specific configure flags, a specific build system,
etc. This is one of the major improvements over traditional system package
managers that Guix and Nix offer. Both package managers, like Flatpak, can be
used on top of any existing GNU/Linux distrubution, BTW, so you don't have to
use a distro that so greatly offends like you like the one I help develop.
You've drawn a whole lot of conclusions without knowing the facts and have
been pretty rude in the process.

------
Overtonwindow
Did anyone else click on this thinking it had something to do with Ikea?

~~~
jaclaz
Count me in. To further the shame, the apebox evoked something like sending
primates from one zoo to the other ...

------
sandGorgon
is flatpak going to stick to its focus around desktop software only? because
that was one ofnits original goals.

Snap on the other hand is actually shipping docker into production.

~~~
ealexhudson
Are you confusing Snaps/snappy
([http://snapcraft.io/docs/core/](http://snapcraft.io/docs/core/)) with
[https://snap-ci.com/](https://snap-ci.com/) ?

Ubuntu's snappy is the obviously snap-named flatpak competitor, and it doesn't
appear to me to do an awful lot with Docker?

~~~
evand
Docker is available as a snap: [https://www.docker.com/docker-news-and-
press/docker-and-cano...](https://www.docker.com/docker-news-and-press/docker-
and-canonical-partner-cs-docker-engine-millions-ubuntu-users)

